Agentic RAG — RAG с агентами

Короткая версия

Agentic RAG имеет смысл, когда вопрос:

• сложный и составной;
• требует нескольких источников;
• требует tool calls, а не только retrieval;
• может потребовать повторного поиска;
• не укладывается в retrieve once -> answer once.

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

Вопрос: «Сравни два тарифных плана, проверь актуальные лимиты и посчитай, какой дешевле при 2000 запросах в день»

Когда это оправдано

• enterprise research assistant;
• support agent с несколькими системами;
• financial or ops assistant с SQL/API/tools;
• internal copilots, которым нужен KB + web + app data.

1. Чем agentic RAG отличается от обычного RAG

2-step RAG выглядит так:

question -> retrieve -> answer

Agentic RAG выглядит ближе к такому циклу:

question
-> decide whether to retrieve
-> choose source/tool
-> retrieve or call tool
-> inspect result
-> continue or stop
-> answer

Ключевой сдвиг в том, что retrieval становится управляемой серией решений, а не фиксированным шагом конвейера.

2. Routing важнее, чем “автономность”

На практике самый полезный агентный слой часто не в том, что система “думает как человек”, а в том, что она умеет правильно маршрутизировать запросы.

Например:

• company policy question -> internal KB;
• свежий рыночный факт -> web search;
• user account question -> CRM / SQL / API;
• вычисление -> calculator / code tool;
• простой общий вопрос -> direct answer without retrieval.

Это уже сильный upgrade относительно схемы “любой запрос всегда идёт только в vector search”.

3. Multi-step retrieval нужен не так часто, но иногда решает всё

Есть вопросы, которые нельзя закрыть одним retrieval call:

• compare X and Y across multiple docs;
• find source, then verify freshness;
• собрать answer из нескольких systems;
• сначала найти сущность, потом дочитать детали;
• сначала найти policy, потом проверить exception.

Именно здесь agentic RAG выигрывает у обычного pipeline. Он может:

1. сделать первый retrieval;
2. понять, чего не хватает;
3. сформировать следующий sub-query;
4. добрать недостающий контекст;
5. остановиться только когда coverage достаточен.

4. Tool use делает retrieval частью workflow, а не единственным инструментом

Практический агентный RAG редко ограничивается одной retrieval function.

Обычно рядом появляются:

• file_search;
• web_search;
• SQL / database queries;
• CRM or ticketing APIs;
• calculator / code execution;
• knowledge-specific MCP tools.

Это важно, потому что часть вопросов требует не “найти текст”, а:

• посчитать;
• сверить;
• вызвать внутренний сервис;
• собрать данные из structured и unstructured sources.

5. Stop criteria и budgets — обязательная часть

Agentic retrieval легко выходит из-под контроля, если не задать рамки.

Практически всегда нужны:

• max number of search steps;
• max web calls;
• timeout budget;
• token / cost budget;
• explicit “insufficient evidence” exit.

Без этого agentic RAG превращается в дорогой loop, который делает вид, что “исследует”, а на деле просто повторяет похожие запросы.

6. Agentic RAG не отменяет обычный retrieval quality

Частая ошибка: думать, что агент спасёт плохой retrieval stack.

Если:

• chunking слабый;
• filters broken;
• hybrid search не настроен;
• reranking отсутствует;
• индекс грязный,

то агент просто будет много раз ходить в плохой retrieval.

Поэтому normal order такой:

1. сначала довести baseline retrieval;
2. потом добавлять orchestration.

7. Где agentic RAG действительно силён

Особенно хорош в сценариях:

• research assistants;
• deep support triage;
• enterprise copilots with multiple systems;
• due diligence / audit / ops flows;
• workflows с обязательной проверкой источников и next-step decisions.

Хуже всего оправдан для:

• простого docs QA;
• маленького FAQ;
• сценариев со строгим low-latency SLA;
• задач, где ответ почти всегда есть в одном документе.

8. Хороший agentic RAG в 2026 — это workflow, а не свободный хаос

Anthropic, LangChain и OpenAI-паттерны сходятся в одном: самые полезные агентные системы обычно не полностью открытые, а имеют понятный workflow:

• router;
• retriever(s);
• evaluator;
• optional web lookup;
• synthesis step;
• final answer.

То есть practical agentic RAG ближе к structured workflow with decisions, чем к “полностью автономному исследователю”.

Минимальный workflow

from openai import OpenAI

client = OpenAI()

tools = [
    {
        "type": "file_search",
        "vector_store_ids": ["vs_internal_docs"],
    },
    {
        "type": "web_search_preview",
    },
]

response = client.responses.create(
    model="gpt-5-mini",
    input="Сравни внутреннюю политику возвратов с публичной FAQ и отметь расхождения.",
    tools=tools,
)

Но production-grade version обычно оборачивает это в workflow с:

• route classifier;
• per-tool budgets;
• answer verification;
• escalation path;
• traces.