Evals для AI-агентов: как тестировать качество, безопасность и бизнес-результат

Evals для AI-агентов — это воспроизводимая система проверок, а не разовая оценка нескольких ответов. Агент может хорошо выглядеть на подготовленном демо и ошибаться при неполных данных, конфликтующих инструкциях, сбое инструмента или нестандартной формулировке. Без набора сценариев команда узнаёт об этом от клиента.

Обычная метрика похожести текста недостаточна. AI-агент отвечает, вызывает CRM и другие инструменты, соблюдает полномочия, задаёт уточнения и передаёт человеку. Поэтому оценка должна охватывать весь ход выполнения и фактический бизнес-результат.

Четыре уровня оценки

Нельзя компенсировать провал безопасности высоким средним баллом за стиль. Для критичных требований используют отдельные блокирующие проверки. Общий score помогает сравнивать версии, но решение о релизе принимается по набору порогов.

Как собрать качественный eval-набор

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

Каждый кейс содержит вход, исходное состояние систем, ожидаемые факты, разрешённые и запрещённые действия, критерии оценки и ожидаемое конечное состояние. Для части задач допустимы разные хорошие формулировки, поэтому эталоном является не один текст, а набор проверяемых требований.

Набор делят минимум на разработческий и закрытый контрольный. Если команда постоянно настраивает prompt по одному и тому же тесту, она переобучается на этот набор. Новые production-ошибки после обезличивания добавляются как regression cases.

Детерминированные проверки, модельные graders и люди

В первую очередь применяют точные проверки: JSON соответствует схеме, обязательное поле заполнено, инструмент разрешён, сумма не изменилась, создана одна сущность, секрет отсутствует в ответе. Они дешёвые, понятные и дают однозначную причину провала.

Model grader полезен для критериев, которые сложно выразить кодом: понял ли агент намерение, достаточно ли обосновал ответ, не звучит ли категорично при неопределённости. Его rubric должен описывать уровни и приводить примеры. Результаты регулярно сравнивают с оценками экспертов, потому что автоматический судья тоже может быть непоследователен.

Человек остаётся нужен для калибровки, спорных кейсов, новых рисков и оценки бизнес-приемлемости. Полезен двойной слепой разбор случайной выборки. Если эксперты расходятся, проблема часто в нечётком критерии, а не только в агенте.

Официальный OpenAI Evals API позволяет создавать и запускать оценки с заданными критериями и источниками тестовых данных, а затем сравнивать конфигурации. Возможности сверены 17 августа 2026 года; конкретный фреймворк не отменяет необходимость собственного словаря рисков и бизнес-метрик.

Как оценивать вызовы инструментов

Правильный финальный ответ может скрывать опасную траекторию. Например, агент сначала запросил всю клиентскую базу, затем выбрал нужную строку и выдал корректный статус. Поэтому журнал eval-run должен содержать вызовы, аргументы, ответы, задержку, ошибки и конечное состояние.

Для тестов используют изолированное окружение и фиксируемые mock-ответы. Отдельный прогон на sandbox реальной системы проверяет контракт интеграции. Production-данные не должны изменяться eval-запуском.

Безопасность и red-team сценарии

Red-team набор проверяет обход прав, prompt injection в сообщении и данных CRM, извлечение системных инструкций, социальную инженерию, массовые действия и утечку через инструмент. Важно тестировать не только прямую команду, но и длинный диалог, где опасное намерение появляется постепенно.

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

Риски ранжируют по вероятности и последствиям. Низкая частота не делает раскрытие персональных данных приемлемым. Для критичных сценариев требуется ноль провалов на контрольном наборе и отдельное ручное подтверждение перед релизом.

Связь evals с бизнес-результатом

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

Offline-eval даёт быстрый и безопасный сигнал, но не полностью предсказывает поведение пользователей. После прохождения порогов версия запускается на малой доле трафика или в теневом режиме. Онлайн-метрики сравниваются с контрольной группой, а опасные сигналы имеют автоматическое отключение.

Regression gates и цикл релиза

1. ВерсионированиеФиксируются модель, prompt, инструменты, схемы, данные и настройки.
2. Быстрый наборНа каждом изменении запускаются короткие блокирующие проверки.
3. Полный наборПеред релизом оцениваются все сегменты, риски и стоимость.
4. СравнениеНовая версия сопоставляется с текущей по каждому критичному срезу.
5. CanaryОграниченный поток подтверждает offline-результат на реальных запросах.
6. МониторингДрейф, ошибки инструментов и новые жалобы превращаются в тесты.

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

Набор не остаётся неизменным. Продукт, данные, поведение клиентов и внешние API меняются. Владелец evals регулярно обновляет сценарии, пересматривает вес сегментов и удаляет устаревшие проверки только с зафиксированной причиной.

Дополнительный разбор: Как оценивать retrieval, факты и цитаты RAG-системы.