RAG против агентного RAG против графового RAG: как выбрать подходящую архитектуру поиска
Узнайте, почему наивный подход RAG терпит неудачу при решении вопросов с несколькими этапами обработки и с использованием структурированных данных, а также как циклы с участием агентов и поиск на основе графов каждый из себя устраняют отдельные недостатки.
Проблема, которую решает RAG
Любая модель большого языка обладает знаниями, накопление которых прекращается по окончании обучения, и она может рассуждать только на основе информации, входящей в её окно контекста. Метод генерации с усилением через поиск решает эту проблему путём добавления внешней памяти, к которой модель может обращаться при ответе на вопрос. Вместо того чтобы полагаться исключительно на то, что она выучила во время обучения, модель берёт соответствующий текст из коллекции документов и использует этот материал для формирования своего ответа.
Основные шаги, вероятно, уже знакомы вам:
- Исходные документы разбиваются на более мелкие фрагменты и преобразуются в векторные эмбеддинги.
- Эти эмбеддинги сохраняются в векторной базе данных — популярными выборами являются Pinecone, Weaviate, pgvector и подобные инструменты.
- Когда пользователь отправляет запрос, он также преобразуется в эмбеддинг с использованием того же метода.
Весь этот процесс выполняется один раз от начала до конца: одно получение данных, одна генерация. Этот метод дешев, его поведение легко понимать, и он отлично справляется с широким спектром задач — поиском во внутренних документах, ответами на вопросы поддержки на основе базы знаний или обработкой вопросов и ответов на основе статического набора документов.
Где примитивный RAG терпит неудачу
Когда этот простой подход не срабатывает, проблемы обычно относятся к нескольким определенным категориям:
- Вопросы, требующие связи нескольких фактов. Вопросы вроде «Какие поставщики продлили контракты после обновления политики в 3-м квартале?» требуют двух отдельных фрагментов информации, которые почти наверняка находятся в разных частях данных. Метод векторного сходства находит фрагменты, семантически похожие на запрос, а не конкретную комбинацию фактов, необходимую для его ответа.
- Отсутствие встроенных условий остановки. Система всегда возвращает свои k лучших фрагментов, независимо от того, содержат ли они действительно ответ. Когда настоящий ответ находится вне этого набора из k фрагментов, модель либо выдумывает что-то правдоподобное, либо дает неопределенный и бесполезный ответ.
- Отсутствие цикла обратной связи. Если первая попытка поиска не дает результата, ничто в работе системы не фиксирует этого и не пытается сформулировать запрос лучше. Система просто продолжает работу с тем, что у нее есть.
Ни один из этих феноменов не является настоящей ошибкой; это естественные последствия основного предположения, заложенного в архитектуру — что поиск по сходству среди несвязанных текстовых фрагментов может заменить собой настоящую оценку релевантности. Agentic RAG и Graph RAG нацелены на разные слабые места в этом предположении.
Agentic RAG: добавление цикла принятия решений к процессу поиска
Agentic RAG заменяет жесткую последовательность «поиск — генерация» на цикл, в котором большая языковая модель выступает в роли координатора — определяя, что искать, нужен ли дополнительный поиск, и когда собрано достаточно информации для формирования ответа.
Вместо одного шага поиска процесс выглядит примерно так:
- Модель читает запрос и определяет, какую информацию ей на самом деле нужна.
- Она решает, действительно ли необходим поиск вообще, и если да, составляет запрос к поиску — возможно, разбивая сложный вопрос на более мелкие подвопросы.
- Она получает результаты, оценивает их достаточность, и если они недостаточны, переписывает запрос и снова выполняет поиск.
- При необходимости она может использовать различные источники — хранилище векторов, SQL-базу данных, API веб-поиска, внутренний сервис — в зависимости от требований вопроса.
- Только после того, как она приходит к выводу, что у неё достаточно доказательств, она формирует окончательный ответ.
По сути, это помещает RAG внутрь агентного цикла, используя тот же паттерн вызова инструментов, что и у помощников по программированию: планирование, действие, наблюдение за результатом и затем решение о том, продолжать или нет. Получение информации больше не является обязательным первым шагом, а становится лишь одним из нескольких инструментов, применяемых выборочно, а не автоматически при каждом запросе.
Преимущество заключается в гибкости. Простой вопрос запускает один поиск; вопрос, требующий трех последовательных поисков в разных системах, получает именно это. Такая конфигурация также позволяет осуществлять самокоррекцию — если полученные фрагменты явно неверны, агент может это распознать и сформулировать другой запрос вместо того, чтобы уверенно отвечать на основе ненадежного контекста.
Такая гибкость сопряжена с реальными затратами. Каждый шаг планирования и каждый этап оценки представляют собой отдельный вызов модели, поэтому на один запрос приходится больше вызовов LLM, возрастает задержка, а профиль затрат становится гораздо сложнее для предсказания заранее. Агентный подход RAG хорошо работает, когда сложность запросов сильно варьируется от одного запроса к другому, поскольку фиксированная схема обработки либо тратит ресурсы впустую на простые вопросы, либо не справляется с сложными. Он менее подходит, когда требуется постоянно низкая задержка или когда запросы достаточно однородны, чтобы тщательно настроенный инструмент поиска с одним вызовом уже эффективно с ними справлялся.
Graph RAG: восстановление структуры, уничтожаемой чанкированием
Graph RAG направлен на совершенно другую проблему: обычный векторный поиск по чанкам не имеет встроенного понимания того, как связаны между собой различные элементы.
Вместо того чтобы полагаться исключительно на векторный индекс (хотя его также можно использовать одновременно), Graph RAG создает граф знаний непосредственно из исходного материала. Для этого извлекаются сущности — люди, продукты, организации, понятия — а также связи между ними, такие как «работает в», «зависит от», «приводит к» или «является версией». В результате поиск перестаёт быть чисто поиском по сходству и становится отчасти задачей прослеживания связей в графе: начиная с соответствующей сущности, система может переходить к связанным с ней сущностям и получать информацию, которая никогда бы не появилась при использовании только совпадений ключевых слов или векторных представлений, просто потому что она находится на несколько шагов от неё в совершенно другом документе.
Исследования Microsoft GraphRAG являются наиболее часто цитируемой реализацией этого подхода, и они включают дополнительную функцию, особенно ценную для одного типа запросов — обнаружения сообществ. Система группирует граф в кластеры тесно связанных между собой элементов и заранее вычисляет краткое описание для каждого кластера. Это придает Graph RAG преимущество при решении обширных вопросов, охватывающих всё корпус данных — например, «Какие темы повторяются во всем этом наборе отчетов?» — что именно является категорией, с которой наиболее трудно справляется простой RAG, поскольку ни один отдельный фрагмент не содержит полного ответа; ответ возникает только путем синтеза информации из всего набора данных.
Здесь расходы носят структурный характер, а не случайный. Создание графа является дорогостоящим процессом, поскольку требует выполнения операции извлечения сущностей и связей для всего корпуса текстов, обычно с использованием большой языковой модели, плюс дополнительного шага генерации кратких описаний сообществ. Этот метод также не подходит для корпусов, которые часто меняются, поскольку граф необходимо пересоздавать или постепенно обновлять каждый раз при изменении документов — это гораздо более сложная операция, чем простое добавление нового вектора в индекс эмбеддингов.
Сравнение трех подходов
Стоит отметить, что эти подходы не являются взаимоисключающими. Распространённой практикой является использование агентного цикла, оснащённого как векторным поисковиком, так и графовым поисковиком в качестве инструментов, что позволяет агенту выбирать между ними или использовать оба в зависимости от требований запроса. Агентский слой на самом деле представляет собой стратегию оркестрации, расположенную над любым механизмом поиска, поэтому он естественным образом добавляется поверх Graph RAG, а не конкурирует с ним.
Практическая система принятия решений
Вместо того чтобы выбирать подход из-за его текущей популярности, полезно пройти конкретный процесс принятия решений:
- Начните с простой версии RAG. Это самый недорогой вариант для разработки и устранения ошибок, и для большинства реальных приложений он уже достаточно хорош. Избегайте добавления сложности, пока у вас нет доказательств её реальной необходимости.
- Перейдите на версию Agentic RAG, как только заметите определенные паттерны сбоев: вопросы, требующие извлечения информации из нескольких источников, ответы, которые оказываются неверными из-за необходимости модели в поиске, оценке найденного материала и повторном поиске, или нагрузка, в которой смешаны простые и сложные запросы таким образом, что одна фиксированная схема обработки либо слишком перегружена, либо недостаточна.
Основная мысль отражает закономерность, характерную для проектирования систем: более сложная архитектура не является автоматически лучшей; она превосходна лишь в отношении определенного типа проблем. Примитивный RAG не справляется с задачами, требующими многократных выводов и анализа отношений. Agentic RAG устраняет этот недостаток за счет внедрения итераций. Graph RAG решает проблему отношений путем создания структуры. Правильная диагностика того, с какой именно проблемой вы сталкиваетесь, — ключ к успеху.
Связанные материалы
- Почему стоимость агентных ИИ-систем растет стремительно: модель расчета затрат, основанная на архитектуре — объясняет, почему затраты на агентов на основе больших языковых моделей следует измерять за каждое выполненное задание, а не за каждый вызов, и описывает такие архитектурные подходы, как маршрутизация моделей, лимиты контекста и кэширование для контроля расходов.
- Второй мозг: преобразование стенограмм собраний в поисковую знаниевую сеть — объясняет, как агентная система извлекает сущности из стенограмм собраний и хранит их в Cosmos DB, что позволяет осуществлять поиск с использованием естественного языка и исследовать знаниевую сеть.