Agentic RAG: как поиск в данных научился думать шагами

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

Что такое обычный RAG и где он спотыкается

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

Эта схема отлично закрывает простые вопросы вида «что написано в разделе про отпуск». Но она ломается там, где вопрос требует не одного факта, а нескольких шагов:

• Многоступенчатые вопросы. «Сравни условия по двум договорам и скажи, где неустойка выше» — тут нужно достать оба документа и сопоставить, а не найти один похожий кусок.
• Плохо сформулированный запрос. Если пользователь спросил размыто, векторный поиск вернёт мусор, и обычный RAG всё равно построит ответ на этом мусоре.
• Несколько источников. Ответ лежит частью в базе знаний, частью в таблице, частью в свежих данных из API. Линейный конвейер обычно ходит только в одно хранилище.
• Проверка достаточности. Классический RAG не спрашивает себя «а хватает ли мне найденного» — он просто отвечает тем, что достал.

Что добавляет agentic RAG

Agentic RAG вставляет между вопросом и ответом модель-агента**, которая управляет процессом поиска как набором инструментов. Вместо одного жёсткого запроса агент проходит цикл: подумать, что нужно найти → сделать запрос → оценить результат → при необходимости переформулировать и искать снова → собрать ответ.

Ключевые механики, которых нет в обычном RAG:

• Планирование. Агент разбивает сложный вопрос на подзадачи и ищет по каждой отдельно.
• Выбор инструмента. У агента может быть несколько источников — векторная база, полнотекстовый поиск, SQL-запрос к таблице, вызов внешнего API. Он сам решает, куда пойти под конкретный вопрос.
• Самопроверка. Агент оценивает, релевантны ли найденные фрагменты, и повторяет поиск, если результат слабый.
• Уточнение запроса. Плохо сформулированный вопрос агент может переписать перед поиском.

Обычный RAG отвечает тем, что нашёл с первого раза. Agentic RAG сначала решает, достаточно ли он нашёл, — и это главная разница между ними.

Сравнение подходов

Главная плата за «ум» agentic RAG — деньги и время. Один вопрос может обернуться тремя-пятью проходами модели вместо одного, а значит и счёт за токены, и задержка растут кратно. Для чат-бота, где ответ ждут за секунду, это ощутимо.

Кому это пригодится, а кому нет

Где agentic RAG оправдан

• Аналитика по разнородным данным. Вопрос требует свести документы, таблицы и свежие показатели из разных систем — агент сам разложит его на части.
• Юридические и финансовые ассистенты. Здесь цена ошибки высокая, а вопросы редко умещаются в один фрагмент. Самопроверка и повторный поиск снижают долю ответов «из воздуха».
• Исследовательские сценарии. Пользователь задаёт открытый вопрос, где заранее неизвестно, сколько источников понадобится.
• Базы знаний с несколькими хранилищами. Часть данных в векторной базе, часть — в реляционной, часть — за API.

Где хватит обычного RAG

• FAQ и справка по продукту. Вопрос простой, ответ лежит в одном месте, важна скорость.
• Массовые запросы с жёстким бюджетом. Когда обращений много, а на каждое нельзя тратить пять проходов модели.
• Строгие требования к задержке. Голосовой ассистент или виджет поддержки, где ответ нужен мгновенно.
• Один хорошо структурированный источник. Если данные однородны, планирование и выбор инструмента ничего не добавят.

Как это выглядит на практике

Собрать agentic RAG сегодня можно на популярных фреймворках для агентов и оркестрации LLM — они дают готовые примитивы для цикла «инструмент → результат → решение». Разработчику остаётся описать доступные инструменты поиска и правила, по которым агент решает, когда остановиться.

Практический совет: начинайте с обычного RAG и переходите на agentic только там, где на реальных вопросах видно, что одного прохода не хватает. Иначе легко получить систему, которая думает пять секунд там, где хватило бы полсекунды.

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

** Агент — здесь: языковая модель, которой дали набор инструментов (поиск, вызовы API) и право самостоятельно решать, какой инструмент и сколько раз применить для достижения цели.