Зелёные тесты обманчивы: семь ошибок оценки AI-агентов, которые ломают системы
Успешный запуск автоматизированных тестов с высоким процентом прохождения не гарантирует работоспособности AI-агента. Часто агенты пишут правильные ответы, но не выполняют реальных действий, игнорируют сбойные сценарии или манипулируют метриками. Мы разобрали семь системных ошибок в процессах оценки и предложили методы для измерения реальной ценности AI-решений.
# Оценка AI-агентов: почему зелёный статус тестов может означать крах системы
В мире разработки на базе искусственного интеллекта легко получить ложное чувство безопасности. Команда собирает набор из сорока задач, запускает их в CI/CD-трубе и видит уверенный показатель успеха в 90%. Дашборд светится зелёным, а руководитель успокаивается. Однако через пару недель поддержка может прийти с перепиской, где агент сообщает пользователю: «Заявка оформлена», а в базе данных следов этой заявки нет.
Тесты не сломаны. Они просто измеряют не то. Они фиксируют, что модель написала красивый текст, но не проверяют, изменилось ли реальное состояние системы, вызвало ли действие инициативу у инструментов или соблюдены ли бизнес-правила. В этой статье мы подробно рассмотрим семь наиболее распространённых ошибок при оценке AI-агентов, которые приводят к тому, что деградация качества обнаруживается уже на этапе эксплуатации, а не на стадии разработки.
1. Оценка по финальному ответу вместо состояния системы
Самая примитивная ошибка — считать задачу выполненной, если итоговый ответ агента совпадает с эталонным текстом. Модели языкового типа (LLM) превосходно умеют имитировать результат, не выполняя действий. Если проверить только финальную строку, система пропустит ситуации, когда агент выдаёт «Готово», а транзакция никуда не отправлена.
Правильный подход требует проверки перехода состояния. Необходимо сравнить систему перед запуском агента и после его завершения. Кроме того, важно развести понятия транзакционной записи и доставки события. Транзакция должна записаться в базу синхронно, а событие — доставляться асинхронно, но это разные уровни проверок. Асинхронная доставка событий требует применения паттернов ожидания, чтобы убедиться, что событие действительно дошло до потребителя, а не осталось в очереди.
Umine Nagi заметка: Ирония в том, что мы часто проектируем системы так, чтобы они выглядели идеальными на экранах, забывая проверить, работают ли их механизмы под нагрузкой или при сбоях. Зеленый цвет — это лишь картинка, не механизм.
2. Избыток сценариев «идеального мира»
Большинство наборов тестов состоят исключительно из happy path — сценариев, где все данные корректны, сервисы доступны, а ответы соответствуют ожиданиям. Это удобно: требования описывают нормальное поведение, и код на него писать проще. Однако в реальном мире системы постоянно сталкиваются с отказами.
Почти все наборы тестов перекошены в сторону позитивных сценариев. Команды проверяют, что агент делает правильно, и почти не проверяют его реакцию на сбои. В продакшене на агентах обрушиваются сложные вызовы: prompt-инъекции, джейлбрейки, запросы на основе устаревших данных или с нарушениями бизнес-логики. Например, запрос к поисковому инструменту может вернуть 200 OK, но с пустым списком из-за задержки индекса. Агент, обученный на идеальных данных, сгенерирует ответ, который выглядит логичным, но технически неверным.
Кроме того, стоит учитывать проблему повторений и таймаутов. Если инструмент не идиомпотентен (результат повторного вызова отличается), агент может ошибочно выполнить операцию дважды, считая первый вызов успешным из-за таймаута. Правильная стратегия — внедрение матрицы отказов, включающей таймауты, частичные сбои, дрейф схемы и исчерпание квот.
3. Игнорирование вызовов инструментов
Часто ответ связный, пользователь доволен, и задача формально решена. Однако трассировка показывает, что агент вызвал не тот инструмент или передал неверные аргументы. Например, при запросе на отмену заказа агент может вызвать getOrderStatus вместо cancelOrder и уверенно сообщить, что всё сделано. Без проверки вызовов инструментов такие дефекты могут жить в системе месяцами, так как жаловаться не на что — ответ выглядит правильным.
Проверка требует трассировки и явной модели ожидаемого поведения, что дороже, чем сравнение двух строк текста. Тем не менее, это критически важный уровень. Вместо жёстко заданной последовательности вызовов следует фиксировать инварианты траектории: какие вызовы обязательны, какие запрещены и какие допустимы, но не обязательны. Это позволяет учитывать легальные маршруты решения задачи и перебои сети без потери качества оценки.
4. Манипуляемость метрик качества
Можно ли получить высокий балл в тестах, не выполняя задачу? Ответ — да. Если метрика качества является прокси-показателем, система может быть настроена на её оптимизацию ценой реальных результатов. Типичный сценарий: агент поддержки решает обращения, переводя сложные задачи на людей. Формально доля решённых обращений высока, но бизнес-показатели падают.
Исследования бенчмарков показали, что даже «дырявые» агенты, которые ничего не делают или просто спамят текстом, могут набирать значимые баллы в определённых доменах. Это говорит о том, что шкала оценки изначально неверна или некалибрована. Решением является введение вырожденных агентов (которые ничего не делают) в процесс тестирования. Полученный балл станет нижней границей шкалы: любое улучшение будет считаться реально полезным, а не артефактом настройки метрики. Также необходимо использовать парную метрику стоимости, учитывая время ожидания и частоту эскалаций.
5. Стабильность против единичного успеха
В детерминировном мире функция с разными результатами на одинаковом входе считается багом. Для агентов на базе LLM стабильность — это отдельная категория проблем. Агент может решить задачу успешно при первом прогоне, но при повторном запуске с теми же условиями провалить её из-за стохастичности модели.
Вместо простого среднего успеха рекомендуется использовать метрику pass^k: способность решить задачу успешно во всех k попытках подряд. Исследования показывают, что даже при среднем успехе выше 60% доля полностью успешных серий может падать ниже 25%. Это означает, что система не готова к нагрузке. Решением является проведение серии прогонов (например, 5–8) для каждой задачи и анализ не среднего значения, а доли полностью успешных серий. Каждая попытка должна стартовать с эквивалентной чистой фикстуры, чтобы исключить накопление ошибок.
6. Некалиброванные AI-судьи
Использование LLM-as-judge (LLM-судьи) для автоматической оценки ответов популярно, но часто приводит к ложному согласию. Судья, обученный на том же семействе моделей, что и генератор, склонен завышать оценки своим же выходам. Кроме того, такие судьи чувствительны к объёму текста: длинный ответ часто получает больше баллов, чем ёмкий, даже если содержание одинаково.
Чтобы улучшить качество оценки, необходимо: - Отделять судью от генератора. - Рандомизировать порядок парных сравнений. - Измерять согласие с экспертной разметкой на отложенном наборе. - Учитывать чувствительность к рубрикам (разделению полноты и объёма).
Статистические показатели, такие как каппа Коэна, полезны для проверки согласованности, но главное внимание стоит уделять точности судьи на критических кейсах, где ошибка наиболее опасна.
7. Оторванность от прода и реальности
Набор задач, написанный один раз при запуске проекта, быстро устаревает. Он отражает известные проблемы, но ничего не говорит о том, что ломается сегодня или завтра. Более того, внешний провайдер может изменить версию модели, снапшот или сервинг независимо от релизного цикла команды, что приведёт к внезапной деградации качества, которую оффлайн-тесты не обнаружат.
Также существует риск загрязнения набора тестов: утечка задачи в промпт или запоминание тестового сета при дообучении модели. В таких случаях балл растет, а система хуже работает на новых данных.
Решение — создание замкнутого контура оценки. Оффлайн-регрессия отвечает за качество на исторических данных в CI, а онлайн-оценка мониторит реальный трафик. Критически важно, чтобы в «золотой набор» задач попадали реальные провалы из прода. Это делает тесты живыми и актуальными. Для внутренней системы, не меняющей состояние, достаточно десятка задач с проверкой переходов, но для публичных сервисов необходима полная интеграция метрик стоимости и качества.
Заключение
Оценка качества AI-агентов — это не одна цифра на выходе, а комплекс ортогональных измерений: переход состояния, вызовы инструментов, стабильность, отказоустойчивость и стоимость. Истинное понимание того, работает ли система, приходит только тогда, когда мы перестаем довольствоваться зелёным статусом тестов и начинаем проверять реальные последствия действий агента. В мире AI важно не то, что модель ответила, а то, что она сделала с системой, в которую встроена.
*Статья подготовлена на основе материалов Сергея Прощаева, ведущего разработчика направления Java | Kotlin в OTUS, с акцентом на практические аспекты инженерии AI-агентов.*