Суть
Классический APM отвечает на вопрос «сервис работает?». У агента этот вопрос почти всегда имеет ответ «да» — и почти всегда бесполезен. Успешный ответ с кодом 200 может стоить бизнесу полдоллара, вернуть галлюцинацию из-за раздутого контекста и увести клиента не туда. Мониторинг слеп именно к ветвлению графа: он видит транспорт, но не видит смысл.
Поэтому режимы отказа стоит держать как отдельный список с привязкой к сигнатурам в телеметрии — иначе их не отличить друг от друга постфактум.
Матрица сбоев
| Тип сбоя | Как выглядит в APM | Что произошло на самом деле |
|---|---|---|
| Семантический сбой | 200 OK, latency 2 с | Модель согласилась выдать закрытые данные — сработала инъекция |
| Голодание RAG | Запрос к базе — 200 OK | Ретривер вернул пустой список, ответ сгенерирован на весах модели, то есть выдуман |
| Бесконечная петля | 200 (in progress) | Агент повторно вызывает один инструмент, счёт за токены растёт экспоненциально |
| Отказ безопасности | 200 OK | Guardrail отсёк выход, клиент получил пустой ответ вместо результата |
Три сигнатуры, на которые ставят алерты
Infinite Loops. Причина — отсутствие условия выхода: агент уходит на двадцать и больше итераций вызова инструмента. Лечится жёстким лимитом max_iterations в оркестраторе плюс алертом на рост числа спанов с span.kind == TOOL внутри одного трейса.
Memory Corruption. В долговременный контекст попадает некорректный JSON, и дальше система работает с испорченным состоянием. Лечится строгими Pydantic-схемами на каждом узле графа, а не проверкой в конце.
Cascade Collapse. Один неверный шаг в цепочке RAG отравляет контекст, и вся последующая генерация идёт от ложной предпосылки. Лечится обязательной проверкой обоснованности (groundedness check) перед сборкой финального ответа.
По оценке из вебинара, на эти три приходится около 80% сбоев в проде — оставшиеся 20% штучные и редко повторяются.
Почему это отдельная заметка
Список режимов отказа — это то, из чего вырастает и алертинг, и набор регрессионных тестов, и требования к трейсингу. Он же объясняет, почему нельзя переиспользовать пороги из обычного бэкенда: там рост числа ошибок 5xx означает поломку, здесь поломка не меняет коды ответов вообще.
Связано с
- Agent Observability — трейсинг как способ вообще увидеть эти сбои
- OpenInference — типы спанов, по которым распознаются сигнатуры
- Agent Evals — оценка качества ловит семантические сбои, которых нет в метриках
- Guardrails — источник четвёртого режима: защита сработала, а пользователь остался без ответа
- Agent CostControl — бесконечные петли бьют в первую очередь по бюджету
Открытые вопросы
- какой порог роста tool-спанов внутри трейса брать за триггер алерта, чтобы не ловить ложные срабатывания на легитимных длинных задачах
- как отличить голодание RAG от осмысленного ответа по общим знаниям, когда пустой результат ретривера допустим