LLM as a judge : évaluer un modèle avec un LLM

Dès qu'une équipe change un prompt, teste un nouveau modèle ou lance un fine-tuning, la même question revient : qui relit les sorties pour vérifier qu'elles sont toujours bonnes ? Relire cent conversations à la main une fois, c'est faisable. Le refaire à chaque mise à jour de prompt, pendant des mois, ne tient pas. C'est ce vide que le LLM-as-a-judge vient combler : faire noter les réponses d'un modèle par un autre modèle, avec une grille de lecture explicite plutôt qu'un avis flou.

L'idée n'est pas nouvelle, elle vient d'une recherche académique de 2023 encore largement citée, et elle s'est industrialisée depuis dans des outils open source concrets. Mais un juge LLM traîne ses propres biais mesurés, documentés, et loin d'être anecdotiques. Cet article détaille ce que dit la recherche, comment monter un juge en pratique avec un outil comme Promptfoo, et les pièges qu'on a vus se reproduire sur de vrais projets.

Pourquoi confier la notation à un LLM

Sur un projet d'agent IA, la sortie à évaluer n'est jamais figée : un changement de prompt, une mise à jour de base de connaissance ou un changement de modèle peut faire régresser la qualité d'une réponse sans que rien ne casse techniquement. Le test unitaire classique vérifie qu'un format JSON est valide ou qu'un champ existe, pas si la réponse est pertinente, complète ou dans le bon ton. Cette dernière question demandait jusqu'ici un relecteur humain, ce qui borne mécaniquement le volume qu'on peut se permettre de vérifier à chaque mise à jour.

La question de fond, faire noter une réponse de modèle de langage par un autre modèle de langage, a été formalisée dans un papier de recherche largement cité, Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. Le résultat central : sur un jeu de test contrôlé, GPT-4 utilisé comme juge est d'accord avec les évaluateurs humains dans 85 % des cas (notation individuelle comme comparaison par paires, hors égalités), quand deux évaluateurs humains ne sont eux-mêmes d'accord entre eux que dans 81 % des cas. Un juge LLM bien cadré n'est donc pas moins fiable qu'un second humain, il est juste disponible à un tout autre volume.

Sur les projets d'agents vocaux IA que nous développons chez Noxcod, comparer deux versions d'un prompt avant un déploiement passe par une notation automatisée sur un jeu de conversations réelles anonymisées, plutôt que par une relecture manuelle qui ne suit jamais le rythme des itérations de prompt. Le juge ne remplace pas l'avis humain sur le fond, il rend possible de tester chaque changement au lieu d'en tester un sur dix faute de temps.

Ce que la recherche a vraiment mesuré

Le papier de recherche s'appuie sur deux jeux de données construits pour l'occasion. MT-bench propose 80 questions multi-tours de bonne qualité, notées par 3 000 votes d'experts recueillis auprès de 58 évaluateurs qualifiés. Chatbot Arena, la plateforme de confrontation ouverte au public, a rassemblé environ 30 000 votes sur un mois, dont un échantillon de 3 000 votes en tour unique a servi de base de comparaison directe avec les jugements humains. Ce sont ces chiffres qui donnent leur poids aux 85 % d'accord cités plus haut, pas une estimation isolée sur un petit échantillon.

Le même papier documente aussi ce qui casse un juge LLM mal cadré. Le plus frappant : sans consigne particulière (le prompt de notation par défaut), le juge ne reste cohérent qu'à 65,0 % des cas quand on inverse simplement l'ordre des deux réponses comparées. Autrement dit, présenter la réponse A avant B ou B avant A peut à lui seul changer le verdict près d'un tiers du temps, un biais de position pur qui n'a rien à voir avec la qualité réelle des réponses. Deux autres biais s'ajoutent : le biais de verbosité (une réponse plus longue est jugée meilleure à contenu égal) et le biais d'auto-préférence (un modèle tend à mieux noter les réponses qui ressemblent à son propre style, y compris les siennes).

Notation par rubrique ou comparaison par paires : deux méthodes, pas une

Deux façons de noter coexistent, et les confondre est une source fréquente de configuration bancale. La notation individuelle (single-answer grading) donne une seule réponse au juge avec une grille de critères, et lui demande un score ou un verdict pass/fail. La comparaison par paires (pairwise comparison) présente deux réponses concurrentes au juge et lui demande laquelle est meilleure, ou une égalité.

Écrire une bonne grille de notation est un exercice de prompt engineering à part entière : une consigne vague ("cette réponse est-elle bonne ?") produit un juge instable, alors qu'une grille qui détaille des critères concrets et pénalise explicitement les défauts connus (verbosité inutile, invention de faits, ton hors charte) produit une notation reproductible d'un run à l'autre.

Mettre en place un juge LLM avec Promptfoo

Sur le terrain, on n'écrit que rarement son propre harnais de notation depuis zéro. Promptfoo est l'outil open source le plus répandu pour ça : licence MIT, 23 700 étoiles sur son dépôt GitHub, et racheté par OpenAI en mars 2026 tout en restant open source, un signal que même l'éditeur de GPT considère l'évaluation indépendante des modèles comme un sujet à part entière.

La configuration passe par un fichier YAML avec une assertion de type llm-rubric :

assert:
  - type: llm-rubric
    value: |
      La réponse doit indiquer clairement les étapes d'annulation.
      La réponse ne doit inventer aucune politique non documentée.
      Retourne pass=true si les deux critères sont respectés.

Le modèle qui sert de juge se choisit indépendamment du modèle testé, en surchargeant le fournisseur au niveau global ou par assertion :

defaultTest:
  options:
    provider: openai:responses:gpt-5-mini

La documentation officielle de Promptfoo est explicite sur un point souvent négligé : le juge doit être au moins aussi capable que le système évalué, jamais plus faible. Sur un fine-tuning, cette règle compte double : après avoir affiné un modèle sur des données métier, le juge doit rester indépendant du jeu de données d'entraînement, sinon il valide des réponses biaisées par construction plutôt que de les détecter.

Les pièges qu'on a vus en vrai

Premier piège, le plus courant : utiliser le même modèle, ou la même famille de modèle, comme juge et comme système testé. Le biais d'auto-préférence documenté plus haut joue alors à plein, et le taux de réussite affiché grimpe artificiellement sans que la qualité réelle ait bougé. La parade est simple à énoncer, plus rare à appliquer : le juge doit venir d'une famille de modèle différente de celle testée, ou, pour les projets sensibles à la confidentialité, tourner en local sur une infrastructure séparée plutôt que d'envoyer les sorties d'un client vers une API tierce. C'est le même arbitrage que celui détaillé dans notre article sur le LLM en local en entreprise : héberger soi-même le modèle qui juge évite qu'une sortie client transite par un tiers, simplement pour la faire noter.

Deuxième piège : déployer un juge en production sans jamais l'avoir calibré. Le résumé de la documentation Promptfoo le formule sans détour : commencer par une seule règle claire de type pass/fail, et calibrer le juge sur des exemples déjà étiquetés par un humain avant de lui faire confiance en intégration continue. Sans cette étape, on découvre le décalage entre le verdict du juge et la réalité le jour où un client se plaint d'une réponse que le juge avait notée "conforme".

Troisième piège, plus coûteux qu'il n'y paraît : appeler le juge LLM sur chaque test, y compris ceux qu'une vérification déterministe suffirait à trancher. Un juge LLM consomme des tokens à chaque appel, et ce coût s'additionne vite quand la suite de tests grossit ; c'est un sujet à part entière, que nous détaillons dans notre article sur le FinOps IA et la maîtrise des coûts LLM. La bonne pratique documentée par Promptfoo consiste à empiler d'abord des vérifications rapides et gratuites (validité JSON, présence d'un champ, valeur exacte attendue), et à ne réserver le juge LLM, plus lent et plus cher, qu'aux critères vraiment qualitatifs qu'aucun test déterministe ne peut trancher.

Où un juge LLM ne remplace pas un humain

Un juge LLM note contre une grille qu'un humain a écrite, avec un accord mesuré à 85 % sur un jeu de test contrôlé, jamais 100 %. Sur des critères purement fonctionnels (le format est-il respecté, l'information demandée est-elle présente), cet écart est négligeable. Sur des sorties à fort enjeu, contenu médical, juridique ou financier, où une erreur rare mais grave pèse plus que quatre-vingt-cinq réponses correctes, s'appuyer uniquement sur un juge automatique revient à accepter un taux d'erreur qu'aucun humain ne validerait s'il le voyait écrit noir sur blanc.

Là aussi, la règle qu'on applique en projet est simple : le juge LLM absorbe le volume de la vérification récurrente, la relecture humaine reste sur l'échantillon à fort risque et sur la calibration initiale de la grille. Aucun des deux ne remplace l'autre, ils se partagent le travail selon ce qui est en jeu. Chez Noxcod, on accompagne la mise en place de ce type de pipeline d'évaluation dans le cadre de projets de développement sur mesure, du choix de la méthode de notation jusqu'à son intégration dans la chaîne de déploiement.

Si votre projet touche à des sorties générées par un LLM et que la relecture manuelle est devenue le goulot d'étranglement de vos mises à jour, planifier un appel avec notre équipe permet de voir ensemble quelle méthode de notation correspond à votre volume et à vos critères de risque.

Questions fréquentes

Le juge LLM doit-il être plus puissant que le modèle évalué ?

Oui, ou au minimum d'un niveau équivalent. La documentation de Promptfoo le formule comme une règle dure : un juge moins capable que le système testé produit des verdicts moins fiables que le système lui-même, ce qui rend la notation inutile voire trompeuse.

Combien coûte une notation par juge LLM ?

Chaque appel au juge consomme des tokens comme n'importe quel appel de modèle, un coût qui s'ajoute à celui du système testé. La pratique courante est de réserver le juge LLM aux critères qualitatifs et de filtrer en amont avec des vérifications déterministes gratuites, pour ne payer le juge que sur ce qui le justifie vraiment.

Un juge LLM peut-il remplacer complètement une relecture humaine ?

Non. Même un juge bien calibré plafonne autour de 85 % d'accord avec un évaluateur humain sur un jeu de test contrôlé. Ça suffit pour absorber le volume de la vérification récurrente, pas pour les sorties à fort enjeu où une erreur rare doit rester détectée par un humain.

Comment éviter que le juge favorise ses propres réponses ?

En choisissant un juge d'une famille de modèle différente de celle testée. Le biais d'auto-préférence documenté dans la recherche académique fait qu'un modèle tend à mieux noter des réponses qui ressemblent à son propre style, y compris les siennes.

Faut-il inverser l'ordre des réponses en comparaison par paires ?

Systématiquement. La recherche a mesuré que le verdict d'un juge sans consigne particulière ne reste cohérent qu'à 65 % quand on inverse simplement l'ordre de présentation des deux réponses comparées, un biais de position qui n'a rien à voir avec la qualité réelle du contenu.