6 тихих отказов AI-агента: когда убедительный ответ ≠ правильное действие

Разница между чат-ботом и AI-агентом не в интеллекте, а в последствиях. Чат-бот генерирует текст; агент совершает действия: вызывает инструменты, запускает многошаговые процессы, и его результат напрямую попадает в конвейеры принятия решений. Именно поэтому традиционный вопрос валидации — «насколько точна модель?» — для агентных систем не работает. Нужен другой вопрос: «как именно эта система может сбойнуть?»

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

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

1. Фактическая галлюцинация

Агент не выдумывает несуществующее число — он берёт реальное, но из неверного контекста. Материал приводит такой пример: в ответ на вопрос о метрике тестовой выборки агент возвращает AUC обучающей (0,8934 вместо 0,8412). Проверка «есть ли это число в документе?» ошибки не поймает — число там есть. Автор указывает, что верификация требует полной проверки: модель — метрика — выборка.

2. Некорректное использование инструментов

Агент выбирает не тот инструмент, и никакого явного сбоя не происходит. В примере из материала вместо submit_escalation агент последовательно вызывает data_lookup и risk_check — замечание по комплаенсу остаётся без эскалации, хотя текст ответа выглядит разумным. Обнаружить это можно только анализом последовательности выполнения действий, не текста.

3. Нарушение корпоративной политики и цепочки эскалаций

Агент действует технически корректно, но в обход регламента. При сбое risk_check он автоматически вызывает submit_escalation, минуя обязательное согласование с руководителем. Инфраструктура отрабатывает штатно, ошибки в логах нет — нарушение всплывает только при аудите. Это режим отказа, невидимый для мониторинга исполнения.

4. Непоследовательное многошаговое рассуждение

На длинных цепочках агент теряет нить. В примере из материала агент находит модель MDL-009 в таблице зависимостей, но не проходит дальше по цепочке к зависимой от неё MDL-001 — и возвращает исходную строку таблицы вместо полной цепочки. Масштаб проблемы иллюстрирует бенчмарк из статьи: на наборе из 520 многошаговых вопросов одна из ведущих моделей при точном совпадении набрала 0% (название модели в источнике не указано); после калиброванной повторной оценки — лишь 50%.

5. Нарушение калибровки уверенности

Агент оценивает уверенность в 8/10 для каждого ответа — независимо от того, верен он или нет. Агрегированные бенчмарки этого не улавливают: усреднённая точность выглядит приемлемо. Но в работе это означает, что неверные ответы принимаются без дополнительной проверки — именно потому, что агент сообщает высокую уверенность. Это тихий сбой, который не видно ни в логах, ни в метриках качества текста.

6. Повреждение состояния между ходами

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

И что же делать

Ошибки исполнения требуют анализа последовательности действий («что агент сделал»), ошибки рассуждения — верификации результата («что агент утверждает»).

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