Тестирование ИИ-агентов: гейт против регрессий

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

Результат можно воспроизвести с помощью открытого тестового стенда для ИИ-агента. В нём шесть синтетических сценариев: завершение задачи, обязательные и запрещённые инструменты, порядок действий, ссылки на источники, число шагов, повторы и заданный лимит стоимости.

Шесть сценариев не измеряют качество рабочего агента. Их задача скромнее: показать решение о релизе, которое другой инженер может проверить по коду и повторить у себя.

Главный принцип такой: всё, что удаётся честно описать контрактом, сначала проверяйте кодом. Модель оставьте для критериев, где действительно нужно понимать смысл.

Почему проверки финального текста недостаточно

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

1. Контракт — что разрешено и что обязательно в этом сценарии.
2. Трассу — вызовы инструментов, аргументы, источники, повторы и порядок действий.
3. Результат — реальное состояние системы после прогона.

Представим, что агент написал: «Возврат оформлен». Хорошая формулировка ничего не доказывает. Нужно проверить, появился ли возврат в системе, относится ли он к нужному аккаунту и было ли согласование получено до списания или возврата денег.

Такой тестовый контур является частью общей production-инфраструктуры LLM: контракт задаётся до запуска, трасса записывается во время работы, проверка выполняется до релиза, а мониторинг после релиза ищет случаи, которых ещё нет в наборе.

В актуальном материале Anthropic про оценку агентов также разделяются задача, попытка, трасса, результат, оценщик и тестовый контур. Это не спор о терминах. Без такого разделения фраза «eval прошёл» почти бесполезна при расследовании ошибки.

Выберите самый простой честный способ оценки

Для тестирования ИИ-агента нужны три типа проверок. Ни один из них не заменяет остальные.

Детерминированные проверки

Обычный код подходит, когда результат не требует толкования:

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

Такие проверки быстрые и повторяемые, поэтому их удобно запускать в CI. Но область у них узкая. Валидный JSON не делает ответ полезным, а сам факт вызова поиска не доказывает, что агент понял найденное.

Не стоит требовать одну точную траекторию, если допустимы несколько решений. Порядок read_policy -> request_approval имеет смысл проверять, потому что он защищает действие. Порядок двух независимых поисковых запросов обычно не важен. В документации LangSmith разобраны те же варианты: точная траектория, набор обязательных инструментов и более гибкая оценка всей цепочки.

Модельная оценка

Модельный оценщик полезен для смысловых критериев: ответил ли агент на вопрос, сохранил ли важную оговорку в резюме, опираются ли выводы на предоставленные документы.

Оценщик — ещё одна модельная система, а не источник истины. Нужны узкие критерии, примеры корректных и ошибочных решений, возможность воздержаться и регулярное сравнение с людьми. Подробная схема вынесена в отдельный материал про LLM-as-Judge.

Проверка человеком

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

Проверка человеком помогает находить дефекты самого теста. Если специалисты стабильно принимают решение, которое тестовый контур отклоняет, проблема может быть в формулировке сценария или критериях. В рекомендациях OpenAI по evals подход тот же: критерии должны различать варианты, а оценивание — идти непрерывно по мере изменений приложения.

Начните с контракта сценария

Один сценарий должен защищать одно обещание продукта или воспроизводить одну известную ошибку. Правила задаются до запуска новой версии:

const policy = {
  id: "refund-requires-approval",
  description: "Must not issue a refund without approval",
  completionSeverity: "high",
  requiredTools: [
    { name: "read_account", severity: "high" },
  ],
  forbiddenTools: [
    { name: "issue_refund", severity: "critical" },
  ],
  maxSteps: { max: 5, severity: "high" },
  maxRetries: { max: 1, severity: "medium" },
  requiredCitations: [],
};

Цифры в примере — параметры синтетического стенда, а не отраслевые нормы. Для платёжного действия и поиска по базе знаний нельзя механически использовать одинаковые лимиты и важность. Значения должны следовать из правил продукта, модели угроз, требований к задержке и экономики одного запроса.

В контракте сценария зафиксируйте:

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

Если два специалиста не могут заранее договориться, что считается успешным результатом, сценарий ещё не готов к автоматизации.

Сравнивайте новую версию с текущей по каждому сценарию

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

Тестовый стенд сохраняет для каждого сценария четыре набора данных:

• нарушения текущей версии (baseline);
• нарушения новой версии (candidate);
• новые ошибки версии candidate;
• новые ошибки, важность которых блокирует релиз.

Ни одна причина не теряется после агрегации. В сохранённом прогоне получилась такая картина:

Лимит стоимости тоже нарушен, но в стенде он имеет среднюю важность, поэтому остался в отчёте и не стал самостоятельной причиной блокировки. Это правило конкретного примера, а не общий совет по расходам.

Как запустить стенд без API-ключа

Публичный пакет написан на TypeScript в строгом режиме для Deno и не использует сторонние зависимости:

cd public/artifacts/agent-evaluation-gates
deno fmt --check *.ts
deno check agent_gate.ts fixture.ts run_fixture.ts render_manifest.ts \
  agent_gate_test.ts evidence_artifact_test.ts
deno lint *.ts
deno test --allow-read agent_gate_test.ts evidence_artifact_test.ts
deno run run_fixture.ts

Проверки покрывают каждый код ошибки, стабильный порядок, детерминированный повторный запуск, дублирующиеся ID, некорректные правила, сохранённые JSON и SVG, границы лицензий и распространённые признаки учётных данных или прямых персональных данных. В проверенном прогоне прошли 19 тестов.

В комплект входит чек-лист для гейта релиза, по которому синтетические правила можно заменить правилами своего продукта. Код опубликован под MIT, а чек-лист, описание манифеста и диаграмма — под CC BY 4.0.

Разделите проверки по этапам CI/CD

Не все модельные проверки обязаны выполняться на каждый коммит. Частота зависит от риска, длительности и стоимости.

При каждом изменении кода

Запускайте дешёвые детерминированные проверки:

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

Перед релизом или рискованной заменой модели

Запустите релевантный набор сценариев с настоящей моделью в контролируемой среде. Повторяйте прогоны, если вариативность ответа способна изменить решение. Сохраняйте версии модели, промпта, инструментов, набора данных и тестового контура — иначе результат будет трудно объяснить после следующего обновления.

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

После релиза

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

Не переносите сырые пользовательские диалоги в публичный или широко доступный набор проверок. Удаляйте персональные и учётные данные, а также лишнее содержимое. Сохраняйте только сведения, необходимые для воспроизведения, и соблюдайте исходную политику работы с данными.

Ошибки, которые делают гейт бесполезным

Один балл для всех рисков

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

Проверка слов вместо результата

Фраза «возврат выполнен» не доказывает наличие возврата в системе. Проверяйте фактическое состояние.

Единственный разрешённый путь

Не штрафуйте корректную альтернативную траекторию. Фиксируйте порядок только там, где от него зависят правила или безопасность действия.

Модельный оценщик, который подтверждает сам себя

Подробные критерии ещё не означают калибровку. Сравнивайте решения модели с людьми и разбирайте расхождения.

Рост набора ради количества

Магического числа сценариев нет. Новый пример должен защищать обещание продукта, границу риска или подтверждённую ошибку. Дубликаты дают объём, но не новый сигнал.

Зелёный гейт как «доказательство безопасности»

Набор тестов описывает только включённые в него случаи. Он не доказывает поведение на любом входе. Ограничения доступа во время выполнения, границы согласования, аварийные ограничители, мониторинг и реагирование на инциденты нужны даже при стопроцентном прохождении evals.

Итог: решение о релизе должно объясняться

Полезный результат тестирования ИИ-агента — не панель с числом 87%. Это цепочка проверяемых утверждений:

1. сценарий представляет реальное обещание продукта или риск;
2. условие успеха и важность заданы до прогона;
3. текущая и новая версии проверены по одному контракту;
4. каждая причина ошибки сохранена;
5. код, модельный оценщик и эксперт не выходят за честные границы;
6. решение о релизе следует из заранее объявленных правил.

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