LLM-as-Judge : Claude pour auditer un agent Gemini

Dans l'article précédent, j'ai comparé 7 modèles de 4 fournisseurs sur la même tâche. Gemini 3 Flash a gagné sur l'équilibre précision/coût/latence. Sauf que même le meilleur score au benchmark, ça garantit pas que l'agent est bon. 74,5% de précision, ça veut quand même dire qu'on a un produit sur quatre avec la mauvaise réponse. Et le pire : sur certains, l'agent affiche une grosse confiance alors qu'il s'est planté.

Le benchmark dit ce qui plante. Pas pourquoi. Pour ça, j'avais besoin d'un truc capable de relire le raisonnement de l'agent pas à pas et de me montrer où ça déraille.

Du coup j'ai construit un juge.

Le principe

L'agent de prod tourne sur Gemini 3 Flash. Rapide, pas cher, c'est pour ça qu'il est en prod. Mais il fait des erreurs. Et certaines erreurs se ressemblent. Si j'arrivais à identifier les patterns, je saurais quoi corriger dans le prompt ou le pipeline.

Relire les traces à la main, c'est faisable mais c'est long. Chaque trace fait 3-6 appels d'outils, chacun avec une requête de recherche, des résultats, du contenu de page, et une étape de raisonnement. Un produit, c'est 10-15 minutes si tu fais ça bien. Cinquante produits, c'est une semaine.

La solution : mettre un modèle plus costaud (Claude Opus 4.6) sur le coup. Claude raisonne mieux que Gemini Flash. Il peut lire une trace d'agent en entier, repérer les erreurs de logique, vérifier les sources, essayer des approches que l'agent a loupées. En gros, une code review par un dev senior. Sauf que le dev senior est aussi un LLM.

Le process en 3 phases

Le juge suit un process strict en 3 phases pour chaque review.

La règle clé : si l'agent a dit "inconnu" mais que le juge a trouvé la réponse, c'est "incorrect". On juge le résultat, pas l'effort.

Ce que le juge a trouvé

75 scans de prod analysés (20 dans un premier lot, 55 dans un second). Score moyen : environ 50/100. Ça a l'air catastrophique, mais je fais pas tourner le juge sur les cas faciles. Je sélectionne les cas intéressants : confiance "probable", scans où le préfixe GS1 contredit le pays trouvé, résultats surprenants, produits où un user a remonté une erreur. Le juge est un outil d'apprentissage, pas un échantillon représentatif.

L'intérêt, c'est pas le score agrégé. C'est les patterns.

Trois trucs ressortent.

Les agents prennent des raccourcis. Le plus gros pattern (28/55 scans, lot 2) : l'agent utilise tous ses appels d'outils pour des recherches web et ne lit quasi jamais les pages. Il trouve un snippet qui dit "Fabriqué en France", il prend ça pour argent comptant, et il passe au suivant. Sauf que le snippet peut être un lien de navigation, un filtre de catégorie, ou une mention qui concerne un autre produit sur la même page. La réponse était souvent sur la page, à un clic.

Si tu construis un agent avec des outils, vérifie qu'il les utilise tous. Le nôtre avait read_webpage dispo mais préférait rester dans sa boucle confortable de snippets.

Les benchmarks construits à la main ont des angles morts. L'agent ne cherchait jamais par numéro de code-barres (18/55 scans). Toujours par nom de produit. Mais certains produits ont pas de nom clean dans notre base, et en cherchant l'EAN direct sur les sites de retailers, il serait tombé sur des infos d'origine structurées sans forcer.

Ce pattern était invisible dans le benchmark. Chaque item avait un nom clean parce que je l'avais construit comme ça. Le benchmark testait "est-ce que l'agent trouve l'origine d'un produit connu". La prod testait "est-ce que l'agent gère n'importe quel code-barres qu'un mec scanne au rayon". Pas la même question, pas les mêmes modes de défaillance.

Les patterns bougent, et il faut les suivre. Entre le lot 1 (20 reviews) et le lot 2 (55 reviews), les snippets mal interprétés sont passés de 35% à 18%. Mais les appels d'outils gaspillés sont montés de 15% à 25%. L'agent progressait sur certains trucs et régressait sur d'autres. Sans lancer l'analyse deux fois, j'aurais loupé les deux tendances.

Le problème du coût (et un hack pas glamour)

Le juge tourne avec Claude Opus 4.6 via l'API Anthropic, avec les mêmes outils de search et de lecture de page. La Phase 2 à elle seule peut envoyer 4-8 appels d'outils. Chaque review coûte entre 0,40 et 0,70 $.

Pour 50 produits, ça fait 20-35 $. Pas la mort, mais trop cher pour de la QA régulière. Et moi je voulais analyser tous les scans de prod intéressants, pas juste un échantillon.

Ma solution : j'ai reconstruit exactement le même juge en commande slash dans Claude Code. Même process en 3 phases, mêmes outils, même output structuré. La différence : la version CLI tourne sur mon abo Claude Max au lieu de l'API. Coût marginal par review : 0 $.

La version API existe toujours pour l'usage automatisé. Mais au quotidien, je tape /judge <EAN> dans mon terminal et j'ai la même review structurée sans payer à l'appel.

Pas glamour. Mais efficace. Ça m'a fait passer de "je peux me permettre 20 reviews par mois" à "je review tout ce que je veux". Et c'est ce volume qui rend l'analyse de patterns utile.

L'analyse de patterns

Une review individuelle, c'est utile. Des patterns sur 75 reviews, ça change la donne.

À côté du juge, j'ai construit une commande d'analyse qui lit les N dernières reviews et identifie ce qui revient : quels tags de problèmes sortent le plus, quelles défaillances se regroupent, quelles recos reviennent sous différentes formes, quels types de requêtes plantent systématiquement.

L'output est un rapport priorisé. Chaque pattern a une fréquence (X sur N reviews), un rating d'impact (est-ce que ça cause des mauvaises réponses ou juste de l'inefficacité ?), et un scope (universel, par marché, par catégorie). À la fin : 3-5 recos classées par priorité.

C'est là que le système se rentabilise. Une review dit "ce produit a eu la mauvaise réponse parce que l'agent a fait confiance à un snippet trompeur". Soixante-quinze reviews disent "l'agent ne lit quasi jamais les pages, et imposer un ratio minimum de lecture réglerait le problème à la source". L'un c'est une anecdote. L'autre c'est une stratégie.

Le benchmark et le juge se complètent. Le benchmark mesure la performance agrégée et attrape les régressions. Le juge explique pourquoi ça plante et fait remonter des patterns que les jeux de test construits à la main ne voient pas. J'ai besoin des deux.

La boucle

Tout l'intérêt du juge, c'est de nourrir l'agent. Certaines recos ont donné des résultats direct. Le pattern EAN-first est devenu un changement de prompt. Le truc sur les snippets mal interprétés a mené aux règles anti-FC décrites dans l'article sur le prompt engineering (celles qui plantaient sur Flash Lite mais marchaient sur 3 Flash).

D'autres recos n'ont rien donné en pratique. L'adaptation linguistique (chercher en italien pour les produits italiens) a rajouté du bruit sans rien améliorer. Parfois le juge identifie un problème mais le fix n'existe pas encore, ou le modèle arrive pas à gérer la complexité en plus.

Le juge remplace pas ton jugement sur quoi changer. Il montre où regarder.

Est-ce que ça vaut le coup ?

Le système de juge, c'est du boulot d'ingé. Le process en 3 phases, le schéma de review structuré, le formatage des traces, le rebuild en CLI, la couche d'analyse.

Mais avec du recul : le juge a trouvé le pattern EAN-first qu'aucun benchmark n'aurait fait remonter, même en passant des heures dessus. Il a confirmé les résultats du benchmark avec des données de prod. Et il m'a donné un vocabulaire structuré pour les défaillances (ces 13 tags) qui permet de suivre les patterns dans le temps.

Si tu construis un agent qui tourne en prod, t'as besoin d'un moyen de comprendre pourquoi il plante, pas juste combien de fois. La relecture manuelle scale pas. Un agent-juge, si.

La suite : De 42% à 78% : le journal d'itération complet d'un agent IA en prod. 108 runs de benchmark, 7 modèles, 6 versions de prompt, 3 semaines. Chaque décision, et la timeline qui relie tout.

Cet article fait partie d'une série sur la construction d'un agent IA de production pour Mio. Précédent : 7 LLM de 4 fournisseurs sur la même tâche agentique.