MMLU-Pro : l’accord des IA détecte-t-il les erreurs ?
Une étude teste si l’accord des meilleurs modèles d’IA révèle les erreurs de MMLU-Pro. Résultats, limites et méthode pour exploiter ces signaux.
Quand les meilleurs modèles d'IA contestent une réponse, qui a raison ?
Un benchmark est souvent présenté comme une mesure fiable, presque comme un instrument de laboratoire. Le souci, c'est qu'une simple erreur dans les réponses « officielles » peut faire trébucher plusieurs modèles à la fois. Et ce n'est pas qu'un problème pour les chercheurs : quand des entreprises s'appuient sur ces évaluations pour décider quoi acheter ou déployer, elles risquent de bâtir une décision sur une base bancale.
Une étude menée par MV2, au nom de Munim, Inc., s'est demandée si l'accord entre des modèles performants pouvait servir à repérer des erreurs dans MMLU-Pro, un benchmark de questions à choix multiples. Le résultat n'est pas tranché : le consensus permet bien de retrouver des questions déjà identifiées comme mal corrigées par des experts, mais il signale aussi pas mal de questions que ces experts avaient validées. Et une seconde analyse suggère qu'une partie des alertes vient d'options ajoutées au benchmark, sans qu'on sache pour autant si ces options sont réellement correctes.
Voici ce que disent (et ne disent pas) les chiffres, comment lire la méthode, et ce que ça peut apporter aux équipes qui évaluent des systèmes d'IA.
Ce que mesure l'audit de MMLU-Pro
MMLU-Pro est un benchmark de questions à choix multiples utilisé pour comparer les capacités de modèles de langage sur différents sujets. Ses mainteneurs publient les réponses produites par les modèles pour chaque question. Du coup, on peut regarder non seulement les scores globaux, mais aussi les désaccords entre les modèles et le corrigé officiel.
L'audit de MV2 part d'un signal déjà vu dans un travail précédent : sur 46 questions de MMLU-Pro héritées de MMLU, des experts avaient détecté une erreur de corrigé, et les 45 modèles disponibles choisissaient plus souvent la réponse des experts que la clé officielle. La question suivante était plus générale : est-ce que ce type de consensus peut aussi aider à repérer d'autres erreurs dans un ensemble de 12 032 questions ?
Une règle simple, fixée avant l'analyse
Les chercheurs ont retenu les dix modèles les plus précis parmi 45 archives exploitables, avec des scores allant de 91,1 % pour Gemini 3.1 Pro à 70,3 % pour Gemini 1.5 Pro. Une question est signalée si deux conditions sont réunies :
- au moins six modèles sur dix choisissent la même option, qui n'est pas la réponse officielle ;
- cette option a plus de votes que la réponse officielle.
L'intérêt, c'est aussi le cadrage de la comparaison : les modèles n'ont pas accès aux étiquettes de correction de MMLU-Redux 2.0, utilisé comme point de contrôle. Les auteurs ont annoncé la règle et les prédictions avant d'analyser les résultats, puis ils ont « gelé » l'analyse. Ça limite le risque d'ajuster la méthode après avoir vu les chiffres.
Ce n'est pas une garantie absolue. Mais ça rend les choix méthodologiques plus clairs et permet à d'autres de reproduire l'analyse. Et c'est important : un audit reproductible reste un audit fondé sur une règle, donc sur des choix à interpréter.
Un échantillon expert incomplet
MMLU-Redux couvre 2 829 des 6 810 questions issues de MMLU dans MMLU-Pro, soit environ 40 % de cette partie du benchmark. Les experts n'ont pas examiné les 5 222 questions provenant d'autres sources, ni l'ensemble des options telles qu'elles apparaissent dans MMLU-Pro.
Concrètement, l'étude ne compare pas toutes les questions à un corrigé humain exhaustif. Elle teste plutôt si un signal de consensus se retrouve là où des experts ont déjà repéré des problèmes. Utile pour juger la méthode, mais pas une vérification complète des 12 032 réponses officielles.
Ce que les résultats montrent - et ne prouvent pas
Le signal est clair sur le groupe que les experts jugent « vraiment faux » : 36 questions sur 55 sont signalées, soit 65,5 %. Pour les questions que les experts disent correctes, le taux chute à 11,5 %, soit 294 sur 2 553. En pratique, le consensus apparaît donc environ 5,7 fois plus souvent quand la clé est jugée erronée que quand elle est validée - et dépasse le seuil « d'environ cinq fois » attendu par les auteurs.
La méthode retrouve aussi 34 des 46 erreurs héritées examinées dans l'audit précédent. Pour 31 d'entre elles, l'option choisie par le panel correspond exactement à la réponse des experts. Sur ce petit sous-ensemble, le signal des modèles rejoint donc souvent une correction indépendante.
Le taux d'alerte n'est pas un taux d'erreur
Le problème apparaît quand on regarde les alertes en volume. Sur les 359 questions examinées par des experts et signalées par la règle, 65 portent une étiquette d'erreur, soit 18,1 %. Seules 36 sont des erreurs de clé ; les 29 autres relèvent d'autres problèmes identifiés par les experts. Autrement dit, environ quatre alertes sur cinq ne sont pas, au sens strict, des « clés » fausses.
Attention : ça ne veut pas dire que ces questions seraient forcément correctes. Les modèles peuvent aussi partager une erreur, défendre une réponse alternative plausible, ou pointer un problème qui n'avait pas été vu. Mais avec les données de cet audit, on ne peut pas départager ces scénarios.
Il faut donc garder deux idées distinctes :
- « le consensus apparaît plus quand une clé est erronée » : c'est bien ce que montrent les chiffres ;
- « une question signalée est probablement erronée » : ce n'est pas démontré avec le même niveau de force.
Un résultat différent selon l'origine des questions
Quand on regarde l'origine des questions, les taux ne bougent pas pareil. Les questions issues de MMLU et non examinées par les experts sont signalées dans 12,75 % des cas, contre 6,64 % pour celles venant d'un site STEM. Or, le document de présentation de MMLU-Pro indiquait que cette source STEM figurait parmi celles où des erreurs de corrigé avaient été observées.
Les auteurs s'attendaient donc à un taux plus élevé pour ce groupe. Or c'est l'inverse. Deux explications restent possibles : les clés STEM seraient plus « propres », ou bien les modèles répartiraient leurs réponses erronées entre plusieurs options, ce qui empêcherait un consensus net. Sans nouvelle révision humaine, les chiffres ne permettent pas de trancher.
Un seuil plus strict : plus de précision, moins de rappel
Après l'analyse préenregistrée, les chercheurs ont testé une règle plus exigeante : les dix modèles doivent choisir exactement la même option. Résultat : la règle signale 201 questions au lieu de plus, et 21 des 55 clés erronées identifiées par les experts ressortent. Sur les questions examinées par les experts et signalées, 36,4 % portent une étiquette d'erreur, contre 18,1 % avec le seuil initial.
Le compromis est classique : plus le seuil est strict, plus on réduit les faux positifs - mais on laisse passer davantage de problèmes. Pour une équipe qui veut produire une petite liste à vérifier manuellement, l'unanimité peut être plus adaptée. Pour créer un inventaire large, le seuil « six sur dix » est plus utile, à condition d'accepter un volume élevé de vérifications.
Pourquoi les options ajoutées compliquent la correction
MMLU-Pro reprend des questions de MMLU et garde les quatre options d'origine, tout en ajoutant jusqu'à six choix supplémentaires. Les experts de MMLU-Redux ont examiné les quatre options initiales, pas forcément toutes les options ajoutées. Résultat : une option peut être validée « officiellement » parce qu'elle a été examinée, alors qu'une nouvelle option ajoutée ensuite pourrait aussi sembler correcte à un modèle.
Ce point devient plus gênant encore quand on relit la manière dont MMLU-Pro a été construit : la revue indiquée dans le document de présentation de MMLU-Pro affirme avoir retiré 1 953 options ajoutées issues de MMLU, justement parce qu'elles étaient également correctes. La question devient alors simple à formuler, mais difficile à résoudre avec ces données : est-ce que des options problématiques subsistent et expliquent une partie des désaccords ?
Ce que vérifie la seconde analyse
Les chercheurs ont préenregistré un second audit pour distinguer les options d'origine et les options ajoutées. Ils ont pu classer 5 818 questions issues de MMLU qui conservent les quatre choix initiaux. Le test porte alors sur la réponse majoritaire du panel : s'agit-il d'une option parmi les quatre d'origine, ou d'une option ajoutée dans MMLU-Pro ?
Quand les experts disent que la clé officielle est erronée, le panel choisit une option d'origine dans 36 cas signalés - ce qui colle avec le fait que les experts ont évalué ces choix. À l'inverse, quand les experts valident la clé, le panel sélectionne une option ajoutée dans 185 cas sur 290, soit 63,8 %.
Ce résultat va dans le sens de l'hypothèse des options ajoutées. Mais il faut aussi regarder leur « part » dans le menu de choix. Elles représentent 64,1 % des options non officielles disponibles sur ces questions. Donc le panel les choisit à peu près dans la même proportion que leur taille dans l'espace de réponses. En plus, 105 alertes sur 290 pointent vers un distracteur d'origine déjà visible par les experts. Les options ajoutées expliquent une partie du phénomène, pas tout.
Une hypothèse plausible n'est pas une validation
Cette seconde analyse ne prouve pas que les options choisies par les modèles sont correctes. Elle dit seulement où se porte le consensus.
Pour trancher, il faudrait une nouvelle revue humaine qui examine la question complète : l'énoncé, toutes les options, et les ambiguïtés possibles. Et même là, on peut s'attendre à des désaccords, parce que certaines formulations sont effectivement difficiles à départager.
Les résultats par domaine invitent aussi à se méfier d'une explication trop simple. Les auteurs s'attendaient à un effet plus marqué en droit, mais dans les questions de droit signalées, 69 sur 139 pointent vers une option ajoutée : c'est comparable au 61,9 % observé ailleurs. Autrement dit, l'hypothèse sectorielle attendue n'est pas confirmée.
Comment utiliser le consensus sans le prendre pour un verdict
Si vous êtes une équipe produit ou une organisation qui évalue des modèles, le message opérationnel n'est pas « remplacer l'humain par un vote ». Le consensus sert plutôt d'outil de triage : il aide à repérer quelles questions valent une nouvelle vérification, surtout quand le volume rend une revue exhaustive immédiate irréaliste.
Dans ce cadre, ça peut servir à auditer un benchmark interne, vérifier un jeu de données utilisé pour comparer des modèles, ou repérer des items susceptibles de pénaliser un système sans raison. Dans un processus d'achat d'IA, par exemple, vous pouvez utiliser le signal pour demander une clarification lorsqu'un score paraît anormalement bas. En revanche, vous ne devriez pas conclure qu'un fournisseur est meilleur « parce que ses réponses s'accordent avec celles d'autres modèles ».
Une procédure de revue en trois niveaux
Vous pouvez organiser le travail comme suit :
- Générer des candidats. Fixez à l'avance le nombre de modèles, le seuil de consensus et les critères d'exclusion. Conservez les réponses brutes et la version exacte du benchmark.
- Trier par niveau de risque. Séparez les alertes alignées avec une correction experte connue, celles qui semblent venir d'options ajoutées, et les désaccords pour lesquels il n'y a pas d'explication claire. Ne les rangez pas tous dans une seule catégorie « erreur ».
- Faire vérifier les cas prioritaires par un humain. La revue doit couvrir l'énoncé, toutes les options et la justification, pas seulement le choix majoritaire des modèles.
Le seuil dépend de l'objectif. Si vous examinez quelques dizaines de cas, exiger l'unanimité peut améliorer la précision. Si vous cherchez à cartographier les anomalies, prendre six modèles sur dix est plus efficace, au prix de faux positifs plus nombreux. Dans les deux cas, il faut comparer le coût de la vérification humaine au coût d'un benchmark mal corrigé.
Vérifier l'indépendance du signal
Dix sorties ne sont pas forcément dix avis indépendants. Dans cet audit, les dix positions incluent trois exécutions de Claude 3.5 Sonnet, deux versions de GPT-4o et deux exécutions « arx ». Des systèmes proches peuvent partager des données, des architectures ou des biais, et leur accord peut donner une impression de « confirmation » plus forte que la diversité réelle des jugements.
Il faut aussi documenter les versions, les paramètres et les sources. Une règle testée sur les sorties publiées de MMLU-Pro ne se transpose pas automatiquement à un benchmark interne, à des tâches de génération libre ou à des données en français. Dans un contexte européen, si vous évaluez des usages sensibles, intégrez cette incertitude dans votre gouvernance : traçabilité des données, validation humaine et justification des décisions restent nécessaires, surtout quand un résultat peut avoir des effets sur des personnes.
Des cas à revoir, pas une liste de corrections
L'audit fournit 1 210 identifiants de questions signalées lors de la première analyse et 455 questions issues de MMLU où le consensus porte sur une option ajoutée lors de la seconde. Ce sont des files de travail : on y trouve des identifiants, des lettres de réponse et des comptes, pas une preuve que les clés sont erronées.
Quatre cas hérités méritent une attention particulière : les questions 6639 en virologie, 8972 en algèbre abstraite, 9677 en astronomie et 9947 en physique conceptuelle. Sur chacune, les dix modèles sélectionnés préfèrent la clé de MMLU-Pro à la correction attribuée aux experts. Trois de ces cas reposent sur l'interprétation de corrections de MMLU-Redux exprimées via de simples chiffres. Ce sont des priorités de vérification humaine, pas des preuves que les experts se sont trompés.
Conclusion
L'accord de plusieurs modèles peut aider à améliorer le contrôle qualité d'un benchmark. Mais ça ne transforme pas un vote algorithmique en jugement expert.
Dans l'audit de MMLU-Pro, le signal est nettement plus fréquent quand les clés ont déjà été jugées erronées. Pourtant, à un seuil de six modèles sur dix, la majorité des alertes examinées par des experts concernent des questions qu'ils avaient validées.
La bonne approche consiste donc à traiter ces résultats comme une priorisation de revue : choisissez un seuil selon le coût des erreurs et celui de la vérification, gardez une traçabilité claire, puis faites valider les cas par des personnes compétentes. Pour les équipes qui évaluent des modèles en production, ça peut rendre les audits plus ciblés. Mais ça ne remplace ni un corrigé fiable, ni une validation humaine explicite.