Руководство для начинающих по применению Agentic RAG

Давайте сначала разберемся, как работает традиционный алгоритм RAG. Генерация с расширенным извлечением (Retrieval-Augmented Generation, RAG) объединяет различные этапы:

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

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

Основной алгоритм довольно прост:

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

Это работает. Но есть и проблемы.

Почему традиционные разрывы RAG-резины в производстве…

Подход с фиксированным конвейером терпит неудачу предсказуемым образом.

• Постоянно происходит нерелевантный поиск . Пользователь спрашивает: «Какова ваша политика возврата средств?» Система ищет документы, касающиеся обработки платежей, управления подписками и настроек учетной записи, поскольку во всех них упоминаются деньги. Фактическая политика возврата средств может быть скрыта в пятом результате. Теперь модели приходится просеивать шум, чтобы найти нужный сигнал.
• Чрезмерное получение информации приводит к растрате токенов и денег. Простые вопросы обрабатываются так же, как и сложные. Пользователь спрашивает: «Какой у вас адрес электронной почты?» Система всё равно получает пять документов и передаёт их модели. Вы только что потратили в 10 раз больше токенов, чем было необходимо для ответа, который модель могла бы дать напрямую.
• Задержка увеличивается на протяжении всего процесса. Встраивание запроса (50 мс). Поиск в базе данных (100 мс). Переранжирование результатов (150 мс). Генерация ответа (800 мс). На простой вопрос уходит 1,1 секунды. Пользователи это замечают.
• Ограничения контекста вынуждают принимать непростые решения. Вы можете получить доступ к 10 документам, но не все они помещаются в контекстное окно. Обрезать их? Сначала кратко их описать? Каждый выбор влечет за собой новые проблемы.
• Галлюцинации сохраняются даже при хорошем извлечении информации. Модель может зацепиться за одно предложение в извлеченном контексте и построить весь ответ вокруг него, игнорируя противоречивую информацию в других документах. Или она может смешивать извлеченную информацию со своими обучающими данными, создавая уверенные, но неверные ответы.

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

Что на самом деле означает «Agentic RAG»?

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

Представьте себе: если традиционный подход RAG — это конвейер, то агентный подход RAG — это дерево решений.

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

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

Простой пример это наглядно демонстрирует.

Пользователь спрашивает: «Сколько составляет 15% от 240?» Традиционный алгоритм RAG может запросить документацию о процентах. Агентный алгоритм RAG распознает это как математическую задачу, которую модель может решить напрямую, и полностью пропускает запрос.

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

Часть «агентный» относится к этому циклу принятия решений.

Система анализирует запрос, принимает решение о действии (получить, вычислить, сгенерировать), оценивает результат и решает, продолжать ли работу или вернуть ответ.

Основной рабочий процесс агента RAG

Давайте посмотрим, как система Agentic RAG обрабатывает реальный запрос с помощью помощника по созданию документации.

Запрос: «Сравните методы аутентификации в версиях 2.x и 3.x»

Система проходит через ряд решений:

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

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

3. Выбор источников.
Вместо поиска по всему содержимому система выбирает:

• Архивированная документация для версии 2.x
• Текущая документация для версии 3.x

Традиционная система RAG выполняла бы единый широкий поиск по всем источникам.

4. Получение и оценка.
Система получает документацию для обеих версий и оценивает ее полноту:

• Содержимого версии 2.x достаточно.
• Содержание версии 3.x неполное и содержит ссылки на другое руководство.

Система принимает решение о повторном получении данных.

5. Уточнение поиска.
Программа выполняет целевой поиск отсутствующих данных аутентификации версии 3.x и извлекает необходимую информацию.

6. Проверка и генерация.
При наличии достаточной информации из обеих версий система генерирует структурированное сравнение:

• OAuth 2.0 и ключи API (обе версии)
• JWT (только версия 3.x)
• Ссылки на конкретные разделы документации

Именно это делает рабочий процесс активным и самостоятельным.

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

6 типов агентных систем RAG

Agentic RAG — это не единая архитектура. Это спектр паттернов, каждый из которых добавляет этапы принятия решений на разных этапах процесса поиска.

Условный (одношаговый) агентный RAG

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

Можно ли ответить на этот вопрос, используя обучающие данные модели? Требуется ли для этого актуальная информация? Является ли это задачей на вычисления или рассуждения, не требующей извлечения информации?

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

Как это работает:

• Поступает запрос пользователя.
• Модель оценивает: Требуется ли для этого внешняя информация?
• Если нет: сгенерируйте ответ непосредственно на основе знаний модели.
• Если да: найдите соответствующие документы, затем сгенерируйте
• Возвращает ответ

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

Плюсы:

• Снижает затраты на получение данных на 30–40% запросов в приложениях смешанного назначения.
• Более быстрая обработка запросов, не требующих извлечения данных.
• Простота внедрения и отладки.
• В итоге обычно получается снижение затрат при аналогичной общей задержке.

Минусы:

• Добавляет один вызов LLM перед получением данных (200–300 мс)
• Модель может ошибочно принять решение пропустить этап извлечения данных.
• Требуется настроить подсказку для принятия решения в соответствии с вашим конкретным сценарием использования.

Итеративный / Многоэтапный агентный RAG

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

Как это работает:

• Выполните первоначальное извлечение данных на основе запроса пользователя.
• Модель оценивает полученный контент на предмет достаточности и релевантности.
• Если недостаточно: сформулируйте уточненный запрос и выполните повторное получение данных.
• Повторять до максимального количества итераций (обычно 2–3).
• Сформируйте окончательный ответ на основе накопленного контекста.

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

Плюсы:

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

Минусы:

• Каждая итерация добавляет задержку (цикл извлечения + цикл оценки).
• Более широкое использование токенов на нескольких этапах.
• Для предотвращения бесконечных циклов необходимы тщательно продуманные условия остановки.

Tool-Trueing Agentic RAG

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

Как это работает:

• Проанализируйте запрос пользователя, чтобы понять его информационные потребности.
• Модель определяет, какие источники данных являются релевантными.
• Перенаправление к соответствующему инструменту(ам): API, база данных, поисковая система и т. д.
• При необходимости запускайте инструменты последовательно или параллельно.
• Сгенерировать ответ на основе результатов работы инструмента.

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

Плюсы:

• Использование правильного источника данных значительно повышает релевантность.
• Сокращает количество ненужных поисков по нерелевантным источникам.
• Можно комбинировать данные API в реальном времени со статической документацией.
• Оптимизирует затраты за счет использования только необходимых источников.

Минусы:

• Требуется тщательное определение инструментов и четкие описания.
• Решение о маршрутизации добавляет один вызов LLM.
• Неправильная маршрутизация направляет запросы не по тому адресу.
• Более сложное управление инструментами и обработка ошибок.

Планирование на основе агентного RAG

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

Как это работает:

• Модель анализирует запрос и создает многоэтапный план.
• В плане указано, что нужно получить, что вычислить и в каком порядке.
• Система выполняет план шаг за шагом.
• Результаты каждого этапа определяют последующие этапы.
• На заключительном этапе все результаты обобщаются в ответ.

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

Плюсы:

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

Минусы:

• Этап планирования вносит задержку на начальном этапе.
• Планы могут оказаться неверными, что приведет к неправильному пути.
• Если первые шаги окажутся неэффективными, восстановиться будет сложно.

Рефлексивный / Самооценивающий агент RAG

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

Как это работает:

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

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

Плюсы:

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

Минусы:

• Удваивает себестоимость производства (первоначальная + оценочная).
• Добавляет задержку в 500–1000 мс.
• Требуются четкие, измеримые критерии оценки.

Многоагентная РАГ

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

Как это работает:

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

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

Плюсы:

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

Минусы:

• Высокая сложность реализации
• Сложно отлаживать
• Управление контекстом между агентами — непростая задача.
• В большинстве производственных систем лучшие результаты достигаются при использовании более простых шаблонов.

Пауза: Что мы уже обсудили

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

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

Производственные модели для управления задержками и затратами

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

Условное извлечение на основе уверенности

Перед выполнением запроса спросите модель: «По шкале от 1 до 10, насколько вы уверены, что этот запрос требует внешней информации?» Если уверенность ниже 7, выполните запрос. Если выше, сгенерируйте запрос напрямую. Эта простая эвристика сокращает количество ненужных запросов на 30–40% в приложениях смешанного назначения.

Ранняя остановка в итеративных системах

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

Кэширование на нескольких уровнях

• Встраивание кэша для распространенных запросов
• Результаты извлечения данных из кэша доступны в течение 1–24 часов (в зависимости от требований к актуальности данных).
• Кэшировать полные ответы для действительно идентичных запросов.
• Используйте семантическое кэширование, чтобы понять, что вопросы «Как мне сбросить пароль?» и «Я забыл пароль, что мне делать?» — это один и тот же вопрос.
• Это позволяет сократить количество вызовов API на 50–70% для приложений, использующих формат часто задаваемых вопросов (FAQ).

Сначала неглубокое извлечение, затем глубокое.

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

Параллельная оценка потоковой обработки

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

Ограничения на количество итераций с учетом бюджета

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

Асинхронное уточнение для некритических путей

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

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

Как выбрать правильный вариант расцветки Agentic RAG

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

Может ли модель ответить на большинство запросов, используя только обучающие данные?

Если да: начните с условного одношагового агентного RAG. По возможности позвольте системе пропускать поиск. Это простейший агентный шаблон, и его часто бывает достаточно.

Если нет: переходите к следующему вопросу.

У вас есть несколько различных источников данных, требующих разных способов доступа?

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

Если нет: переходите к следующему вопросу.

Часто ли запросы бывают неоднозначными или недостаточно конкретными?

Если да: Рассмотрите итеративный агентный RAG. Позвольте системе уточнять поиск на основе найденных данных. Ограничьте количество итераций до 2–3, чтобы контролировать задержку.

Если нет: переходите к следующему вопросу.

Требуют ли запросы выполнения нескольких шагов в определенной последовательности?

Если да: используйте основанный на планировании Agentic RAG. Пусть система создаст и выполнит план. Это работает, когда важна последовательность действий (например, поиск предварительных условий перед проверкой соответствия требованиям).

Если нет: переходите к следующему вопросу.

Высока ли цена неправильного ответа?

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

Если нет: Вероятно, вашего базового шаблона будет достаточно.

Дополнительные соображения:

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

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

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

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

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

Итог

Agentic RAG — это спектр, а не бинарный выбор.

С одной стороны, у нас есть традиционные системы управления производственными процессами с фиксированным конвейером. С другой — полностью автономные системы, которые планируют, выполняют, оценивают и итеративно совершенствуют процессы. Большинство производственных систем находятся где-то посередине.

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

Если 90% ваших запросов отлично работают с традиционным RAG, не стоит добавлять агентное поведение повсюду. Добавьте его к тем 10%, которые испытывают трудности.

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

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

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