L'échange de non-infériorité : comment nous déployons des changements de modèles sur une égalité de qualité

Le 2026-09-01, nous avons basculé notre interface de chat payante "think" de Grok 4.6 (raisonnement activé) vers GLM 5.3 (effort élevé) après une évaluation où le modèle challenger a obtenu un score inférieur de 1,7 point sur la qualité des réponses. Sur notre prompt de production, le premier jet de token du modèle en place prenait un temps médian de 88 906 ms ; celui du challenger, 4 169 ms. La même évaluation a également permis de basculer l'interface de chat payante "fast" (une victoire de +10,0 points) et les deux modes de l'interface gratuite (+13,3 et +11,7 points). Les trois interfaces utilisent aujourd'hui le challenger en production, les modèles précédents étant à un paramètre d'environnement près. Nous appelons cette pratique l'échange de non-infériorité, et nous pensons qu'elle représente la bonne approche pour les changements de modèles en production : le rôle de l'évaluation n'est pas de trouver un gagnant, mais d'établir, selon des règles figées avant le test, que le challenger ne perd pas, puis de laisser les dimensions que les utilisateurs ressentent réellement (latence du premier jet de token, extrêmes, fiabilité) trancher l'égalité.

Pourquoi la porte intuitive échoue

La plupart des équipes gèrent un changement de modèle de manière évidente : exécuter une évaluation, déployer uniquement si le nouveau modèle obtient un meilleur score. Deux problèmes rendent cette approche inefficace.

Premièrement, sur des tâches produit réelles, les différences de qualité entre les modèles de pointe actuels sont généralement inférieures à la capacité de mesure de votre système de jugement. Notre benchmark de conformité à 20 tâches a mesuré une variation de test-retest de 18,2 points sur une échelle de 100 points pour notre juge, et nous avons préenregistré un verdict d'égalité sur cette base même (l'évaluation a eu lieu le lendemain de ce changement ; nous l'avons documenté ici). Une porte qui exige une amélioration sur cet instrument ne se déclenche presque jamais de manière honnête. Une porte sans cette exigence déploie sur du bruit.

Deuxièmement, une porte exigeant une amélioration stricte crée les mauvaises incitations : soit rien ne se déploie jamais, soit quelqu'un relance l'évaluation jusqu'à ce que le bruit favorise le challenger.

L'alternative est empruntée aux essais cliniques. Un essai de non-infériorité ne demande pas si le nouveau traitement est meilleur, mais seulement s'il n'est pas inacceptablement pire, selon une marge définie avant toute collecte de données. Adoptez cette conception intégralement : préenregistrez une bande d'égalité et les garde-fous opérationnels, exécutez une seule fois, et rendez le verdict mécanique.

La configuration : trois interfaces, trois règles figées

Nous avons évalué trois interfaces de chat de production d'un même produit, un seul banc d'essai, une seule exécution. Chaque interface a sa propre règle de décision, figée le 2026-09-01 avant toute prise de décision :

Interface	Modèle en place	Modèle challenger	Règle préenregistrée
Payante fast	GLM 5.2	GLM 5.3-Flash, effort bas	Qualité dans une marge de 5,0 points ET latence médiane du premier jet de token non matériellement pire ET p90 inférieur à la course de repli de 8 s ET taux de dépassement de 10 s non pire de plus de 5 pp
Payante think	Grok 4.6, raisonnement activé	GLM 5.3, effort élevé	Qualité dans la bande d'égalité de 5,0 points autorise le changement
Gratuite (déconnecté et repli sur quota dépassé)	GLM 4.7	GLM 5.3-Flash, effort bas	Qualité dans une marge de 5,0 points ET latence médiane du premier jet de token inférieure à 2x le modèle en place

La bande d'égalité était de 5,0 points sur la métrique de qualité, figée dans le plan et non ajustée après avoir vu les scores. Un garde-fou était figé sous forme de texte plutôt que de nombre : la règle de l'interface payante fast indique que la latence médiane du premier jet de token du challenger doit être "non matériellement pire", sans seuil attaché. Le plan est le plan, et ce garde-fou a nécessité un appel à jugement dans la section des résultats ; la solution consiste à utiliser un seuil numérique la prochaine fois, et il figure dans la liste de vérification. Notre couche de streaming bascule vers un état d'attente après 8 secondes sans premier jet de contenu sur les interfaces fast et 120 secondes sur les interfaces think, donc les garde-fous de latence ont été écrits en fonction de ces budgets réels.

Méthode, telle que figée :

• Le prompt était l'assemblage de production. 22 445 caractères : le prompt de style concis, l'injection de connaissances du framework construite à partir de la question, le bloc de l'espace de travail, la date. Identique en octets pour tous les bras. Un prompt de démonstration compact aurait mesuré un produit différent.
• Quatre tâches, trois tâches de réponse GRC longues et une tâche de politique ancrée dans l'espace de travail native du chat, chacune notée sur une échelle de 0 à 2 avec cinq critères. Trois échantillons par bras par tâche à température 0.
• Un seul modèle juge a noté chaque sortie à l'aveugle : Grok 4.3, exécuté via OpenRouter, sans étiquettes de bras, sans connaissance du modèle ayant produit quoi. Il partage un fournisseur avec exactement un bras, le modèle en place think. Le biais d'auto-préférence des évaluateurs LLM est documenté lorsque le juge note ses propres générations (Panickssery, Bowman et Feng, arXiv:2404.13076, 2024-04-15), et les biais de position et de verbosité sont répertoriés dans les configurations LLM-as-a-judge (Zheng et al., arXiv:2306.05685, 2023-06-09). Aucun de ces articles ne mesure le biais au niveau de la famille, et nous non plus, donc nous avons enregistré la direction du risque au lieu de supposer la neutralité : si un biais familial existe ici, il favorise le modèle en place, ce qui rend le changement think conservateur, et non permissif.
• Les références du modèle en place ont été régénérées fraîches lors de la même exécution. Notre évaluation de juin 2026 du même modèle en place utilisait un juge différent et un assemblage de prompt plus ancien, donc réutiliser ses chiffres stockés aurait comparé deux instruments différents. Même juge, même jour, même assemblage, ou la comparaison n'est pas concluante.
• Un plafond de dépenses préenregistré avec un arrêt automatique, et des timeouts stricts par appel.

Les résultats

La qualité est le score moyen du juge en pourcentage du maximum de l'échelle ; 12 générations notées par bras (4 tâches, 3 échantillons), 2026-09-01 :

Interface	Bras	Qualité
Payante fast	GLM 5.2 (modèle en place)	81,7
Payante fast	GLM 5.3-Flash, effort bas	91,7
Payante think	Grok 4.6, raisonnement activé (modèle en place)	91,7
Payante think	GLM 5.3, effort élevé	90,0
Gratuite fast	GLM 4.7 (modèle en place)	80,0
Gratuite fast	GLM 5.3-Flash, effort bas	93,3
Gratuite think	GLM 4.7, raisonnement activé (modèle en place)	80,8
Gratuite think	GLM 5.3-Flash, effort bas	92,5

La latence est le temps jusqu'au premier jet de token sur une connexion en streaming ; six répétitions par bras sur une tâche ancrée dans l'espace de travail de production (le même assemblage de prompt de 22 445 caractères que le banc d'essai de qualité), 2026-09-01 :

Bras	TTFC p50	TTFC p90	Répétitions au-dessus de 10 s
Payante fast : GLM 5.2	773 ms	2 626 ms	0 sur 6
Payante fast : GLM 5.3-Flash	2 641 ms	4 011 ms	0 sur 6
Payante think : Grok 4.6	88 906 ms	101 591 ms	6 sur 6
Payante think : GLM 5.3	4 169 ms	57 707 ms	2 sur 6
Gratuite fast : GLM 4.7	2 857 ms	3 163 ms	0 sur 6
Gratuite fast : GLM 5.3-Flash	3 350 ms	3 640 ms	0 sur 6
Gratuite think : GLM 4.7	18 014 ms	24 156 ms	6 sur 6
Gratuite think : GLM 5.3-Flash	3 052 ms	7 612 ms	0 sur 6

Appliquées mécaniquement, les règles figées ont donné trois verdicts :

• Payante fast : VALIDÉ, et l'interface est devenue plus lente. Qualité +10,0 points. Premier jet de token 3,4 fois plus lent (773 ms à 2 641 ms en médiane), mais p90 à 4,0 s contre la course de repli de 8 s et zéro répétition au-dessus de 10 s des deux côtés. C'est ici que le verdict a cessé d'être entièrement mécanique : le garde-fou sous forme de texte ("non matériellement pire") n'a pas de seuil, et nous avons jugé qu'une médiane de 2,6 s avec un p90 à 4,0 s et aucun dépassement le respecte. Cet appel est enregistré ici plutôt que lavé dans un seuil qui n'a jamais existé. Que les utilisateurs perçoivent 2,6 s comme pire que 0,8 s n'est pas quelque chose que cette évaluation a mesuré ; ce qu'elle a établi, c'est que le garde-fou tel que figé a passé, et qu'une exigence de rapidité supérieure à celle du modèle en place aurait opposé son veto à un changement que les règles figées considéraient comme une victoire de qualité incontestable.
• Payante think : VALIDÉ sur une égalité. 90,0 contre 91,7 est -1,7 point, dans la bande de 5,0 points. Face à cela, les 88,9 secondes médianes du modèle en place sur notre sonde (6 répétitions sur 6 au-dessus de 10 s) sont devenues 4,2 secondes médianes (2 sur 6 au-dessus de 10 s, et le p90 du modèle en place était déjà au-dessus de 100 s). Une amélioration de 21 fois du chiffre que les utilisateurs ressentent, pour 1,7 point qui se situe dans la bande d'égalité préenregistrée.
• Gratuite : VALIDÉ. +13,3 points en mode fast, +11,7 en mode think, et les 18,0 secondes médianes de l'ancien bras think avec 6 dépassements sur 6 sont devenues 3,1 s avec aucun.

Le verdict think est celui qui mérite d'être discuté, donc voici l'argument en entier. La bande préenregistrée indique qu'un écart de 1,7 point n'est pas une différence de qualité. Les 18,2 points de variation de test-retest que notre benchmark de conformité a mesurés le lendemain, sur un ensemble de tâches et une échelle de notation différents, est la seule mesure directe que nous ayons de la résolution de notre juge sur nos instruments, et elle est d'un ordre de grandeur supérieur à cet écart. Aucun des deux chiffres n'est un intervalle de confiance pour cet écart particulier, et la bande est une règle de décision, non un plancher de bruit mesuré. Mais les deux pointent dans la même direction. Maintenir l'interface think à 1,7 point que nos instruments ne résolvent pas, alors que la médiane du premier jet de token du modèle en place sur notre sonde était de 89 secondes, inverse les priorités : le chiffre que les utilisateurs ressentent en premier est la latence, et elle a évolué de 21 fois dans notre mesure.

Un verdict a une durée de vie limitée

En juin 2026, nous avons évalué GLM 5.2 (sorti le 2026-06-16) comme remplacement de GLM 4.7 sur le même produit, et le verdict du 2026-06-18 était ne pas remplacer : deux juges aveugles indépendants l'ont classé comme équivalent en qualité à GLM 4.7, avec des égalités exactes une fois une erreur d'infrastructure exclue, mais il a échoué aux garde-fous opérationnels de manière décisive, principalement sur la latence think : une médiane de 93 s pour le premier jet de token contre 2,1 s pour GLM 4.7 sur nos tâches et notre configuration, un écart de 44 fois.

Trois mois plus tard, son successeur a battu le même modèle en place sans contestation dans les deux modes gratuits de l'évaluation de septembre. Deux conclusions que nous traitons désormais comme des règles permanentes.

Les verdicts de modèle ont une durée de vie limitée, mesurée en mois. Un appel "équivalent en qualité, inapplicable en opération" est un verdict sur un modèle à un moment précis, non sur le créneau ; le créneau a reçu un modèle différent et le verdict a changé. C'est une autre raison pour laquelle nous régénérons les références du modèle en place à chaque évaluation de changement, plutôt que de citer les anciennes : les références stockées comparent silencieusement des instruments différents, et les verdicts périmés comparent silencieusement des générations de modèles différentes. Le chiffre de juin était vrai. Nous ne l'avons pas hérité, et il ne nous liait pas.

Deux problèmes que le banc d'essai a détectés

Générations vides avec un plafond serré. Le premier passage de latence le 2026-09-01 a exécuté chaque bras avec un plafond de complétion de 256 tokens. Les douze lignes des deux bras think GLM (GLM 4.7 et GLM 5.2, six chacun) sont revenues vides : le canal de raisonnement a consommé le budget avant l'existence du premier jet de contenu, donc la ligne mesurait le plafond, non le modèle. Le bras think Grok 4.6 a streamé correctement avec le même plafond. Nous avons invalidé le passage et relancé les bras think GLM avec un plafond de 4 096 tokens avant de lire un seul percentile ; le banc d'essai de qualité avait utilisé un budget de 16k tout au long et n'a pas été affecté. Il s'agit de la même classe d'échec que le zéro silenc que nous avons documenté en août (des données sans contenu, notées comme une mesure). Le garde-fou peu glamour est : compter les générations vides par bras, et refuser d'agréger tout bras dont le compte n'est pas nul.

La forme de la requête du modèle en place ne se transfère pas. Nous avons sondé si la configuration précédente pouvait être copiée sur le challenger. Lors de nos tests API du 2026-09-01, 24 appels sur 24 à travers GLM 5.3 et GLM 5.3-Flash qui portaient reasoning: {enabled: false} sur la route testée ont renvoyé HTTP 400, donc dans nos sondages, le raisonnement ne peut pas être désactivé sur cette famille ; effort bas est le plancher, non un bouton. Une migration de modèle recrée la configuration de requête à partir du comportement réel du challenger. Chaque paramètre que vous copiez du modèle en place sans retester est un facteur de confusion que vous introduisez dans votre propre évaluation.

Ce que cela affirme et n'affirme pas

Les chiffres de qualité proviennent de 12 générations notées par bras (4 tâches, 3 échantillons, température 0), un seul modèle juge, aucune calibration humaine des échelles de chat, un seul passage en une journée (2026-09-01), sur notre assemblage de prompts et notre configuration de service uniquement. La bande d'égalité de 5,0 points était une règle de décision préenregistrée, non un plancher de bruit mesuré pour cet instrument ; notre benchmark de conformité à 20 tâches, exécuté le lendemain (2026-09-02) sur un ensemble de tâches et une échelle de notation différents, a mesuré 18,2 points de variation de test-retest du juge, donc nous traitons les différences de qualité dans la bande comme non mesurées, non comme nulles. Les percentiles de latence proviennent de 6 répétitions en streaming par bras sur une tâche ancrée dans l'espace de travail, notre assemblage de prompt, notre configuration, ce jour-là : des propriétés de notre configuration, non des benchmarks fournisseurs. Tous les résultats sont des instantanés au 2026-09-01. Une description publique de notre méthodologie de benchmark, y compris la manière dont nous mesurons la variation du juge, est disponible sur la page de qualité des modèles.

La liste de vérification

Avant votre prochain changement de modèle en production :

1. Figez la règle de décision par interface avant le passage : bande d'égalité, garde-fous de latence, garde-fous de queues, plafond de dépenses, et ce qu'une égalité signifie.
2. Dimensionnez la bande d'égalité à partir de la variation de test-retest de votre juge sur vos échelles. Si vous n'avez jamais retesté des réponses identiques, vous ne savez pas à quel point vos différences de qualité mesurables sont petites.
3. Évaluez sur l'assemblage de prompt de production, identique en octets pour tous les bras. Un prompt de démonstration mesure un produit que vous n'exécutez pas.
4. Régénérez les références du modèle en place lors du même passage, même juge, même jour. Les références stockées sont des comparaisons entre instruments différents.
5. Gardez les queues, non les moyennes : latence p90 du premier jet de token et taux de dépassement de 10 s, par rapport à vos replis de streaming réels.
6. Comptez les générations vides par bras et refusez de noter tout bras qui en a. Corrigez le budget de complétion, puis mesurez.
7. Recréez la configuration de requête pour le challenger, paramètres de raisonnement inclus. Ne copiez jamais la forme du modèle en place dans l'évaluation.
8. Sachez dans quelle direction le biais familial de votre juge pousse la décision, et concevez de manière à ce qu'il pousse vers la prudence.
9. Donnez une date d'expiration à chaque verdict. Relancez toute évaluation plus ancienne qu'un trimestre.

Une égalité n'est pas de l'indécision. C'est le verdict que votre évaluation de qualité peut réellement défendre, et le fait de le préenregistrer permet de confier la décision aux chiffres que vos utilisateurs ressentent.