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

Цикл агента работает примерно так: разобрать вопрос пользователя, построить план извлечения, выполнить извлечение или вызовы инструментов, синтезировать результаты, проверить, отвечают ли они на вопрос, затем либо остановиться и ответить, либо вернуться на другой проход. Это тот же паттерн извлечение → рассуждение → решение, описанный в архитектурах в стиле ReAct, и он хорошо работает, когда запросы требуют многошагового рассуждения или доказательства, разбросанные по разным источникам.

Но цикл вводит базовую хрупкость. Агент оптимизирует локально. На каждом шаге он спрашивает: «У меня достаточно?» и когда ответ неясен, по умолчанию переходит к «получить больше». Без жёстких правил остановки по умолчанию спираль идёт вверх. Агент извлекает больше, эскалирует, извлекает снова, каждый проход сжигает токены без гарантии прогресса. В официальном учебнике LangGraph по агентной RAG была ровно эта ошибка: бесконечный цикл извлечения, который требовал крышки rewrite_count для исправления. Если эталонная реализация может зацикливаться вечно, production-системы определённо будут.

Исправление — это не лучший prompt. Это бюджетирование, gating и лучшие сигналы.

Таксономия режимов отказа: что ломается и почему

Дрожание поиска: цикл, который никогда не сходится

Дрожание поиска — это агент, повторно извлекающий информацию без выхода на ответ. В трассах это видно чётко: почти дублирующиеся запросы, колеблющиеся поисковые термины (расширение, затем сужение, затем снова расширение) и качество ответов, остающееся плоским во всех итерациях.

Конкретный сценарий. Пользователь спрашивает: «Какова наша политика возмещения расходов для удалённых сотрудников в Калифорнии?» Агент извлекает общую политику возмещения. Его верификатор отмечает ответ как неполный, потому что он не упоминает специфические для Калифорнии правила. Агент переформулирует: «Возмещение расходов для удалённой работы в Калифорнии». Он извлекает слегка связанный документ HR. Всё ещё не уверен. Он переформулирует снова: «Трудовой кодекс Калифорнии, возмещение расходов». Три итерации спустя он сжёг свой бюджет извлечения, и ответ едва ли лучше, чем после первого раунда.

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

Штормы инструментов и переполнение контекста: когда агент наводняет себя

Штормы инструментов и переполнение контекста обычно происходят вместе, и каждое усугубляет другое.

Шторм инструментов происходит, когда агент делает чрезмерные вызовы инструментов: каскадные повторы после timeouts, параллельные вызовы, возвращающие избыточные данные, или стратегия «вызвать всё для безопасности» когда агент неуверен. Один стартап задокументировал агентов, делающих 200 вызовов LLM за 10 минут, сжигая $50–$200 прежде чем кто-либо заметил. Другой увидел, как затраты подскочили на 1,700% во время сбоя провайдера, когда логика повтора спиралью вышла из-под контроля.

Переполнение контекста — это нисходящий результат. Массивные выходы инструментов вставляются прямо в контекстное окно: сырой JSON, повторяющиеся промежуточные резюме, растущая память до тех пор, пока внимание модели слишком разреженное для следования инструкциям. Исследования последовательно показывают, что модели уделяют меньше внимания информации, похороненной в середине длинных контекстов. Исследование Stanford и Meta «Lost in the Middle» обнаружило падение производительности на 20+ процентных пункта, когда критическая информация находится в середине контекста. В одном тесте точность многодокументного вопросно-ответного взаимодействия фактически упала ниже производительности с закрытой книгой при включении 20 документов, что означает добавление извлечённого контекста активно ухудшило ответ.

Основные причины: отсутствие бюджетов или лимитов скорости для каждого инструмента, отсутствие стратегии сжатия для выходов инструментов и конфигурация извлечения типа «втиснуть всё», которая рассматривает top-20 как разумное по умолчанию.

Как обнаружить эти отказы рано

Вы можете поймать все три режима отказа с небольшим набором сигналов. Цель — сделать молчаливые отказы видимыми прежде чем они появятся в вашём счёте.

Количественные сигналы для отслеживания с первого дня:

  • Вызовы инструментов за задачу (среднее и p95): скачки указывают на штормы инструментов. Исследуйте выше 10 вызовов; жёсткая остановка выше 30.
  • Итерации извлечения на запрос: если медиана 1–2, но p95 составляет 6+, у вас проблема дрожания на сложных запросах.
  • Скорость роста длины контекста: сколько токенов добавляется за итерацию? Если контекст растёт быстрее, чем полезное доказательство, у вас есть переполнение.
  • p95 задержка: хвостовая задержка — это то место, где скрываются агентные отказы, потому что большинство запросов заканчиваются быстро, а несколько спиралей вверх.
  • Стоимость за успешную задачу: самая честная метрика. Она штрафует впустую потраченные попытки, не только среднюю стоимость за запуск.

Качественные трассы: заставьте агента обосновать каждый цикл. На каждой итерации регистрируйте две вещи: «Какое новое доказательство было получено?» и «Почему этого недостаточно для ответа?» Если обоснования расплывчаты или повторяются, цикл дрожит.

Как каждый отказ отображается на скачках сигналов: дрожание поиска проявляется в виде растущих итераций, в то время как качество ответа остаётся плоским. Штормы инструментов проявляются в виде скачков количества вызовов наряду с timeouts и скачками стоимости. Переполнение контекста проявляется в виде роста токенов контекста, в то время как следование инструкциям деградирует.

Правила срабатывания (установленные как жёсткие крышки): максимум 3 итерации извлечения; максимум 10–15 вызовов инструментов за задачу; потолок токенов контекста относительно эффективного окна вашей модели (не её заявленного максимума); и временной лимит на каждый запуск. Когда срабатывает срабатывание, агент чисто останавливается и возвращает свой лучший ответ с явной неопределённостью, не более повторов.

Смягчение и рамка принятия решений

Каждый режим отказа отображается на конкретные смягчающие меры.

Для дрожания поиска: реализуйте явный верификатор, который не только отклоняет, но указывает, какой конкретный контекст отсутствует. Добавьте критерий сходимости: если две последовательные итерации извлекают результаты с перекрытием > 80%, остановитесь. Если вы думаете, что три цикла недостаточно для вашего сценария использования, это знак того, что классическое RAG с лучшей фильтрацией перед агентом может быть более эффективным.