Une étude préenregistrée publiée le 3 septembre pose une question opérationnelle difficile aux équipes qui utilisent des modèles de langage pour évaluer d'autres systèmes : l'évaluateur lui-même est-il assez stable pour décider d'un passage en production ?
L'article Clean Engineering, Unstable Measurement n'a pas été conçu comme une critique de principe des juges LLM. Les chercheurs voulaient mesurer la progression d'une solution à partir de fragments visibles de raisonnement. Leur protocole imposait toutefois que le modèle observateur réussisse d'abord des tests de fiabilité. Les deux campagnes se sont arrêtées à cette étape.
Sur 52 988 tentatives de requête auditées, les auteurs rapportent une corrélation de Spearman de 0,400 entre classements répétés dans une même fenêtre, contre un seuil préenregistré de 0,90. Dans un autre test, 100 requêtes identiques octet par octet ont été rejouées le lendemain avec le même nom de modèle ; l'accord exact sur le classement n'a atteint que 0,78, pour une exigence de 0,99.
Les 52 988 tentatives ne constituent pas 52 988 échantillons indépendants. L'article précise que ses analyses reposent sur des unités bien plus petites, notamment 31 groupes de tâches valides, 100 paires de rejouage et 3 060 jugements sur des erreurs construites. Le résultat porte donc sur la fiabilité d'un instrument de mesure, pas sur la taille d'une évaluation comparative.
Une requête exécutée correctement ne garantit pas une mesure stable
Le point central est la distinction entre correction technique et fiabilité de la mesure. Livraison des requêtes, validité du schéma, empreintes des requêtes et métadonnées enregistrées peuvent être impeccables, alors que l'évaluateur échoue malgré tout aux critères de stabilité fixés à l'avance.
Les auteurs décrivent trois mécanismes. Dans un protocole, l'association entre les étiquettes et leur signification influençait le résultat. Dans un autre, l'écart entre candidats était largement inférieur au bruit propre de l'évaluateur. Enfin, dans le classement complet, des requêtes identiques pouvaient produire des permutations différentes, et l'exigence d'une permutation exactement identique amplifiait de petites variations en échecs complets.
Le mécanisme général est cohérent avec des travaux indépendants. Thinking Machines Lab a déjà montré qu'une inférence à température zéro pouvait diverger selon la mise en lot des requêtes et a publié des noyaux conçus pour rendre les calculs indépendants du lot. La documentation de vLLM Ascend décrit désormais un mode d'invariance au lot destiné à rendre la sortie indépendante de la taille et de l'ordre des requêtes.
La documentation d'Anthropic sur les versions établit également une frontière importante : un identifiant de modèle peut figer les poids alors que l'infrastructure de service qui l'entoure, notamment le routage ou la logique d'échantillonnage, peut évoluer et produire des différences observables.
Ces sources ne reproduisent pas les chiffres du nouvel article. Elles confortent seulement le principe d'ingénierie selon lequel un nom de modèle fixe n'est pas forcément un instrument d'observation parfaitement immuable.
Multiplier les appels n'a pas suffi
Les auteurs ont testé plusieurs échappatoires évidentes. Dans des mesures complémentaires, quatre fournisseurs ont affiché des médianes de stabilité comprises entre 0,74 et 0,88 sur la batterie étudiée. Attendre davantage n'a pas amélioré de façon significative les jours observés. Une installation auto-hébergée utilisant des opérations invariantes au lot s'est montrée plus stable lorsqu'elle était peu chargée, mais la charge concurrente a multiplié le désaccord par 8,4 et l'a rapproché du niveau observé sur les services partagés.
L'étude a aussi simulé un plan équivalent à 748 000 appels. Avec la distribution mesurée, le seuil préenregistré n'a été franchi aucune fois sur 500 simulations. Cela ne signifie pas qu'augmenter la taille d'échantillon est toujours inutile. Cela signifie qu'un échantillonnage massif ne répare pas un critère qui exige une résolution plus fine que le bruit mesuré de l'instrument.
Les auteurs bornent leurs conclusions. Ils ne disent pas que tous les modèles évaluateurs sont inutilisables, ni que tous les fournisseurs se comportent de la même manière. Les résultats concernent les configurations, protocoles et fenêtres temporelles effectivement testés.
Le dossier de reproductibilité est détaillé sans être parfait. Le supplément public contient manifestes, données dérivées, rapports, configurations scellées, textes de préenregistrement et code de reconstruction des figures. Les réponses brutes des fournisseurs restent d'accès restreint. L'article signale aussi un écart de calendrier dans un préenregistrement et une lacune de provenance pour certains anciens essais ; ceux-ci ne servent qu'à l'analyse exploratoire.
Qualifier l'évaluateur avant de lui donner un droit de veto
La conclusion d'Aipolix n'est pas « n'utilisez plus de modèles évaluateurs ». Elle est plus précise : un évaluateur ne devrait pas décider seul d'une mise en production, d'un filtrage de données d'entraînement ou d'un contrôle de régression tant que sa propre fiabilité n'a pas été mesurée sur le chemin d'exécution réel.
Quatre contrôles en découlent.
D'abord, enregistrer l'identité de version la plus forte disponible, et pas seulement le nom convivial du modèle. Si l'API expose un identifiant daté, une empreinte ou des métadonnées de service, ces éléments doivent accompagner chaque exécution.
Ensuite, mesurer la répétabilité sur entrée identique avant de figer un seuil. Un sous-ensemble représentatif doit être rejoué dans la même fenêtre puis sur l'horizon temporel pertinent pour l'exploitation. La question n'est pas seulement de savoir si la note moyenne paraît raisonnable, mais si le bruit est faible par rapport à la marge de décision.
Troisièmement, calibrer le seuil sur la résolution réelle de l'instrument. Si un écart d'un point bloque une version alors que l'évaluateur varie de plusieurs points avec la même entrée, le contrôle mesure autant l'observateur que le produit. Il faut alors modifier le seuil, l'agrégation ou l'évaluateur.
Enfin, une défaillance de mesure doit produire « mesure invalide », et non une réussite ou un échec implicite. Une réponse mal formée, une identité de version manquante ou un test de stabilité non satisfait doit retirer à l'évaluateur son pouvoir de décision.
Une conséquence directe pour la gouvernance de l'IA
De nombreuses architectures de gouvernance utilisent un modèle évaluateur comme couche de contrôle peu coûteuse : évaluer une sortie, comparer la note à une politique, puis autoriser ou bloquer l'étape suivante. Cette étude montre pourquoi ce contrôle peut être moins solide qu'il n'y paraît, même si toute l'automatisation qui l'entoure est irréprochable.
Un journal d'audit peut prouver que le processus s'est exécuté exactement comme prévu. Si l'instrument varie à la même échelle que la frontière de décision, ce journal ne suffit pas à démontrer que la décision elle-même est reproductible.
La distinction à retenir en production est simple : la preuve d'exécution montre ce que le système a fait ; la preuve instrumentale montre si la mesure méritait réellement d'avoir autorité.
La contribution la plus utile de l'article n'est donc pas un nouveau score d'évaluation comparative. C'est une règle d'architecture pour les systèmes d'évaluation : avant qu'un LLM ne devienne un critère bloquant, il faut le qualifier comme instrument de mesure dans les mêmes conditions de service que celles où il prendra la décision.