Evals для AI-агентов: как ловить регрессии до production

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

Ручной chat test это не regression suite. Для AI-агента eval должен проверять не только финальный текст, но и то, какие tools он вызвал, какие состояния изменил и чем закончилась бизнес-операция.

Я бы собирал такой набор раньше очередной смены модели. Иначе каждый релиз остаётся маленьким экспериментом на production.

Test case начинается с ожидаемого outcome

Для свободного текста exact match почти бесполезен. Один и тот же корректный ответ может быть сформулирован десятками способов.

Я описываю goal, обязательные факты, запрещённые действия и допустимый terminal state. Например: пользователь должен получить статус заказа, агент не меняет заказ и вызывает только read-only tool.

Microsoft предлагает оценивать агентов по качеству результата и траектории действий, а не только по одному response.

Проверяемые источники: Microsoft Learn — Design and operationalize agent evaluation · Microsoft Learn — Agent Evaluators for Generative AI

Нужны happy path и неприятные края

Если eval содержит только идеальные запросы, он просто подтверждает демо. Я добавляю пустые поля, конфликтующие данные, повтор события, timeout tool, injection и неоднозначный intent.

Microsoft evaluation checklist отдельно рекомендует покрывать функциональные и risk-сценарии. Google также предлагает оценивать agents на наборах примеров и измеримых criteria.

Production обычно ломается не там, где пользователь написал учебный prompt.

Проверяемые источники: Microsoft Learn — Review the agent evaluation checklist · Google Cloud — Evaluate your agents

MEDIA FRAME · PLACEHOLDERИллюстрация будет добавлена позже

Tool trajectory проверяется отдельно от текста

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

В eval я сохраняю последовательность tool calls, arguments, retries и terminal outcome. Для критичных команд проверяю, что запрещённый tool вообще не появился в trajectory.

Agent evaluators в Microsoft Foundry включают оценки tool calls и task completion. Это полезнее общего `looks good`.

Проверяемые источники: Microsoft Learn — Agent Evaluators for Generative AI

Baseline фиксируется до изменения

Перед новой моделью или prompt я прогоняю текущую production-конфигурацию и сохраняю baseline. Потом тот же набор проходит кандидат.

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

Я бы блокировал релиз по hard gates для опасных операций и уже потом сравнивал мягкие quality metrics.

Проверяемые источники: Microsoft Learn — Design and operationalize agent evaluation · Microsoft Learn — Review the agent evaluation checklist

LLM-judge полезен, если его самого калибровали

Часть качества нельзя выразить regex. Тогда модель-судья может оценить полноту, groundedness или соответствие rubric.

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

Google evaluation docs разделяют автоматические metrics и model-based evaluation. Такой гибрид для production мне кажется разумным.

Проверяемые источники: Google Cloud — Evaluate your agents

Production failures должны возвращаться в eval-set

Нашли новый edge case в логах — он больше не должен оставаться только постмортемом. Добавляем sanitized пример в regression suite.

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

Так evals становятся памятью production. Без неё команда обречена повторно находить одни и те же ошибки после каждого большого изменения.

Каждый такой кейс получает owner и причину добавления, чтобы suite не превращался в бесконечный архив случайных разговоров.

Проверяемые источники: Microsoft Learn — Design and operationalize agent evaluation · Google Cloud — Evaluate your agents

Нестабильный тест не должен молча блокировать релиз

Некоторые eval cases сами по себе stochastic. Если один раз из двадцати judge меняет оценку, hard gate на одном прогоне превращает CI в лотерею.

Я бы помечал deterministic checks и probabilistic metrics отдельно. Для второй группы нужны повторения, confidence interval или хотя бы понятный допустимый диапазон.

Критичные safety invariants всё равно лучше сводить к детерминированному outcome: tool не вызван, запись не создана, permission denied. Там случайность нам вообще не нужна.

Отдельно полезно фиксировать причину flaky case. Если нестабильность вызвана внешним tool или тестовыми данными, чинить judge бессмысленно. Если плавает именно model behavior, это уже сигнал для повторов и более строгого outcome contract. Иначе одна цифра скрывает три разных типа шума.

Проверяемые источники: Microsoft Learn — Design and operationalize agent evaluation · Microsoft Learn — Agent Evaluators for Generative AI

Короткие вопросы перед production

Что такое LLM evals?

Это воспроизводимые проверки поведения модели или агента на наборе сценариев и критериев. Для агента полезно оценивать outcome, tool calls, safety и terminal state, а не только текст ответа.

Можно ли использовать одну LLM для оценки другой?

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

Когда запускать regression evals?

Перед изменениями модели, prompt, tools, policy и других элементов, которые могут повлиять на поведение. Критичные production failures стоит добавлять в suite постоянно.

Хороший релиз для меня скучный: старый suite прошёл, новые кейсы добавлены, dangerous actions не регрессировали. Если единственная проверка — десять минут в chat UI, production пока остаётся тестовым стендом.

Смежные контуры, которые стоит прогнать отдельно для «AI agent evals»: LLM observability: как мониторить AI-агента в production · Как перенести AI-автоматизацию с прототипа в рабочую систему · prompt injection ai agenty.