Comment évaluer le tool calling d’un agent IA : checklist pratique

Une évaluation de tool use commence par le résultat vérifiable de la tâche, pas par la question de savoir si le modèle a appelé la fonction attendue. Figez l’état initial, la demande utilisateur, les outils disponibles, les limites de données et d’autorité, les changements autorisés, le critère de fin et les événements interdits. Sinon, un exact match avec un appel de référence récompense une seule trajectoire alors qu’un autre chemin sûr peut produire le même résultat correct.

Séparez les outils read, propose et mutate. Trouver un document, préparer un brouillon et envoyer un e-mail présentent des risques différents et exigent des graders différents. Pour chaque fixture, versionnez prompt, modèle, tool catalog, schemas, policy et snapshot du sandbox. Les tâches réelles doivent exiger gestion de l’ambiguïté, clarification, appels multiples et traitement des erreurs, pas simplement répéter un nom de fonction présent dans la demande.

• Initial state → enregistrements connus, permissions, horloge et dépendances externes.
• Expected outcome → état terminal vérifiable ou abstention correcte.
• Allowed trajectory → invariants obligatoires sans imposer un trajet unique.
• Forbidden event → read/write non autorisé, fuite, doublon ou action sans approval.

Construisez des slices pour la bonne sélection, la confusion entre outils similaires, un appel manqué, un appel inutile et les cas où aucun outil n’est nécessaire. Testez séparément entité inconnue, champ obligatoire absent, date ambiguë, mauvais tenant, identifiant stale et demande hors autorité. Un JSON valide ne prouve que la forme : un semantic grader doit vérifier que les arguments correspondent à l’intention, à l’état et à la policy.

Tool precision et recall ne sont utiles qu’au niveau d’un slice précis. Une forte précision globale peut masquer un modèle qui choisit systématiquement un outil mutating dangereux plutôt qu’une vérification read-only. Ajoutez des cas négatifs où la bonne réponse est de demander une clarification, refuser ou escalader vers un humain. Pour les parallel calls, vérifiez l’indépendance des opérations et que le résultat ne dépend pas d’un ordre de fin aléatoire.

Un mock qui renvoie toujours success ne teste pas le tool calling. L’environnement d’évaluation doit reproduire schema validation, authorization, latency, pagination, rate limits, partial results, timeouts et side effects. Pour les outils mutating, utilisez une base isolée ou un environnement record-replay avec read-back autoritatif. Le harness enregistre model proposal, policy verdict, requête réelle, tool response et état final comme des événements distincts.

Injectez des défaillances contrôlées : 429 avant exécution, timeout après commit, évolution du schema, révocation de permission entre planning et execution, livraison dupliquée et état stale. Après un résultat incertain, la bonne trajectoire réconcilie d’abord via une opération read-only plutôt que de retry à l’aveugle. L’idempotency key doit rester liée de façon stable à l’intention de l’opération ; une nouvelle key aléatoire à chaque tentative ne protège pas des doublons.

L’outcome grader lit le system of record et vérifie que l’état requis a été atteint. Le trajectory grader cherche les événements requis et interdits : authorization avant write, approval lié au payload exact, aucun secret dans les arguments, bon traitement des tool errors et arrêt après exécution. Le side-effect grader compte doublons, orphaned writes, mauvaises destinations et changements hors scope. Une belle réponse finale ne compense pas une action dangereuse dans le trace.

N’exigez pas un match littéral de chaque étape lorsque plusieurs trajectoires sont valides. L’ordre exact compte pour les invariants de sécurité—par exemple consulter la policy avant un refund—mais pas pour deux read calls indépendants. Un model grader peut évaluer la qualité de l’explication ou la pertinence d’une clarification ; permissions, schema, ledger balance et final state doivent être vérifiés de façon déterministe. Une calibration humaine reste nécessaire pour les critères métier ambigus.

• Outcome → état correct, réponse ou refus justifié.
• Trajectory → decisions, calls, policy gates et error transitions corrects.
• Integrity → aucun side effect inutile, dupliqué ou non autorisé.
• Efficiency → calls, tokens, latence et coût par tâche vérifiée avec succès.

La performance des outils ne dépend pas seulement du modèle. Noms, descriptions, overlap, paramètres, format de réponse, nombre d’outils disponibles et contexte renvoyé modifient le comportement de l’agent. Comparez candidate et baseline sur un frozen regression set et un jeu held-out séparé. L’ablation d’un facteur à la fois aide à distinguer une amélioration de schema d’un changement de sampling ou d’une fuite de données.

Rapportez task success, critical policy violations, validité sémantique des arguments, confusion matrix de tool selection, appels inutiles, recovery success, final-state mismatch, latence p95 et coût par verified success. Ajoutez des répétitions et confidence intervals pour les runs stochastiques. Ne transposez pas un benchmark fournisseur à votre workflow : production catalog, distribution des données, permissions et surface d’erreur diffèrent.

Le decision record fixe dataset, modèle, prompt, catalog, schemas, executor, policy, thresholds, owner et rollback revision. Un unauthorized write critique, cross-tenant read, secret exposure, approval bypass ou une action financière dupliquée bloque le release quel que soit le task success moyen. Une régression non critique peut réduire le catalog, désactiver les parallel calls, remettre un outil en read-only ou imposer un human approval.

Le rollout passe par sandbox offline, shadow traffic sans side effects, canary read-only, writes avec approval puis seulement bounded autonomy. La production telemetry utilise le même event schema que l’eval harness avec contrôles de redaction et retention. Après un incident, réconciliez d’abord l’état externe, bloquez le tool/version affecté et restaurez le known-good envelope ; le trace nettoyé devient ensuite un regression fixture permanent.