Agentic RAG: when an agent should control retrieval

Классический RAG — фиксированный конвейер: запрос всегда проходит одни и те же шаги, retrieval выполняется ровно один раз, и модель обязана отвечать по тому, что принесли. Agentic RAG переворачивает управление: поиск становится инструментом (tool) в цикле агента, и модель сама решает, вызывать ли его, с каким запросом, сколько раз и когда остановиться. Роутинг, переписывание запроса и multi-hop из прошлого урока перестают быть отдельными подсистемами — они становятся поведением модели в цикле «подумай → вызови инструмент → посмотри на результат → повтори или отвечай».

Это снимает главное ограничение конвейера — одинаковую обработку неодинаковых запросов. Простой вопрос агент закрывает одним вызовом поиска; сравнительный — серией вызовов с разными запросами; вопрос-цепочку — последовательными хопами, где следующий запрос формулируется по результатам предыдущего. Никакой ручной логики decomposition — современные модели уровня Claude или GPT-4o делают это из коробки, если инструмент хорошо описан.

Цена свободы: латентность и стоимость становятся непредсказуемыми (агент может сделать и один, и восемь вызовов), отладка сложнее (трасса у каждого запроса своя), а слабая модель в цикле деградирует хуже конвейера — зацикливается на неудачных запросах или отвечает без поиска вовсе. Отсюда рабочее правило: agentic RAG выбирают, когда распределение запросов разнородно и заранее не классифицируется; для узкого предсказуемого потока (FAQ-бот) фиксированный конвейер быстрее, дешевле и стабильнее. Гибрид — роутер, отправляющий простые запросы в конвейер, сложные — агенту.

Агент вызывает поиск так, как он описан. Плохое описание — «ищет документы» — даёт запросы-копии вопроса пользователя и один вызов там, где нужно три. Рабочая сигнатура делает семантику явной:

search_kb = {
  'name': 'search_knowledge_base',
  'description': (
    'Гибридный поиск по базе знаний продукта (документация, '
    'релиз-ноуты, тарифы; обновляется ежедневно). Формулируй запрос '
    'как короткую фразу с ключевыми терминами, НЕ копируй вопрос '
    'пользователя дословно. Для сравнений делай отдельный вызов '
    'на каждую сущность. Если результаты нерелевантны — переформулируй '
    'и повтори, максимум 4 вызова на задачу.'
  ),
  'input_schema': {
    'type': 'object',
    'properties': {
      'query': { 'type': 'string' },
      'source': { 'type': 'string', 'enum': ['docs', 'release_notes', 'pricing'] },
      'top_k': { 'type': 'integer', 'default': 8 },
    },
    'required': ['query'],
  },
}

Три решения, которые здесь зашиты. Разные источники — либо enum-параметр, либо отдельные инструменты (search_docs, search_tickets, query_metrics_sql): отдельные инструменты лучше, когда у источников разная семантика и формат результата. Инструкции по формулировке запросов живут в description — это самое читаемое моделью место. Лимит вызовов продублирован и в описании, и жёстко в коде цикла: модельному самоограничению доверять нельзя.

Результат инструмента тоже проектируется: возвращайте не сырые чанки, а компактные сниппеты с id, заголовком, датой и «крошками» раздела — агенту нужно решить, достаточно ли этого, а полные тексты можно подгрузить отдельным инструментом fetch_document.

Главный выигрыш agentic RAG в контроле галлюцинаций — способность не отвечать по мусору. В конвейере, если retrieval принёс нерелевантные чанки, модель всё равно генерирует ответ. Агент может оценить находки и скорректировать курс.

Паттерн CRAG (Corrective RAG) формализует это: после поиска лёгкий оценщик (отдельный дешёвый LLM-вызов или обученный классификатор) присваивает результатам метку correct / incorrect / ambiguous. Correct — идём в генерацию; incorrect — переформулированный повторный поиск или запасной источник (веб-поиск вместо локальной базы); ambiguous — комбинируем оба пути. Self-RAG идёт дальше: модель обучена генерировать специальные рефлексивные токены — «нужен ли поиск», «релевантен ли фрагмент», «подтверждён ли ответ» — но в продакшене чаще воспроизводят ту же логику обычными промптами поверх готовой модели.

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

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

Собирая всё вместе, продакшен-агент с retrieval выглядит так:

• Роутер на входе: no-retrieval / конвейер / агент — по сложности запроса.
• Набор инструментов: search_knowledge_base (гибрид + reranker внутри — агенту незачем знать про RRF), fetch_document, при необходимости web_search и query_sql.
• Жёсткие бюджеты в коде: максимум вызовов инструментов (обычно 4–6), таймаут всей задачи, потолок токенов на трассу.
• Оценка находок перед генерацией (CRAG-подобная) и разрешение на отказ от ответа.
• Трассировка каждого шага в observability-систему (Langfuse, OpenTelemetry).

Частые провалы и их причины. Агент копирует вопрос пользователя в поисковый запрос — лечится описанием инструмента и примерами в system-промпте. Агент зацикливается на переформулировках одного неудачного запроса — лечится лимитом вызовов и инструкцией «после двух неудач меняй стратегию, а не слова». Агент отвечает без поиска на вопрос из базы — лечится инструкцией «для фактических вопросов о продукте всегда вызывай поиск» и eval’ом, который это ловит.

И контрольный вопрос перед выбором этой архитектуры: сможете ли вы объяснить по трассе, почему агент ответил именно так? Если наблюдаемости нет, agentic RAG превращается в недетерминированный чёрный ящик, и команда откатится на конвейер после первого серьёзного инцидента. Наблюдаемость — не дополнение к архитектуре, а её несущая часть.