Что такое архитектура RAG? Полное определение с подробными практическими примерами

RAG (retrieval augmented generation, генерация, дополненная поиском) — это процесс, при котором LLM используют внешнюю информацию, чтобы дополнить и улучшить свои ответы. Архитектура RAG — это набор компонентов и связей, благодаря которым RAG становится возможным.

Существует несколько категорий RAG, и у каждой из них своя уникальная архитектура. По сути, архитектура системы RAG определяет, каким именно образом информация хранится, извлекается и передается LLM.

Что такое архитектура RAG?

Архитектура RAG — это конфигурация компонентов (и связанных с ними возможностей), которая лежит в основе конкретной системы RAG. Все такие архитектуры строятся на базовом шаблоне, который часто называют «простым» или «наивным» RAG.

Вот общий обзор базовой архитектуры RAG:

• Источник информации: здесь хранится внешняя информация. Это может быть поисковый индекс, векторная база данных, представляющая большие объемы информации, или хранилище необработанных документов.
• Компонент извлечения: механизм, с помощью которого выполняются запросы к источнику информации. Например, система RAG может использовать простой поиск по ключевым словам, чтобы находить релевантные фрагменты текста, или более сложные векторные запросы для поиска по сходству.
• Компонент оркестрации: этот уровень представляет собой часть приложения на базе LLM, которая запускает конвейер RAG для пользовательского промпта — совместно с LLM или независимо от нее. Он также объединяет извлеченную информацию в расширенный промпт.

Компоненты архитектуры RAG обычно распределяются по двум путям. Путь загрузки данных получает данные и упорядочивает их, формируя источник информации, по которому можно выполнять поиск. Одно из самых распространенных применений — векторные базы данных, в которых большие объемы текста преобразуются в доступное для поиска хранилище векторных эмбеддингов.

Путь извлечения принимает промпт пользователя и формирует запрос для поиска по источнику информации. Затем оркестратор добавляет извлеченную информацию во входной контекст LLM. В агентных и гибридных архитектурах RAG путей извлечения может быть несколько.

Типы архитектуры RAG

Было бы ошибкой рассматривать RAG как набор полностью обособленных архитектур. Большинство инженеров применяют модульный подход, внедряя отдельные компоненты под конкретные сценарии использования. Хотя условные границы провести можно, важно учитывать, что модели архитектуры во многом пересекаются.

1. Базовый RAG

Базовый RAG, также называемый «наивным» или «простым» RAG, служит архитектурным шаблоном для других типов RAG.

Лежащий в его основе процесс относительно прост: пользователь вводит промпт, оркестратор определяет (самостоятельно или совместно с LLM), нужна ли внешняя информация, а затем формирует и отправляет соответствующий поисковый запрос.

Внешним источником информации обычно служит векторная база данных, но это может быть и база данных SQL, веб-API, граф знаний или даже хранилище «необработанных» документов. Затем эта дополнительная информация добавляется во входной контекст LLM.

Помимо SQL-запросов и API, существует два основных типа методов извлечения:

• Лексический поиск (поиск по ключевым словам): это простая форма RAG, при которой из пользовательского запроса извлекаются ключевые слова, которые затем сопоставляются с фрагментами текста, содержащими эти слова. В современных конвейерах оркестратор может для этого выполнять так называемый разреженный векторный запрос, который не улавливает смысл.
• Плотный векторный поиск (семантический поиск): плотные векторные эмбеддинги улавливают смысл. Оркестратор может обращаться к плотной векторной базе данных так, чтобы учитывался смысл как пользовательского промпта, так и исходной информации.

Использование памяти также является важной частью архитектуры RAG. Речь идет о том, как LLM использует контекст предыдущих чатов для построения поискового запроса, привязывая его к более широкому контексту обсуждения (или нескольких обсуждений). Диалоговый RAG — норма для большинства чат-ботов, хотя в некоторых сценариях, например при ответах на обращения в службу поддержки, может использоваться RAG для одиночных вопросов.

2. Гибридный RAG

Гибридный RAG сочетает два разных типа извлечения — обычно по ключевым словам и семантическое. Поиск по ключевым словам находит совпадающие термины, а векторный поиск — фрагменты со схожим смыслом.

Могут применяться и другие формы извлечения, например обход графа знаний или запросы к базам данных SQL. Процессом часто управляет логика маршрутизации — в виде запрограммированных правил или классификации вопроса моделью (хотя несколько конвейеров также могут работать одновременно).

Оркестратор объединяет результаты и может переранжировать их перед передачей LLM. Переранжирование — это процесс присвоения оценок релевантности извлеченным фрагментам, чтобы LLM в первую очередь учитывала наиболее подходящую информацию.

3. Адаптивный RAG

В адаптивном RAG компонент маршрутизации выбирает стратегию извлечения с учетом требований пользовательского промпта, после чего оркестратор выполняет выбранный рабочий процесс.

В исходном фреймворке (Adaptive-RAG) роль классификатора выполняла модель меньшего размера, которая выбирала между отсутствием извлечения, одношаговым или многошаговым извлечением. Сейчас в некоторых архитектурах вместо этого используются генеративные модели или эвристики на основе правил.

Это популярная архитектура, поскольку она распределяет вычислительные ресурсы в зависимости от сложности и требований промпта, сокращая количество лишних шагов извлечения для более простых промптов. Она часто используется в ассистентах, работающих с вопросами разных типов.

4. Корректирующий RAG (CRAG)

Корректирующий RAG оценивает извлеченную информацию, прежде чем добавить ее во входной контекст LLM. Модуль оценки извлечения определяет, релевантна ли извлеченная информация и полезна ли она. Уникальная архитектурная особенность — явный этап оценки и коррекции перед генерацией ответа.

Если информация оказывается неполной или неприменимой к промпту, запускаются дополнительные запросы. В них могут использоваться методы извлечения, отличные от тех, что применялись для исходного запроса, например веб-поиск или обход графа знаний.

Корректирующий RAG распространен в областях, где важна точность, например в медицине и юриспруденции. Однако для него требуется дополнительный источник информации, способный дополнить изначально извлеченные фрагменты.

5. Self-RAG

В self-RAG модель может инициировать запросы после получения исходного входного контекста. Сгенерированные ответы сверяются с извлеченными данными с помощью токенов рефлексии, а при необходимости через оркестратор отправляются дополнительные запросы. И наоборот, LLM может решить, что извлечение вообще не требуется.

Он отличается от корректирующего RAG тем, что LLM сама оценивает свои выходные данные, определяет, нужно ли извлечение и полезен ли извлеченный текст, а также отслеживает собственные ответы и при необходимости изменяет их. Корректирующий RAG, напротив, оценивает качество извлеченной информации до генерации.

Эта архитектура особенно полезна для сложных промптов в духе глубокого исследования. Поскольку она встраивает оценку релевантности (извлеченной информации) в генерацию ответа, это хороший вариант для промптов, требующих ответов, основанных на фактических данных.

6. Агентный RAG

Агентный RAG — это любая форма RAG, выполняемая в контексте агентной платформы. Модель использует свои способности к рассуждению, чтобы определить, какая информация нужна, и выбирает один из доступных вариантов извлечения.

Извлечение может запускаться столько раз, сколько потребуется, а для более сложных запросов модель может назначать агентов. Например, LLM может запросить поиск в базе данных, чтобы определить поставщика, запустить поиск по документам для отбора соответствующих контрактов и в завершение выполнить веб-поиск, чтобы проверить контактные данные по общедоступным источникам.

Агентный RAG — основная архитектура, применяемая в популярных чат-ботах: Perplexity, ChatGPT, Claude и других. Поскольку эти платформы предоставляют основной модели доступ к множеству инструментов и конвейеров RAG, она может выбирать, какая форма извлечения лучше всего подходит для промпта.

7. Мультимодальный RAG

Мультимодальный RAG извлекает контекст из разных типов медиа. Это важная форма RAG, поскольку она делает доступной для LLM информацию, которая иначе осталась бы недоступной, например графики и аудиозаписи.

Базовая архитектура здесь та же, что и в любой другой системе. Например, конвейер индексирования может подготавливать изображения к поиску, преобразуя их непосредственно в эмбеддинги. Затем агентная система RAG может извлекать эти изображения вместе с семантически релевантным текстом и передавать их визуально-языковой модели для совместной обработки.

8. GraphRAG

GraphRAG использует графы знаний наряду с векторным поиском для извлечения информации о сущностях. Как правило, оркестратор находит релевантные начальные сущности, которые также называют узлами, с помощью извлечения ключевых слов или иногда предварительного векторного поиска. Графовый ретривер обходит граф знаний, чтобы сформировать более широкий контекст.

Например, в ответ на запрос подробного анализа товарной категории LLM может запустить векторный поиск, чтобы выявить конкретные сущности (товары). Затем оркестратор запустит поиск по графу знаний, чтобы найти связанные сущности, например поставщиков, точки розничной продажи, отзывы и т. д.

9. Разветвленный RAG

Если гибридная архитектура RAG позволяет использовать разные методы извлечения, то разветвленный RAG — это одновременное выполнение нескольких запросов, называемых ветвями. Каждая ветвь может обращаться к отдельному источнику информации, или же ветви могут параллельно обращаться к одному источнику с разными запросами или фильтрами. В агентной архитектуре RAG часто используется разветвленный RAG.

10. HyDE (Hypothetical Document Embeddings, эмбеддинги гипотетических документов)

HyDE — это инновационная форма RAG, при которой LLM создает гипотетический текстовый документ, показывающий, как мог бы выглядеть оптимальный ответ. Затем этот «гипотетический документ» используется для формирования запроса, обеспечивающего более точное извлечение. Хотя релевантные знания не представлены в параметрах LLM, логика здесь такова: фрагмент, похожий на ответ, может лучше совпадать с релевантными документами, чем короткий вопрос или неоднозначный промпт.

Пример простой архитектуры RAG: векторная база данных

Базовый RAG служит основой для более сложных типов архитектуры. В простой системе RAG, использующей векторную базу данных, исходная документация разбивается на небольшие части (чанки) и преобразуется в плотные эмбеддинги. Когда пользователь вводит промпт, оркестратор формирует запрос, кодирует его и обращается к базе данных, чтобы найти релевантные фрагменты.

Вот пошаговое описание процесса:

1. Большие объемы текста преобразуются в векторы с помощью автоматизированного конвейера загрузки данных и модели эмбеддингов, например BERT.
2. Приложение базы данных упорядочивает, индексирует и хранит векторы для быстрого поиска.
3. Пользователь вводит промпт в чат-бот (например, Perplexity).
4. Оркестратор приложения кодирует промпт (с помощью модели эмбеддингов), чтобы извлечь релевантную информацию из векторной базы данных.
5. Векторная база данных возвращает релевантные фрагменты, а оркестратор добавляет их во входной контекст («большой промпт») и передает его LLM.
6. LLM использует дополнительный контекст, чтобы сгенерировать ответ с опорой на свои внутренние знания (хранящиеся в ее параметрических весах).

Развернуть

Пример продвинутой архитектуры RAG: агентный RAG

Агентный RAG — это базовая архитектура систем RAG в рамках агентной платформы. Потоки агентного RAG, как правило, сложны, поскольку ИИ-агенты могут вызывать различные инструменты и конвейеры в зависимости от характера промпта и при необходимости задействовать несколько агентов.

Вот практический пример этого процесса:

1. Пользователь вводит сложный вопрос, требующий глубокого исследования темы. Для примера предположим, что промпт звучит так: «Составь прогноз доходов компании на ближайшие шесть месяцев с учетом крупных геополитических событий».
2. LLM приходит к выводу, что потребуется сочетание запросов RAG к разным типам контента.
3. Задействуются три разных агента: (а) для векторного поиска, (б) для привязки к данным из интернета и (в) для поиска по изображениям (мультимодального поиска).
4. Агенты ищут релевантную информацию, например новости и внутренние финансовые данные, через оркестратор с помощью доступных инструментов извлечения.
5. LLM сопоставляет извлеченные результаты с исследовательским вопросом каждого агента и ранжирует их по релевантности.
6. LLM оценивает информацию и там, где ее не хватает, запускает дополнительный поиск через отдельных агентов.
7. Когда извлечено достаточно информации, LLM формирует прогнозы по сценариям на основе имеющихся финансовых показателей (извлеченных из внутренней документации) и вызывает инструмент-калькулятор, чтобы спрогнозировать доходы для каждого сценария.
8. LLM формирует итоговый ответ на основе извлеченной информации и расчетов, при необходимости ссылаясь на источники.

Развернуть

Что ждет RAG в будущем?

Современные инновации направлены на то, чтобы сделать текущие архитектуры RAG глубже и быстрее, повысить точность извлечения мультимедийных данных и создавать системы, способные работать с самой свежей информацией.

Вот три тенденции, которые сейчас определяют направление исследований:

• Глубокое исследование по множеству источников: архитектура RAG, способная планировать поиск, запускать несколько ветвей по разнородным источникам, оценивать извлеченные данные и самостоятельно оптимизировать сгенерированные ответы. Агентный RAG, способный выполнять все эти задачи, становится все быстрее и экономичнее.
• Мультимодальные приложения: конвейеры извлечения все лучше работают с изображениями и видео. Они все точнее находят определенные типы информации в сложных мультимодальных данных, таких как длинные видео и детализированные диаграммы.
• Привязка ответов к постоянно меняющейся информации: приложения на базе LLM могут использовать источники информации в реальном времени (например, видеопотоки и датчики) для формирования входного контекста. Системы также могут создавать многогранные информационные сети, как, например, в GraphRAG, для интерпретации этих данных.

RAG лежит в основе работы приложений на базе LLM. Он позволяет самым разным пользователям, от обычных потребителей до предприятий, работающих в специализированных областях, решать проблемы, связанные с галлюцинациями, неполнотой обучающих данных и отсутствием доступа к специализированным внутренним знаниям.

Именно поэтому системы RAG и лежащая в их основе архитектура — одно из самых динамичных и захватывающих направлений исследований в области ИИ.