Vérité factuelle flottante : fixation de la version du jeu de données dans les suites d’évaluation des LLM

Lorsque la note d’un benchmark de LLM varie entre deux exécutions, on souhaite savoir si c’est le modèle qui a changé ou les données sur lesquelles il a été évalué. Dans la plupart des systèmes d’évaluation ouverts, rien ne permet de consigner cette seconde possibilité. Un audit récent du catalogue de tâches dans lm-evaluation-harness, l’un des outils les plus utilisés pour évaluer les modèles ouverts, a révélé qu’une seule configuration sur 841 disposait d’un champ de révision du dataset, et cette valeur ne correspondait en réalité à aucun numéro de version. Cet article explique comment ce chiffre a été obtenu, pourquoi le dénominateur est aussi important que le numérateur, comment un autre ensemble d’outils a fait le choix inverse, et comment vous pouvez effectuer la même vérification pour vos propres évaluations.

Le chiffre principal et celui qui a été écarté

Cette mesure mérite d’être étudiée en partie en raison de la manière dont elle a d’abord échoué. Une version initiale du comptage indiquait qu’une configuration sur 13 986 avait verrouillé ses données, un chiffre bien plus élevé. Cette donnée a été rejetée en quelques heures à peine. Parmi ces 13 986 fichiers, 10 391 ne désignent pas eux-mêmes de jeu de données mais en héritent un d’un fichier parent via include:, tandis que 2 966 sont des fichiers de groupe qui ne mentionnent aucun jeu de données du tout. Aucun de ces deux types n’a rien à verrouiller, ce qui fait que leur prise en compte gonfle le dénominateur et donne l’impression que les résultats sont bien plus solides qu’en réalité. Les analystes ont noté que c’était la deuxième fois en une semaine qu’un chiffre impressionnant résultait d’une mauvaise inspection du contenu du dénominateur, ce qui constitue un avertissement utile pour quiconque crée ses propres indicateurs.

Après correction, les conclusions sont les suivantes : dans lm-evaluation-harness, 841 configurations de tâches désignent directement un ensemble de données, et une seule d’entre elles remplit un champ de révision. Ce champ contient refs/convert/parquet, un référentiel qui sélectionne un format de stockage plutôt qu’une version spécifique des données. En pratique, aucune configuration n’est fixée de manière définitive. Chaque exécution est évaluée en fonction de l’état dans lequel se trouve par hasard l’ensemble de données source au jour de son exécution.

Principales conclusions en bref

• Sur 13 986 configurations de tâches, 841 désignent directement un ensemble de données. Les 13 145 restantes se divisent en 10 391 fichiers qui héritent d’un ensemble de données via include: et 2 966 fichiers de regroupement ne possédant pas d’ensemble de données propre.
• Seule l’une de ces 841 configurations définit une clé de révision ou SHA, et ce qu’elle contient, refs/convert/parquet, choisit un format de fichier plutôt que de fixer une version.

Parmi les 673 fichiers de tâches Python, seuls 15 appellent load_dataset, et seulement 2 d’entre eux fournissent la valeur revision=.

Les configurations font référence à 273 ensembles de données distincts. Pour l’ensemble de données médian, aucune configuration le mentionnant n’a été modifiée depuis 547,9 jours. 196 sur 273 (71,8 %) avaient plus d’un an et 245 (89,7 %) plus de six mois.

openai/evals adopte une approche inverse : 455 des 463 évaluations qu’il contient lisent un fichier samples_jsonl situé dans le répertoire, soutenu par 722 fichiers de données stockés dans ce même répertoire. Ses valeurs de référence ne peuvent pas varier, mais elles peuvent devenir obsolètes.

Il n’a pas été vérifié si un quelconque ensemble de données source avait réellement changé, car huggingface.co était inaccessible depuis l’environnement d’audit. La conclusion est que toute variation resterait inaperçue, et non qu’une telle variation ait eu lieu.

En bref

Un ensemble d’évaluation n’est en réalité qu’un graphe de dépendances, et les équipes logicielles fixent ces dépendances pour des raisons valables. En examinant chaque configuration de tâche dans lm-evaluation-harness, en extrayant l’ensemble de données contre lequel chacune est évaluée et en cherchant une version fixée, on a obtenu un candidat qui n’était en fait pas une véritable version fixée. En mesurant le temps pendant lequel ces configurations étaient restées inchangées, on a constaté que l’ensemble de données médian n’avait pas fait l’objet d’une modification dans une configuration référentielle depuis environ dix-huit mois. Rien de tout cela ne prouve que les valeurs de référence publiées soient fausses. Cela montre simplement que si l’une d’elles devenait erronée en raison d’un changement dans ses données, l’ensemble d’évaluation lui-même ne signalerait rien.

Pourquoi un benchmark a besoin d’une version d’ensemble de données fixée

Le modèle testé n’est pas la seule chose qui puisse changer. Chaque configuration de tâche fait référence à un ensemble de données, par exemple alexandrainst/m_truthfulqa, OALL/ACVA ou CogComp/mc_taco, et un ensemble de données hébergé sur une plateforme publique est un artefact en évolution constante. Il dispose de mainteneurs et reçoit des corrections, des modifications de licence, de nouvelles répartitions, de nouvelles configurations, ainsi que de temps en temps une correction silencieuse d’une étiquette dont on savait qu’elle était erronée. Cette activité est normale et généralement bénéfique.

Le problème réside dans l’impact que cela a sur les comparaisons. Une note n’a de sens qu’en relation avec une référence stable. Lorsqu’une nouvelle version du modèle produit une note différente, on en apprend davantage sur ce modèle. En revanche, si ce sont les données qui changent, on observe un artefact de mesure qui ressemble à une découverte. Sans enregistrement de la version modifiée, il est impossible de distinguer les deux, ni a posteriori ni au moment où l’évaluation est effectuée.

Une note non enregistrée est une mesure dont les critères n’ont jamais été consignés dans le registre.

C’est la même logique qui sous-tend les fichiers de verrouillage dans les projets JavaScript : une plage indiquée dans package.json, telle que ^4.2.0, permet aux builds d’intégrer silencieusement de nouveaux codes, tandis qu’un fichier de verrouillage consigne précisément la version finale utilisée. Les données d’évaluation méritent le même traitement.

Comment le comptage a été réalisé

C’est dans la méthodologie que se trouvent la plupart des décisions importantes, en particulier celles concernant le dénominateur.

• Repositorioire : EleutherAI/lm-evaluation-harness, cloné avec l’historique complet à l’aide de --filter=blob:none --unshallow. Cela couvre 4 115 commits allant du 27 août 2020 jusqu’à un HEAD daté du 10 septembre 2026, la mesure ayant été effectuée le 12 septembre 2026. Le catalogue change constamment, donc des exécutions ultérieures donneront des chiffres différents.
• Parcours de la configuration : tous les fichiers .yaml et .yml situés sous lm_eval/tasks. Pour chaque fichier, le script a extrait dataset_path ou hf_path, cherché la présence de dataset_revision, revision, dataset_sha ou sha, et enregistré si le fichier utilisait l’option include:.

Dénominateur éligible : seuls les fichiers qui désignent eux-mêmes un ensemble de données. Les configurations héritées et les fichiers de groupe qui se contentent d’emballer d’autres tâches ont été exclus, car ils ne possèdent rien de propre à identifier.

Vétusté : un git log par fichier indique la date à laquelle chaque fichier a été ajouté et modifié pour la dernière fois, en se basant sur la date du commit HEAD plutôt que sur la date actuelle, afin que ces valeurs restent constantes avec le temps.

Ce filtrage a permis d’identifier 841 configurations éligibles correspondant à 273 ensembles de données distincts.

Jusqu’à quel point les configurations sont-elles vétustes ?

La vétusté doit être indiquée de deux manières, car le calcul évident s’est avéré trompeur, ce qui n’a été compris qu’après une inspection manuelle.

Calculé par configuration, le temps médian depuis la dernière modification est de 729,8 jours. Parmi les 841 configurations, 691 (82,2 %) n’avaient pas été modifiées depuis plus d’un an, et 551 (65,5 %) n’avaient jamais été modifiées du tout depuis leur ajout.

Ces chiffres exagèrent la réalité. Seulement cinq commits ont ajouté 50,9 % des 841 configurations, et un seul commit, decc533d, en a introduit 272 en une seule journée. La distribution par configuration ne reflète donc pas 841 choix indépendants évoluant selon leurs propres délais ; elle reflète plutôt un petit nombre de contributions massives accompagnées d’une longue queue.

En regroupant par ensemble de données plutôt que par fichier, ce regroupement disparaît :

• Pour l’ensemble de données médian, 547,9 jours s’étaient écoulés depuis la dernière modification d’une configuration qui le référençait.
• 196 des 273 ensembles de données (71,8 %) étaient vieux d’un an ou plus.
• 245 des 273 (89,7 %) étaient vieux de plus de 180 jours.

Celui qui avait été le plus négligé durait 994,1 jours.

C’est la valeur par ensemble de données qui mérite d’être citée, car elle résiste à l’objection liée au regroupement. La médiane reste d’environ dix-huit mois, et neuf sur dix ensembles de données dépassent les six mois.

Le verrouillage est pris en charge, mais rarement utilisé

Il serait injuste de critiquer la suite logicielle si elle rendait le verrouillage impossible, ce qui n’est pas le cas. Le chargeur utilisé est la bibliothèque standard Hugging Face datasets, et load_dataset accepte un argument de révision. Dans la partie Python du catalogue des tâches, 2 sur les 15 fichiers qui appellent load_dataset spécifient revision=, sur un total de 673 fichiers Python dans ce répertoire, et l’un de ces deux utilise une référence de pull-request pour verrouiller les données.

Même si la fonction de fixation est disponible, presque personne ne l’utilise, et rien dans le flux de travail n’incite les contributeurs à l’employer. Lorsque la valeur par défaut est de flotter, un catalogue de 841 configurations reste en état flottant, car ce sont bien les valeurs par défaut qui sont utilisées dans de grands catalogues.

Si vous gérez des évaluations, la solution la moins coûteuse consiste à rechercher aujourd’hui dans vos propres définitions de tâches un champ de révision pour voir combien de résultats apparaissent.

L’autre compromis : les données fournies dans openai/evals

openai/evals répond à la même question dans l’autre direction, et son approche n’est pas clairement inférieure. Parmi 463 configurations d’évaluation, 455 lisent un fichier samples_jsonl stocké dans le répertoire lui-même, qui contient 722 fichiers de données pour les soutenir. Les valeurs de référence sont fournies, ce qui signifie qu’elles sont fixées par construction : les données sont versionnées par Git, tout comme le reste.

L’avantage réside dans une reproductibilité parfaite : une évaluation réalisée en 2024 peut être reproduite avec des données identiques à la lettre. Le prix à payer, c’est l’obsolescence progressive. Une version fournie ne reçoit jamais de corrections provenant des sources originales, si bien que, bien que l’ensemble ne puisse pas s’éloigner des normes, il peut progressivement devenir obsolète, en évaluant les nouveaux modèles à l’aide d’une version ancienne dont les erreurs ont été corrigées il y a des années.

Aucun de ces deux ensembles ne choisit la troisième voie : fixer une version spécifique et la faire évoluer délibérément. L’un reste flottant sans aucun historique ; l’autre se fige sans mise à jour. Dans les deux cas, le choix est fait par défaut plutôt que par décision consciente.

Ce que la mesure ne montre pas

Les limites de l’analyse sont tout aussi importantes que ses résultats.

• Aucun changement dans l’ensemble de données n’a été observé. La politique réseau de l’environnement d’audit a refusé les connexions vers huggingface.co ; le proxy a renvoyé une erreur 403 lors des tentatives de connexion depuis les deux machines, ce qui a empêché de récupérer des informations sur la résolution et la date de dernière modification. Tout ici concerne la possibilité de détecter un changement, et non le fait qu’un changement ait réellement eu lieu.
• Le fait que quelque chose ne soit pas marqué comme verrouillé ne signifie pas qu’il y a une erreur. Beaucoup de ces ensembles de données n’ont probablement jamais changé. L’allégation porte sur l’absence d’un contrôle, et non sur une erreur réelle.
• Le fait que des données soient obsolètes ne signifie pas qu’elles ont été négligées. Une configuration que personne n’a modifiée depuis 700 jours peut être complète et exacte. L’ancienneté indique simplement que personne ne l’a revue, ce qui est différent d’un défaut.

Un harnais ne représente pas l’ensemble du domaine. Un catalogue a été analysé en profondeur et un autre utilisé à des fins de comparaison. Des outils tels que promptfoo, deepeval et ragas sont des bibliothèques plutôt que des registres, et ils ne disposent pas de catalogue d’tâches YAML comparable ; par conséquent, les résultats obtenus n’ont aucune valeur à leur sujet.

L’exclusion des fichiers include: relève d’un jugement subjectif. Une interprétation plus stricte pourrait se demander si les configurations parentales fixent automatiquement les paramètres pour leurs enfants. Cela a été vérifié, et ce n’est pas le cas.

Questions fréquentes

Les scores de référence publiés sont-ils donc peu fiables ?

Non, et cette interprétation doit être rejetée. Un contrôle spécifique fait défaut. Un score n’est compromis que si les données de base changent ; l’audit montre qu’en cas de tel événement, la suite ne conserve aucun enregistrement permettant de le détecter ultérieurement.

Pourquoi ne pas simplement vérifier si les ensembles de données ont changé ?

Cela nécessite d’accéder à huggingface.co pour déterminer les versions des ensembles de données, ce que la politique réseau de l’audit a bloqué avec un code 403 lors des requêtes CONNECT, tant sur une machine cloud que locale. Au lieu d’inférer un écart à partir de signaux moins fiables, l’analyse a été limitée aux éléments pouvant être vérifiés uniquement depuis le répertoire, c’est pourquoi la conclusion concerne plutôt le verrouillage que les changements.

Le verrouillage est-il toujours la bonne solution ?

Pas automatiquement. Une évaluation verrouillée ne détecte jamais les corrections réelles des étiquettes erronées, ce qui explique pourquoi openai/evals peut être parfaitement reproductible tout en devenant progressivement inexact. Une politique plus fiable consiste à verrouiller puis à faire évoluer les versions : verrouiller une version, la faire avancer intentionnellement et enregistrer chaque modification, ce que presque personne ne fait.

Comment pouvez-vous vérifier votre propre ensemble d’outils ?

Vérifiez vos définitions de tâches, extrayez les noms des champs présents dans l’ensemble de données, et recherchez dans ces fichiers toute version ou clé SHA. Le rapport entre le deuxième comptage et le premier correspond à la métrique évoquée ici. L’audit indiquait environ trente secondes de calcul par mille fichiers, ce qui en fait une vérification peu coûteuse à intégrer dans le processus CI.

Conclusion

• Considérez les ensembles de données d’évaluation comme des dépendances : notez précisément la version associée à chaque score que vous comptez comparer.
• Soyez méfiant face à des ratios extrêmes avant d’avoir examiné le contenu du dénominateur ; les configurations héritées et agrégées ont failli transformer une découverte modeste en une interprétation trompeuse.
• Les données flottantes et les données figées présentent des problèmes opposés : l’une évolue sans laisser de trace, l’autre vieillit sans correction. Une méthode de suivi avec journal des modifications permet d’éviter ces deux problèmes.

La date de péremption et l’absence de broches indiquent l’absence de mécanismes de contrôle, et non une preuve que les résultats sont erronés.

La question clé pour toute équipe effectuant des évaluations dans un environnement CI est la suivante : lorsque la note varie d’une exécution à l’autre, qu’est-ce dans votre configuration qui vous permet de déterminer si c’est le modèle ou les données qui ont changé ? Si la réponse est « rien », un champ de révision dans vos définitions de tâches constitue le point de départ le plus simple. Vous pouvez consulter directement le catalogue de tâches lm-evaluation-harness ainsi que le registre openai/evals pour comparer ces deux approches.

Lectures complémentaires

• Un plan échelonné des concepts d’ingénierie IA et du moment où ils sont importants — Découvrez quels concepts d’ingénierie IA déterminent si un système fonctionne ou non, lesquels sont essentiels une fois le développement terminé pour la production, et lesquels peuvent attendre.
• Gérer LLM-as-a-Judge comme un système de production en vie — Apprenez comment le cycle de vie en quatre étapes de Netflix — données fiables, entraînement ajusté selon des critères précis, déploiement sécurisé et surveillance continue — permet à LLM-juge de rester précis à grande échelle.