Agentic RAG (агентный RAG): что это и как работает
Agentic RAG (агентный RAG) — это подход, в котором поиск информации для языковой модели не идёт по жёсткому конвейеру, а управляется агентом: модель сама решает, нужен ли ей поиск, что именно искать, какие фрагменты отбросить и когда найденного хватает для ответа.
Классический RAG устроен линейно: вопрос превращается в вектор, из базы достаётся фиксированное число фрагментов (top-k), они подставляются в промпт. Агентный вариант добавляет между этими шагами решения: поиск можно повторить с другим запросом, результаты — оценить и выбросить, а ответ — отложить до тех пор, пока контекст не станет достаточным.
Что это
Разница не в том, что появился новый вид поиска, а в том, кто им управляет. В обычном RAG маршрут задан разработчиком и одинаков для всех вопросов. В агентном RAG маршрут выбирает модель через вызов инструментов: она видит, что вернул поиск, и решает следующий шаг.
| Классический RAG | Agentic RAG | |
|---|---|---|
| Маршрут | запрос → top-k → ответ | цикл «план → поиск → оценка → уточнение» |
| Число поисковых запросов | один, задан заранее | столько, сколько нужно, в пределах лимита |
| Решение «данных хватает» | не принимается | принимается моделью на каждом шаге |
| Инструменты | векторная база | несколько: векторная база, веб-поиск, SQL, API |
Как работает
Цикл состоит из повторяющихся шагов:
- План. Модель-контроллер разбирает вопрос и решает, нужен ли внешний поиск, а если нужен — формулирует первый запрос.
- Поиск. Вызывается инструмент: поиск по векторной базе, веб-поиск, запрос к базе данных.
- Оценка. Модель смотрит на выдачу и отвечает на вопрос: фрагменты релевантны, их достаточно, есть ли противоречия.
- Уточнение. Если данных мало — переформулируется запрос, ищется другой источник или вопрос разбивается на части.
- Ответ. Когда контекст признан достаточным, сильная модель формулирует ответ со ссылками на найденное.
Из чего это собрано: LLM как контроллер, набор инструментов поиска и механизм проверки достаточности контекста. Последний чаще всего реализуют отдельным дешёвым вызовом со структурированным выводом — модель возвращает {"sufficient": false, "next_query": "..."}, и цикл продолжается. Общая логика «рассуждение и действие вперемешку» описана в работе ReAct: модель чередует рассуждение и обращение к внешнему источнику, а результат предыдущего действия влияет на следующий шаг.
Self-RAG
В работе Self-RAG модель обучают адаптивно доставать фрагменты по необходимости и критиковать и найденное, и собственный ответ с помощью специальных reflection-токенов. Так модель сама решает, нужен ли поиск, и оценивает, насколько найденное подходит и насколько хорош её собственный ответ. Идея полезна для практики даже без дообучения: похожие проверки можно задать промптом или отдельным классификатором.
Corrective RAG (CRAG)
В Corrective RAG добавляется лёгкий оценщик качества выдачи: он возвращает степень уверенности, и от неё зависит, какое действие по поиску запустится, например дополнение результатов веб-поиском. Дополнительно документы разбираются на части и пересобираются, чтобы отбросить нерелевантное. Механизм заявлен как подключаемый к любому RAG-пайплайну.
Итеративный поиск и multi-hop
Вопросы вида «сравните условия возврата в договорах 2024 и 2026 года» требуют нескольких поисков: сначала найти один договор, затем второй, затем сопоставить. Это называется многошаговым (multi-hop) поиском. Здесь важно ограничение: без лимита итераций цикл может ходить по кругу, переформулируя один и тот же запрос.
Примеры
- Сравнение документов. Клиент спрашивает, чем отличаются два тарифа. Агент ищет каждый тариф отдельно и сводит результат, а не надеется, что оба фрагмента попадут в один top-k.
- Вопросы про свежие данные. Поиск по внутренней базе устарел — агент замечает, что фрагменты относятся к прошлому году, и доходит до веб-поиска или до API.
- Аналитика по базе данных. Сначала SQL-запрос за цифрами, затем поиск по документации, объясняющей методику расчёта, и только потом ответ.
Agentic RAG на RouterAI
RouterAI даёт OpenAI-совместимый API https://routerai.ru/api/v1 и Anthropic Messages API https://routerai.ru/api: инструменты и структурированный вывод работают через стандартные поля tools и response_format, отдельный шлюз под цикл поиска не нужен. Ключ один, оплата в рублях, работа из России без VPN, модели — из общего каталога.
import json
from openai import OpenAI
client = OpenAI(
base_url="https://routerai.ru/api/v1",
api_key="sk-xxxxxxxxxxxxxxxx",
)
TOOLS = [{
"type": "function",
"function": {
"name": "search_docs",
"description": "Поиск по базе знаний, возвращает до 5 фрагментов",
"parameters": {
"type": "object",
"properties": {"query": {"type": "string"}},
"required": ["query"],
},
},
}]
messages = [{"role": "user", "content": "Чем отличаются условия возврата в тарифах Basic и Pro?"}]
for step in range(4): # лимит итераций
resp = client.chat.completions.create(
model="anthropic/claude-sonnet-5.5",
messages=messages,
tools=TOOLS,
)
msg = resp.choices[0].message
messages.append(msg.model_dump())
if not msg.tool_calls:
print(msg.content)
break
for call in msg.tool_calls:
result = search_docs(**json.loads(call.function.arguments)) # ваш поиск
messages.append({
"role": "tool",
"tool_call_id": call.id,
"content": result,
})
Роли моделей в цикле удобно разделить: дорогая модель отвечает, дешёвая — оценивает выдачу и переформулирует запрос.
| Шаг цикла | Модель из каталога |
|---|---|
| Контроллер и финальный ответ | anthropic/claude-sonnet-5.5 |
| Оценка релевантности, переформулировка | z-ai/glm-5.3-flash |
| Массовые дешёвые проверки | deepseek/deepseek-v4.1-flash-1017 |
| Эмбеддинги для поиска | qwen/qwen3-embedding-8b |
Стоимость одного вопроса зависит от модели и объёма контекста: в агентном цикле к цене ответа добавляются все промежуточные вызовы. Актуальные цены — в каталоге.
Плюсы и минусы
Плюсы. Отвечает на вопросы, где один поиск проваливается: сравнения, многошаговые запросы, данные, разбросанные по разным источникам. Не тратит контекст на явно нерелевантные фрагменты. Видно, какие источники использованы — трасса вызовов остаётся в логах.
Минусы. На один вопрос уходит несколько вызовов модели, поэтому латентность и стоимость выше, чем у обычного RAG. Цикл может зациклиться или уйти в бесконечные уточнения. Качество зависит от описаний инструментов и от того, насколько надёжна оценка выдачи.
Ограничители, без которых систему не стоит выпускать: лимит итераций (в примере выше — 4), бюджет на запрос и таймаут, правило «если два раза подряд пришло то же самое — отвечать по тому, что есть». Подробнее о том, как не потерять контекст в длинном цикле, — в статье про управление контекстом.
Связанные термины
- Расширенная генерация с поиском (RAG) — базовый подход, который здесь дополняется решениями агента
- Tool Calling API — механизм, через который модель вызывает поиск
- AI Agent — что вообще делает систему агентом
- Structured Output — как получить от модели однозначный вердикт о достаточности контекста
- Agent Harness — обвязка, в которой живёт цикл поиска
- Чанкинг текста для RAG — от нарезки документов зависит, что вообще найдётся