Comment obtenir des étiquettes fiables sur les trajectoires d'agents

Étiqueter un tweet, c'est une décision. Étiqueter une trajectoire d'agent, c'est des dizaines : chaque étape de l'exécution est un petit jugement, et ces jugements dépendent les uns des autres. Deux personnes appliquées s'accorderont en général sur le fait qu'une exécution a réussi, puis divergeront sur laquelle de ses douze étapes a dérapé. Si vous ne concevez pas votre protocole en tenant compte de cet écart, vos données de trajectoires « étiquetées » ne sont pas fiables, et le modèle de récompense ou l'analyse de débogage que vous bâtissez dessus hérite du bruit.

Une trajectoire est la trace complète d'une exécution d'agent : son objectif, puis pour chaque étape le raisonnement, l'appel d'outil et l'observation. L'annoter revient à juger l'exécution dans son ensemble et à marquer où les étapes individuelles ont échoué. L'étiquette globale fait facilement consensus ; les étiquettes par étape, non, et ce sont elles dont un modèle de récompense ou une analyse de débogage a besoin. Des données de trajectoires fiables viennent d'une taxonomie d'erreurs serrée, d'un accord par étape mesuré délibérément, et d'un moyen de résoudre les désaccords.

Ce qui rend une trajectoire difficile à annoter

Les étapes ne sont pas indépendantes, et cela compte davantage que leur nombre.

• Attribution de l'erreur. Quand une exécution échoue, l'échec visible se situe souvent plusieurs étapes après la vraie faute. L'agent a fait un mauvais plan à l'étape 3, et cela est apparu comme une réponse fausse à l'étape 11. Deux annotateurs qui observent la même exécution peuvent avoir raison tous les deux de dire « cette étape est fausse » tout en divergeant sur l'étape à incriminer.
• Effets en cascade. Dès qu'une étape dérape, tout ce qui suit est contaminé. Une étape ultérieure est-elle « fausse » en elle-même, ou seulement fausse parce qu'elle a hérité d'un mauvais état ? Les annotateurs ont besoin d'une règle sur ce point, sinon ils se divisent.
• État caché. Le raisonnement de l'agent n'apparaît pas toujours dans la trace, et ses outils ont des effets de bord invisibles. τ-bench (Yao et al., 2024) traite cela en comparant l'état de la base de données en fin d'exécution à un état objectif annoté, parce qu'on ne peut souvent pas juger de la justesse à partir de la seule transcription.
• La « nécessité », notion subjective. Décider qu'une étape était inutile plutôt que fausse relève du jugement, et c'est l'une des étiquettes les moins fiables en pratique. Une recherche redondante n'est pas une erreur, mais elle n'est pas propre non plus.

Concevez la taxonomie avant d'étiqueter

Votre taxonomie détermine la qualité de vos données, et les jeux de données d'échecs d'agents qui ont fonctionné ont été bâtis taxonomie d'abord. MAST, la Multi-Agent System Failure Taxonomy (Cemri et al., 2025), est née d'annotateurs experts étudiant 150 traces, itérant sur les catégories jusqu'à atteindre un kappa de Cohen de 0,88, et seulement ensuite passant à plus de 1600 traces réparties sur ses 14 modes d'échec. La fiabilité est venue du travail sur la taxonomie, pas d'un plus grand nombre d'annotateurs.

Une trajectoire est un objectif, une chaîne d'étapes pensée-action-observation et un résultat, chaque étape portant ses propres étiquettes

Une taxonomie utilisable est petite, presque exhaustive et à catégories mutuellement exclusives. Trois catégories de premier niveau couvrent la plupart des échecs d'agents :

• Erreurs de raisonnement : une conclusion fausse, des preuves ignorées, un mauvais plan.
• Erreurs d'exécution : le mauvais outil, un appel mal formé, un résultat mal traité.
• Erreurs de sûreté : une action dangereuse, un comportement hors périmètre, une fuite de données.

Donnez aux annotateurs un champ libre « autre » pour qu'un échec inédit ait où aller au lieu d'être forcé dans la catégorie la plus proche, puis surveillez ces notes « autre » et promouvez celles qui reviennent en catégories nommées. AgentRewardBench (Lù et al., 2025) est un bon modèle de ce qu'il faut capturer au niveau de l'exécution : ses relecteurs experts ont jugé chacune des 1302 trajectoires sur le succès, les effets de bord et la répétitivité, trois axes qu'un simple indicateur de réussite aurait écrasés.

Une taxonomie petite et mutuellement exclusive avec une porte de sortie pour les échecs inédits

Mesurer l'accord sur des étiquettes multi-étapes

Le succès global est l'étiquette facile. Deux personnes regardent une exécution et s'accordent le plus souvent sur sa réussite ou son échec. Si c'est le seul chiffre que vous rapportez, vos données paraissent plus fiables qu'elles ne le sont.

Mesurez l'accord là où il est vraiment difficile. Calculez l'accord inter-annotateurs séparément pour la justesse de l'étape et pour la catégorie d'erreur, car les deux se comportent différemment : les gens s'accordent bien plus sur le fait qu'une étape est fausse que sur le pourquoi. Alignez les désignations de première étape fausse d'un annotateur à l'autre, puisque cette étape unique est la plus déterminante pour entraîner un modèle de récompense de processus, au sens de PRM800K / « Let's Verify Step by Step » (Lightman et al., 2023). Et traitez l'évaluation automatique avec méfiance : AgentRewardBench a constaté que les vérifications à base de règles sur lesquelles reposent les bancs d'essai courants tendent à sous-estimer le succès des agents ; une étiquette automatique bon marché ne remplace donc pas l'étiquette humaine, elle n'en est qu'une première passe.

Arbitrer les désaccords et former les annotateurs

Un désaccord sur une trajectoire signifie en général que la taxonomie est sous-spécifiée quelque part, pas qu'un annotateur a fauté. Quand deux annotateurs divergent sur l'étape à incriminer, cette paire d'étiquettes vous dit que la règle de cascade est sous-spécifiée, et le correctif remonte dans les consignes.

Deux pratiques portent l'essentiel du poids. D'abord, arbitrez les désaccords plutôt que de les mettre au vote, car sur une trajectoire c'est la conversation « pourquoi as-tu choisi cette étape » qui écrit la vraie règle ; voir Arbitrage et résolution des désaccords. Ensuite, formez progressivement les annotateurs sur les longues traces. Les trajectoires fatiguent, et un annotateur épuisé à l'étape 40 n'est pas le même instrument qu'un annotateur frais à l'étape 2. Plafonnez ou paginez les longues exécutions, et calibrez tout le monde sur un ensemble de traces commun avant de les laisser travailler seuls.

Le faire dans Potato

Le type trajectory_eval de Potato affiche chaque étape sous forme de carte et y attache une taxonomie d'erreurs par étape avec des poids de gravité, si bien que les étiquettes ci-dessus vivent dans la configuration.

annotation_schemes:
  - annotation_type: trajectory_eval
    name: step_evaluation
    description: "Evaluate each step for correctness and mark any errors."
    steps_key: steps
    error_types:
      - {name: reasoning,  subtypes: [logical_error, factual_error, planning_error]}
      - {name: execution,  subtypes: [wrong_tool, wrong_args, api_error]}
      - {name: safety,     subtypes: [harmful_action, data_leak, scope_violation]}
    severities:
      - {name: minor,    weight: -1}
      - {name: major,    weight: -5}
      - {name: critical, weight: -10}
    show_score: true

Les poids de gravité se cumulent en un score de trajectoire, ce qui permet de classer les exécutions et de suivre les régressions d'une version de modèle à l'autre. Quand l'objectif est précisément la première étape fausse pour entraîner un modèle de récompense, le type process_reward dispose d'un mode première-erreur prévu pour cela. Potato importe des traces depuis 15 formats vers une vue d'étapes commune, si bien que vous pouvez annoter une exécution quel que soit le framework qui l'a produite ; voir Annotation agentique.

Pour aller plus loin

• Annoter les trajectoires d'agents, la référence détaillée de la fonctionnalité.
• Modèles de récompense de processus et étiquetage au niveau de l'étape, pour les données de première erreur et de récompense par étape.
• Évaluer l'usage d'outils et les appels de fonctions, pour juger les appels d'outils individuels.
• L'accord inter-annotateurs expliqué, pour les statistiques de fiabilité sur lesquelles tout cela repose.

Les pages de la galerie construites à partir de vrais bancs d'essai d'agents montrent les schémas en contexte : WebArena, τ-bench et AgentRewardBench.