Agentic RAG против Classic RAG: от конвейера к контуру управления

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

Делиться

Введение: Почему это сравнение важно

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

За последний год все больше команд начали переходить от конвейера «одного прохода» к циклам, подобным работе агентов, которые могут повторять попытки получения данных и вызывать инструменты, если первый проход оказался неудачным. Gartner даже прогнозирует, что к 2028 году 33% корпоративных программных приложений будут включать в себя агентный ИИ , что свидетельствует о том, что «агентные» модели становятся все более распространенными, а не нишевыми.

Агентный подход RAG изменяет структуру системы. Поиск становится циклом управления: поиск, рассуждение, принятие решения, затем повторный поиск или остановка. Это отражает основную модель подходов «рассуждение и действие», таких как ReAct, в которых система чередует рассуждение и действие для сбора новых доказательств.

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

Классический RAG: ментальная модель конвейера

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

В общих чертах, конвейер выглядит следующим образом:

1. Запрос: принимает вопрос пользователя (и любые инструкции системы) в качестве входных данных.
2. Получение: извлечение k наиболее релевантных фрагментов (обычно с помощью векторного поиска, иногда гибридным способом).
3. Составьте контекст: выберите и расположите лучшие отрывки текста в контексте задания (часто с перегруппировкой).
4. Задача: Составьте ответ, желательно со ссылками на найденные фрагменты текста.

В чём хорош классический RAG?

Классический RAG наиболее эффективен, когда приоритетами являются предсказуемая стоимость и задержка. Для простых запросов типа «Что делает этот флаг конфигурации?», «Где находится конечная точка API для X?» или «Каковы ограничения плана Y?», обычно достаточно одного прохода получения информации. Ответы предоставляются быстро, а отладка осуществляется напрямую: если выходные данные некорректны, сначала проверьте релевантность и разбивку на блоки, а затем проанализируйте поведение подсказок.

Пример (классический RAG на практике):
Пользователь спрашивает: «Что делает флаг конфигурации MAX_UPLOAD_SIZE?»

Программа для извлечения данных загружает страницу справочника по конфигурации, где определен флаг.

Модель отвечает за один проход: «Она устанавливает максимально допустимый размер загружаемого файла за один запрос», и приводит точный фрагмент кода.

Отсутствие циклов и вызовов инструментов гарантирует стабильность стоимости и задержки.

Там, где классический RAG упирается в стену

Классический RAG — это «одноразовый» подход. Если восстановление не удается, в модели отсутствует встроенный механизм восстановления.

Это проявляется несколькими распространенными способами:

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

Почему это важно:
Когда классический метод RAG терпит неудачу, это часто происходит незаметно. Система по-прежнему дает ответ, но это может быть уверенный синтез, основанный на слабых доказательствах.

Агентная RAG: от поиска к контуру управления

В Agentic RAG сохраняются компоненты извлечения и генерации, но изменяется структура управления. Вместо того чтобы полагаться на один проход извлечения, процесс извлечения заключен в цикл, позволяющий системе анализировать имеющиеся данные, выявлять пробелы и при необходимости повторять попытку извлечения. Этот цикл придает системе «агентный» характер: она не только генерирует ответы на основе имеющихся данных, но и активно выбирает способ сбора более убедительных доказательств до тех пор, пока не будет выполнено условие остановки. Полезной аналогией является отладка инцидентов: классический RAG похож на выполнение одного запроса к логам и написание вывода на основе полученных данных, в то время как Agentic RAG — это цикл отладки. Вы запрашиваете данные, проверяете имеющиеся данные, замечаете, чего не хватает, уточняете запрос или проверяете вторую систему и повторяете процесс, пока не будете уверены в правильности решения или не достигнете временного/бюджетного лимита и не объявите о проблеме.

Минимальный цикл выглядит так:

1. Получение: извлечение потенциальных доказательств (документов, результатов поиска или результатов работы инструментов).
2. Причина: обобщите имеющиеся данные и определите, чего не хватает или что остается неясным.
3. Примите решение: остановиться и ответить, уточнить запрос, сменить источник/инструмент или передать вопрос на рассмотрение вышестоящему руководству.

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

Что добавляют агенты

Планирование (декомпозиция)
Агент может разложить вопрос на более мелкие, основанные на доказательствах задачи.

Пример: «Почему настройка единого входа (SSO) не удается для части пользователей?»

• Какие коды ошибок мы видим?
• Какая конфигурация IdP используется?
• Это вопрос по документации, по логам или по конфигурации?

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

Использование инструментов (помимо извлечения)
В агентской системе RAG поиск информации — один из нескольких доступных инструментов. Агент также может использовать:

• второй индекс
• Запрос к базе данных
• API поиска
• Программа проверки конфигурации
• Легковесный верификатор

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

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

Self-RAG — хороший пример этого направления исследований: он разработан для того, чтобы по запросу получать критический анализ найденных фрагментов и генерировать его, вместо того, чтобы всегда использовать фиксированный этап поиска по k лучшим вариантам.

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

Компромиссы: преимущества и недостатки петель

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

Однако введение цикла меняет ожидания от производства. Что мы подразумеваем под «циклом» ? В этой статье цикл — это одна полная итерация цикла управления агента: Получение → Обоснование → Принятие решения, повторяющаяся до тех пор, пока не будет выполнено условие остановки (высокая уверенность + цитирования, максимальное количество шагов, ограничение бюджета или эскалация). Это определение важно, потому что как только получение становится итеративным, стоимость и задержка становятся распределенными: некоторые запуски останавливаются быстро, в то время как другие требуют дополнительных итераций, повторных попыток или вызовов инструментов. На практике вы перестаете оптимизировать «типичный» запуск и начинаете управлять поведением «хвоста » (задержка p95, скачки стоимости и каскады вызовов инструментов в наихудшем случае).

Вот небольшой пример того, как может выглядеть цикл «Получить → Обосновать → Решить» в коде:

# Цикл «Получить → Причина → Решение» (агентный RAG) evidence = [] for step in range(MAX_STEPS): docs = retriever.search(query=build_query(user_question, evidence)) gaps = find_gaps(user_question, docs, evidence) if gaps.satisfied and has_citations(docs): return generate_answer(user_question, docs, evidence) action = decide_next_action(gaps, step) if action.type == «refine_query»: evidence.append((«hint», action.hint)) elif action.type == «call_tool»: evidence.append((«tool», tools[action.name](action.args))) else: break # Безопасная остановка, если цикл не помогает return safe_stop_response(user_question, evidence)

Где циклы помогают

Agentic RAG наиболее полезен, когда «получить один раз → получить ответ» недостаточно. На практике циклы помогают в трех типичных случаях:

1. Вопрос сформулирован недостаточно конкретно и требует уточнения.
2. Доказательства разбросаны по множеству документов или источников.
3. Первая попытка получения данных возвращает неполную или противоречивую информацию, и системе необходимо провести проверку, прежде чем подтвердить действие.

Где петли причиняют боль

Компромисс заключается в операционной сложности. Использование циклов приводит к появлению большего количества движущихся частей (планировщик, средство извлечения, дополнительные инструменты, условия остановки), что увеличивает вариативность и затрудняет воспроизведение результатов. Также расширяется область для сбоев: результат может выглядеть «нормальным» в конце, но при этом все равно расходовать токены из-за многократного извлечения, повторных попыток или каскадного использования инструментов.

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

Типы сбоев, которые вы увидите на ранних этапах производства.

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

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

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

Краткое сравнение: Classic и Agentic RAG

Структура принятия решений: когда оставаться верным классическому подходу, а когда переходить к агентскому.

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

Матрица решений: сложность × допустимая погрешность

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

Практические правила организации движения (что и куда направлять).

Классический RAG обычно лучше подходит, когда задача состоит в основном в поиске или извлечении данных:

• Часто задаваемые вопросы и ответы по документации.
• Ответы в одном документе (политики, спецификации, ограничения)
• Быстрая помощь там, где предсказуемость задержки важнее идеального покрытия.

Внедрение Agentic RAG обычно оправдывает дополнительную сложность, когда задача требует многоэтапного сбора доказательств:

• Разложение вопроса на подвопросы
• Итеративный поиск (переписывание, расширение/сужение, смена источников)
• Проверка и перекрестная проверка с использованием различных источников/инструментов.
• Рабочие процессы, в которых для получения уверенного и подтвержденного ответа требуется «повторить попытку».

Простое правило: не платите за циклы, если ваша задача не приводит к регулярной ошибке при выполнении за один проход .

Рекомендации по внедрению: перед переходом на «полный режим работы с агентом» следует добавить второй этап.

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

Основной вывод

Agentic RAG — это не просто улучшенная версия RAG; это RAG с добавленным контуром управления. Этот контур может повысить корректность сложных, неоднозначных или многошаговых запросов, позволяя системе уточнять поиск и проверять доказательства перед ответом. Компромисс заключается в операционных аспектах: повышенная сложность, более высокая задержка в конце цепочки запросов и скачки затрат, а также дополнительные режимы отказов, требующие отладки. Четкое планирование бюджетов, правила остановки и отслеживаемость необходимы при использовании этого подхода.

Заключение

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

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

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

• Извлечение из плотных проходов (DPR)
• HyDE (расширение запроса для более эффективного извлечения данных)
• Эталон BEIR (оценка эффективности систем сбора данных за пределами одного набора данных)
• RAGAS (система оценки RAG)
• Инструментоформовщик
• Генерация многодокументных документов в стиле FiD

Источник: towardsdatascience.com