Pourquoi évaluer les modèles qui évaluent

Les modèles de langage ne servent pas seulement à rédiger ou à répondre. On les utilise aussi pour noter des réponses, comparer deux résultats, vérifier le respect d'une consigne, ou classer des contenus. Souvent, on parle de « LLM comme juge ». L'idée est simple : quand la correction traditionnelle coûte cher, l'automatisation peut aider - mais elle ne supprime pas le problème de fond. Elle le déplace : désormais, c'est le modèle évaluateur qui doit être fiable.

Si un juge accepte une réponse fausse, il peut gonfler artificiellement les scores d'un système. Dans un produit, il peut valider une information incorrecte, rater une erreur de calcul ou donner l'impression d'une conformité "cohérente", sans vérifier le fond. Et le risque grimpe vite dès que le verdict du juge influence une décision opérationnelle, une mesure de performance, ou une interaction avec un client.

Ce benchmark part d'une question précise : un modèle sait-il contrôler une réponse, ou sait-il seulement produire une justification qui a l'air convaincante ? L'expérience teste aussi plusieurs biais possibles : favoritisme pour ses propres réponses, influence de l'ordre d'affichage, et effet d'un nom ou d'une phrase de confiance.

Le point méthodologique clé est justement celui qu'on ne peut pas "remplacer" : les réponses correctes sont déterminées par du code, pas par un autre modèle. Comme ça, on évite de mesurer un simple accord entre IA et on l'associe réellement à la vérité. Pour une équipe produit, la conclusion est nette : un juge n'est utile que si sa décision est confrontée à une référence fiable.

Une expérience conçue pour isoler les biais

Le protocole en deux étapes commence par un script Python. Il génère 90 questions, réparties en six familles : exécution de courts programmes, calcul de dates, problèmes arithmétiques écrits en langage naturel, opérations sur des chaînes de caractères, petites énigmes logiques et dénombrement. Le script calcule chaque réponse, puis une seconde implémentation, indépendante, vérifie les résultats.

Ensuite, les dix modèles répondent. Une méthode de correction basée sur la dernière ligne de chaque réponse permet d'identifier ce qui est juste et ce qui est faux. On obtient ainsi un corpus de sorties réelles, dans le style de chaque modèle, avec des étiquettes de vérité qui ne dépendent pas d'un jugement "linguistique".

Puis on passe à l'étape de jugement. Les modifications sont construites pour ne changer qu'un facteur à la fois.

Le protocole ajoute aussi des contrôles. Des phrases neutres servent de placebo pour mesurer les variations "normales" entre deux évaluations. Les réponses justes et fausses sont appariées par question et, autant que possible, par longueur. Enfin, pour tester l'auto-préférence, le même texte est évalué selon trois versions : par l'auteur et par deux autres modèles. Ça évite de confondre favoritisme et indulgence générale.

Les appels en échec sont réessayés avec un délai progressif, puis écartés. Si plus de 10 % des appels d'un modèle échouent, les résultats ne sont pas retenus. Ce choix est logique : un score fabriqué à partir de réponses manquantes aurait l'air plus "propre" qu'il ne l'est. Le benchmark ajoute aussi deux points de comparaison : un juge qui répond toujours « correct » et un autre qui choisit systématiquement la réponse la plus longue.

Dix modèles, venant de six fournisseurs, ont été testés - majoritairement des modèles économiques ou de taille intermédiaire, ainsi que des modèles à poids ouverts. Les modèles les plus coûteux ont été exclus pour respecter le budget de test sur Kaggle. Résultat : les chiffres de coût sont des estimations basées sur cette expérience, pas des tarifs garantis pour tous les usages ni toutes les périodes.

Les résultats : la compétence compte plus que l'auto-préférence

Ce que ces résultats changent pour les entreprises

Pour une équipe produit, choisir le modèle "le plus connu" ou "le moins cher" ne suffit pas. Il faut partir du risque associé à une mauvaise validation, puis tester le juge sur des erreurs plausibles dans votre contexte.

Le benchmark suggère que Gemma 4 31B est une option relativement économique parmi les modèles les plus fiables : environ 10 % de fausses validations et un coût estimé de 1,25 dollar pour 1 000 évaluations. Gemini 3.8 Flash obtient le meilleur taux rapporté, 5 %, pour environ 2,69 dollars par millier. À l'inverse, les taux observés de 57 % et 90 % pour GPT-5.4 nano et GPT-5.4 mini rendent ces modèles difficiles à recommander comme juges autonomes sur ce type de tâche, même si leur coût unitaire reste bas.

Attention : ces chiffres ne se transfèrent pas tels quels à un assistant de service client, à une revue de conformité RGPD, ou à l'analyse de contrats. Ici, on teste des exercices vérifiables avec une réponse de référence claire. Les tâches ouvertes et les décisions réglementaires posent d'autres problèmes : plusieurs réponses peuvent être défendables, les critères peuvent être ambigus, et le coût d'une erreur n'est pas le même partout.

Cela dit, une méthode de sélection pragmatique peut s'appliquer :

1. Définir le rôle du juge. Est-il chargé de filtrer, de noter, de prioriser, ou de déclencher une action ? Plus la décision a de conséquences, moins une validation automatique est acceptable.
2. Construire un jeu de test représentatif. Inclure des réponses correctes, des erreurs réalistes, des cas limites, et des formulations différentes. Faites vérifier les étiquettes par une méthode indépendante ou par des experts métier.
3. Mesurer les deux types d'erreurs. Une fausse validation laisse passer une réponse incorrecte ; un faux rejet écarte une réponse correcte. Le coût métier peut être très différent.
4. Tester les perturbations. Inverser l'ordre des choix, varier la longueur, retirer les noms, et ajouter des formulations de confiance. Si le verdict change sans lien avec le fond, le juge est fragile.
5. Fournir les références disponibles. Quand une réponse est calculable ou qu'une procédure est documentée, donnez au modèle la réponse de référence, la règle applicable, ou les éléments de preuve pertinents.
6. Prévoir une revue humaine. Les cas ambigus, à forte conséquence, ou hors du domaine validé doivent sortir du flux automatique.

Et après déploiement, il faut surveiller. Une évaluation ponctuelle ne garantit pas la stabilité : les modèles évoluent, les prompts changent, et les utilisateurs s'adaptent. Le bon réflexe consiste à versionner le modèle et les consignes, conserver un échantillon de décisions, puis réévaluer régulièrement les erreurs observées. Ce n'est pas aussi "sexy" qu'un score unique, mais c'est beaucoup plus utile pour maîtriser le risque.

Limites du benchmark et pistes de suivi

On a ici des données solides, mais ce n'est pas une loi générale qui s'applique à tous les modèles et tous les usages. L'expérience repose sur dix modèles, des échantillons limités pour certains tests, et une seule exécution par modèle et par tâche. Par exemple, pour l'analyse de l'auto-préférence, chaque modèle n'a été exposé qu'à 24 textes contenant ses propres erreurs ; pour le test de position, à 40 paires ; et pour la reconnaissance de soi, à 15 paires.

Beaucoup de tests ont aussi été réalisés. Dans ce genre de contexte, des résultats isolés peuvent apparaître "par chance" quand la taille d'échantillon est faible. Les écarts observés pour les deux modèles GPT-5.4 méritent donc une nouvelle expérience avant d'être considérés comme acquis. L'auteur du benchmark le dit d'ailleurs clairement : une deuxième exécution serait nécessaire.

Le protocole privilégie des réponses dont la vérité peut être déterminée automatiquement. C'est un avantage pour mesurer les erreurs précisément, mais aussi une limite. Un juge qui évalue la qualité d'un résumé, la pertinence d'une réponse juridique, ou le ton d'un message ne peut pas se contenter de comparer un résultat à une référence unique. Il faut une grille de critères. Il reste à vérifier si les mêmes conclusions tiennent dans ces évaluations plus ouvertes.

Les réglages techniques comptent aussi. Pendant les essais, certains modèles de raisonnement ont épuisé leur limite de jetons en interne et ont renvoyé des réponses vides. Une limite trop basse a même fait chuter temporairement un score de 99 % à 23 %. Des erreurs de quota et des soucis de disponibilité fournisseur ont aussi entraîné des exclusions. Un benchmark mesure donc à la fois le modèle et son environnement d'exécution : limites de sortie, reprises, délais d'attente et gestion des échecs.

Le jeu de données et les tâches sont publics sur Kaggle. L'analyse s'inscrit dans la continuité de travaux sur les évaluateurs LLM et les biais de position, notamment Panickssery et al. (2024) et Zheng et al. (2023). Pour ceux qui veulent reproduire le test, l'élément le plus important à conserver reste l'étiquetage indépendant des réponses : sans vérité de référence, on ne sait pas si le juge est précis ou juste d'accord avec lui-même.