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

Tool-use eval починається не з питання «чи викликала модель очікувану функцію», а з перевірюваного результату задачі. Зафіксуйте початковий стан, запит користувача, доступні інструменти, межі даних і повноважень, допустимі зміни, критерій завершення та заборонені події. Інакше точний збіг з еталонним викликом винагороджує одну траєкторію, навіть коли інший безпечний шлях дає той самий правильний результат.

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

• Initial state → відомі записи, дозволи, 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, timeout і side effects. Для mutating tools використовуйте ізольовану базу або record-replay середовище з authoritative read-back. Harness записує model proposal, policy verdict, фактичний request, tool response та фінальний стан як різні події.

Ін’єктуйте контрольовані відмови: 429 до виконання, timeout після commit, schema evolution, permission revocation між planning і execution, duplicate delivery та stale state. Після невизначеного результату правильна траєкторія — спочатку reconcile через read-only operation, а не сліпий retry. Idempotency key має бути стабільно прив’язаний до наміру операції; нова випадкова key на кожній спробі не захищає від дубля.

Outcome grader читає system of record і перевіряє, чи досягнуто потрібного стану. Trajectory grader шукає обов’язкові та заборонені події: authorization до write, approval для точного payload, відсутність secret у arguments, коректну обробку tool error і зупинку після виконання. Side-effect grader рахує дублікати, orphaned writes, неправильні destinations і зміни поза scope. Гарна фінальна відповідь не компенсує небезпечну дію у trace.

Не вимагайте буквального збігу кожного кроку, якщо кілька траєкторій валідні. Точний порядок потрібен для security invariants — наприклад, lookup policy до refund — але не для двох незалежних read calls. Model grader може оцінювати якість пояснення або доречність уточнення, проте permissions, schema, ledger balance і final state повинні перевірятися детерміновано. Людська калібрація потрібна для неоднозначних бізнес-критеріїв.

• 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. Додавайте repetitions і confidence interval для стохастичних runs. Не переносіть vendor benchmark на свій workflow: production catalog, data distribution, permissions і error surface інші.

Decision record фіксує dataset, model, 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, approval-required writes і лише потім bounded autonomy. Production telemetry використовує ту саму event schema, що eval harness, але з redaction і retention controls. Після інциденту спочатку reconcile-ять зовнішній стан, блокують affected tool/version і повертають known-good envelope; очищений trace стає постійним regression fixture.