ИИ-агент с RAG: когда retrieval нужен агенту, а когда достаточно поиска

Раздел

AI-агенты для бизнеса

Сложность

средняя

Обновлено

2026-05-22

Короткий ответ

ИИ-агенту нужен RAG не всегда. Retrieval нужен внутри tool loop, когда агент должен сам решать, какие источники запросить, уточнить вопрос, собрать несколько фрагментов и только потом выполнить действие или передать человеку. Если задача сводится к одному вопросу и одному источнику, обычный поиск или classic RAG часто надежнее.

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

Эта статья связывает AI агент, создание AI-агента и RAG-кластер: RAG система, RAG база знаний и RAG для службы поддержки.

Краткий brief

Когда агенту нужен retrieval

Retrieval становится частью агентного контура, когда вопрос требует решения, а не только ответа. Агент должен выбрать источник, проверить ограничение, собрать контекст и иногда отказаться от действия.

Примеры:

OpenAI в документации File search описывает hosted tool, который позволяет модели искать по vector stores перед ответом. Для agentic сценария важно не само наличие tool, а политика его использования: когда агент обязан искать, сколько результатов брать, как показывать annotations и когда не продолжать без источника.

Когда достаточно поиска

Не делайте agentic RAG там, где обычный поиск лучше.

Достаточно search или classic RAG, если:

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

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

Tool loop architecture

Безопасный агентный RAG контур выглядит так:

user request
  -> intent and risk classification
  -> retrieval tool with access filters
  -> source check and citation plan
  -> optional second retrieval or clarification
  -> answer, draft action or escalation
  -> audit log and eval trace

Важное ограничение: retrieval tool не должен видеть больше, чем пользователь или роль агента. AWS guidance по secure RAG прямо выделяет retrieval-time metadata filtering and role-based access controls, а также provenance and source attribution. Значит, фильтры прав должны быть частью tool call, а не просьбой в prompt.

Минимальный tool contract:

retrieval_tool:
  allowed_sources: [support_kb, product_docs]
  required_filters: [user_group, document_status, product_version]
  max_results: 6
  must_return: [source_url, title, section, updated_at, owner]
  forbidden_sources: [drafts, personal_notes, incident_logs]

Context window и citations

Длинный context window не отменяет retrieval. Большое окно помогает держать больше текста, но не отвечает на вопросы:

• какие источники актуальны;
• что пользователь имеет право видеть;
• какой документ устарел;
• какой фрагмент является authoritative;
• где citation;
• когда надо отказаться.

Microsoft в RAG material для Azure AI Search отдельно описывает structured responses with grounding data, citations and execution metadata для agentic retrieval. Для бизнеса это важнее красивого ответа: можно восстановить, какой источник был выбран и почему.

Плохой ответ агента: “по политике можно закрыть заявку”. Хороший ответ: “в текущем runbook от 2026-05-10 закрытие без подтверждения клиента запрещено; нужен escalation в L2” и ссылка на источник.

Guardrails и escalation

Agentic RAG должен уметь останавливаться. Чем больше tools, тем важнее refusal и escalation.

Останавливайте агента, если:

• retrieval не нашел approved source;
• найденный источник просрочен по freshness SLA;
• источники конфликтуют;
• пользователь просит действие без citation;
• вопрос затрагивает деньги, договор, безопасность, персональные данные или права доступа;
• агенту нужен write tool, но нет approval;
• score retrieval ниже порога.

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

Пилотный сценарий

Начните с одного сценария, где агент получает пользу от retrieval, но не может навредить.

Пример для поддержки:

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

Чеклист

• Есть конкретный workflow, а не абстрактный “агент с базой знаний”.
• Понятно, почему обычного поиска недостаточно.
• Retrieval tool применяет access filters до передачи контекста модели.
• Tool возвращает source URL, section, owner, updated_at и статус.
• Агент обязан показать citation или отказаться.
• Есть правила second retrieval, clarification и escalation.
• Write actions отключены до отдельного approval.
• В eval есть вопросы без ответа, закрытые источники и конфликтующие документы.
• Логи хранят trace, но не секреты и customer data.
• После 20-50 сценариев есть решение: оставить classic RAG, включить agentic retrieval или остановить.

FAQ

Agentic RAG всегда лучше classic RAG?

Нет. Agentic retrieval полезен для сложных, многошаговых вопросов. Для простых запросов classic RAG быстрее, проще и легче проверяется.

RAG система AI и ИИ-агент с RAG - это одно и то же?

Нет. RAG система отвечает на вопрос по источникам. ИИ-агент с RAG использует retrieval как один из tools внутри многошаговой задачи: найти источник, проверить риск, подготовить действие или остановиться.

Можно ли дать агенту доступ ко всей базе знаний?

Для пилота не стоит. Дайте один corpus, allowed sources, metadata filters и clear forbidden sources. Расширяйте только после eval.

Что важнее: хороший retriever или сильная модель?

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

Нужен ли RAG coding agent?

Иногда да: для актуальной документации, локального кода, changelog и API contracts. Но coding agent все равно должен работать через allowed paths, review и tests. Для командной разработки смотрите AI code для команды и AI coding agents.

Что читать дальше?

Сначала откройте AI агент, затем создание AI-агента и RAG систему. Если сценарий про поддержку, продолжите с RAG для службы поддержки.