Le modèle comme juge (LLM-as-a-judge) : ce qu’il évalue et quels biais vérifier

Définition : qu’est-ce qu’un modèle utilisé comme juge ?

Un modèle utilisé comme juge est un modèle de langage qui sert à évaluer une réponse, une sortie ou le comportement d’une application d’IA selon des critères définis à l’avance. Il peut, par exemple, attribuer une note, classer le résultat ou comparer deux options. L’expression anglaise courante est « LLM-as-a-judge ».

L’objet évalué n’est pas nécessairement un texte. Selon l’usage, il peut s’agir de la réponse d’un chatbot, d’un résumé, d’une sortie produite par un outil ou de la trace des actions d’un agent. L’évaluation peut également tenir compte d’informations de référence, comme la question initiale, un document source, une politique ou une liste de contraintes.

Cette expression désigne une méthode d’évaluation, et non une garantie d’exactitude. Le jugement produit reste une sortie de modèle : il dépend de ce qu’on lui demande d’examiner, des critères qui lui sont fournis et des informations dont il dispose. Une note automatisée n’équivaut donc pas, à elle seule, à une vérité vérifiée, à une étiquette de référence indépendante ou à une évaluation humaine.

Dans sa portée opérationnelle, le guide de Langfuse définit cette méthode comme l’utilisation d’un modèle de langage pour évaluer la qualité des sorties d’une autre application fondée sur un LLM. La documentation de MLflow couvre les applications LLM et les agents, et cite plusieurs dimensions possibles de la qualité, notamment l’exactitude, la pertinence, l’ancrage dans les sources, la sécurité et l’utilité. Ces descriptions permettent de comprendre les usages, mais ne font pas d’un outil particulier une définition universelle.

Comment se déroule le processus ?

Un processus d’évaluation raisonnable commence par la définition de ce que l’on veut juger et de la finalité recherchée. Vérifier qu’une réponse respecte une politique n’est pas la même chose qu’évaluer si elle est claire pour une personne. Si l’objectif reste vague, le modèle peut produire un jugement qui semble précis sans répondre au besoin réel.

On précise ensuite les critères. Une grille d’évaluation peut décrire des dimensions distinctes, comme la fidélité à une source, la couverture des informations, le respect des contraintes ou la pertinence. Elle peut aussi définir une échelle et expliquer ce que signifie chaque niveau. La grille n’élimine pas les désaccords, mais elle rend explicites les attentes envers le juge.

On fournit ensuite les éléments utiles : la réponse ou la trace à évaluer et, si nécessaire, la question, le document de référence, les règles en vigueur ou les contraintes de la tâche. Le contexte doit suffire à appliquer le critère. Ce guide ne présume toutefois pas que davantage d’informations améliore toujours le jugement : il convient de vérifier le contexte dont la tâche a réellement besoin.

La consigne d’évaluation précise le rôle du juge et le format de la sortie. Le résultat peut inclure une note, une catégorie, une préférence entre plusieurs options et une explication. Enfin, on examine le jugement : on recherche les erreurs, on le compare à des évaluations humaines ou à des références externes lorsque c’est possible, puis on décide s’il convient à l’usage envisagé. Le fait que le juge fournisse une justification ne prouve pas, à lui seul, que celle-ci est correcte.

Formes de jugement : notation, classification et comparaison

Dans une évaluation par critères, le juge examine une réponse individuellement, par exemple sur une échelle définie par l’équipe. Une note n’est interprétable que si l’on sait ce que représente chaque valeur. Une note globale peut masquer qu’une réponse est fidèle mais incomplète, ou complète mais contraire à une contrainte. Distinguer plusieurs dimensions peut rendre ce type de compromis plus lisible.

Dans une classification, le juge attribue une catégorie, par exemple « conforme », « non conforme » ou « à examiner ». Il peut aussi répartir plusieurs réponses en groupes ou en niveaux. Les catégories évitent l’apparence d’une précision numérique, mais nécessitent toujours des définitions claires et une application adéquate de ces définitions par le modèle.

Dans une comparaison par paires, on présente deux options et l’on demande au juge de choisir celle qui répond le mieux à un critère, ou de déclarer une égalité si le format le permet. Le résultat est relatif : la préférence pour une option ne prouve ni qu’elle est correcte ni qu’elle dépasse un seuil absolu. De plus, la comparaison porte sur la paire présentée ; elle ne permet pas automatiquement d’établir un classement fiable de toutes les réponses possibles.

Ces formats sont différents et répondent à des questions différentes. Une note cherche à exprimer une performance sur une échelle ; une catégorie attribue une étiquette ; une comparaison indique une préférence entre plusieurs options. Il ne faut pas supposer qu’un format est toujours supérieur aux autres. Le choix dépend de la décision à prendre et doit être testé sur des exemples représentatifs.

Exemple pratique : réponses du service client

Imaginons qu’une équipe souhaite examiner les réponses d’un assistant de service client. L’objet de l’évaluation est chaque réponse ; le contexte utile peut comprendre la demande de la personne et la version en vigueur de la politique applicable. Une grille pourrait distinguer, au minimum, le fait que la réponse traite la demande, qu’elle concorde avec la politique fournie et qu’elle respecte les contraintes de communication définies par l’équipe.

Le juge pourrait classer chaque dimension, attribuer des notes distinctes et signaler les cas incertains pour examen. Par exemple, si la réponse promet un remboursement, le critère ne devrait pas être de savoir si cette promesse paraît raisonnable : il faut la vérifier par rapport à la politique fournie. L’évaluation du modèle indique comment celui-ci a interprété les éléments ; elle ne remplace ni la vérification de la mise à jour de la politique ni la décision sur la règle à appliquer.

Pour évaluer la méthode, l’équipe peut sélectionner des cas couvrant différentes demandes et exceptions, comparer les jugements à des évaluations humaines et examiner les désaccords. Si le système sert à prioriser les demandes à revoir, il est également utile de vérifier s’il repère les cas que l’équipe considère comme sensibles ou incertains. Il s’agit d’une piste de conception : les sources disponibles ne permettent pas d’affirmer qu’un juge sera d’accord avec des spécialistes dans tous les cas.

Exemple pratique : résumés de documents

Pour comparer des résumés, l’objet évalué est le résumé et le contexte de référence comprend le document d’origine ainsi que la consigne de résumé. Les critères peuvent distinguer la couverture des points pertinents et la fidélité des affirmations au texte source. Séparer ces dimensions aide à ne pas confondre une rédaction fluide avec un résumé complet ou fidèle.

Un juge peut noter chaque résumé individuellement ou comparer deux résumés pour déterminer lequel couvre le mieux les éléments pertinents sans introduire d’affirmations non étayées. L’examen devrait vérifier si l’évaluation repère des omissions précises ou des affirmations incompatibles avec le document, au lieu de s’appuyer uniquement sur une explication générale telle que « celui-ci est plus complet ».

Les informations considérées comme pertinentes dépendent de la tâche : un résumé de direction, un résumé technique et un résumé conçu pour répondre à une question particulière peuvent nécessiter des couvertures différentes. Le document source et l’objectif du résumé doivent donc être accessibles à l’évaluateur. La note du juge ne constitue pas, en elle-même, une liste vérifiée des faits omis ou inventés.

Exemple pratique : agents de programmation

Pour évaluer un agent de programmation, l’objet peut inclure le résultat final et la trace des actions, et pas seulement le texte de la réponse. La tâche, les tests disponibles et les contraintes déterminent ce que signifie « terminer le travail ». Les critères explicites peuvent notamment porter sur la résolution de la tâche demandée et le respect de limites telles que l’interdiction de modifier certains fichiers ou d’utiliser un outil donné, si ces limites font partie de la consigne.

Un juge peut évaluer chaque critère, résumer les éléments de la trace qui semblent l’étayer ou indiquer qu’il ne peut pas trancher avec les informations disponibles. L’équipe doit vérifier si le jugement correspond à un résultat vérifiable. Par exemple, une explication convaincante affirmant que la tâche est terminée ne remplace pas l’exécution des tests ; inversement, réussir un test isolé ne prouve pas nécessairement que toutes les contraintes ont été respectées.

Cet exemple montre pourquoi l’objet de l’évaluation doit être défini avec soin : juger uniquement la réponse textuelle peut faire oublier des actions importantes, tandis que juger une trace sans connaître ses contraintes peut conduire à une évaluation incomplète. Les éléments de preuve suffisants dépendent de l’environnement et de la tâche concernés.

Que vérifier avant de se fier à un juge ?

Il est essentiel de vérifier la concordance entre les jugements du modèle et une référence adaptée à la tâche. Cette référence peut prendre la forme d’évaluations humaines, de règles vérifiables ou de résultats externes, selon ce que l’on mesure. Un taux de concordance global ne suffit pas si l’on ne sait pas quels cas ont été évalués, comment les désaccords ont été résolus et si les exemples représentent l’usage prévu.

Il est également utile de tester la stabilité du processus. Si l’on présente plusieurs fois le même cas, le jugement reste-t-il suffisamment constant pour la décision envisagée ? Les évaluations changent-elles lorsque l’on modifie des éléments de présentation qui ne sont pas pertinents ? Dans une comparaison par paires, il faut vérifier si le fait d’inverser l’ordre des options change la préférence. Ce sont des questions de validation, et non des affirmations selon lesquelles ces variations se produisent toujours.

La justification doit être examinée séparément. Une explication peut aider à repérer le critère appliqué par le modèle, mais elle ne prouve pas que la note soit correcte. On peut confronter les raisons aux éléments fournis et vérifier si elles s’appuient sur des preuves pertinentes, ou si elles sont vagues, incompatibles avec le résultat ou non étayées par la source.

Enfin, il faut évaluer si le juge convient à la tâche. Un modèle capable d’évaluer un type de réponse n’est pas automatiquement validé pour un autre domaine, une autre langue, un autre format d’entrée ou une décision aux conséquences différentes. Une étude de synthèse technique sur le LLM-as-a-judge présente le domaine comme l’utilisation de modèles de langage pour évaluer des tâches complexes ; la description disponible mentionne également l’emploi de consignes et d’exemples pour définir les tâches. Cela ne suffit pas, à soi seul, à établir qu’une méthode donnée est fiable dans chaque application.

Notions proches et confusions fréquentes

Un benchmark est un ensemble structuré de tâches ou de cas utilisé pour mesurer ou comparer des systèmes dans des conditions définies. Un modèle utilisé comme juge est, quant à lui, une méthode permettant d’attribuer des évaluations à des sorties. Un benchmark peut intégrer un juge, mais les deux termes ne désignent pas la même chose : le jeu d’évaluation définit les cas à tester ; le juge produit les évaluations ou y contribue.

Une grille d’évaluation est une spécification de critères, de niveaux ou de règles de notation. Ce n’est pas nécessairement un modèle ni un résultat. Le juge peut recevoir une grille pour guider son évaluation, mais la présence d’une grille ne garantit pas qu’il l’appliquera correctement.

La note attribuée par un juge n’équivaut pas non plus à une étiquette de référence ni à la vérité du cas. Une réponse peut obtenir une note élevée tout en contenant une erreur que la grille n’a pas détectée ou que l’évaluateur a mal interprétée. Lorsqu’une vérification directe est possible — par exemple une règle vérifiable ou le résultat d’un test — mieux vaut ne pas la remplacer, sans validation, par un avis généré.

Enfin, il faut distinguer le modèle évaluateur du modèle évalué. Dans une application, il peut s’agir de modèles du même type ou de modèles différents, mais leurs rôles sont distincts : l’un génère la réponse ou exécute la tâche ; l’autre porte un jugement sur cette sortie. Et « jugement automatisé » ne signifie pas « sans supervision humaine » : une évaluation humaine peut être nécessaire pour valider la méthode, résoudre des cas particuliers ou prendre des décisions importantes.

Limites et critères pratiques d’utilisation

Le jugement dépend de la définition de la tâche, des critères et du contexte fourni, ainsi que du comportement du modèle évaluateur. Une évaluation automatisée doit donc être décrite assez précisément pour que d’autres personnes comprennent ce qui a été jugé, selon quelles consignes et avec quelle sortie du juge. La documentation des outils peut proposer des formats opérationnels et des dimensions d’évaluation, mais les recommandations d’une plateforme ne constituent pas, à elles seules, la preuve qu’une conception donnée fonctionne dans toutes les applications.

Avant d’adopter cette méthode, il est utile de se demander : le critère correspond-il à un véritable besoin du produit ou s’agit-il seulement d’une approximation facile à noter ? Dispose-t-on de cas de référence adaptés ? Sait-on comment traiter les désaccords et les résultats incertains ? La sensibilité aux changements de présentation a-t-elle été testée ? La décision peut-elle être confrontée à une vérification externe ? Les réponses aident à déterminer dans quels cas le juge peut servir d’appui et dans quels cas un examen supplémentaire est nécessaire.

Il est également utile de commencer par un usage limité et réversible, d’analyser des exemples de réussite et d’échec, puis de réévaluer la méthode lorsque les politiques, les données, les consignes ou le modèle changent. C’est une recommandation pratique, et non une garantie de stabilité de l’évaluation. L’étendue de la supervision humaine doit dépendre de l’importance de la décision, des conséquences d’une erreur et des éléments obtenus pour la tâche concernée.

Pour approfondir, on peut consulter les fiches consacrées à l’évaluation de l’IA, aux benchmarks, aux grilles d’évaluation et à l’humain dans la boucle, ainsi que l’entrée sur le **juge LLM** et les critères de **comparaison de modèles**. Ces notions sont liées, mais ne sont pas interchangeables.

En résumé, un modèle utilisé comme juge peut structurer ou automatiser une partie du travail d’évaluation lorsque les critères et l’objet sont clairement définis. Son résultat doit être interprété comme le jugement produit par un modèle et vérifié pour l’usage envisagé. La question pratique n’est pas de savoir si un juge est fiable dans l’absolu, mais quels éléments justifient son emploi pour une tâche, des données et des conséquences particulières.

Concepts associés