Семь ошибок в оценке AI-агентов: тесты зелёные, а прод ломается
Tech Lead Сергей Прощаев описал семь ошибок в eval-обвязке AI-агентов, из-за которых тесты показывают успех, а о деградации команда узнаёт от поддержки. Главная причина — проверка финального текста вместо состояния системы.
- Проверка только финального текста не замечает, когда агент сообщает об успешном действии, которого не было.
- Почти все eval-наборы для агентов перекошены в happy path и не проверяют поведение при сбоях.
- Соответствие вызовов инструментов ожидаемым — самое недообсуждаемое измерение в тестировании агентов.
Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E-commerce Сергей Прощаев опубликовал на Хабре разбор семи ошибок в оценке AI-агентов. По его наблюдениям, eval-обвязка — слой, который недооценивают ещё сильнее, чем архитектуру самих агентов.
Типичная картина: у команды есть набор из сорока задач, прогон в CI и отчёт с процентом успеха около девяноста. Через две недели поддержка приносит переписку, где агент отрапортовал «заявка оформлена», а в базе по этой заявке пусто. Сценарий в наборе есть, и он проходит. Тесты не сломаны — они измеряют не то.
Семь ошибок
- Успех считают по финальному тексту, а не по состоянию системы. Модель прекрасно описывает результат, которого не было. Проверка одного лишь ответа не замечает ситуацию, когда агент сообщает об успешном действии, хотя действия не произошло. Прощаев ссылается на τ-bench от Sierra: основной критерий там — соответствие конечного состояния базы целевому. В исходном эксперименте GPT-4o в соответствующей конфигурации решал меньше половины задач.
- Набор состоит из одних happy path. Тесты пишутся по требованиям, а требования описывают нормальное поведение. Прод подсовывает враждебные входы: prompt-инъекции, джейлбрейки, намеренную путаницу. Самый недооценённый класс — структурно валидный, но семантически неверный ответ инструмента: устаревшие данные из поиска, старая схема после миграции, время в другой таймзоне.
- Никто не проверяет, какие инструменты агент вызывал. Ответ связный, задача формально решена, а в трейсе агент дёрнул getOrderStatus вместо cancelOrder и уверенно сообщил, что всё сделано.
Автор отмечает, что таймаут не равен неуспеху: агент получает write-timeout на cancelOrder, честно повторяет вызов, а первая операция уже закоммичена. Если инструмент неидемпотентен, аккуратный агент спокойно проведёт списание дважды.
Как чинить: задачу должно засчитывать проверка перехода состояния, а не его наличия. Правило «на каждую happy-path задачу минимум одна поломка» — это пол, а не потолок. У одного workflow бывает полтора десятка независимых режимов отказа, и правильнее вести их матрицу. Оценка агента — не одна цифра на выходе, а несколько ортогональных измерений, каждое со своим механизмом проверки.
Для профиТехнические детали: архитектура, цифры, ссылки
В статье приведён пример на Kotlin: тест проверяет переход состояния заказа, а не его наличие, разводит транзакционную запись в outbox и доставку события, а также использует await() для ожидания доставки.
Проверка одного лишь финального текста не замечает ситуацию, когда агент сообщает об успешном действии, хотя действия не произошло.
Автор ссылается на τ-bench от Sierra, где основной критерий — соответствие конечного состояния базы целевому, а для части задач дополнительно проверяется обязательный текстовый вывод.
Вопросы и ответы
- Почему тесты AI-агентов показывают успех, а в проде сбои?
- Потому что проверка сравнивает финальный текст ответа, а не состояние системы: агент может сообщить об успешном действии, которого не было.
- Что такое τ-bench?
- Бенчмарк от Sierra, где основной критерий — соответствие конечного состояния базы целевому, а для части задач дополнительно проверяется обязательный текстовый вывод.
- Как правильно проверять действия агента?
- Проверять переход состояния, а не его наличие, и отдельно контролировать, какие инструменты агент вызывал и с какими аргументами.
