Ingénierie d'évaluation : l'étape qui transforme un modèle à 200 $ en un système à 200 000 $ (guide complet)

Tout le monde loue le même cerveau désormais.

Le modèle que vous pouvez obtenir pour quelques centaines d'euros par mois est, à peu de choses près, le même que celui qu'une entreprise avec un millier d'ingénieurs utilise. Cela était censé niveler les différences. Au lieu de cela, l'écart entre deux équipes qui louent le même cerveau est devenu plus grand que l'écart entre deux modèles.

Un agent de voyage, de type logiciel, a répondu à une question sur un voyage : un taux de change avec une décimale, la température de la semaine, les horaires d'ouverture d'un musée. Précis, propre, d'apparence utile. Tout était inventé.

L'outil de recherche était revenu vide, et le modèle a discrètement comblé le vide en présentant sa propre invention comme un fait qu'il avait vérifié.

Ensuite, l'équipe a mesuré cela sur 100 sessions réelles et a obtenu deux chiffres qui ne devraient jamais être aussi éloignés.

Qualité des réponses : 83,9 %.

Dans quelle mesure ces réponses étaient fondées sur ce que les outils avaient réellement renvoyé : 32,3 %.

L'agent écrivait magnifiquement et disait la vérité un tiers du temps.

Personne ne l'a remarqué, car l'écriture était la seule partie que l'on regardait.

83,9 % de qualité des réponses contre 32,3 % de fidélité, une seule et même exécution

Même agent, même jour : la barre de gauche montre ce que la démo affiche, la barre de droite ce que le client reçoit réellement.

Un meilleur modèle n'aurait pas détecté cela. Ce qui manquait, c'était la couche qui décide si une réponse est correcte, puis qui agit en conséquence.

Cette couche représente toute la distance entre une IA qui impressionne et une IA qui se fait payer. C'est la ligne la moins chère de la pile et la seule que personne ne peut vous vendre, car elle encode votre propre définition de ce qui est correct.

Ceci n'est pas une lecture en diagonale. Ouvrez un terminal à côté. La configuration commence par une seule commande que vous possédez déjà, et elle aboutit à quelque chose qui semble déraisonnable : des pull requests qui fusionnent sans que personne ne les lise.

Avant de commencer, suivez-moi sur X et rejoignez mon canal Telegram où je poste plus de contenu IA chaque jour. Les deux sont gratuits.

X -

https://x.com/Argona0x Telegram -

https://t.me/+r0clI4-MMC03ZjAy

Ce qu'est l'ingénierie d'évaluation

Une entreprise qui fait tourner des agents en production a dit tout haut ce que beaucoup pensent tout bas, en une phrase. Au fil des versions successives de leur agent, ils ont changé ni le modèle, ni les prompts, ni les interventions humaines, seulement les évaluations — et les scores ont bougé sur toutes les dimensions.

Même cerveau. Examinateur différent. Meilleur produit.

Leur propre conclusion par la suite était plus directe : les évaluations auraient dû être dans le système dès le premier jour, pas au neuvième mois.

Un thermomètre vous dit que la pièce est froide. Un thermostat allume le chauffage.

Presque tous ceux qui construisent avec une IA possèdent au mieux un thermomètre : un tableau de bord, une impression, un vendredi après-midi où quelqu'un fait défiler les sorties et dit que ça semble moins bien que la semaine dernière.

L'ingénierie d'évaluation, c'est le câblage qui va de la lecture à la chaudière.

← thermomètre contre thermostat, avec le verdict qui retourne dans le graphe

Toute la différence réside dans la flèche de retour à droite : le verdict retourne dans le graphe et modifie ce qui s'exécute ensuite.

Cela est arrivé dans un ordre fixe. D'abord, un agent dans une boucle, pour qu'il puisse essayer, regarder le résultat, et réessayer. Ensuite, plusieurs agents disposés sous forme de graphe, afin que les tâches qui ne dépendent pas les unes des autres s'exécutent en parallèle plutôt que de faire la queue.

Des boucles, puis des graphes, puis des évaluations.

https://x.com/Argona0x/status/2080626046903157126

Le graphe a été la dernière mise à niveau qui vous a rendu plus rapide. Le juge décide si cette vitesse en valait la peine.

Vingt agents fonctionnant en même temps, tous rendant des comptes à un seul juge gelé, c'est vingt fois plus d'endroits où une réponse erronée peut sembler correcte.

C'est aussi la seule partie du système qui devient plus précieuse chaque semaine où vous l'utilisez. Le modèle est une location. L'examinateur est à vous, et chaque échec que vous lui donnez y reste définitivement.

Ce qui rend le prix d'entrée étrange. L'examinateur coûte presque rien à installer, et le modèle qu'il examine coûte environ 200 $ par mois.

Étape 1 · Le moteur d'évaluation que vous possédez déjà

Vous pensez que cela commence par une plateforme : un contrat, un prix par siège, un trimestre de configuration avant le premier chiffre utile.

Cette hypothèse est la raison pour laquelle la plupart des gens ne construisent jamais cette couche, et elle a cessé d'être vraie il y a environ quatre semaines.

Le test à l'aveugle

1. Deux chercheurs ont réalisé le test honnête. Ils ont pris 100 traces de production réelles d'un agent vocal en direct, ont fait marquer chaque échec à la main par un expert humain, ont construit une taxonomie de 39 échecs étiquetés, puis ont caché les étiquettes et ont soumis le même lot à tous les systèmes d'évaluation du marché.

Trouvez-les vous-même.

La ligne intéressante n'était pas le gagnant :

1. Braintrust Loop : 87,2 % des échecs signalés par l'humain ont été récupérés.
2. Codex sur GPT-5.5 High : 84,6 % de rappel, 82,8 % de précision.
3. LangSmith : 79,5 %.
4. Arize AX : 74,4 % de rappel, et la meilleure précision du groupe à 91,0 %.

Un agent de codage général, sur un abonnement que vous payez déjà, a surpassé deux plateformes d'évaluation dédiées. L'une d'elles a écrit la conclusion clairement : vous pouvez obtenir des résultats similaires en utilisant votre agent de codage.

Ensuite, les plateformes ont fait quelque chose de plus étrange que de perdre. Elles ont bougé.

En quatre semaines, quatre fournisseurs d'évaluation ont intégré leur expertise sous forme de compétence installée dans l'agent de codage de quelqu'un d'autre : LangChain le 22 juillet, Galileo, AWS sous licence Apache 2.0, et Arize plaçant son extraction de traces dans des compétences destinées, selon leurs mots, à votre agent de codage préféré.

Personne n'a compté ces quatre mouvements comme un seul.

C'est une catégorie qui se décompose dans le terminal que vous avez déjà ouvert.

Installer l'examinateur

Tout installer prend trois lignes.

1npx skills add langchain-ai/langchain-skills --skill '*' --yes --global
2npx skills add langchain-ai/langsmith-skills --skill '*' --yes --global
3uv tool install evalkit --from git+https://github.com/awslabs/Agent-EvalKit.git

Dans Claude Code, la même chose s'installe comme un plugin :

1/plugin marketplace add langchain-ai/langchain-skills
2/plugin install langchain-skills@langchain-skills

← exécution réelle dans un terminal : l'installation des compétences, evalkit init crée la structure du dossier

Une exécution réelle sur une machine réelle : les compétences sont installées comme fichiers globaux, et evalkit init met en place le dossier dans lequel votre évaluation vivra.

Deux détails ici valent plus que les commandes.

1. Deux dépôts, deux tâches : langchain-skills construit les évaluations, langsmith-skills extrait les exécutions de production réelles pour les construire. Presque tout le monde installe le premier, puis se demande d'où vient le matériel.
2. Ce n'est pas une fonctionnalité de Claude Code : ces compétences suivent la spécification ouverte des compétences, donc les fichiers identiques se chargent dans Codex, Cursor, Windsurf et Goose.

Le kit AWS fonctionne avec six commandes, chaque phase écrivant dans un dossier eval/ que la suivante lit :

1evalkit init my-agent-evaluation
2# then, inside your coding agent:
3/evalkit.plan Evaluate my agent at ./my_agent for grounding and tool accuracy
4/evalkit.data
5/evalkit.trace
6/evalkit.run_agent
7/evalkit.eval
8/evalkit.report

La dernière commande est celle qui vaut toute la configuration. /evalkit.report renvoie des recommandations prioritaires pointant vers des endroits spécifiques de votre code.

L'examinateur est installé. Maintenant, il faut lui permettre d'agir.

Étape 2 · Faire en sorte que le score modifie la prochaine arête

Vous allez construire votre première évaluation, obtenir un chiffre, le regarder, et ne rien ressentir.

Cette sensation est correcte. Un chiffre dans un rapport n'a pas de chemin de retour vers l'exécution qu'il a mesurée.

Une seule ligne corrige toute la discipline, et elle appartient à un fondateur de 21 ans à Tokyo avec 258 abonnés, dont le post à ce sujet a reçu deux likes :

Un score qui ne change jamais le comportement, c'est de l'analyse. Une évaluation qui modifie la prochaine arête, c'est de l'ingénierie.

Son câblage comporte six règles. Chacune prend un verdict et fait quelque chose de structurel à l'exécution en cours :

1low context recall   → reject the handoff
2bad tool use         → retry or swap the node
3hallucination        → quarantine the branch
4schema failure       → block the edge
5compliance risk      → route to human review
6verified completion  → terminate the run

← six verdicts, six actions structurelles sur l'exécution en cours

Chacune de ces six est une décision de routage que le graphe exécute. L'évaluation dirige l'exécution en vol, une arête à la fois.

Règles pour le juge lui-même

L'examinateur a besoin de sa propre hygiène, et presque personne ne configure cette partie correctement.

1. Juger depuis une autre famille : un modèle reconnaît sa propre écriture et la note plus gentiment une fois qu'il l'a reconnue. Une équipe d'évaluation utilise Sonnet comme juge pour les sorties générées par Haiku, intentionnellement. Une ligne sur X le dit en moins de mots : la même famille génère et évalue, donc les angles morts sont partagés.
2. Écrire la grille d'évaluation en une ligne : la forme fonctionnelle est littéralement Réussite ssi [le résultat réussi et indépendamment observable]. Un verdict principal, jamais un ensemble de scores proxy.
3. Séparer le travail par type : le juge décide des appels sémantiques, le code simple décide des appels objectifs. Le test a-t-il réussi, le fichier existe-t-il, l'état a-t-il changé.
4. Ne jamais récompenser la forme d'une réponse : la règle écrite dans la compétence interdit de noter sur la longueur de la réponse, les mots-clés, le nombre de citations, le libellé exact, le nombre d'appels d'outils ou la similarité avec une référence. Récompensez la forme et l'agent apprendra la forme.
5. Épingler le juge et enregistrer sa version : un examinateur qui se met à jour silencieusement rend tous les scores avant et après incomparables, et vous ne le remarquerez pas avant un mois. L'épingle de version est celle que les gens sautent, et celle qui rend un mois de scores illisibles après coup.

Optimisez contre un juge assez longtemps et l'agent apprendra à avoir l'air correct plutôt qu'à être correct.

Maintenant, le score a un endroit où aller. Le problème suivant est de savoir d'où viennent les bons tests, car les inventer à un bureau est la raison pour laquelle le premier ensemble de tout le monde est inutile.

Étape 3 · Transformer une exécution échouée en évaluation

Les tests que vous inventez de toutes pièces vous protègent des échecs que vous avez déjà imaginés.

Ceux qui coûtent de l'argent se trouvent dans vos logs en ce moment même, avec un horodatage.

La boucle entière comporte cinq étapes :

1mine traces -> identify a failure -> build an eval -> improve the agent -> rerun

D'où viennent les tests

La première étape porte tout le poids. La compétence qui fait cela professionnellement nomme quelles exécutions extraire, et elle commence par 25 traces complètes, pas plus, choisies de sorte que les bons et les mauvais comportements se côtoient :

1. Une requête normale qui s'est terminée : votre base de référence pour ce à quoi ressemble un fonctionnement correct.
2. Une requête que l'utilisateur a confirmée : la trace rare où vous savez que la réponse était bonne.
3. Une requête que l'utilisateur a corrigée ou reformulée : la correction est l'étiquette, gratuitement.
4. Une exécution avec un appel d'outil échoué, vide ou répété : la répétition signifie une boucle, le vide signifie qu'une réponse inventée arrive.
5. Une exécution avec une défaillance externe : un délai d'attente ou une limite de débit, où la seule chose testée est la façon dont votre agent se comporte lorsque le monde dit non.

Chacune est rédigée en quatre lignes, et ce modèle est la partie qui vaut la peine d'être volée :

1Observed behavior: what the user asked and what the agent actually did
2Comparison:       what worked and what did not
3Attribution:      agent behavior, dependency behavior, or unclear
4Eval candidate:   the capability to preserve or improve

L'attribution est l'endroit où les débutants perdent une semaine.

La même recherche appelée deux fois avec des arguments identiques est une boucle dans votre agent. Un code 429 qui revient est une limite de quelqu'un d'autre, et cela ne devient votre évaluation que si votre agent était censé s'en remettre.

De la découverte au dossier

Ensuite, la découverte devient un dossier, et le dossier est le format que l'outillage exécute :

1evals/<task-id>/
2├── task.toml
3├── instruction.md
4├── environment/
5└── tests/

← 25 traces → un échec → un dossier de tâche Harbor : ce que l'agent voit, ce qui reste caché

Une capacité par dossier. L'instruction et l'environnement sont visibles par l'agent testé. Le résultat attendu, la grille d'évaluation et les identifiants du juge ne le sont pas, et cette séparation est la seule raison pour laquelle le score signifie quelque chose.

Trois règles empêchent les échecs qui font abandonner les gens :

1. Ne jamais traiter la réponse enregistrée comme vérité : la trace vous dit ce que votre agent a fait, jamais ce qu'il aurait dû faire. Prenez le corrigé à partir des tests, des enregistrements sources, des politiques, de l'état connu ou d'une personne.
2. Testez le test avant de lui faire confiance : soumettez deux résultats factices à la main au vérificateur, l'un clairement correct et l'autre plausible mais faux. Si l'un ou l'autre va dans le mauvais sens, c'est la grille qui est cassée, pas l'agent.
3. Surveillez que l'environnement ne donne pas la réponse : si la configuration remet le résultat avant que l'agent n'atteigne l'outil qu'il était censé utiliser, la tâche réussit pour toujours et ne mesure rien.

Tout ce qui coûte de l'argent ou écrit en production est simulé plutôt qu'appelé, afin que la suite s'exécute aussi souvent que vous le souhaitez sans facture.

Une instruction lance tout cela, dans l'agent que vous avez déjà ouvert :

1Use the eval-engineering skill.
2
3Map this repository's agent: entrypoint, tools, backing data, and what a good
4result looks like. Then read the 25 traces in ./traces and propose two or three
5eval candidates grounded in what actually failed there.
6
7Recommend one. Do not implement until I choose.
8Build it as a Harbor task under evals/, keep the rubric and expected outcome
9hidden from the target, and test the verifier on one passing and one plausible
10wrong result before the real run.

L'étape d'entretien est délibérée. L'équipe qui a écrit la compétence a constaté que questionner l'utilisateur bat la génération en une seule fois à chaque fois, pour la simple raison que la définition de ce qui est correct se trouve dans votre tête et nulle part dans le modèle.

Exécutez-la quelques fois et chaque échec cesse d'être un incident et devient un test permanent.

Étape 4 · Laissez le graphe fusionner son propre travail

Chaque pull request qu'un agent ouvre atterrit au même endroit : une file d'attente humaine.

Vous devenez le goulot d'étranglement de votre propre automatisation, et la flotte que vous avez construite tourne à la vitesse d'un seul relecteur fatigué.

La solution ne ressemble en rien à faire davantage confiance au modèle. Lorsqu'un agent ouvre une pull request, quatre signaux sont déjà disponibles, et un score de confiance est calculé à partir d'eux sur-le-champ :

1. Résultat des garde-fous : une réussite ou un échec déterministe sur les normes de blocage. Aucun modèle impliqué.
2. Trajectoire d'évaluation récente : comment cette version exacte de cet agent a été notée récemment.
3. Taux de retour historique : à quelle fréquence cet agent, sur ce dépôt, sur cette classe de changement, a vu son travail annulé auparavant.
4. Résultat du bac à sable : a-t-il fonctionné.

Au-dessus du seuil, il se fusionne tout seul. En dessous, un humain le reçoit avec le signal défaillant nommé, afin que la révision commence par le problème plutôt que par la première ligne.

← quatre signaux → un score de confiance → fusion automatique, ou routage vers un humain

Trois de ces quatre sont de l'historique et des vérifications déterministes, et exactement un d'entre eux touche le modèle.

La confiance en un agent est un calcul actuariel.

Ce que vous construisez, c'est un historique avec un prix, de la même manière qu'un assureur en construit un, et il devient plus précis chaque semaine, que les modèles s'améliorent ou non.

À quoi cela ressemble quand ça tourne

Dans la même entreprise qui n'a changé que ses évaluations, 19 pull requests sur 20 sur l'agent entièrement autonome fusionnent sans intervention humaine.

Parmi les meilleurs agents, environ les trois quarts du travail fusionné sont intégrés sans aucune édition humaine, le taux de retour reste à un chiffre faible, et les garde-fous à eux seuls renvoient une pull request sur cinq avant qu'une personne ne la voie.

Quelqu'un qui utilise ce modèle sur ses propres dépôts l'a formulé d'une manière qu'aucun fournisseur n'emploierait :

Au cours des 90 derniers jours, j'ai approuvé et fusionné environ 1 500 pull requests. Je n'ai pas regardé une ligne de code. Comment puis-je faire autant confiance aux agents ? Je ne leur fais pas du tout confiance. Je ne fais pas non plus confiance à ma capacité à réviser leur code. Mais je fais confiance à ma capacité à contraindre leur travail.

La contrainte est le produit.

Et l'avertissement qui vaut plus que la formule vient d'une équipe qui a exécuté 285 itérations d'une base de code auto-améliorante et a abouti à 1 094 pull requests fusionnées et zéro régression.

Leur propre ligne est celle à retenir : 38 tests verts coexistaient avec un produit complètement cassé.

Une suite peut être entièrement verte tandis que le produit qu'elle protège s'effondre, c'est pourquoi la boucle doit converger vers le cahier des charges plutôt que vers le score.

Activez-la de manière prudente :

1. Exécutez-la d'abord en mode fantôme : la porte évalue chaque pull request et n'en fusionne aucune, pendant au moins 4 heures de trafic réel.
2. Fixez un seuil de déviation de 2 % : si le verdict automatisé et le verdict humain sont en désaccord au-delà de ce seuil, la porte reste fermée.
3. Échantillonnez les traces à 1 % à 5 % : la capture complète de tout est un coût que vous n'avez pas besoin de supporter.

Une équipe de deux personnes où chaque changement écrit par un agent attend un relecteur peut prendre en charge à peu près autant de travail que ce relecteur peut en lire.

Avec la porte fermée sur la partie risquée et ouverte sur les 80 % ennuyeux, les mêmes deux personnes commencent à soumissionner sur les contrats qu'elles refusaient auparavant.

La facture du modèle ne bouge pas. Tout le reste, oui.

Étape 5 · Les évaluations à construire cette semaine

Une suite trop lente ou trop vague n'est jamais exécutée, donc voici la partie à garder.

Commencez avec trois mesures, pas douze. Les trois qui ont exposé l'agent de voyage sont un bon point de départ pour tout agent qui appelle des outils :

1. Fidélité : la réponse est-elle fondée sur ce que les outils ont réellement renvoyé. C'est celle qui était à 32,3 % alors que tous les autres chiffres sur le tableau de bord semblaient corrects.
2. Exactitude des paramètres d'outil : bon outil, bons arguments.
3. Qualité de la réponse : la sortie est-elle cohérente et utile pour la personne qui a posé la question.

Si votre agent livre du code, évaluez plutôt le changement. Les cinq dimensions utilisées en production sur chaque pull request : intention et décision, exécution et artefact, exhaustivité et utilité, instruction et limite, efficacité.

Choisissez le type de jeu de données à dessein. Il en existe quatre : final_response pour la réponse seule, single_step pour une décision isolée, trajectory pour le chemin complet emprunté par l'agent, et RAG pour la qualité de la récupération.

Évaluer uniquement la réponse finale, c'est ainsi qu'un agent atteint une réponse correcte via une séquence cassée sans que personne ne le remarque.

Dimensionnez-la pour qu'elle reste vivante. Réservez 300 à 800 cas, et gardez 500 d'entre eux en cours d'exécution en moins de 5 minutes.

Une suite qui prend plus de temps qu'une pause-café cesse d'être exécutée.

Les cinq premières évaluations, dans l'ordre :

1. Résultat d'outil vide : l'outil ne renvoie rien, et l'agent doit le dire au lieu d'inventer le chiffre.
2. Appel répété : la même recherche avec les mêmes arguments deux fois. C'est une boucle, et l'évaluation la fait échouer.
3. Refus de limite : on demande quelque chose en dehors de ses autorisations, l'agent décline proprement au lieu de chercher un contournement.
4. Intégrité du transfert : ce que le nœud précédent a produit est ce que le nœud suivant lit, sans rien inventé entre les deux.
5. Achèvement vérifié : terminé signifie qu'un signal réel dit terminé, jamais la propre parole de l'agent.

← cette semaine : trois mesures, un type de jeu de données, cinq évaluations (la carte à sauvegarder)

Trois mesures, un type de jeu de données, cinq évaluations. C'est un après-midi de travail, et chaque semaine qui suit, la suite vaut plus que la semaine précédente.

Ceux qui passent en premier

Le modèle n'a jamais été la partie intéressante. C'est une location, identique pour tout le monde, et il sera remplacé deux fois avant la fin de l'année.

Ce qui survit à chaque remplacement, c'est l'examinateur que vous avez construit autour de lui : les échecs que vous avez transformés en tests permanents, les règles qui permettent à un verdict de modifier la prochaine arête, l'historique qui permet à une machine de fusionner son propre travail.

C'est cela qui décide si les 200 $ sur votre relevé de carte produisent une démo ou produisent une entreprise.

La plupart des gens retourneront faire défiler les sorties un vendredi et décider que ça semble à peu près correct.

Ceux qui passent en premier consacrent un après-midi à câbler le thermostat, puis passent l'année suivante avec un agent qui ne peut pas casser deux fois la même chose.

Trois lignes résument toute la discipline :

1. Mesurez le chemin que l'agent a emprunté, jamais seulement la réponse sur laquelle il a atterri.
2. Un verdict qui ne modifie pas la prochaine arête est un rapport.
3. Tout échec que vous ne transformez pas en test permanent, vous le rencontrerez à nouveau.

Installez une compétence. Extrayez 25 traces. Construisez une évaluation aujourd'hui, et ajoutez-en une chaque fois que quelque chose se casse.

Si vous voulez rester informé de tout ce qui se passe dans l'IA, suivez-moi sur X et Telegram :

X -

https://x.com/Argona0x Telegram -

https://t.me/+r0clI4-MMC03ZjAy