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 або фінальну відповідь без доказу незалежно від того, наскільки переконливо виглядає output.

Мінімальний trace містить task ID, tenant/user context, model і agent revision, policy version, початковий state fingerprint, 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 випала, verdict для consequential run стає 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 звіряє claimed 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 → кожний крок дозволений, релевантний і підтверджений.
• Policy → жодний hard invariant не порушено.
• Recovery → uncertain state reconciled before retry.
• Efficiency → лише серед безпечних успішних runs.

Deterministic graders мають першими перевіряти schema, allowlist, identity/scope, approval freshness, 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 і лише тоді вирішує, повторювати дію чи завершити. Перевіряйте також компенсацію: якщо 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 мінімізуйте до regression case з privacy-safe trace. Так evaluation стає живим release control, а не разовою таблицею, яку урочисто забули після pilot.