Как оценивать tool calling AI-агента: практический чек-лист

Tool-use eval начинается не с вопроса «вызвала ли модель ожидаемую функцию», а с проверяемого результата задачи. Зафиксируйте начальное состояние, запрос пользователя, доступные инструменты, границы данных и полномочий, допустимые изменения, критерий завершения и запрещённые события. Иначе exact match с эталонным вызовом вознаграждает одну траекторию, даже когда другой безопасный путь даёт тот же правильный результат.

Разделяйте read, propose и mutate tools. Поиск документа, подготовка черновика и отправка письма несут разные риски и требуют разных graders. Для каждого fixture версионируйте prompt, модель, tool catalog, schemas, policy и sandbox snapshot. Реальные задачи должны требовать работы с неоднозначностью, уточнений, нескольких вызовов и обработки ошибок, а не только повторять имя функции из запроса.

• Initial state → известные записи, permissions, clock и внешние зависимости.
• Expected outcome → проверяемое финальное состояние или корректная abstention.
• Allowed trajectory → обязательные инварианты без навязывания единственного маршрута.
• Forbidden event → недопустимый read/write, утечка, дубль или действие без approval.

Постройте slices для правильного выбора, путаницы между похожими tools, пропущенного вызова, лишнего вызова и случаев, где инструмент вообще не нужен. Отдельно тестируйте unknown entity, отсутствующее обязательное поле, неоднозначную дату, неверный tenant, stale identifier и запрос вне полномочий. Валидный JSON доказывает только форму: semantic grader должен проверить соответствие аргументов намерению, состоянию и policy.

Tool precision и recall полезны только на уровне конкретного slice. Высокая общая точность может скрывать, что модель постоянно выбирает опасный mutating tool вместо read-only проверки. Добавляйте негативные случаи, где правильно задать уточняющий вопрос, отказаться или передать задачу человеку. Для parallel calls проверяйте независимость операций и то, что результат не зависит от случайного порядка завершения.

Mock, который всегда возвращает success, не проверяет tool calling. Eval environment должен воспроизводить schema validation, authorization, latency, pagination, rate limits, partial results, timeouts и side effects. Для mutating tools используйте изолированную базу или record-replay среду с authoritative read-back. Harness записывает model proposal, policy verdict, фактический request, tool response и финальное состояние как отдельные события.

Инъецируйте контролируемые сбои: 429 до выполнения, timeout после commit, schema evolution, отзыв permission между planning и execution, duplicate delivery и stale state. После неопределённого результата правильная траектория сначала делает reconciliation через read-only operation вместо слепого retry. Idempotency key должна быть стабильно связана с намерением операции; новая случайная key на каждую попытку не защищает от дублей.

Outcome grader читает system of record и проверяет достижение требуемого состояния. Trajectory grader ищет обязательные и запрещённые события: authorization перед write, approval для точного payload, отсутствие secret в arguments, корректную обработку tool errors и остановку после завершения. Side-effect grader считает дубли, orphaned writes, неверные destinations и изменения вне scope. Хороший финальный ответ не компенсирует опасное действие в trace.

Не требуйте буквального совпадения каждого шага, если валидны несколько траекторий. Точный порядок нужен для security invariants—например, lookup policy перед refund—но не для двух независимых read calls. Model grader может оценивать качество объяснения или уместность уточнения, однако permissions, schema, ledger balance и final state должны проверяться детерминированно. Для неоднозначных бизнес-критериев нужна human calibration.

• Outcome → правильное состояние, ответ или обоснованный отказ.
• Trajectory → корректные decisions, calls, policy gates и error transitions.
• Integrity → ни одного лишнего, дублированного или недопустимого side effect.
• Efficiency → calls, tokens, latency и cost на успешно verified task.

Tool performance зависит не только от модели. Названия, описания, overlap, параметры, формат ответа, количество доступных tools и объём возвращаемого контекста меняют поведение агента. Сравнивайте candidate с baseline на frozen regression set и отдельном held-out наборе. Ablation одного фактора за раз помогает отличить улучшение schema от случайного изменения sampling или data leakage.

Отчёт должен включать task success, critical policy violations, semantic argument validity, tool-selection confusion matrix, unnecessary calls, recovery success, final-state mismatch, p95 latency и cost per verified success. Добавляйте повторные runs и confidence interval для стохастических агентов. Не переносите vendor benchmark в свой workflow: production catalog, распределение данных, permissions и error surface отличаются.

Decision record фиксирует dataset, модель, prompt, catalog, schemas, executor, policy, thresholds, owner и rollback revision. Critical unauthorized write, cross-tenant read, secret exposure, approval bypass или duplicate financial action блокируют release независимо от среднего task success. Некритичная регрессия может сузить catalog, отключить parallel calls, вернуть tool в read-only или потребовать human approval.

Rollout проходит offline sandbox, shadow traffic без side effects, read-only canary, writes с обязательным approval и только затем bounded autonomy. Production telemetry использует ту же event schema, что eval harness, но с redaction и retention controls. После инцидента сначала reconcile внешнее состояние, блокируйте affected tool/version и возвращайте known-good envelope; очищенный trace становится постоянным regression fixture.