Évaluer une IA générative : au-delà des benchmarks classiques

Un modèle sort, affiche 92 % sur MMLU, se hisse en tête d'un classement, et la presse spécialisée titre aussitôt sur « le nouveau meilleur modèle du marché ». Puis les équipes qui le déploient en production découvrent, quelques semaines plus tard, qu'il hallucine sur leurs documents internes, qu'il répond mal à leurs requêtes métier, ou qu'il coûte trois fois plus cher à l'usage que prévu pour un gain de qualité à peine perceptible. Ce décalage n'est pas un accident : c'est la conséquence directe d'une évaluation de l'IA générative encore largement construite autour d'un seul type d'instrument, le benchmark à choix multiples, alors que la question posée par un déploiement réel est toujours plus large que « combien de bonnes réponses sur un questionnaire ».

Ce constat n'a rien d'anecdotique. À mesure que les grands modèles de langage se sont rapprochés, puis ont dépassé, les scores humains sur les batteries de tests classiques, la discipline de l'évaluation a dû se réinventer. Trois grandes familles de méthodes se sont imposées en complément — parfois en remplacement — des benchmarks statiques : le LLM-juge, qui utilise un modèle pour évaluer un autre modèle ; les arènes de préférence humaine, qui font s'affronter des réponses devant des votants ; et l'évaluation holistique, qui refuse de résumer un modèle à un seul chiffre. Chacune apporte une réponse partielle, chacune a ses angles morts, et aucune ne suffit isolément.

Cette chronique fait le tour de ces méthodes, de leurs forces documentées et de leurs limites connues, avec un objectif pratique : donner à quiconque évalue un modèle — data scientist, chef de produit IA, ou simple utilisateur curieux de comprendre les classements qu'il consulte — les repères pour lire un score sans s'y fier aveuglément, et pour construire, si besoin, sa propre grille de jugement.

Pourquoi un score de benchmark ne suffit plus

Le principe d'un benchmark est simple et, en apparence, rassurant : on soumet au modèle un ensemble fixe de questions à réponse vérifiable, on compte les bonnes réponses, on obtient un pourcentage comparable d'un modèle à l'autre. Cette mécanique a fait ses preuves pendant des années — c'est elle qui a permis de suivre, benchmark après benchmark, les progrès des systèmes de traitement du langage depuis la fin des années 2010. Mais elle repose sur deux hypothèses fragiles : que le test mesure une capacité générale et non un ensemble de réponses mémorisées, et que le score reste discriminant, c'est-à-dire capable de distinguer un modèle très bon d'un modèle excellent.

Ces deux hypothèses vacillent aujourd'hui pour les benchmarks les plus utilisés. La première fragilité porte un nom : la contamination des données. La seconde porte, elle aussi, un nom : la saturation. Il faut comprendre ces deux phénomènes avant d'aborder les alternatives, car ce sont eux qui expliquent pourquoi l'industrie a dû inventer d'autres façons de juger un modèle.

Il faut ajouter une troisième limite, plus structurelle encore : un questionnaire à choix multiples mesure une compétence isolée, hors contexte, sur un tour de conversation unique. Or l'essentiel des usages réels d'une IA générative en 2025 ne ressemble plus à cela. Un assistant qui répond en s'appuyant sur des documents fournis par l'entreprise, un agent qui enchaîne plusieurs appels d'outils pour accomplir une tâche, ou un système qui doit maintenir la cohérence d'un dialogue sur vingt échanges, mobilisent des compétences — suivi de contexte long, fiabilité de l'appel de fonction, résistance à l'erreur en chaîne — qu'aucun QCM ne peut approcher. C'est précisément ce vide que les trois familles de méthodes présentées dans cette chronique tentent, chacune à sa manière, de combler.

La contamination des données : le correcteur a déjà vu le sujet

Un grand modèle de langage est entraîné sur des volumes de texte tirés d'Internet qui se comptent en milliers de milliards de tokens. Or les benchmarks les plus célèbres — questionnaires MMLU, problèmes mathématiques GSM8K et MATH, jeux de questions-réponses variés — sont eux-mêmes publiés en ligne, discutés sur des forums, repris dans des articles, cités dans des dépôts de code. Rien n'empêche, mécaniquement, qu'un extrait de ces jeux de test se retrouve, sous une forme identique ou légèrement reformulée, dans le corpus d'entraînement d'un modèle ultérieur. C'est ce que la littérature appelle la « contamination des données de benchmark » (benchmark data contamination) : le modèle n'a pas appris à résoudre le problème, il a mémorisé la réponse attendue.

L'ampleur du phénomène est documentée. Une synthèse académique consacrée spécifiquement à cette question rapporte que des benchmarks mathématiques largement utilisés, comme GSM8K et MATH, apparaissent dans les données d'entraînement de modèles modernes, avec une contamination relevée sur un ensemble de trente et un modèles étudiés. La fuite de données de test dans des benchmarks aussi centraux que MMLU ou GSM8K est décrite comme « devenue courante », au point que des scores élevés peuvent refléter davantage une mémorisation qu'une réelle capacité de généralisation à des cas inédits.

Le problème ne se limite pas à une question de triche délibérée. Il tient surtout à l'échelle : personne ne contrôle ligne à ligne des corpus d'entraînement de plusieurs milliers de milliards de tokens, et l'exclusion complète d'un jeu de test devenu viral sur le web est, en pratique, très difficile à garantir. Plusieurs approches de détection existent — recherche de chevauchements exacts ou approximatifs entre les données d'entraînement et les questions du test, insertion de chaînes témoins (canary strings) destinées à signaler une éventuelle fuite, ou encore mesures statistiques de divergence entre la distribution des réponses du modèle et celle attendue d'un système qui découvre réellement la question. Mais ces méthodes de détection restent imparfaites, et une revue de littérature sur le sujet souligne que la contamination des données est devenue une préoccupation croissante à mesure que l'évaluation des grands modèles de langage a gagné en importance stratégique et commerciale.

La conséquence pratique est directe : un score de 95 % sur un benchmark public, obtenu par un modèle entraîné après la diffusion massive de ce benchmark sur le web, doit être lu avec prudence. Ce n'est pas nécessairement une preuve de triche — cela peut aussi être le résultat d'un entraînement sur des données très proches sans être identiques —, mais c'est un signal qui invite à chercher d'autres preuves de compétence avant de conclure à une supériorité réelle. La communauté de la recherche a répondu à ce problème en faisant évoluer les pratiques d'évaluation d'un modèle statique — un même jeu de questions, année après année — vers des approches plus dynamiques : jeux de test renouvelés régulièrement, questions générées à la volée, ou benchmarks construits sur des événements et des données postérieurs à la date d'entraînement connue du modèle testé.

La saturation : quand tous les modèles ont la même note

Le second phénomène qui érode la valeur d'un benchmark est plus subtil : même sans contamination, un test fini par perdre sa capacité à distinguer les modèles entre eux, simplement parce que les meilleurs systèmes s'en approchent trop. On parle de saturation, ou d'effet de plafond.

L'histoire de l'évaluation en traitement du langage naturel est ponctuée d'épisodes de ce type. Le benchmark GLUE, introduit en 2018 pour évaluer la compréhension générale du langage sur neuf tâches, a été rapidement dépassé par les modèles pré-entraînés de la génération suivante — au point de justifier, dès 2019, la création d'une version durcie, SuperGLUE. Le même schéma s'est reproduit avec les benchmarks de sens commun comme HellaSwag, puis avec MMLU, devenu la référence pour évaluer les connaissances généralistes d'un modèle sur cinquante-sept matières. Les meilleurs modèles se sont progressivement regroupés à quelques points de pourcentage les uns des autres sur MMLU, réduisant d'autant la capacité du test à départager des générations de modèles pourtant très différentes en pratique.

C'est précisément ce constat qui a motivé, en 2024, la publication de MMLU-Pro. Les auteurs de ce benchmark durci expliquent avoir voulu construire une version « plus robuste et plus exigeante » de MMLU, en consolidant les cinquante-sept matières d'origine en quatorze domaines plus larges, en portant le nombre de choix de réponse de quatre à dix — ce qui réduit mécaniquement les chances de deviner la bonne réponse par élimination — et en retirant, à l'aide d'un filtrage basé sur la difficulté estimée par d'autres modèles, la majorité des questions jugées trop faciles ou trop ambiguës. L'objectif affiché n'était pas de rendre l'IA plus intelligente, mais de rendre la mesure plus discriminante.

Benchmark	Introduit	Ce qu'il mesurait	Ce qui l'a rendu moins discriminant
GLUE	2018	Compréhension générale du langage (9 tâches)	Saturé par les modèles pré-entraînés dès 2019
SuperGLUE	2019	Version durcie de GLUE	Saturé à son tour par les générations suivantes
MMLU	2020	Connaissances généralistes, 57 matières, QCM à 4 choix	Modèles de tête regroupés à quelques points d'écart
MMLU-Pro	2024	Version durcie : 14 domaines, 10 choix, questions filtrées par difficulté	Conçu pour repousser l'échéance de la saturation

Cette course entre benchmark et modèle n'est pas près de s'arrêter : chaque nouvelle génération de test finira, tôt ou tard, par être rattrapée par les progrès des modèles qu'elle évalue. C'est un phénomène sain en soi — il traduit un progrès réel des capacités — mais il signifie qu'un score isolé, sans contexte sur la fraîcheur et la difficulté du test employé, n'a qu'une valeur limitée pour comparer deux modèles publiés à un an d'écart.

Le LLM-juge : faire évaluer un modèle par un autre modèle

Face aux limites des questionnaires à réponse unique, une partie de l'industrie a pris un virage méthodologique en 2023 : utiliser un grand modèle de langage comme évaluateur d'un autre modèle. L'article fondateur de cette approche, publié par une équipe de Berkeley et de l'université Carnegie Mellon, introduit deux outils devenus des références du secteur : MT-Bench, un jeu de questions conversationnelles à plusieurs tours conçu pour évaluer la capacité de dialogue d'un assistant, et Chatbot Arena, une plateforme de confrontations en direct entre modèles jugées par des votants humains. L'idée centrale de l'article est de vérifier si un modèle puissant, utilisé comme juge, peut remplacer une partie du travail d'évaluation humaine sur des réponses ouvertes — c'est-à-dire des réponses qui n'ont pas de bonne réponse unique et vérifiable, contrairement à un QCM.

Le résultat, largement cité depuis, est encourageant : les auteurs rapportent qu'un juge fondé sur un modèle puissant s'accorde avec les préférences humaines, qu'elles soient recueillies en conditions contrôlées ou via une foule de votants, à plus de 80 % — un niveau d'accord comparable à celui mesuré entre deux évaluateurs humains entre eux. Ce chiffre a légitimé une pratique aujourd'hui très répandue : demander à un modèle de comparer deux réponses, de les noter sur une grille, ou d'attribuer un score à une sortie unique, à une échelle qu'aucune équipe humaine ne pourrait tenir manuellement.

Pourquoi le LLM-juge séduit

L'attrait du LLM-juge tient à trois avantages concrets, qui expliquent son adoption massive dans les équipes produit :

• Le passage à l'échelle : un modèle peut évaluer des milliers de réponses en quelques minutes, là où un panel humain nécessite du temps, des instructions détaillées et une coordination logistique ;
• L'évaluation de réponses ouvertes : contrairement à un QCM, le LLM-juge peut noter la qualité d'une explication, la pertinence d'un résumé ou la justesse du ton d'une réponse, des dimensions que les benchmarks classiques ne couvrent pas ;
• La reproductibilité relative : à température basse et avec un prompt de jugement stable, un même juge donne des résultats globalement cohérents d'une exécution à l'autre, ce qui facilite le suivi dans le temps.

Ce que les biais documentés imposent comme prudence

Ces avantages ne doivent pas masquer des biais désormais bien identifiés dans la littérature. Le premier est le biais de position : un juge peut favoriser systématiquement la réponse présentée en premier — ou en second, selon les modèles — indépendamment de sa qualité réelle, ce qui impose de faire tourner l'ordre de présentation des réponses comparées. Le deuxième est le biais de verbosité : les modèles-juges ont tendance à préférer les réponses plus longues et mieux formatées, même quand la longueur n'apporte rien de plus. Le troisième, plus subtil, est le biais d'auto-préférence : un juge favorise les styles de réponse proches des siens, ou ceux de modèles de la même famille, une source de distorsion difficile à corriger sans faire appel à un juge d'une architecture différente.

Un dernier point mérite une attention particulière : ces biais s'aggravent nettement dès que la tâche évaluée sort du registre conversationnel généraliste pour entrer dans un domaine d'expertise pointue. Une étude publiée lors d'une conférence dédiée à l'interaction humain-machine a mesuré l'accord entre un LLM-juge et des experts humains sur des tâches relevant de la diététique et de la santé mentale : l'accord tombe alors entre 60 % et 68 %, avec une variabilité marquée selon le critère évalué — bien en deçà des plus de 80 % rapportés sur des tâches conversationnelles génériques.

Sur une tâche conversationnelle générale, un LLM-juge s'accorde avec l'humain presque autant que deux humains s'accordent entre eux. Sur une tâche d'expertise pointue — santé, droit, finance — cet accord peut chuter de vingt points : le juge automatique perd alors une bonne partie de sa valeur probante.

La leçon pratique qui s'en dégage n'est pas d'abandonner le LLM-juge, mais de le calibrer : comparer périodiquement ses verdicts à ceux d'évaluateurs humains sur un échantillon, faire tourner l'ordre des réponses comparées, croiser plusieurs juges de familles différentes plutôt qu'un seul, et réserver un contrôle humain systématique aux décisions à fort enjeu — un diagnostic médical suggéré, une clause contractuelle générée, un conseil financier. C'est exactement la recommandation que formulent les chercheurs ayant étudié les domaines à expertise pointue : privilégier des contrôles humains ponctuels, une évaluation hybride, et une boucle de retour continue dans les contextes à forts enjeux.

Les arènes de préférence humaine : un vote, mais pas une vérité absolue

Si le LLM-juge automatise l'évaluation, les arènes de préférence humaine gardent l'humain au centre du jugement, tout en le faisant passer à l'échelle par la foule. Le principe de Chatbot Arena, plateforme devenue une référence du secteur depuis son lancement, est simple : un utilisateur pose une question, reçoit deux réponses générées par deux modèles dont l'identité lui est cachée, puis vote pour celle qu'il préfère. Ces votes, agrégés sur plusieurs millions de confrontations (plus de 5 millions de votes cumulés selon les données publiques d'Arena/LMArena au printemps 2026, un chiffre en croissance continue), alimentent un classement de type Elo — le même système de notation utilisé aux échecs — qui ordonne les modèles selon leur taux de victoire relatif.

Cette méthode a un mérite réel : elle capture une préférence humaine directe, sur des questions authentiques posées par de vrais utilisateurs, plutôt qu'un score sur un questionnaire artificiel. Mais elle n'échappe pas, elle non plus, aux tentatives d'optimisation du classement plutôt que de la qualité réelle — un phénomène que les économistes résument depuis longtemps par l'idée qu'une mesure, dès qu'elle devient un objectif à atteindre, cesse d'être une bonne mesure.

Une étude approfondie publiée en 2025 et consacrée spécifiquement à Chatbot Arena a documenté plusieurs failles structurelles de ce type d'arène. Elle relève d'abord une pratique de tests privés non divulgués : certains fournisseurs peuvent tester plusieurs variantes non publiées de leur modèle sur la plateforme avant sa sortie officielle, puis choisir de ne publier que le meilleur score obtenu et de retirer les autres variantes du classement — les chercheurs ont ainsi identifié vingt-sept variantes privées testées par un seul fournisseur dans la période ayant précédé la sortie d'un de ses modèles phares. L'étude relève ensuite une inégalité d'accès aux données de confrontation : les modèles propriétaires de quelques grands fournisseurs recevraient une part disproportionnée du volume total de votes, tandis qu'un ensemble bien plus large de modèles à poids ouverts se partagerait une portion nettement plus restreinte des données. Or l'accès à davantage de données de confrontation permettrait, selon la même étude, des gains de performance substantiels sur la distribution spécifique de l'arène — un avantage qui n'a rien à voir avec la qualité générale du modèle, mais tout à voir avec sa capacité à s'adapter aux habitudes de vote de la plateforme.

Un classement construit sur des votes reste un instrument précieux — mais un fournisseur qui teste des dizaines de variantes en coulisses et ne publie que la meilleure ne mesure plus un modèle : il optimise un classement.

Cette étude ne disqualifie pas les arènes de préférence humaine — elle rappelle simplement qu'aucune méthode d'évaluation, aussi séduisante soit-elle sur le papier, n'est à l'abri d'un effet Goodhart dès lors qu'elle devient un enjeu commercial. La bonne pratique consiste à lire un classement d'arène comme un indice parmi d'autres, à vérifier la transparence de la méthodologie du fournisseur de la plateforme, et à se méfier particulièrement des écarts de quelques points entre modèles proches, qui peuvent relever du bruit méthodologique autant que d'une différence de qualité réelle.

L'évaluation holistique : sortir du chiffre unique

Une troisième famille de réponses au problème consiste à refuser, dès le départ, l'idée qu'un modèle puisse être résumé par un seul nombre. C'est la philosophie du projet HELM (Holistic Evaluation of Language Models), porté par le Center for Research on Foundation Models de l'université Stanford. Plutôt que de classer les modèles sur une tâche isolée, HELM les évalue sur un ensemble large de scénarios représentatifs d'usages réels, et sur plusieurs axes simultanés : l'exactitude, mais aussi la calibration — la capacité d'un modèle à exprimer une incertitude cohérente avec sa véritable fiabilité —, la robustesse face à des variations mineures de formulation, l'équité entre groupes démographiques, les biais, la toxicité potentielle des réponses, et l'efficacité en termes de coût et de latence.

Cette approche multidimensionnelle part d'un constat simple : deux modèles peuvent afficher une exactitude comparable sur un même benchmark tout en différant radicalement sur leur robustesse à des reformulations, leur tendance à halluciner sous la contrainte, ou leur coût réel d'exploitation. Un tableau de classement unique masque ces différences ; un rapport d'évaluation multidimensionnel les révèle. Pour une équipe qui doit choisir un modèle pour un cas d'usage précis, cette granularité compte souvent davantage que le rang global dans un classement généraliste.

Cette philosophie se retrouve, à plus petite échelle, dans une pratique de plus en plus répandue chez les équipes qui déploient des applications à base de modèles de langage : la construction d'un jeu d'évaluation interne, propre à leur cas d'usage, plutôt qu'une dépendance exclusive aux benchmarks publics. Cette approche répond directement aux deux problèmes évoqués plus haut — la contamination, puisqu'un jeu de test maison n'a jamais pu fuiter dans un corpus d'entraînement public, et la saturation, puisque la difficulté du jeu de test peut être ajustée à la marge de progression réellement recherchée. Elle a aussi l'avantage de mesurer ce qui compte vraiment pour l'usage visé, plutôt qu'une compétence générique dont la corrélation avec la performance réelle en production n'est jamais garantie.

Cette logique multidimensionnelle gagne enfin à être prolongée dans le temps, au-delà du seul moment de la sélection du modèle. Un tableau de bord d'évaluation qui ne vit qu'au moment du choix initial perd rapidement sa pertinence : les fournisseurs font évoluer leurs modèles derrière une même API, les habitudes des utilisateurs se déplacent, et la distribution des requêtes réellement envoyées en production diverge, semaine après semaine, du jeu de test initial. Traiter l'évaluation comme un instrument de suivi continu — au même titre qu'un indicateur de performance applicative classique — permet de détecter tôt une dégradation, plutôt que de la découvrir a posteriori dans les retours des utilisateurs.

Construire sa propre grille d'évaluation

De ce panorama se dégagent des recommandations concrètes, applicables par toute équipe qui doit choisir, ajuster ou surveiller un modèle d'IA générative — sans nécessiter les moyens d'un grand laboratoire de recherche.

Ne jamais s'arrêter à un seul chiffre

Un score de benchmark public reste un point de départ utile pour éliminer les candidats manifestement sous-performants, mais il ne doit jamais constituer le seul critère de décision. La bonne pratique consiste à croiser au moins trois sources d'information : un ou deux benchmarks publics récents et peu susceptibles d'avoir contaminé les données d'entraînement du modèle testé, un jugement automatisé par LLM-juge sur des cas représentatifs de l'usage visé, et un échantillon d'évaluation humaine — même restreint — sur les décisions à plus fort enjeu.

Construire un jeu de test maison

Rien ne remplace un ensemble de cas de test tirés de l'usage réel visé : questions effectivement posées par les utilisateurs, documents effectivement traités, formats de réponse effectivement attendus. Ce jeu de test, versionné comme du code, permet de comparer des modèles ou des versions de prompt dans la durée, et de détecter une régression avant qu'elle n'atteigne la production.

Discipliner l'usage du LLM-juge

Quand un LLM-juge est utilisé, quelques précautions réduisent nettement les biais documentés :

• Alterner systématiquement l'ordre de présentation des réponses comparées, pour neutraliser le biais de position ;
• Préférer, quand c'est possible, une notation fondée sur une référence vérifiable plutôt qu'une comparaison libre entre deux sorties, moins sensible au biais de verbosité ;
• Recourir à plusieurs juges issus de familles de modèles différentes plutôt qu'à un seul, pour limiter le biais d'auto-préférence ;
• Recalibrer périodiquement le juge automatisé contre un échantillon annoté par des humains, en particulier sur les domaines d'expertise pointue où l'écart d'accord est le plus documenté.

Regarder au-delà de la qualité brute

Un modèle légèrement moins précis mais deux fois moins coûteux et deux fois plus rapide peut constituer, pour un cas d'usage donné, le meilleur choix. Le suivi du coût par requête, de la latence, du taux de refus et de la stabilité des réponses dans le temps mérite la même rigueur que le suivi de l'exactitude — c'est souvent sur ces axes, plus que sur le score brut, que se joue la viabilité économique d'un déploiement.

Répéter l'évaluation, pas seulement au lancement

Un modèle accessible par API peut être mis à jour silencieusement par son fournisseur ; une application en production évolue ; les usages des utilisateurs se déplacent. L'évaluation n'est donc pas un jalon ponctuel avant le lancement, mais une pratique continue, au même titre que la surveillance de tout système en production.

Ce qu'il faut retenir

Aucune des méthodes présentées ici ne constitue, à elle seule, une mesure fiable et suffisante de la qualité d'une IA générative. Les benchmarks classiques restent utiles comme filtre initial, mais s'érodent sous l'effet conjugué de la contamination des données et de la saturation des scores. Le LLM-juge permet de faire passer à l'échelle une évaluation de réponses ouvertes, avec un accord proche de celui obtenu entre humains sur des tâches génériques — mais cet accord se dégrade nettement sur les domaines d'expertise pointue, et les biais de position, de verbosité et d'auto-préférence exigent des garde-fous méthodologiques. Les arènes de préférence humaine ajoutent un signal précieux de goût réel des utilisateurs, mais restent vulnérables, comme tout classement devenu enjeu commercial, aux tentatives d'optimisation du score plutôt que de la qualité sous-jacente. L'évaluation holistique, enfin, rappelle qu'un modèle se juge sur plusieurs axes à la fois — exactitude, robustesse, calibration, coût, équité — et non sur un chiffre unique affiché en tête d'un classement.

La bonne nouvelle, dans ce panorama, tient à la maturité croissante de la discipline elle-même. Les biais des LLM-juges sont aujourd'hui documentés et mesurés, les failles des arènes de préférence ont été mises au jour par des travaux publics et rigoureux, et des cadres d'évaluation holistique comme HELM offrent une alternative transparente et reproductible au classement à chiffre unique. L'évaluation de l'IA générative rattrape peu à peu son retard sur la vitesse de progression des modèles eux-mêmes — et c'est une condition nécessaire pour que les choix de déploiement, dans les entreprises comme chez les particuliers, reposent sur des preuves plutôt que sur des titres de presse.

Pour qui doit choisir un modèle demain, la meilleure boussole n'est donc pas de chercher le classement ultime qui trancherait toutes les questions, mais de construire, à son échelle, un petit arsenal de méthodes complémentaires — un benchmark récent pour dégrossir, un LLM-juge discipliné pour passer à l'échelle, un contrôle humain ciblé pour les décisions qui comptent, et un suivi continu une fois le modèle en production. C'est cette combinaison, plus que n'importe quel score isolé, qui permet de savoir si un modèle est réellement bon — pour l'usage précis qu'on veut en faire.

Sources

Cet article s'appuie sur des sources techniques publiques et vérifiables :

• Zheng, L. et al., « Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena » — arXiv 2306.05685 (NeurIPS 2023, article fondateur du LLM-juge, MT-Bench et Chatbot Arena).
• Singh, S. et al., « The Leaderboard Illusion » — arXiv 2504.20879 (avril 2025, biais structurels de Chatbot Arena : tests privés, accès inégal aux données, déprécations opaques).
• Wang, Y. et al., « MMLU-Pro: A More Robust and Challenging Multi-Task Language Understanding Benchmark » — arXiv 2406.01574 (NeurIPS 2024, saturation de MMLU et conception d'un benchmark durci).
• « Limitations of the LLM-as-a-Judge Approach for Evaluating LLM Outputs in Expert Knowledge Tasks » — ACM Digital Library (IUI 2025) (accord LLM-juge / experts humains sur des tâches spécialisées).
• « Benchmark Data Contamination of Large Language Models: A Survey » — arXiv 2406.04244 (juin 2024, ampleur et détection de la contamination des benchmarks).
• « A Survey on Data Contamination for Large Language Models » — arXiv 2502.14425 (février 2025, panorama des méthodes de détection et de décontamination).
• Stanford CRFM, « Holistic Evaluation of Language Models (HELM) » — crfm.stanford.edu/helm (cadre d'évaluation multidimensionnel : exactitude, calibration, robustesse, équité, efficacité).