Les traces brutes ne sont pas des évaluations

La couche manquante entre les vrais échecs d’agents et un progrès mesurable du modèle

L’échec dangereux d’un agent n’est pas quand le modèle a manifestement tort. C’est quand le modèle paraît opérationnel alors que l’état du travail est encore cassé.

Un utilisateur demande quelque chose à un agent. L’agent planifie, appelle des outils, lit des fichiers, met à jour des enregistrements, réessaie, obtient une preuve partielle, et rend compte. La prose paraît assurée. La trace paraît active. L’humain commence à croire que le travail a avancé.

Mais parfois rien d’important n’a changé. Ou seulement à moitié. Ou au mauvais endroit. L’agent dit « fait » pendant que l’environnement dit silencieusement non. C’est ça, le signal. Et c’est pourquoi les traces brutes ne sont pas des évaluations.

Une trace brute est l’endroit où l’échec a été découvert. Une évaluation est l’objet réduit qui préserve le mécanisme de l’échec suffisamment pour être rejoué, mesuré, comparé et amélioré. Si on confond les deux, le travail de fiabilité devient du bruit : contexte privé, conditions d’exécution non reproductibles, journaux non rejouables, impressions sur la qualité du modèle, et aucun moyen de dire si le prochain checkpoint s’est réellement amélioré.

Une trace brute n’est pas la bonne unité

Les agents ne font plus que répondre à des questions. Ils changent l’état du travail. Ils écrivent des fichiers, éditent des dépôts, envoient des messages, mettent à jour des enregistrements, routent des tickets, et affirment ce qui a changé. Cela change l’unité d’évaluation.

La question n’est plus seulement : la réponse était-elle bonne ? La question est : l’obligation déléguée est-elle devenue un changement d’état vérifié, et l’affirmation finale est-elle restée à l’intérieur de la preuve ?

Les traces brutes sont utiles parce qu’elles contiennent le désordre : l’obligation réelle de l’utilisateur, l’interprétation de l’agent, les outils disponibles, le contexte manquant, les actions intermédiaires, l’environnement local, la preuve périmée, et le risque humain créé par l’affirmation finale.

Ce désordre compte. Mais c’est un mauvais objet public ou d’entraînement. Il peut contenir des noms privés, des chemins locaux, du contexte métier, des fichiers, des messages, des données clients, des secrets, des permissions, ou des conditions d’exécution irreproductibles.

Une trace brute répond : que s’est-il passé ici ? Une évaluation répond : un modèle peut-il gérer cette classe de situation dans des conditions contrôlées ? Le bon geste n’est ni de déverser les traces ni de les ignorer. Le bon geste est la réduction.

Les échecs terrain sont des instruments de découverte

Les benchmarks sont en général construits à partir de tâches propres : prompt, réponse attendue, solution de référence, test caché. Cela marche pour beaucoup de problèmes. La fiabilité des agents casse autrement.

L’échec important n’est souvent pas dans la réponse finale. Il est dans la transition entre délégation, action, état observé, preuve inspectée, affirmation finale, et ce que l’humain croit désormais.

Le travail réel expose des modes d’échec que les benchmarks propres manquent : fausse complétion, intention sans exécution, mises à jour partielles rapportées comme complètes, preuve périmée traitée comme actuelle, succès d’outil confondu avec succès de tâche, reprise d’une erreur suivie d’une nouvelle affirmation non étayée.

Voir L’échec le plus dangereux des agents n’est pas l’hallucination pour comprendre les différents modes d’échec.

Ce ne sont pas que de mauvaises réponses. Ce sont des transitions opérationnelles cassées. L’agent produit des croyances sur l’état du travail. Si ces croyances sont fausses, l’humain peut cesser de vérifier, attendre un travail qui n’avance pas, faire confiance à un état qui n’existe pas, ou porter la responsabilité d’un système qu’il ne pouvait pas raisonnablement superviser.

C’est un signal terrain de grande valeur. Mais il ne devient utile que lorsqu’il devient une évaluation.

La transformation manquante

La transformation ressemble à ceci :

échec terrain
-> cas réduit
-> contrat d'environnement
-> oracle observable
-> rejeu
-> checkpoint ou delta produit

La confidentialité n’est pas une arrière-pensée

La confidentialité n’est pas une couche de conformité ajoutée à la fin. Elle fait partie de la méthode d’évaluation. Le but n’est pas d’expédier du travail privé dans la boucle d’entraînement de quelqu’un d’autre. Le but est de préserver la structure causale tout en retirant le matériel privé.

Remplacer les vraies personnes par des acteurs neutres, les vrais fichiers par des fichiers synthétiques, les vrais messages par des messages synthétiques, les données clients par des données structurellement équivalentes, les chemins locaux par des chemins neutres, et le contexte métier par le minimum de contexte de tâche nécessaire pour reproduire le piège.

Les noms n’ont pas d’importance. Le piège en a.

Par exemple, l’échec original peut impliquer un vrai enregistrement client, un document privé, un fichier en production, et une affirmation finale qui surestime ce qui a changé. La graine d’évaluation n’a pas besoin du client. Elle a besoin du motif causal :

obligation : mettre à jour un état externe
action de l'agent : mise à jour partielle ou mauvaise cible
preuve : résultat d'outil incomplet ou ambigu
mauvais comportement : rapporter une complétion totale
bon comportement : inspecter l'état, rapporter une complétion partielle, demander l'étape suivante ou la réparation
oracle : comparer l'état final de l'environnement à l'état cible

L’oracle, c’est l’état du travail

Pour les chatbots, un oracle peut souvent être textuel : la réponse contenait-elle le bon fait, résolvait-elle le problème de maths, correspondait-elle à la référence ? Pour les agents, le texte ne suffit pas.

La question n’est pas seulement : l’agent a-t-il répondu correctement ? La question est : l’obligation est-elle devenue un changement d’état vérifié ?

Si on a demandé à l’agent de créer un fichier, inspecter le système de fichiers. Si on lui a demandé d’envoyer un message, vérifier que le message est parti vers la bonne cible. Si on lui a demandé de mettre à jour un enregistrement, comparer l’enregistrement final à l’état cible. S’il a enquêté sur un échec, vérifier qu’il a inspecté la preuve pertinente au lieu d’inventer une explication plausible.

Et s’il n’a pas pu accomplir la tâche, l’oracle devrait vérifier qu’il s’est arrêté de manière véridique, a préservé l’état, et a remis à l’humain une action suivante sûre.

C’est la discipline centrale :

AFFIRMATION FINALE <= PREUVE OBSERVABLE
LANGAGE D'ACTION <= TRACE D'ACTION

La transformation paraît simple. Le difficile n’est pas de tracer les flèches. Le difficile est de décider quoi préserver, quoi synthétiser, quel état observer, et quelle classe d’échec mérite d’être suivie.

Si un lab veut un signal terrain utile, il ne devrait pas demander seulement des journaux. Les journaux sont nécessaires. Ils ne suffisent pas.

L’objet utile est une graine d’évaluation réduite : définition de tâche ; outils et environnement disponibles ; état initial ; graine utilisateur ou montage de simulation ; pièces mobiles ; comportement attendu ou idéal ; vérificateur ou exigences d’état final ; famille d’échec ; affirmation finale ; preuve observable ; note de risque humain ; frontière de confidentialité ; statut de rejeu.

Ce n’est pas de la bureaucratie. C’est comme ça qu’on transforme du travail réel en quelque chose sur quoi une équipe modèle peut raisonner. La valeur n’est pas dans le volume de traces. La valeur est dans la qualité de la réduction.

Un seul cas réduit de grande qualité, avec un oracle verrouillé, peut être plus utile que cent sessions brutes que personne ne peut rejouer, partager, classer ou comparer.

Ce que les équipes produit peuvent apprendre

Cette méthode n’est pas seulement pour l’entraînement de modèles. C’est du signal produit. Un échec d’agent réduit indique où la correction doit aller : comportement du modèle, prompt système, contrat d’outil, garde-fou d’exécution, signal de statut dans l’UI, chemin de reprise, frontière de permission, définition du « fait », passage de relais humain, documentation, ou couverture d’évaluation.

Cette distinction compte parce que beaucoup d’échecs d’agents ressemblent à des échecs de modèle alors qu’ils sont des échecs système. L’exécution a pu cacher l’état pertinent. L’outil a pu renvoyer un succès ambigu. L’UI a pu montrer une progression sans preuve. Le produit a pu manquer d’un état d’arrêt sûr. Le vérificateur a pu vérifier la mauvaise chose. On a pu demander à l’humain de superviser sans assez de visibilité.

Les traces brutes montrent le désordre. Les évaluations réduites disent quoi changer.

La plus petite graine d’évaluation utile

La plus petite graine d’évaluation issue du terrain n’a pas besoin d’être énorme. Elle doit préserver le mécanisme de l’échec. Une graine minimale peut être :

1. Obligation de l'utilisateur
2. État initial de l'environnement
3. Outils disponibles
4. Comportement sûr attendu
5. État cible observable
6. Condition d'échec
7. Oracle
8. Note de risque humain

C’est assez pour tester si l’agent peut boucler entre obligation, action, preuve et affirmation. C’est aussi assez pour comparer des checkpoints.

Le modèle A surclame. Le modèle B inspecte l’état mais échoue à la reprise. Le modèle C rapporte une complétion partielle de manière véridique et demande l’entrée manquante. Maintenant tu as un delta.

Pas une impression. Pas une démo. Pas un score de benchmark détaché du travail. Un delta comportemental sur une classe d’échec opérationnelle.

La nouvelle unité d’évaluation

Pour les agents, l’unité n’est pas prompt -> réponse. L’unité est :

obligation -> action -> état observé -> affirmation véridique

Les échecs terrain révèlent où cette chaîne casse. Les graines d’évaluation rendent la cassure reproductible. Les oracles rendent la réponse mesurable. Les deltas de checkpoint rendent le progrès visible.

La conclusion

Donc les traces brutes ne sont pas des évaluations. Elles sont l’endroit où naissent les évaluations.

Le travail est de les réduire sans tuer le signal : retirer le matériel privé, garder la structure causale, définir la tâche, verrouiller l’oracle, rejouer à travers les checkpoints, et séparer le comportement du modèle des échecs produit et d’exécution.

Le format s’enseigne. Le signal, non. Il vient du fait de voir assez de travail réel pour savoir quels échecs comptent, et de les réduire sans blanchir ce qui a cassé.

Bien faite, une activité de terrain désordonnée devient un signal de fiabilité sur lequel une équipe peut agir — échecs réduits, état observable et affirmations véridiques au lieu de dumps bruts ou de démos polies.

C’est ça, la couche manquante.

— Julien Talbot