Две модели успешно решили по 20 задач службы поддержки, но после семи намеренных поломок рабочего агента выбранная метрика обнаружила только две. Этот эксперимент показывает, почему мониторинг AI-агентов нельзя сводить к красивому проценту успешных ответов: для команд, внедряющих LLM в поддержку, продажи или внутренние процессы, «20 из 20» может означать лишь то, что тест оказался слишком добрым.
Как сообщает The New Stack, автор Кейоде Оджо в сентябре прогнал две модели через одинаковый набор из 20 support-задач. В базовом сценарии обе получили максимальный результат. Затем он стал последовательно ломать уже работающего агента — всего семью разными способами — и сравнивать реакцию наблюдаемой метрики с фактическими проблемами. Совпадение оказалось неполным: сигнал появился только в двух случаях.
Главная неприятность здесь не в том, что один показатель оказался несовершенным. Это ожидаемо: метрика всегда описывает лишь тот срез системы, который в неё заложили. Проблема в более привычном для AI-проектов сценарии: команда видит стабильный дашборд, проходит набор проверочных диалогов и делает вывод, что агент готов к production. Между тем агент — не просто модель, отвечающая на вопрос. Он использует инструкции, контекст, инструменты, историю общения, маршрутизацию и ограничения доступа. Ошибка на любом из этих слоёв может не ухудшить формальный балл, но испортить ответ пользователю или бизнес-процесс.
Классический тестовый набор проверяет заранее известные примеры. Он полезен для регрессии: после изменения промпта или модели можно быстро увидеть, не сломались ли привычные сценарии. Но он плохо отвечает на другой вопрос: что произойдёт, когда в production изменится входной контекст, внешний инструмент вернёт неполный результат, модель неверно интерпретирует инструкцию или агент уверенно выберет неподходящее действие? В отличие от обычного сервиса с более-менее детерминированным поведением, LLM-система способна выдать правдоподобный, но неверный результат — и не оставить в обычном статус-коде ни малейшего намёка на беду.
Именно поэтому мониторинг AI-агентов стоит строить как набор взаимодополняющих проверок, а не как один KPI. Оценка качества финального ответа нужна, но рядом с ней должны жить технические и продуктовые сигналы: доля ошибок вызовов инструментов, время выполнения цепочки, число повторных попыток, случаи передачи человеку, отменённые действия, жалобы пользователей и расхождения между ожидаемым и выполненным действием. Для чувствительных сценариев — финансовых операций, HR, доступа к данным, юридических консультаций — отдельного контроля требуют сами действия агента, а не только текст в последнем сообщении.
Разработчикам это добавляет работы ещё до релиза. Нужно сохранять трассировку выполнения: какие инструкции получил агент, какие шаги сделал, к каким инструментам обратился и что получил в ответ. Без такой картины инцидент превращается в знакомую игру «почему бот сказал именно это», где есть лог, но нет причинной цепочки. Полезны и контролируемые негативные тесты: намеренно повреждать контекст, ограничивать ответ инструмента, менять условия маршрутизации, подавать неоднозначные запросы. Не для того, чтобы добиться стопроцентного покрытия невозможного, а чтобы заранее понять, какие поломки существующий контроль вообще не замечает.
Продактам и владельцам процессов стоит отдельно договориться, что именно считать успехом. Если бот быстро отвечает, но регулярно направляет клиента не в тот поток, средняя скорость выглядит отлично, а операционная нагрузка растёт. Если агент завершает заявку технически корректно, но делает это без обязательной проверки, проблема уже не в качестве генерации, а в контроле бизнес-правил. Метрики должны быть привязаны к последствиям: решён ли запрос, понадобилось ли вмешательство человека, было ли действие обратимым, не возникла ли ошибка в данных или доступах.
Эксперимент с семью поломками не доказывает бесполезность автоматической оценки — он показывает её границы. По мере того как агенты получают право не только отвечать, но и вызывать API, менять записи и запускать процессы, мониторинг AI-агентов станет ближе к наблюдаемости распределённых систем и контролю рисков, чем к разовой проверке чат-бота. Вопрос для команд теперь не «какой у нас score», а «какой реальный сбой пройдёт мимо него и кто заметит это первым».
