AI-агент нельзя оценивать только по тому, насколько убедительно выглядит финальный ответ. Он планирует шаги, вызывает инструменты, меняет состояние внешних систем и может ошибиться задолго до последней реплики. Поэтому evals должны проверять весь run: выбор действий, корректность аргументов, соблюдение policy, фактический результат, latency и стоимость.
Что именно измерять
Task success: достигнута ли цель пользователя.
Tool selection accuracy: выбран ли правильный инструмент.
Argument accuracy: корректны ли параметры вызова.
State verification: подтверждён ли реальный результат действия.
Safety/policy compliance: не вышел ли агент за разрешённые границы.
Latency и cost: укладывается ли run в операционные бюджеты.
Golden set и regression suite
Соберите компактный набор репрезентативных задач с ожидаемым outcome. Включайте happy path, неоднозначные запросы, ошибки API, пустые результаты, retries и опасные действия. После изменения prompt, модели, tools или routing прогоняйте один и тот же regression suite, чтобы видеть реальную дельту, а не субъективное впечатление.
Оценивайте trajectory, а не только ответ
Сохраняйте последовательность steps и tool calls.
Проверяйте, были ли лишние или циклические действия.
Сравнивайте ожидаемый и фактический state transition.
Отмечайте случаи, когда агент получил правильный ответ случайно.
Отдельно измеряйте recovery после failed tool call.
Deterministic checks и LLM-as-a-judge
Там, где можно проверить факт программно, используйте deterministic check: HTTP status, запись в БД, наличие файла, schema validation или точное значение. Judge-модель полезна для субъективных критериев вроде полноты и ясности, но её результат должен быть калиброван на human-labeled примерах и не заменять проверяемые assertions.
Safety evals
Prompt injection из web/file/tool output.
Попытка вызвать запрещённый tool или domain.
Попытка передать секрет в model-visible context.
Опасное действие без approval.
Повтор non-idempotent action после timeout.
Эскалация прав через цепочку aparentemente безопасных шагов.
Метрики production
Offline evals не заменяют production monitoring. Смотрите task completion, user correction rate, tool error rate, retries, approval rejection rate, p95 latency, token/compute cost и долю runs с manual recovery. Метрики стоит сегментировать по intent и типу workflow: среднее по всем задачам быстро скрывает локальные деградации.
Как сравнивать модели и prompts
Фиксируйте dataset и tool environment.
Запускайте несколько повторов для stochastic flows.
Сравнивайте не только success rate, но и cost/latency.
Отдельно учитывайте catastrophic failures.
Не объявляйте победителя по одному aggregate score.
Короткий production checklist
Есть versioned eval dataset.
Есть deterministic assertions для проверяемых outcomes.
Trajectory и tool calls сохраняются для анализа.
Safety cases входят в обязательный regression suite.
Изменения модели/prompt/tools сравниваются на одном наборе.
Production metrics связаны с offline evals и alerting.