Évaluation des trajectoires d’agents IA : vérifier le chemin et le résultat

L’évaluation de trajectoire vérifie la séquence d’observations, de décisions, de tool calls, de réponses de l’environnement, d’approvals et de state transitions entre la demande et le résultat final. Un outcome grader répond à la question « la tâche est-elle terminée ? » ; un trajectory grader vérifie si l’agent a utilisé des sources et outils autorisés, respecté la policy, évité les side effects en double et correctement réagi aux erreurs. Pour une question read-only, le résultat peut parfois suffire. Pour un paiement, un message client, une modification de dépôt ou un workflow avec PII, la sécurité du chemin est une condition distincte de release.

N’imposez pas une seule chaîne canonique d’étapes : un bon agent peut légitimement accomplir la même tâche par plusieurs routes. Définissez plutôt les invariants, classes d’actions autorisées, événements interdits et le terminal state faisant autorité. Un bon grader accepte plusieurs trajectoires sûres, mais échoue en cas de fuite de secret, de write non autorisé, d’erreur masquée, d’action dupliquée ou de réponse finale sans preuve, même si l’output semble convaincant.

Un trace minimal enregistre le task ID, le contexte tenant ou utilisateur, les révisions du modèle et de l’agent, la version de policy, le fingerprint de l’état initial, l’observation, le decision event, le nom et la version de l’outil, les arguments ou leur hash sûr, l’authorization verdict, le statut du résultat d’outil, la clé de retry ou d’idempotency, l’approval event, le reçu du side effect, la réponse finale et le terminal state. Les timestamps et IDs parent-child permettent de reconstruire l’ordre causal des étapes parallèles. Les payloads sensibles ne doivent pas être copiés sans contrôle : conservez une preuve redacted et un raw artifact séparément protégé seulement lorsque cela se justifie.

Le trace doit provenir de l’orchestration et des frontières des outils, pas du self-report du modèle. La phrase « j’ai vérifié le CRM » ne prouve pas qu’un appel CRM a eu lieu ; un chain-of-thought bien rédigé n’est pas un audit log et n’est pas nécessaire pour vérifier des actions externes. Journalisez les événements observables, les versions et les postconditions. Si la télémétrie manque pour un run à conséquences, le verdict devient INCONCLUSIVE, pas PASS.

Séparez le verdict en pertinence de planification, correction des outils, autorité, intégrité de l’état et récupération. La pertinence de planification détecte les loops inutiles et les vérifications nécessaires omises. Tool correctness vérifie le choix de l’outil, les arguments conformes au schema et le traitement de la réponse. Authority rattache chaque action à l’identité, au scope, à l’approval et à l’état courant. State integrity compare le résultat affirmé au system of record. Recovery couvre timeout, partial commit, rate limit, approval périmé et panne de dépendance.

N’évaluez l’efficacité qu’après correctness et safety. Moins d’étapes n’est pas mieux si l’agent a sauté un identity check ; davantage d’étapes n’est pas pire si elles apportent la confirmation requise. Mesures utiles : task success, critical invariant failures, taux d’appels invalides ou non autorisés, side effects en double, appels inutiles, recovery success, couverture des preuves, latence et coût par tâche terminée en sécurité. Ne fusionnez pas un échec critique et une économie de tokens dans un score moyen unique.

• Outcome → le terminal state faisant autorité respecte le task contract.
• Trajectory → chaque étape est autorisée, pertinente et prouvée.
• Policy → aucun hard invariant n’est violé.
• Recovery → l’état incertain est réconcilié avant tout retry.
• Efficiency → évaluée uniquement parmi les runs sûrs et réussis.

Les graders déterministes doivent d’abord vérifier schema, allowlists, identité et scope, fraîcheur de l’approval, idempotency, événements interdits et postconditions faisant autorité. Un model grader est utile pour la pertinence sémantique du plan, la suffisance des preuves ou la qualité d’une escalade, mais il doit recevoir un trace structuré et une rubric, pas un transcript incontrôlé. Gardez la revue humaine pour les cas ambigus à haut risque et la calibration du grader.

Validez le grader sur un jeu labellisé comprenant des cas positifs, négatifs et de frontière. Mesurez le disagreement par risk slice plutôt qu’uniquement avec un taux d’accord global. Versionnez ensemble le prompt, la rubric, le modèle du grader et le threshold avec le bundle de l’agent. Un model grader ne doit pas annuler un échec de sécurité déterministe ; une explication assurée ne transforme pas un write non autorisé en action acceptable.

L’eval set doit inclure un timeout d’outil avant un write et après un partial commit, un résultat malformed, un 429, des données périmées, un schema drift, une permission révoquée, un approval expiré, un objet cross-tenant, une prompt injection dans la sortie d’un outil, un événement dupliqué, des sources contradictoires, un oracle indisponible et une tâche où l’abstention est la bonne décision. Pour chaque fixture, définissez l’état initial, la panne injectée, les transitions autorisées, les événements interdits et le terminal oracle.

« Reconcile before retry » est particulièrement important : après un write incertain, l’agent lit le system of record avec l’operation key et décide seulement ensuite de répéter l’action ou de terminer. Testez aussi la compensation. Si le workflow a créé un draft sans parvenir à le rattacher au case, reste-t-il un orphan ou une tâche est-elle ouverte pour un owner ? Le partial success est précisément ce qui distingue une évaluation de trajectoire de production d’une simple démo de tool calling.

Exécutez un frozen regression set, des cas held-out et un fault-injection slice avec modèle, prompt, outils, policy et environnement épinglés. La promotion exige des résultats acceptables dans chaque slice critique, zéro hard-invariant failure défini, un grader compatible et un rollback testé. Démarrez le canary avec une autorité read-only ou draft-only ; élargir le write scope est une décision distincte, pas une récompense pour un meilleur score moyen.

Après une modification du modèle, du tool schema, de la permission policy, de la logique de retry ou du grader, le verdict précédent devient une preuve historique. Le rollback restaure le bundle compatible complet, arrête les nouveaux runs et réconcilie les side effects inachevés. Transformez chaque incident de production en regression case respectueux de la confidentialité. L’évaluation devient ainsi un contrôle de release vivant plutôt qu’un tableau ponctuel solennellement oublié après le pilote.