Выбор архитектуры RAG: простая, продвинутая, CRAG, GraphRAG, агентская.

Почему RAG и почему одной концепции недостаточно

Искусственные интеллектуальные агенты обладают необходимыми возможностями, однако они могут создавать ложные информации и не способны самостоятельно получать специализированные или реальные в реальном времени данные. Технология Retrieval-Augmented Generation (RAG) решает оба этих проблемы, обеспечивая основание для ответов агента в виде проверенной базы знаний. Однако RAG — это не единый универсальный решение. Простой векторный поиск вполне подходит для базового бота с часто задаваемыми вопросами, но сильно терпит при выполнении сложных задач на рассуждения или анализ, требующих обработки большого количества документов. Далее рассматриваются распространённые архитектуры RAG и критерии выбора среди них в зависимости от требований к задаче.

Что делает RAG

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

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

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

Этап 1: загрузка

На первом этапе сырые файлы преобразуются в структурированные записи, доступные для поиска в базе данных:

1. Загружайте данные из таких источников, как PDF, Notion, SQL и Slack, с помощью инструментов вроде LlamaIndex или LangChain.
2. Очищайте данные от лишнего содержимого, такого как заголовки, подзаголовки и теги HTML.
3. Разбивайте длинные документы на осмысленные фрагменты, например по 500 слов в каждом. Слишком большие фрагменты могут запутать модель, а слишком маленькие — привести к потере контекста.
4. Встраивайте каждый фрагмент с помощью модели встраивания (например, text-embedding-3-small от OpenAI), чтобы преобразовать текст в векторы.
5. Индексируйте эти векторы в векторной базе данных, такой как Pinecone или Chroma, что позволяет выполнять семантический поиск по смыслу.

Этап 2: поиск и генерация

Когда пользователь задает вопрос, вся процедура выполняется за несколько миллисекунд:

1. Трансформация запроса. Система преобразует вопрос, например «Как сбросить пароль?», в вектор с использованием того же модели эмбеддингов, что и на этапе 1.
2. Поиск. Она ищет в базе данных векторов 3–5 фрагментов, математически наиболее близких к вопросу.
3. Переупорядочивание. Модель переупорядочивания повторно проверяет результаты, чтобы лучший вариант оказался в верхней части списка.
4. Дополнение. Найденные фрагменты включаются в промпт для ЯЗЫКА. Типичный промпт указывает модели, что она является полезным помощником, передает ей фрагменты в качестве контекста, а затем задаёт вопрос о сбросе пароля.
5. Генерация. ЯЗЫКА читает промпт вместе с контекстом и формирует ответ, основанный исключительно на предоставленной информации.

Этап 3: обратная связь

Результаты поиска следует постоянно оценивать для предотвращения галлюцинаций. Оценка показывает, основывался ли ответ действительно на контексте, а наблюдаемость указывает, какой именно фрагмент привёл к неверному ответу. Эти данные используются для улучшения стратегии разбиения на фрагменты на этапе 1.

Инструменты по этапам

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

В таблице технологии RAG сортированы по этапам обработки.

Требуется ли векторная база данных?

Не совсем. Для создания RAG не обязателен специализированный хранилище векторов; существуют два более простых подхода. При подходе без базы данных несколько документов разбиваются на фрагменты и хранятся в ОЗУ. Это быстро, бесплатно и не требует настройки, но при перезагрузке память очищается, а с большими документами работа идет медленно. Традиционный подход с базой данных предполагает хранение фрагментов текста в такой системе, как PostgreSQL, и использование поиска по ключевым словам на основе правил. Он хорошо справляется с уникальными фразами, такими как имя человека или идентификатор, но не обладает семантическим пониманием: запрос пользователя о «млекопитающих» не совпадет с документом, в котором написано только «собаки».

Сравнение шести архитектур

Нет единственного решения, подходящего во всех ситуациях. Для некоторых задач необходимы скорость и простота, для других — более глубокий анализ, несколько источников или нетекстовые данные, такие как изображения или графики. Шесть основных подходов покрывают большинство случаев использования: Naive RAG, Advanced RAG, Modular RAG, Corrective RAG (CRAG), GraphRAG и Agentic RAG.

Naive RAG

В этой простейшей форме документы извлекаются на основе запроса и передаются модели без каких-либо корректировок.

На диаграмме показано простое сравнение векторных сходств top-K. Запрос преобразуется в вектор, самые схожие фрагменты берутся из базы данных векторов, после чего они поступают в большую языковую модель. Поиск носит семантический характер, а сложность минимальна.

• Преимущества: самые быстрые ответы и самая низкая стоимость обработки; легко настраивается с помощью библиотек вроде LangChain или LlamaIndex; подходит для получения базовых фактов из чистых документов.
• Недостатки: нерелевантные фрагменты могут создавать шум, сбивающий LLM с толку; он плохо справляется с сложными или многокомпонентными вопросами и не может самостоятельно исправлять ошибки, поэтому неудачный поиск приводит к выдуманным ответам.
• Идеально для: простых вопросов и ответов на небольших, структурированных наборах данных, таких как вопросы и ответы к личным документам, внутренние FAQ компании и простые приложения для общения с документами.

Расширенный RAG

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

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

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

Модульный RAG

Модульный RAG использует структуру типа «подключи и работай», при которой отдельные модули обрабатывают разные этапы рабочего процесса.

Выделенные компоненты включают модули поиска и памяти. Такое разделение системы позволяет настраивать любую её часть без необходимости перестраивать остальные элементы: команда может заменить поисковый механизм на другой, более мощный инструмент ранжирования или другой генератор. Получение данных может осуществляться из различных источников, таких как API, базы данных и веб, причём сложность высока из-за необходимости использования сложного уровня оркестрации.

• Преимущества: каждый компонент легко настраивается, а его можно обновить или заменить без необходимости начинать всё с нуля.
• Недостатки: затраты на настройку и архитектурная сложность очень высоки, требуется заранее тщательное планирование; для управления процессами необходима сильная инженерная команда, к тому же разные версии модулей могут вступать в конфликт.

Идеально для: сложных корпоративных систем, требующих глубокой настройки, таких как ассистент, который одновременно проверяет Jira, Slack и Google Drive.

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

CRAG предназначен для повторной проверки своих ответов и их коррекции в случае ошибок.

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

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

GraphRAG

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

На диаграмме показано прослеживание связей в графе знаний и формирование краткого обзора сообществ. После построения графа система анализирует его на наличие закономерностей в данных, а не только совпадений слов, что позволяет определить связь между Энтитетом А и Энтитетом Б даже в том случае, если они присутствуют в разных документах. Сложность подхода очень высока, поскольку необходимо создавать и поддерживать структурированную базу данных графов.

Вторая иллюстрация, взятая из материалов Microsoft Research, показывает граф знаний, сгенерированный с помощью LLM на основе приватного набора данных с использованием GPT-4 Turbo.

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

Agentic RAG

В этой динамической модели искусственный интеллект выступает в роли координатора, отвечающего за планирование, поиск и уточнение ответа.

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

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

Четырехэтапный путь принятия решений

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

Диаграмма потоков помогает архитекторам выбрать между вариантами Simple, Graph, Corrective и Advanced RAG в зависимости от требований задачи. Шаги следующие:

Шаг 1: тест на сложность. Находится ли ответ в одном документе? Если да, то для небольших документов лучше всего использовать No-DB RAG, а для более крупных — Simple RAG, поскольку он быстрый, недорогой и практически не требует усилий для реализации.

Шаг 2: тест на наличие связей. Требуется ли для получения ответа понимание сложных иерархий или скрытых связей между несколькими источниками данных? Если да, то GraphRAG позволяет отобразить эти ресурсы и связи, которые не видны при обычном поиске в тексте. Например, при вопросе «Какие отделы затронуты политикой A, и кто является их руководителями?» необходимо объединить данные о отделах с данными о сотрудниках, причем GraphRAG представляет их в виде связанных между собой элементов.

Шаг 3: тест надежности и логического мышления. Может ли система позволить себе допускать ошибки? Там, где критически важна высокая точность, Corrective RAG или Self-RAG включают специальный этап проверки на то, действительно ли полученные данные отвечают на вопрос, прежде чем они попадут к пользователю. Если для выполнения такой задачи также требуется многоэтапное логическое мышление, Agentic RAG использует своих агентов для планирования и самосовершенствования.

Шаг 4: баланс между производительностью и затратами. Когда приоритетом является низкая задержка, наилучшим решением будет более простая конфигурация, такая как No-DB, Naive или Simple RAG. Однако когда качество важнее затрат, но не на уровне крайней точности шага 3, Advanced RAG лучше распознает цель запроса по сравнению с более простыми решениями, при этом требуя больше времени на обработку.

Когда не использовать RAG

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

• Широкие рассуждения о здравом смысле, этических нюансах или общем поведении людей. Достаточно использовать внутренние веса заранее обученной модели.
• Запросы об общих знаниях о вещах, которые не меняются десятилетиями. Заранее обученная модель уже достаточна, а RAG только увеличит задержку без улучшения точности.
• Творческое письмо с определенным тоном и стилем. Лучше использовать заранее обученные модели или методы финтунинга, так как RAG здесь избыточен.

Сложные математические или логические задачи, требующие многократных вычислений. Для них более подходит тонкая настройка или использование метода Chain-of-Thought (CoT).

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

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

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