Le piège de la saturation dans les évaluations comparatives de LLM

Une porte d'évaluation comparative ("le nouveau système doit battre l'ancien sur 60 % des tâches") cesse de fonctionner dès que votre évaluation de référence sature le barème. La nôtre l'a fait. Nous avons construit une porte en face-à-face pour décider si un pipeline multi-étapes plus lourd méritait sa place face à notre comportement de production en un seul tour. Nous avons lancé l'évaluation et obtenu un verdict qui ressemblait à un rejet clair : un taux de victoire de 7,1 % contre un seuil de 60 %. Lors de ce test, le challenger n'a jamais été moins bon sur aucune tâche : il a égalé 13 des 14 tâches et a remporté celle qu'il n'a pas égalée. Le chiffre ne nous disait pas que le challenger avait échoué. Il nous disait que nos tâches étaient trop faciles pour distinguer les deux systèmes et que nous avions failli les confondre.

Cette défaillance a une forme qui mérite d'être nommée, car elle est invisible jusqu'à ce que l'on examine le score absolu de la référence. Nous l'appelons le piège de la saturation : lorsque votre évaluation de référence obtient un score proche du plafond, une porte basée sur le taux de victoire ne mesure plus du tout le challenger.

La porte que nous avons construite

La décision était concrète. Un pipeline multi-étapes (planifier, puis exécuter, puis vérifier) coûte plus cher à exécuter qu'un tour de modèle unique, car il effectue plusieurs appels au modèle alors que le tour unique n'en fait qu'un. Ainsi, la question n'était pas "est-il bon ?", mais "est-il clairement meilleur, suffisamment pour justifier le coût supplémentaire ?". S'il ne faisait que correspondre au tour unique, il s'agissait d'une augmentation de coût sans augmentation de qualité, et il ne devait pas être déployé. (Nous ne publions délibérément pas la composition interne du modèle du pipeline ni les données économiques par token ; la leçon ici porte sur l'évaluation, et non sur notre routage.)

Nous avons opérationnalisé "clairement meilleur" en deux critères qui devaient tous deux être satisfaits, car chacun pris isolément peut être manipulé :

Taux de victoire d'au moins 60 %. Le challenger doit remporter au moins 60 % des tâches. Les égalités comptent contre lui : une égalité à un coût plus élevé équivaut à une perte en termes de produit. Nous avons fixé le seuil à 60 % plutôt qu'à 50 % afin qu'un résultat doive survivre au bruit des juges sur un petit ensemble de tâches ; une victoire de 7 sur 12 ne tient qu'à un seul jugement inversé pour être un pile ou face.
Delta de score moyen strictement positif. La différence moyenne des scores par tâche (challenger moins référence) doit être supérieure à zéro, afin qu'un petit nombre de victoires étroites ne masque pas de régressions importantes ailleurs.

L'ensemble des tâches comprenait 14 tâches principales sur un espace de travail synthétique entièrement fictif : un prétendu processeur SaaS de 30 personnes avec des défauts délibérément introduits (une politique ISMS obsolète citant la norme ISO/IEC 27001:2013 retirée, une politique de contrôle d'accès avec une règle MFA auto-contradictoire, un stub de réponse aux incidents, un inventaire de traitement partiel). Aucune donnée client. Chaque tâche comportait un barème de critères binaires évaluables indépendamment, notés par un juge LLM (claude-haiku-4-5, température 0, un verdict JSON par critère). Le juge ne voyait jamais que les livrables publiés, jamais le plan interne du pipeline. Ainsi, un plan promettant "inclure l'Art. 28(3)" ne pouvait pas obtenir de crédit si le document final ne le livrait pas.

Le test, et les deux lignes qui ne concordaient pas

Voici l'ensemble des résultats. La référence est le tour de modèle unique (claude-opus-4-6) ; le challenger est le pipeline multi-étapes, dont la composition interne du modèle est tenue secrète car elle touche au routage. Cela n'a pas d'importance ici, car la leçon est au niveau de l'architecture et ne dépend pas du modèle utilisé dans le pipeline. Un seul test par système, le 11 juin 2026.

Mesure	Valeur
Score moyen de la référence (14 tâches)	0,984
Score moyen du challenger (14 tâches)	1,000
Égalités	13 sur 14
Victoires du challenger	1
Défaites du challenger	0
Taux de victoire (les égalités comptent contre le challenger)	7,1 % (1/14)
Delta de score moyen (challenger moins référence)	+0,016

Lisez la porte au regard de ces chiffres et les deux lignes se contredisent. La ligne du delta moyen passe : le challenger est, en moyenne, très légèrement meilleur et n'est jamais moins bon. La ligne du taux de victoire échoue de manière catastrophique : 7,1 % contre un seuil de 60 %. Une seule porte qui affirme à la fois "le challenger est au moins aussi bon sur toutes les tâches" et "le challenger perd 93 % du temps" ne mesure pas le challenger. Cette contradiction est la signature du piège de la saturation, et c'est le signal à surveiller.

Le mécanisme est arithmétique, pas subjectif. La référence a obtenu un score parfait de 1,0 sur 13 des 14 tâches. Sur une tâche où la référence obtenait déjà 1,0, le meilleur que le challenger puisse faire est une égalité, car il n'y a pas de marge au-dessus de 1,0 pour gagner. Et les égalités, selon notre propre conception, comptent contre lui. Ainsi, un barème que la référence maîtrise parfaitement transforme presque toutes les tâches en une perte structurelle pour le challenger, quelle que soit sa qualité. Le taux de victoire avait cessé d'être une propriété du challenger pour devenir une propriété de l'ensemble des tâches : plus précisément, la part des tâches que la référence avait laissées battables. Il n'en avait laissé qu'une.

La seule tâche où la référence a perdu des points

Examinons la seule tâche où la référence n'a pas obtenu un score parfait de 1,0. Elle a obtenu 0,78, et non parce qu'elle ne pouvait pas accomplir le travail. Il s'agissait d'une tâche où elle en faisait trop : chargée de rédiger l'ensemble manquant de documentation GDPR avec un barème spécifiant trois à cinq artefacts, le tour unique en a produit sept. Chaque artefact était compétent et correctement cité. La seule perte de crédit de toute l'évaluation était une pénalité de surlivraison pondérée, pour ne pas s'être arrêté.

Voilà toute la leçon en un seul point de données. Lorsque les deux systèmes peuvent accomplir la tâche, "peuvent-ils accomplir la tâche ?" n'est plus la question que l'évaluation devrait poser, car les deux répondent oui et égalent. Les seules défaillances restantes à noter sont des défaillances de retenue : en faire trop, dire trop, citer avec trop de confiance, affirmer des choses que l'on ne vous a pas demandé d'affirmer. Notre premier barème mesurait la capacité, notre modèle de référence a saturé ce barème, et le seul signal qui a survécu était une défaillance de retenue que nous avions presque omis d'inclure dans une tâche.

"Alors déployez la référence"

L'objection honnête à tout cela est que le fait qu'une référence obtienne un score de 0,984 vous incite à déployer la référence et à sauter le pipeline coûteux. Si la solution économique est aussi bonne, pourquoi continuer à mesurer ? C'est un défi légitime et il a moitié raison : sur ces tâches, la solution économique était effectivement aussi bonne, et c'est une conclusion réelle.

Il n'a que moitié raison, car la saturation sur les tâches de capacité ne dit rien sur les tâches de retenue, et la retenue est précisément là où un pipeline multi-étapes (qui peut vérifier son propre travail avant de le publier) pourrait réellement prendre l'avantage, ou au contraire aggraver la situation en amplifiant sa propre surréaction. Nos tâches principales n'ont jamais exploré cette dimension. La seule qui l'a fait par accident (la tâche de surlivraison) était la seule à avoir bougé. Ainsi, les 0,984 n'étaient pas la preuve que les deux systèmes étaient équivalents. Ils témoignaient du fait que nos tâches ne pouvaient pas les distinguer sur l'axe qui restait. La saturation est une déclaration sur votre barème, jamais un verdict d'équivalence entre vos systèmes.

Ce que nous avons changé

Nous n'avons pas relancé l'évaluation. Relancer une évaluation saturée ne peut pas augmenter le taux de victoire, car le challenger ne peut pas obtenir un score supérieur à 1,0 de la référence sur les tâches qu'il égalise déjà ; une nouvelle exécution ne fait que reproduire le même plafond à un coût plus élevé. À la place, nous avons renforcé l'ensemble des tâches, en ajoutant des tâches dont les barèmes peuvent être genuinely échoués par un tour unique fort, ciblant chacune un axe de retenue que les tâches principales ignoraient :

Discipline de portée : produire exactement trois documents d'intégration, ni plus ni moins. Évalue le réflexe de surlivraison derrière la seule perte de crédit de la référence.
Omission adaptée au public : un e-mail de sécurité destiné aux clients ainsi qu'une note de couverture interne, alors que l'espace de travail contient une note interne réservée aux partenaires. Évalue si le modèle conserve le contenu privilégié hors de l'artefact destiné à l'extérieur.
Exactitude des citations : un plan d'audit interne devant citer la bonne norme pour l'affirmation et non une norme plausible mais incorrecte.
Gestion des preuves non vérifiées : un rapport d'état d'audit où l'audit est toujours en cours. Évalue si le modèle rapporte ce qui est vérifié plutôt que d'affirmer une conclusion qu'il ne peut pas étayer.

Le cadre anti-triche qui a rendu cette itération sûre mérite d'être énoncé clairement, car un ensemble de tâches renforcé n'est fiable qu'avec une discipline autour. L'ensemble canonique des identifiants de tâches est gelé et haché (sha256 sur les identifiants des tâches, les barèmes et les documents de l'espace de travail, ainsi que sur le modèle du juge et la version du scoreur), et une lecture de la porte n'est acceptée que sur cet ensemble exact : pas de sous-ensemble, pas d'ajouts. Cela rend difficile la sélection discrète des tâches produisant le verdict souhaité, et un rapport obsolète ou modifié manuellement ne peut pas silencieusement autoriser une publication.

Les limites de cette approche

Un test par système, un modèle de juge, 14 tâches. Un juge unique notant des critères binaires présente une variance, c'est la raison pour laquelle le seuil du taux de victoire est fixé à 60 % et non à 50 %. La référence a également été exécutée avec l'invite réelle du système de production, mais sans les mémoires, les compétences enregistrées et la recherche web disponibles dans une session en direct, et chacune de ces lacunes rend la référence plus faible qu'un tour unique réel, ce qui facilite la tâche du challenger, et non l'inverse. En d'autres termes, la référence réelle est probablement encore plus saturée que 0,984. Ces chiffres sont valables à un instant donné, le 11 juin 2026. Nous n'avons pas publié de lecture de la porte sur l'ensemble renforcé des tâches ; l'objectif de ce billet est l'échec révélé par le premier test, et non un nouveau verdict.

Cet échec est différent d'une métrique qui reste verte alors que le produit se dégrade, que nous avons abordé séparément. C'était un chiffre qui mentait. Ici, le chiffre disait la vérité (la référence est vraiment aussi forte sur ces tâches) et ne pouvait toujours pas répondre à la question que nous lui posions. Les deux sont des moyens par lesquels une évaluation semblant positive peut être sans valeur, et ils nécessitent des corrections opposées : la première a besoin d'une meilleure métrique, la seconde de tâches plus difficiles.

Une liste de contrôle pour les portes comparatives

Lisez le score absolu de la référence avant de faire confiance au taux de victoire. Si la référence est proche du plafond, votre seuil de taux de victoire est structurellement inaccessible. Corrigez les tâches, ne relancez pas.
Surveillez le taux d'égalités. Une accumulation d'égalités indique un barème saturé, et non une égalité réelle. Si la plupart des tâches se soldent par une égalité, votre ensemble n'a pas de marge pour que l'un ou l'autre système gagne.
Décidez ce que signifient les égalités avant de lire le chiffre. Lorsque les égalités comptent contre le challenger, une référence saturée transforme un système meilleur en un verdict d'échec. Cela peut être la bonne politique (la nôtre l'était, pour des raisons de coût), mais sachez que vous l'avez choisie.
Traitez les lignes contradictoires de la porte comme un diagnostic. Si votre ligne de delta moyen passe tandis que votre ligne de taux de victoire échoue sévèrement, ce n'est pas un résultat mitigé à moyenner. C'est la saturation qui s'annonce.
Notez la retenue, pas seulement la capacité. Une fois que les deux systèmes peuvent accomplir la tâche, les défaillances discriminantes sont la surlivraison, les fuites de public, les citations excessives et les affirmations de faits non vérifiés. Créez des tâches qu'un modèle fort échoue en faisant trop.
Concevez au moins une tâche que votre référence échouera. Si rien ne sépare vos systèmes, vous ne les avez pas mesurés. Vous avez mesuré votre ensemble de tâches et constaté qu'il était trop facile.
Geler et hacher l'ensemble canonique. Ainsi, ni vous ni une future publication ne pourrez discrètement sélectionner les tâches produisant la réponse souhaitée.

Le piège n'est pas que la référence était bonne. Les bonnes références sont l'objectif. Le piège est de lire un taux de victoire comme un fait sur le challenger alors qu'il était devenu un fait sur les tâches. Lorsque votre comparaison atteint la saturation, l'évaluation a cessé de vous parler de vos modèles pour commencer à vous parler de votre barème. Le bon réflexe est d'écouter ce second message et de rédiger une tâche suffisamment difficile pour faire échouer un modèle fort.

Les chiffres ci-dessus proviennent d'une évaluation interne en face-à-face, menée le 11 juin 2026, avec une référence en un seul tour (claude-opus-4-6) contre un pipeline multi-étapes plan-exécuter-vérifier, jugé par claude-haiku-4-5, sur 14 tâches dans un espace de travail synthétique sans contenu client. Données valables à cette date. Contexte réglementaire : ISO/IEC 27001:2022, RGPD (Art. 28, Art. 30).

Le piège de la saturation : quand votre évaluation de référence est trop bonne pour être mesurée