Annotation de trajectoires d'agents : qui note l'IA qui travaille seule ?
Un agent IA a réservé le mauvais vol. Pas parce qu'il a halluciné une destination — l'email de confirmation final était parfait. Quelque part dans les 47 étapes entre « réserve-moi un vol pour ma réunion à Genève » et la page de paiement, il a interrogé le calendrier avec un mauvais format de date, obtenu zéro résultat en silence, supposé que la réunion était la semaine suivante, et raisonné impeccablement à partir de là. Chaque étape ultérieure était localement correcte... Mais la trajectoire était globalement fausse !
C'est LE problème de qualité de l'ère agentique : la réponse finale n'est que la dernière étape d'une longue exécution, et la noter ne vous apprend presque rien. La discipline qui résout cela s'appelle l'agent trajectory annotation ("annotation de trajectoires d'agents") — la labellisation humaine de la trace d'exécution complète d'un agent — et son produit s'appelle les agentic AI evaluation data (données d'évaluation d'IA agentique) : les datasets qui rendent les agents autonomes mesurables, débogables et entraînables.
💡 Pendant des années chez Innovatiana, nos services de RLHF consistaient à juger la réponse d'un modèle. L'IA agentique change l'unité de jugement : non plus une réponse, mais une trajectoire — une séquence de pensées, d'appels d'outils, d'observations et de décisions. Les compétences se transfèrent ; le métier est nouveau. Ce guide le cartographie.
Anatomie d'une trajectoire (et de son échec)
Une trajectoire, aussi appelée trace, est l'enregistrement complet d'une exécution d'agent. Simplifié, notre échec de réservation ressemble à ceci :
[user] Réserve-moi un vol pour ma réunion à Genève
[pensée] Il me faut la date de la réunion. Je consulte le calendrier.
[appel_outil] calendar.search(query="Genève", date="14/08/2026")
[sortie] { results: [] } ← l'API attend des dates ISO
[pensée] Pas de réunion cette semaine. Ce doit être la semaine prochaine.
[appel_outil] flights.search(dest="GVA", date="2026-08-21") ← prémisse fausse
[...] 41 étapes supplémentaires, localement correctes
[final] ✓ Réservé ! Genève, 21 août. ← confiant, et faux
🧐 Une évaluation au niveau du résultat (« l'agent a-t-il réservé un vol pour Genève ? ») note cette exécution comme un succès. Seule une revue humaine au niveau des étapes attrape l'échec réel : un argument d'outil malformé à l'étape 3, et une inférence injustifiée à l'étape 5.
En réalité, l'annotation, c'est le débogage (si on doit faire un parallèle avec le développement logiciel). Et agrégées sur des milliers de traces, ces annotations deviennent les données d'évaluation et d'entraînement qui empêchent cette classe d'erreur de se reproduire !
Ce que couvre l'annotation de trajectoires d'agents
Annoter une trace, c'est porter un jugement à trois niveaux distincts — une structure désormais standard dans la littérature et les plateformes d'évaluation d'agents :
Niveau 1 — Le résultat (end-to-end)
L'exécution a-t-elle accompli l'objectif réel de l'utilisateur ? Totalement, partiellement, pas du tout — et l'objectif lui-même a-t-il été correctement compris ? Cela ressemble au travail de préférence RLHF classique, à une nuance près : l'annotateur doit juger par rapport à « l'intention » de l'utilisateur, pas à la reformulation qu'en fait l'agent.
Niveau 2 — La trajectoire (le chemin)
Le chemin était-il solide et efficace ? On labellise : la qualité du plan (la décomposition initiale était-elle sensée ?), l'adhérence au plan (l'agent l'a-t-il suivi ou judicieusement révisé ?), l'efficacité des étapes (boucles, appels redondants, gaspillage de tokens), et le comportement de récupération (qu'a fait l'agent après une erreur — réessayer, s'adapter, ou halluciner par-dessus ?).
Niveau 3 — L'étape (la décision)
Chaque action individuelle reçoit ses propres labels : le bon choix d'outil (le bon outil pour la sous-tâche ?), la justesse des arguments (notre bug de format de date vit ici), l'ancrage (ce pas de raisonnement découle-t-il des observations réelles, ou de quelque chose que l'agent a inventé ?), et l'usage de l'information (l'agent a-t-il lu la sortie d'outil qu'il a reçue, ou l'a-t-il ignorée ?).
💡 Les labels de "Safety" et de conformité (actions dangereuses tentées, permissions outrepassées, données sensibles mal gérées) et les tags d'attribution d'erreur sont parmi les plus critiques à attribuer. L'attribution d'erreur est le label le plus précieux et le plus exigeant de la taxonomie : il faut lire toute la trace, former une théorie causale et localiser le défaut le plus précoce, exactement comme dans une revue de code...
Quatre datasets issus de ce travail
L'annotation de trajectoires n'est pas une fin en soi. Elle fabrique quatre actifs de données distincts :
1. Les golden sets d'évaluation. Des traces choisies aux labels vérifiés, utilisées comme benchmarks de régression : chaque nouvelle version de l'agent est rejouée contre elles. Les couches d'annotation de traces des outils d'observabilité (LangSmith et équivalents) existent précisément pour les construire — mais les labels qu'elles contiennent sont des jugements humains, pas des sorties d'outils.
2. Les données de calibration LLM-as-a-judge. La plupart des équipes notent leurs traces automatiquement avec un modèle juge. Les juges dérivent, sur-récompensent la verbosité et manquent les échecs spécifiques au domaine — ils doivent donc être calibrés contre une vérité terrain annotée par des humains, et recalibrés à mesure que l'agent évolue. Le consensus de la recherche : revue humaine périodique associée au jugement automatisé, et non l'un remplaçant l'autre.
3. Les données d'entraînement de process reward models (PRM). La frontière de l'entraînement d'agents : des modèles de récompense qui notent chaque étape, pas seulement le résultat. Des travaux récents (par ex. AgentPRM, WWW 2026) génèrent des labels par étape de façon semi-automatique via estimation par différence temporelle — mais l'approche repose toujours sur des critères de succès définis par des humains et des labels-graines vérifiés par des humains, car contrairement à une preuve mathématique, une action d'agent n'a pas de correction évidente sans jugement.
4. Les corpus de fine-tuning issus de trajectoires réparées. Les échecs annotés deviennent de la supervision : la trace jusqu'à l'étape cassée, plus la continuation corrigée. Ces données de « réparation de trajectoire » comptent parmi les matériaux de fine-tuning les plus précieux qu'une équipe agent puisse posséder.
Ce qui fait un bon annotateur de trajectoires
Ce n'est ni du micro-tasking, ni de la notation de contenu classique. Le profil est plus proche d'un ingénieur QA croisé avec un spécialiste RLHF :
- Une lecture technique fluide : les traces contiennent des appels d'outils JSON, des erreurs d'API, des stack traces et des documents récupérés ; l'annotateur doit les lire nativement
- Du contexte métier : juger si le correctif d'un agent de code est correct, ou si le contrôle de conformité d'un agent financier est suffisant, exige des personnes qui connaissent le domaine — des annotateurs génériques produisent des labels génériques (faux)
- Une discipline causale : savoir distinguer la première étape défectueuse de ses symptômes en aval, et résister au biais rétrospectif quand on connaît l'issue
- Une culture de calibration : les jugements par étape sont subjectifs à la marge ; il faut des traces "gold", un suivi d'accord inter-annotateurs et des tours d'arbitrage — la même machinerie que tout programme de labellisation sérieux, appliquée à un objet nouveau
💡 Un schéma que nous voyons constamment : des équipes investissent dans les prompts de leur juge et rien dans la référence humaine que le juge est censé approximer. Un juge LLM non calibré, c'est une opinion à grande échelle. Cinquante traces annotées rigoureusement valent mieux que cinq mille exécutions auto-notées — parce qu'elles seules vous disent ce que signifient les cinq mille scores.
Un protocole concret : annoter 1 000 traces
À quoi ressemble un dispositif de production, condensé :
1. Le schéma d'abord. Définir la taxonomie de labels à partir de vos modes d'échec (partir des trois niveaux ci-dessus), avec des règles de décision écrites et 10 à 20 traces exemplaires entièrement annotées.
2. Échantillonner délibérément. Ne pas annoter des traces au hasard : stratifier par résultat (succès ET échecs), par type de tâche, par longueur de trace, et sur-échantillonner les scores de juge à faible confiance — c'est là que se trouve l'information.
3. Une annotation en deux passes. Première passe : labels d'étapes et de résultat ; seconde passe par un annotateur senior sur l'attribution d'erreur. Les désaccords partent en arbitrage, et les résolutions alimentent les règles de décision.
4. Mesurer l'accord par famille de labels. La justesse du choix d'outil converge vite ; les labels de qualité de raisonnement, non — suivez-les séparément avec des seuils d'accord différents.
5. Boucler la boucle. Livrer le set labellisé sous trois formes : benchmark de régression, données de calibration du juge, et graine pour le PRM ou le fine-tuning. Un effort d'annotation, trois produits.
Références à lire (et à citer sans se priver)
- AgentPRM: Process Reward Models for LLM Agents via Step-Wise Promise and Progress — Xi et al., WWW 2026. La référence sur la labellisation de récompense par étape pour agents — y compris pourquoi les actions d'agents n'ont pas de correction évidente.
- Agentic Reward Modeling — Peng et al., 2025. Combiner préférences humaines et signaux de correction vérifiables.
- La littérature Agent-as-a-Judge — You et al., 2026 et successeurs. Des évaluateurs autonomes avec accès aux outils — et leurs limites de calibration.
- RM-R1: Reward Modeling as Reasoning — Chen et al., 2025 (arXiv:2505.02387). Pourquoi les jugements de récompense bénéficient eux-mêmes d'un raisonnement explicite — avec des implications pour les consignes d'annotation.
- Les surveys sur l'évaluation par rubriques — littérature arXiv 2026 sur les critères structurés d'évaluation de LLM ; directement applicable à la rédaction de règles de décision d'annotation.
🔍 Ce champ de recherche évolue chaque mois ; les papiers ci-dessus sont des ancres, pas une carte complète. Leurs annexes — taxonomies de labels, statistiques d'accord, prompts d'annotation — en sont les parties opérationnellement utiles.
En conclusion
Les agents échouent au milieu des processus, pas à la fin. Les équipes qui livrent des agents fiables sont celles qui savent voir le "milieu" — et le voir est une discipline de labellisation (ou annotation) humaine quoi qu'on en dise !
🤖 C'est l'évolution naturelle de ce qu'Innovatiana a toujours fait en RLHF et en évaluation : des annotateurs professionnels internes formés techniquement et métier, des chefs de projet dédiés, un suivi d'accord et une traçabilité complète — jamais de crowdsourcing anonyme. Si votre agent travaille seul, assurons-nous que quelqu'un de qualifié le note : https://www.innovatiana.com/fr/contact
