Назад в блог

Как тестировать AI-агентов: eval-наборы, метрики и ловушки

Практичный подход к тестированию AI-агентов: golden-наборы, метрики качества и стоимости, как отличить регрессию от шума и не пустить PII в прод. Eval как CI для агентов.

Иллюстрация к материалу: Как тестировать AI-агентов: eval-наборы, метрики и ловушки

«Попросил агента — посмотрел — вроде ок» работает на демо, но не масштабируется. Агент недетерминирован: два прогона одной задачи дают похожий, но не одинаковый результат. Без воспроизводимого способа мерить качество каждое изменение — промпт, инструмент, модель — превращается в гадание «стало лучше или показалось».

Тестирование агента — это не про «погонять руками», а про eval как часть CI: наборы, метрики и ловушки, которые ловят регрессии до прода.

Почему «посмотрел и ок» не работает

У агента нет фиксированного пути. Задача «разберись с багом» может пройти через поиск, чтение файлов, запуск тестов — и любой набор шагов уникален. Автономия дает гибкость ценой невоспроизводимости. Поэтому:

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

Eval нужен именно чтобы зафиксировать окружение и мерить поведение воспроизводимо.

Golden-наборы: что в них

Golden-набор — это не «10 примеров для промпта», а мини-прод с ответом:

  • Задача и контекст — что агент видит на входе (данные, инструменты, права).
  • Ожидаемый след — какие инструменты должен вызвать, с какими параметрами.
  • Ожидаемый результат — что считается успехом (файл изменен, тикет закрыт, данные не утекли).
  • Ловушки — задачи, где правильный ответ «отказаться» или «запросить подтверждение» (например, деструктивные действия, PII).

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

Метрики: успешность, точность, стоимость, безопасность

Одной метрики «успешно/неуспешно» недостаточно. Разложите качество на четыре измерения:

  • Успешность — доля задач, где агент дошел до ожидаемого результата.
  • Точность следа — вызвал ли нужные инструменты с правильными параметрами, а не «угадал ответ без действия».
  • Стоимость — токены, число шагов, время. Дорогой успех, который можно было сделать дешевле, — тоже регрессия.
  • Безопасность — не вызвал ли запрещенные инструменты, не вернул ли секреты или PII, не вышел ли за scope.

Безопасность как метрика часто пропускается, а именно она ловит самые дорогие провалы — когда агент «успешно» сделал то, чего не должен был.

Ловушки: PII и секреты в тестах

Отдельный класс тестов — то, что агент не должен делать:

  • не возвращать секреты из конфигов и подключений;
  • не выводить PII из выборок без маскирования;
  • не выполнять деструктивные действия без подтверждения.

Эти тесты должны быть в CI так же обязательно, как проверка успешности. Если агент прошел все функциональные кейсы, но провалил PII-ловушку, релиз блокируется. Иначе вы узнаете о проблеме из инцидента, а не из теста.

CI для агентов: как гонять eval

Eval должен гоняться как обычные тесты, но с учетом недетерминированности:

  • Фиксируйте окружение — права, секреты, доступные инструменты. Иначе вы меряете не агента, а окружение.
  • Гоняйте несколько прогонов — один замер для агента это шум. Смотрите на распределение, а не на точку.
  • Версионируйте наборы — новый инструмент или промпт может требовать обновления golden-ожиданий. Храните наборы в репозитории с code review.
  • Сравнивайте с базой — каждый MR показывает delta по метрикам, а не абсолютные числа в вакууме.
  • Храните трейсы — журнал вызовов инструментов для каждого прогона, чтобы разбирать падения.

Так eval перестает быть «запустили руками после релиза» и становится гейтом.

Где Codenik: детерминированная часть для тестов

Eval должен мерить поведение агента, а не случайность доступа. Codenik фиксирует детерминированную часть: какие инструменты доступны, с какими правами, какие секреты применены и что попало в аудит. Это делает прогоны сравнимыми.

Журнал вызовов инструментов — база для разбора падений: видно, какой шаг повел не туда, какие данные агент увидел и с какими правами. Подробнее про наблюдаемость — в статье «Observability и аудит AI-агентов».

Короткий вывод

Тестирование агента — это eval как CI: golden-наборы с ловушками, четыре метрики (успешность, точность следа, стоимость, безопасность), несколько прогонов и сравнение с базой. Без этого каждое изменение агента — гадание.

Фиксируйте окружение, меряйте распределение, блокируйте релиз на PII-ловушках — и агент перестает быть чёрным ящиком, за который страшно отвечать.

Источники и дальнейшее чтение