Trajectory evaluation AI-агентов: проверять путь, а не только результат

Trajectory evaluation проверяет последовательность наблюдений, решений, tool calls, ответов среды, approvals и state transitions между запросом и финальным результатом. Outcome grader отвечает, завершена ли задача; trajectory grader — использовал ли агент разрешённые источники и инструменты, не обошёл ли policy, не повторил ли side effect и корректно ли отреагировал на ошибку. Для read-only вопроса иногда достаточно outcome. Для платежа, сообщения клиенту, изменения репозитория или работы с PII безопасность пути является отдельным условием release.

Не требуйте одного канонического маршрута: сильные агенты могут законно выполнить одну задачу разными путями. Вместо этого задайте инварианты, разрешённые action classes, запрещённые события и authoritative terminal state. Хороший grader допускает несколько безопасных траекторий, но fail-ит утечку секрета, write без authority, скрытую ошибку, duplicate action или финальный ответ без evidence независимо от того, насколько убедительно выглядит output.

Минимальный trace содержит task ID, tenant/user context, model и agent revision, policy version, fingerprint начального state, observation, decision event, tool name/version, arguments или их безопасный hash, authorization verdict, tool result status, retry/idempotency key, approval event, side-effect receipt, final answer и terminal state. Timestamps и parent-child IDs позволяют восстановить причинный порядок параллельных шагов. Sensitive payload не нужно бесконтрольно копировать: храните redacted evidence и отдельно защищённый raw artifact только когда это обосновано.

Trace должен приходить из orchestration и tool boundary, а не из self-report модели. Фраза агента «я проверил CRM» не доказывает вызов CRM; красивый chain-of-thought не является audit log и не нужен для проверки внешних действий. Логируйте наблюдаемые события, версии и postconditions. Если telemetry отсутствует у consequential run, verdict становится INCONCLUSIVE, а не PASS.

Разделите verdict на planning relevance, tool correctness, authority, state integrity и recovery. Planning relevance ловит бессмысленные loops и пропущенные обязательные проверки. Tool correctness проверяет выбор инструмента, schema-valid arguments и обработку ответа. Authority сопоставляет каждое действие с identity, scope, approval и текущим state. State integrity сверяет заявленный outcome с system of record. Recovery проверяет timeout, partial commit, rate limit, stale approval и dependency failure.

Efficiency оценивайте только после correctness и safety. Меньше шагов не лучше, если агент пропустил identity check; больше шагов не хуже, если они дают необходимое подтверждение. Полезные measures: task success, critical invariant failures, invalid/unauthorized call rate, duplicate side effects, unnecessary calls, recovery success, evidence coverage, latency и cost per safely completed task. Не сводите critical failure и экономию tokens в один средний score.

• Outcome → authoritative terminal state соответствует task contract.
• Trajectory → каждый шаг разрешён, релевантен и подтверждён evidence.
• Policy → ни один hard invariant не нарушен.
• Recovery → uncertain state reconciled before retry.
• Efficiency → оценивается только среди безопасных успешных runs.

Deterministic graders должны первыми проверять schema, allowlist, identity/scope, freshness approval, idempotency, prohibited events и authoritative postcondition. Model grader полезен для семантической релевантности плана, достаточности evidence или качества escalation, но ему следует передавать структурированный trace и rubric, а не неконтролируемый transcript. Human review оставьте для высокорисковых неоднозначных cases и калибровки grader-а.

Проверяйте grader на labeled set с позитивными, негативными и boundary cases. Измеряйте disagreement по risk slice, а не только общую agreement rate. Prompt, rubric, grader model и threshold версионируйте вместе с agent bundle. Model grader не должен самостоятельно отменять deterministic security failure; уверенное объяснение не превращает unauthorized write в допустимое действие.

Eval set должен содержать tool timeout до write и после partial commit, malformed result, 429, stale data, schema drift, revoked permission, expired approval, cross-tenant object, prompt injection в tool output, duplicated event, conflicting sources, unavailable oracle и задачу, где правильно abstain-нуть. Для каждой fixture задайте initial state, injected fault, разрешённые переходы, prohibited events и terminal oracle.

Особенно важен принцип `reconcile before retry`: после неопределённого write агент читает system of record по operation key и только затем решает, повторять действие или завершить run. Проверяйте и compensation. Если workflow создал draft, но не смог привязать его к case, остаётся ли orphan или открывается owner task? Именно partial success отличает production trajectory eval от демонстрации tool calling.

Запускайте frozen regression set, held-out cases и fault-injection slice на pinned model, prompt, tools, policy и environment. Promotion требует приемлемого outcome в каждом критическом slice, нуля определённых hard-invariant failures, совместимого grader и проверенного rollback. Canary начинайте с read-only или draft-only authority; write scope расширяйте отдельным решением, а не как награду за улучшение среднего score.

После изменения model, tool schema, permission policy, retry logic или grader предыдущий verdict становится historical evidence. Rollback возвращает весь совместимый bundle, останавливает новые runs и reconcile-ит незавершённые side effects. Production incident сводите к privacy-safe regression case. Так evaluation становится живым release control, а не разовой таблицей, которую торжественно забывают после pilot.