Как повысить производительность конвейера RAG
С ростом популярности приложений Retrieval Augmented Generation(RAG) все чаще возникает вопрос о повышении их производительности. В этой статье представлены все возможные способы оптимизации конвейеров RAG и приведены соответствующие иллюстрации, которые помогут вам быстро понять основные стратегии оптимизации RAG.
Важно отметить, что мы лишь в общих чертах рассмотрим эти стратегии и методы, сосредоточившись на том, как они интегрируются в систему RAG. Однако мы не будем углубляться в сложные детали или проводить вас через пошаговое внедрение.
Стандартный конвейер RAG
На схеме ниже показан самый простой стандартный конвейер RAG. Сначала фрагменты документов загружаются в векторное хранилище (например, в облако Milvus или Zilliz). Затем из векторного хранилища извлекается Top-K наиболее релевантных фрагментов, связанных с запросом. Эти релевантные фрагменты затем вводятся в контекстную подсказку LLM, и, наконец, LLM возвращает окончательный ответ.
Различные типы техник улучшения RAG
Мы можем классифицировать различные подходы к улучшению RAG в зависимости от их роли на этапах конвейера RAG.
- Улучшение запросов: Модификация и манипулирование процессом запроса на входе RAG для лучшего выражения или обработки намерения запроса.
- Улучшение индексирования: Оптимизация создания индексов с кусками с помощью таких методов, как многокусковое индексирование, пошаговое индексирование или многоходовое индексирование.
- Улучшение ретривера: Применение методов и стратегий оптимизации в процессе поиска.
- Усовершенствование генератора: Корректировка и оптимизация подсказок при сборке подсказок для LLM с целью получения более качественных ответов.
- Улучшение конвейера RAG: Динамическое переключение процессов в рамках всего конвейера RAG, включая использование агентов или инструментов для оптимизации ключевых этапов конвейера RAG.
Далее мы представим конкретные методы в каждой из этих категорий.
Улучшение запросов
Давайте рассмотрим четыре эффективных метода улучшения работы с запросами: Гипотетические вопросы, вкрапления гипотетических документов, подзапросы и пошаговые подсказки.
Создание гипотетических вопросов
Создание гипотетических вопросов подразумевает использование LLM для генерации множества вопросов, которые пользователи могут задать по поводу содержимого каждого блока документов. Прежде чем реальный запрос пользователя дойдет до LLM, векторное хранилище извлекает наиболее релевантные гипотетические вопросы, связанные с реальным запросом, вместе с соответствующими фрагментами документов и направляет их в LLM.
Эта методология позволяет обойти проблему междоменной асимметрии в процессе векторного поиска, напрямую участвуя в поиске между запросами, что облегчает нагрузку на векторный поиск. Однако это влечет за собой дополнительные накладные расходы и неопределенность при генерации гипотетических вопросов.
HyDE (Hypothetical Document Embeddings)
HyDE расшифровывается как Hypothetical Document Embeddings. Он использует LLM для создания "гипотетического документа" или фальшивого ответа в ответ на запрос пользователя, лишенного контекстной информации. Затем этот фальшивый ответ преобразуется в векторные вкрапления и используется для запроса наиболее релевантных фрагментов документов в векторной базе данных. Затем векторная база данных извлекает Top-K наиболее релевантных фрагментов документов и передает их в LLM и исходный запрос пользователя для создания окончательного ответа.
Этот метод похож на метод гипотетического вопроса в решении проблемы междоменной асимметрии в векторном поиске. Однако у него есть и недостатки, такие как дополнительные вычислительные затраты и неопределенность при генерации фальшивых ответов.
Более подробную информацию можно найти в статье HyDE.
Создание подзапросов
Когда пользовательский запрос слишком сложен, мы можем использовать LLM для разбиения его на более простые подзапросы перед передачей их в векторную базу данных и LLM. Давайте рассмотрим пример.
Представьте, что пользователь спрашивает: "Чем отличаются функции Milvus и Zilliz Cloud?" Этот вопрос довольно сложный и может не иметь прямого ответа в нашей базе знаний. Чтобы решить эту проблему, мы можем разделить его на два более простых подзапроса:
- Подзапрос 1: "Каковы особенности Milvus?"
- Подзапрос 2: "Каковы особенности Zilliz Cloud?".
Получив эти подзапросы, мы отправляем их в векторную базу данных после преобразования в векторные вкрапления. Затем векторная база данных находит фрагменты документов Top-K, наиболее релевантные каждому подзапросу. Наконец, LLM использует эту информацию для генерации лучшего ответа.
Разбив запрос пользователя на подзапросы, мы облегчаем нашей системе поиск релевантной информации и предоставление точных ответов даже на сложные вопросы.
Создание пошаговых подсказок
Еще один способ упростить сложные пользовательские запросы - создать пошаговые подсказки. Эта техника предполагает абстрагирование сложных запросов пользователя в "пошаговые вопросы"** с помощью LLM. Затем векторная база данных использует эти пошаговые вопросы для извлечения наиболее релевантных фрагментов документов. И наконец, LLM генерирует более точный ответ на основе этих полученных фрагментов документов.
Проиллюстрируем эту технику на примере. Рассмотрим следующий запрос, который является довольно сложным и не простым для прямого ответа:
Исходный запрос пользователя: "У меня есть набор данных с 10 миллиардами записей, и я хочу хранить его в Milvus для запросов. Возможно ли это?"
Чтобы упростить этот пользовательский запрос, мы можем использовать LLM для генерации более простого пошагового вопроса:
Stepback Question: "Каков предельный размер набора данных, с которым может работать Milvus?".
Этот метод может помочь нам получить более точные ответы на сложные запросы. Он разбивает исходный вопрос на более простые формы, облегчая нашей системе поиск релевантной информации и предоставление точных ответов.
Улучшение индексации
Улучшение индексации - еще одна стратегия повышения производительности приложений RAG. Давайте рассмотрим три метода улучшения индексации.
Автоматическое объединение фрагментов документов
При построении индекса мы можем использовать два уровня детализации: дочерние и соответствующие им родительские блоки. Сначала мы ищем дочерние блоки на более тонком уровне детализации. Затем мы применяем стратегию слияния: если определенное количество, n, дочерних чанков из первых k дочерних чанков принадлежат одному и тому же родительскому чанку, мы предоставляем этот родительский чанк в LLM в качестве контекстной информации.
Эта методология была реализована в LlamaIndex.
Построение иерархических индексов
При создании индексов для документов мы можем создать двухуровневый индекс: один для резюме документов, другой - для их фрагментов. Процесс векторного поиска состоит из двух этапов: сначала мы фильтруем релевантные документы на основе резюме, а затем извлекаем соответствующие фрагменты документов исключительно из этих релевантных документов.
Этот подход оказывается полезным в ситуациях с большими объемами данных или в случаях, когда данные иерархичны, например, при поиске контента в библиотечной коллекции.
Гибридный поиск и реранжирование
Метод гибридного поиска и реранжирования объединяет один или несколько дополнительных методов поиска с поиском по векторному сходству. Затем реранжировщик ранжирует полученные результаты на основе их релевантности запросу пользователя.
К распространенным алгоритмам дополнительного поиска относятся методы, основанные на лексической частоте, например BM25, или большие модели, использующие разреженные вкрапления, например Splade. Алгоритмы повторного ранжирования включают RRF или более сложные модели, такие как Cross-Encoder, которые напоминают BERT-подобные архитектуры.
Этот подход использует различные методы поиска для улучшения качества поиска и устранения потенциальных пробелов в векторном отзыве.
Усовершенствование ретривера
Усовершенствование компонента ретривера в системе RAG также может улучшить работу приложений RAG. Давайте рассмотрим некоторые эффективные методы улучшения ретривера.
Поиск в окне предложения
В базовой системе RAG фрагмент документа, передаваемый LLM, представляет собой более крупное окно, охватывающее извлеченный фрагмент вставки. Это гарантирует, что информация, предоставляемая LLM, включает в себя более широкий спектр контекстных деталей, минимизируя потерю информации. Техника Sentence Window Retrieval позволяет отделить фрагмент документа, используемый для поиска вкраплений, от фрагмента, предоставляемого LLM.
Однако увеличение размера окна может привести к появлению дополнительной мешающей информации. Мы можем регулировать размер расширения окна в зависимости от конкретных потребностей бизнеса.
Фильтрация метаданных
Чтобы обеспечить более точные ответы, мы можем уточнить полученные документы, отфильтровав метаданные, такие как время и категория, перед передачей их в LLM. Например, если получены финансовые отчеты за несколько лет, фильтрация по нужному году позволит уточнить информацию в соответствии с конкретными требованиями. Этот метод эффективен в ситуациях с обширными данными и подробными метаданными, например при поиске контента в библиотечных фондах.
Расширение возможностей генератора
Давайте рассмотрим другие методы оптимизации RAG, улучшив генератор в системе RAG.
Сжатие запроса LLM
Шумовая информация в извлеченных фрагментах документов может существенно повлиять на точность окончательного ответа RAG. Ограниченное окно подсказки в LLM также является препятствием для получения более точных ответов. Чтобы решить эту проблему, мы можем сжать нерелевантные детали, подчеркнуть ключевые абзацы и уменьшить общую длину контекста в найденных фрагментах документов.
Этот подход похож на рассмотренный ранее гибридный метод поиска и реранжирования, в котором реранжировщик используется для отсеивания нерелевантных фрагментов документов.
Корректировка порядка расположения фрагментов в подсказке
В статье "Lost in the middle" исследователи заметили, что LLM часто не обращают внимания на информацию в середине документов в процессе рассуждения. Вместо этого они склонны больше полагаться на информацию, представленную в начале и конце документов.
Основываясь на этом наблюдении, мы можем изменить порядок извлечения фрагментов, чтобы улучшить качество ответа: при извлечении нескольких фрагментов знаний фрагменты с относительно низким уровнем доверия размещаются в середине, а фрагменты с относительно высоким уровнем доверия - на обоих концах.
Улучшение конвейера RAG
Мы также можем повысить производительность ваших приложений RAG, улучшив весь конвейер RAG.
Саморефлексия
Этот подход включает в себя концепцию саморефлексии в агентах ИИ. Как же работает эта техника?
Некоторые первоначально полученные фрагменты документов Top-K неоднозначны и могут не давать прямого ответа на вопрос пользователя. В таких случаях мы можем провести второй раунд размышлений, чтобы проверить, действительно ли эти фрагменты могут отвечать на запрос.
Для проверки можно использовать эффективные методы анализа, такие как модели Natural Language Inference (NLI), или дополнительные инструменты, например поиск в Интернете.
Эта концепция саморефлексии была исследована в нескольких работах и проектах, включая Self-RAG, Corrective RAG, LangGraph и т. д.
Маршрутизация запросов с помощью агента
Иногда нам не нужно использовать систему RAG для ответа на простые вопросы, так как это может привести к еще большему непониманию и выводам на основе недостоверной информации. В таких случаях мы можем использовать агента в качестве маршрутизатора на этапе запроса. Этот агент оценивает, должен ли запрос пройти через конвейер RAG. Если да, то запускается последующий конвейер RAG; в противном случае LLM обращается к запросу напрямую.
Агент может принимать различные формы, включая LLM, небольшую классификационную модель или даже набор правил.
Маршрутизация запросов на основе намерений пользователя позволяет перенаправить часть запросов, что приводит к значительному увеличению времени отклика и заметному уменьшению ненужного шума.
Мы можем распространить технику маршрутизации запросов на другие процессы в системе RAG, например определить, когда использовать такие инструменты, как веб-поиск, выполнение подзапросов или поиск изображений. Такой подход гарантирует, что каждый шаг в системе RAG будет оптимизирован на основе конкретных требований запроса, что приведет к более эффективному и точному поиску информации.
Резюме
Хотя ванильный конвейер RAG может показаться простым, для достижения оптимальной производительности бизнеса часто требуются более сложные методы оптимизации.
В этой статье мы обобщили различные популярные подходы к повышению производительности ваших RAG-приложений. Мы также привели наглядные иллюстрации, чтобы помочь вам быстро понять эти концепции и методы и ускорить их внедрение и оптимизацию.
Вы можете получить простые реализации основных подходов, перечисленных в статье, по этой ссылке на GitHub.