Qu’est-ce que le LLM-as-a-judge et quand s’y fier ?
Le LLM-as-a-judge fait noter la réponse d’un modèle par un autre modèle. Voici comment nous avons contrôlé notre propre juge.
En bref. Le LLM-as-a-judge (modèle juge) consiste à faire noter la sortie d’un modèle par un autre modèle de langage. En développant diffox, nous nous en servons pour faire correspondre des constats de revue de code à des bugs que des humains avaient signalés à l’avance. Cet article présente les biais connus de la méthode, puis la façon dont nous avons contrôlé notre propre juge en août 2026 sur 891 paires (chaque paire réunit un constat de review et un bug signalé).
- Demandez au juge si c’est la même chose, pas si c’est bien. Une réponse d’un mot à la question « ces deux textes décrivent-ils le même bug ? » se vérifie ; une note donnée à « cette sortie est-elle bonne ? » ne se vérifie pas.
- L’accord global est trompeur. Sur 945 paires communes, nos deux juges étaient d’accord à 98,8 % ; sur les paires positives, celles qui décident du résultat, l’accord était de 93,5 %.
- Le juge bon marché s’est montré généreux, mais il a peu fait bouger le score. Sur les 400 paires que le juge bon marché déclarait correspondantes, le juge puissant en a rejeté 24 (6,0 %). Quand nous avons noté une configuration avec trois juges différents, le plus grand écart a été de 0,033, sous le seuil de bruit de la mesure (0,09).
- Le vrai bruit vient de l’exécution, pas du juge. Changer de juge a fait bouger le score de 0,033 au plus ; pour le même système, l’écart type d’une exécution à l’autre est de 0,094.
Qu’est-ce que le LLM-as-a-judge ?
La sortie d’un modèle de langage ne peut souvent pas être comparée à une seule bonne réponse : deux commentaires qui décrivent le même bug peuvent être écrits avec des mots tout à fait différents. Le LLM-as-a-judge comble ce manque : vous confiez l’évaluation à un autre modèle, auquel vous donnez une consigne (une grille d’évaluation, ou rubric). En français, nous dirons « modèle juge ».
Le travail qui a popularisé le nom de la méthode est l’article de Zheng et de ses coauteurs, paru en 2023 : ils ont montré que des modèles juges puissants s’accordent avec les préférences humaines dans plus de 80 % des cas, soit le même niveau que l’accord entre humains. Aujourd’hui, la plupart des benchmarks reposent sur un modèle juge. C’est aussi le cas de ReviewBench, que GitHub a publié pour la revue de code : il fait noter les constats par un modèle de langage avec une seule grille, et indique avoir mesuré 96,6 % d’accord en faisant réétiqueter ses données par des ingénieurs seniors.
Le modèle juge n’est pas le premier choix. La documentation d’Anthropic sur l’évaluation donne l’ordre clairement : d’abord la notation par du code, parce que c’est la plus rapide et la plus fiable ; ensuite le modèle juge, pour les jugements qu’une règle ne sait pas exprimer ; et, avant de l’utiliser à grande échelle, tester sa fiabilité.
| Méthode | Point fort | Point faible | Quand l’utiliser |
|---|---|---|---|
| Notation par du code | La plus rapide, la plus fiable, passe à l’échelle sans limite | Ne peut pas rendre un jugement qu’aucune règle n’exprime | Si la réponse se vérifie par une correspondance exacte ou une recherche de texte |
| Notation humaine | La plus souple, la plus fine | Lente et coûteuse | Sur un petit échantillon, pour contrôler le juge |
| Modèle juge | Rapide, souple, passe à l’échelle | A des biais ; à tester d’abord | Quand il faut un jugement et qu’aucune règle ne peut vérifier la réponse |
Source : la documentation d’Anthropic sur l’évaluation, 18 octobre 2026.
Les modèles juges ont des biais connus
Le même article dresse aussi la liste des limites des modèles juges : biais de position, biais de longueur, biais d’autopréférence (en faveur de leurs propres sorties) et capacité de raisonnement limitée. Quand vous mettez un juge en place, prévoyez une parade pour chacune.
Le biais d’autopréférence est le plus facile à éviter : le modèle qui évalue doit être différent de celui qui a produit la sortie. Le code d’exemple d’Anthropic le note comme une bonne pratique. Le biais de position apparaît dans les questions qui comparent deux réponses ; inverser l’ordre des réponses et poser la question deux fois rend son effet visible. Contre le biais de longueur, la parade la plus efficace consiste à demander au juge non pas une note, mais une réponse qui repose sur un seul fait.
Demandez au juge si c’est la même chose, pas si c’est bien
C’est d’abord la question qui fait la fiabilité du juge. « Ce commentaire de review est-il bon ? Note-le de 1 à 10 » n’a pas de bonne réponse ; deux juges, et même deux exécutions du même juge, donnent des notes différentes. Le conseil d’Anthropic va dans le même sens : que le juge réponde seulement « correct » ou « incorrect », ou qu’il choisisse un niveau de 1 à 5 ; une évaluation purement qualitative est difficile à vérifier vite et à grande échelle.
La question de notre juge est une comparaison : on lui donne un commentaire de review et un bug signalé à l’avance dans la même pull request, et on ne lui pose qu’une question. Le cœur de la grille ressemble à ceci :
You are given a review comment and a known bug in the same pull request.
Do they describe the SAME defect: the same code, failing for the same reason?
- A comment about the same file but a different problem is NOT a match.
- A comment that names the symptom while the known bug names its cause IS a match.
- If the comment is too vague to tell, answer no.
Answer with one word: yes or no.Les trois lignes de la grille tranchent à l’avance les cas où le juge hésite le plus : même fichier mais autre problème, symptôme face à la cause, commentaire trop vague. Quand ces lignes ne sont pas écrites, deux juges divergent précisément sur ces cas.
Regardez l’accord sur les paires positives, pas l’accord global
La première étape pour tester un juge consiste à soumettre les mêmes paires à un second juge. Nous avons pris deux modèles différents comme juges, avec la même grille : sur 945 paires communes, ils étaient d’accord à 98,8 %. Pris seul, ce chiffre rassure, et il trompe.
La grande majorité des paires sont des « non » évidents : le commentaire parle d’un fichier, le bug signalé d’un tout autre. Les deux juges s’accordent sur celles-là de toute façon. Ce qui décide du résultat, ce sont les paires où au moins un juge a dit « oui », et là, l’accord était de 93,5 %. Quand vous annoncez la fiabilité d’un juge, donnez le dénominateur : toutes les paires, ou les paires positives.
Nous avons contrôlé le juge bon marché avec un juge puissant, groupe par groupe
Nous faisons nos mesures courantes avec un juge bon marché. Pour répondre à la question « et si ce juge se trompait ? », il n’était pas nécessaire de remplacer le juge partout : la matrice complète demandait 4 185 paires. À la place, nous avons interrogé un modèle plus puissant, réglé sur un effort élevé, sur 891 paires seulement, choisies non pas au hasard, mais dans les groupes qui répondent à la question.
- Les 91 paires où les deux juges ont dit « oui » : le juge puissant n’en a inversé aucune. Une correspondance sur laquelle les deux juges s’accordaient est restée une correspondance avec un juge plus cher.
- Les 400 paires où les deux juges ont dit « non » : 1 seule a été inversée (borne supérieure : 1,4 %). Le juge ne manque pas de correspondances.
- 400 paires parmi les « oui » comptés dans le score : 24 ont été rejetées, soit 6,0 %. Le juge bon marché est généreux quand il compte une correspondance.
Le résultat tient en deux phrases distinctes, qu’il ne faut pas confondre. Les scores absolus sont optimistes d’environ 0,02 à 0,03. Changer de juge n’a pas fait bouger le score d’une configuration de plus de 0,033, ce qui est sous le seuil de bruit de la mesure (0,09). Mais nous l’avons mesuré sur une seule configuration ; nous ne disons donc pas que le classement de deux configurations sera conservé dans tous les cas. Le défaut d’un juge compte, ou non, selon ce que vous en faites.
Le score bouge plus d’une exécution à l’autre que d’un juge à l’autre
Quand nous avons renoté la même configuration avec trois juges différents, le plus grand écart de F1 a été de 0,033. Quand nous avons relancé la même configuration, sur les mêmes pull requests et avec le même juge, l’écart type d’une exécution à l’autre a été de 0,094 ; une fois, sans rien changer, nous avons vu un écart de 0,058 entre deux exécutions.
L’incertitude principale de la mesure ne vient donc pas du juge, mais du caractère aléatoire du système lui-même. La règle qui en découle est simple : si l’écart entre deux configurations est inférieur à environ 0,09, une seule exécution ne permet pas de le voir ; acheter un meilleur juge n’y change rien.
Un constat sans correspondance n’est pas forcément faux
Dans la plupart des benchmarks, le modèle juge compare le constat à une référence, c’est-à-dire aux bugs signalés à l’avance. Un constat absent de la référence compte comme une « fausse alerte ». Or cela dit seulement une chose : la personne qui a préparé la référence n’a pas noté ce point. Le constat peut très bien être juste.
C’est pourquoi ReviewBench publie deux familles de métriques : l’une n’utilise que les étiquettes existantes, l’autre évalue aussi, à part, les constats sans équivalent dans le jeu de référence. Faites la même distinction dans vos propres mesures : « ne correspond pas à la référence » et « faux » sont deux étiquettes différentes, et pour dire la seconde, il faut regarder le constat lui-même.
Conservez les décisions du juge, mesurez les changements de règle sans juge
Un appel au juge est payant, et poser deux fois la même question pour la même paire n’a aucun sens. Conservez chaque décision avec la paire et l’identité du juge : le modèle, le niveau d’effort, la version de la grille. Quand l’un de ces éléments change, ne mettez pas les anciennes et les nouvelles décisions dans le même tableau ; deux chiffres mesurés avec deux juges différents ne sont pas comparables.
Tous les changements ne demandent pas un juge. Quand vous changez un seuil ou un filtre, vous pouvez rejouer l’ancienne et la nouvelle règle sur des résultats déjà conservés, et ne regarder que les endroits où elles divergent. C’est ainsi que nous avons mesuré la modification d’une règle de filtrage : sur 1 405 constats enregistrés, l’ancienne et la nouvelle règle ne divergeaient qu’en 6 endroits, et il a suffi de lire les six à l’œil. Une nouvelle exécution n’aurait été ni gratuite ni aussi exacte.
Ces leçons viennent des propres mesures de diffox : nous ne décidons pas si un changement fonctionne sur la foi d’une seule exécution et d’un juge non contrôlé. Dans le produit lui-même, en revanche, ce n’est pas un modèle juge mais du code qui vérifie la citation sur laquelle repose un constat (article sur l’architecture).
Questions fréquentes
Qu’est-ce que le LLM-as-a-judge ?
C’est une méthode qui fait noter une sortie d’IA par un autre modèle de langage, auquel on donne une consigne (une grille d’évaluation). On l’utilise quand la réponse ne peut pas être comparée à un seul texte correct, par exemple pour décider si deux commentaires décrivent le même bug.
Le LLM-as-a-judge est-il fiable ?
Cela dépend de la question. Une étude de 2023 a montré que des modèles juges puissants s’accordent avec les préférences humaines dans plus de 80 % des cas. Sur les questions de comparaison (« est-ce la même chose ? »), les juges sont cohérents ; sur les questions ouvertes où on leur demande une note, ils ne le sont pas. Avant de faire confiance à un juge, testez-le sur un petit échantillon, avec un second juge ou des étiquettes humaines.
Comment écrire la grille d’évaluation d’un LLM-as-a-judge ?
Ramenez-la à une seule question et limitez la réponse : « oui/non » ou un niveau de 1 à 5. Écrivez dans la grille les cas limites où le juge hésiterait : ce qui compte comme une correspondance, ce qui n’en est pas une, et quoi répondre en cas de doute. La documentation d’Anthropic recommande aussi que le juge raisonne avant de répondre.
Quelles métriques pour un LLM-as-a-judge, et lesquelles regarder ?
Pour le juge lui-même : le taux d’accord avec des étiquettes humaines ou avec un second juge, en particulier l’accord sur les exemples positifs ; et le taux de décisions inversées par un juge plus puissant, avec son intervalle de confiance. L’accord global paraît plus élevé qu’il ne l’est, à cause des exemples négatifs faciles.
Le modèle juge peut-il être le même que le modèle évalué ?
Mieux vaut l’éviter. Les modèles juges ont un biais connu : ils notent plus haut leurs propres sorties. Le code d’exemple d’Anthropic note comme une bonne pratique d’utiliser, pour évaluer, un modèle différent de celui qui a produit la sortie.
Quelle différence entre LLM-as-a-judge et agent-as-a-judge ?
Le LLM-as-a-judge n’évalue que la sortie finale. L’agent-as-a-judge est une extension proposée par un article de 2024 : l’évaluation est confiée à un agent capable d’utiliser des outils, qui donne aussi un retour sur les étapes intermédiaires du travail. Il a été conçu pour évaluer des systèmes d’agents qui travaillent en plusieurs étapes.
diffox utilise-t-il un modèle juge dans ses reviews ?
Pendant le développement, oui : pour faire correspondre les constats à des bugs signalés à l’avance, et mesurer si un changement fonctionne. Quand une pull request est examinée, en revanche, ce n’est pas un modèle juge mais du code qui vérifie la citation sur laquelle repose le constat : la citation se trouve-t-elle vraiment dans le fichier, appartient-elle aux lignes modifiées ?