Métriques d'auto-réparation : quand une évaluation verte cache une régression réelle
Lors de notre évaluation de profondeur multi-documents (2026-06-04, GLM-4.7), une métrique de mappage de clauses a obtenu un score quasi-parfait de 1,0 tandis que l'analyse par document du modèle est tombée à environ un tiers de sa profondeur autonome. La métrique évidente était celle qui mentait.
Le chiffre le plus dangereux dans une évaluation est celui qui reste vert alors que le produit se brise. Nous en avons un. Lors de l'exécution exacte où la profondeur de sortie par document de notre modèle est tombée à environ un tiers de sa profondeur autonome, une métrique de parité a obtenu un score quasi-parfait de 1,0. La métrique n'était ni bruitée ni mal calibrée. Elle mesurait la mauvaise chose, d'une manière que le modèle pouvait satisfaire sans faire le travail. Nous appelons cela une métrique d'auto-réparation, et la découverte de la nôtre a été la chose la plus utile que notre suite d'évaluation ait faite cette semaine-là.
Ce que nous testions
Une tâche courante dans notre produit est l'analyse multi-documents : un utilisateur dépose plusieurs documents de politique en même temps et demande à l'assistant de les mapper chacun contre les clauses d'un cadre, par exemple les contrôles de l'Annexe A de l'ISO/IEC 27001:2022. Un client nous a indiqué que l'analyse de plusieurs documents en une seule requête produisait des résultats plus fins que l'analyse de chaque document individuellement. Avant d'apporter des modifications, nous avons construit une évaluation pour reproduire et mesurer cet écart (ticket interne ISM-549, exécution de référence 2026-06-04).
La configuration était délibérément fidèle à la production. Modèle : GLM-4.7, servi via OpenRouter, correspondant au chemin de requête évalué. Fixtures : sept politiques synthétiques et anonymisées (aucun contenu client), conçues comme le scénario réel qui a déclenché la plainte. La question à laquelle l'évaluation devait répondre était simple : chaque document reçoit-il la même profondeur analytique lorsqu'ils sont analysés ensemble que lorsqu'ils sont analysés individuellement ?
La première métrique, et pourquoi elle s'est auto-réparée
La façon évidente de noter "chaque document a-t-il été analysé" consiste à compter les lignes de mappage des clauses. Une analyse autonome produit un tableau avec une ligne par clause, donc une analyse groupée devrait en produire autant. C'est exactement ce que nous avons essayé en premier.
La parité des lignes est revenue à environ 1,0. Étant donné des clauses numérotées explicites et une instruction "mapper chaque clause", GLM-4.7 s'empresse de conserver une ligne de tableau par clause même lorsque vous lui soumettez sept documents en même temps. Selon cette métrique, rien n'allait mal. L'évaluation était prête à réussir.
Le produit était visiblement pire. Les lignes étaient présentes ; l'analyse autour d'elles avait disparu. En autonomie, chaque ligne de clause contenait une explication, les forces, les lacunes et un court résumé. En groupe, le modèle a conservé le squelette et retiré les muscles : la même forme de tableau, bien moins de raisonnement par clause. La métrique s'était auto-réparée. La sortie satisfaisait "une ligne par clause" tout en supprimant une grande partie de l'analyse par clause, et un décompte de lignes ne peut pas distinguer une analyse complète d'une analyse creuse.
Ce qu'une meilleure métrique a montré
Nous avons donc arrêté de noter la structure et avons commencé à noter le fond. La métrique principale est devenue la parité de volume de contenu : caractères de sortie groupés divisés par la somme des caractères de sortie autonomes, avec un seuil de réussite à 0,6. Lors de l'exécution de référence du 2026-06-04 (GLM-4.7, deux échantillons) :
| Mesure | Échantillon 1 | Échantillon 2 |
|---|---|---|
| Parité de volume de contenu | 0,34 | 0,35 |
| Caractères en autonomie | 48 263 | 47 651 |
| Caractères groupés | 16 201 | 16 609 |
| Parité des lignes de mappage des clauses | 1,00 | 0,98 |
| Juge LLM : documents jugés non dilués | 0 sur 7 | 0 sur 7 |
Lors de la même exécution de référence du 2026-06-04, un proxy de profondeur au niveau des tokens a raconté la même histoire : environ 2 747 tokens de sortie pour un seul document, contre environ 595 tokens par document lorsque les sept étaient groupés, un ratio par document de 0,22.
Trois détails comptent ici. La parité de volume de contenu était à 0,34, bien en dessous du seuil de 0,6. Un juge LLM indépendant, chargé uniquement de noter chaque document comme dilué ou non, a classé 0 document sur 7 comme non dilué dans les deux échantillons. La parité des lignes, la métrique que nous aurions presque livrée, affichait une moyenne de 0,99 sur les deux échantillons (de 0,98 à 1,00). Les trois signaux de fond pointaient dans la même direction : parité de volume de contenu à environ un tiers, le proxy de tokens encore plus bas à 0,22 par document, et le juge classant chaque document groupé comme dilué. Le seul instrument en désaccord était le décompte structurel des lignes.
Pourquoi cela se produit, et les limites de ce que nous savons
Notre lecture des données est que GLM-4.7 auto-budgétise ses efforts à travers les documents lors d'un seul décodage : lorsqu'on lui demande de réaliser sept analyses dans une seule réponse, il répartit un budget global fixe de manière mince plutôt que de produire sept analyses complètes. Nous n'avons pas instrumenté les internals du modèle, donc il s'agit d'une description du comportement que nous avons mesuré, et non d'un mécanisme prouvé. De plus, cela est spécifique à ce modèle et à cette forme de requête. Deux faits de portée sont essentiels. La régression apparaît à l'échelle de production : elle se manifeste à sept documents, pas à deux, donc un test rapide sur une petite entrée aurait passé sans problème. Et elle ne s'est pas reproduite lorsque nous avons exécuté les mêmes fixtures contre un modèle de pointe sur une API directe. La régression n'est apparue que sur le modèle exact et le chemin de requête que nous évaluons et livrons, ce qui est tout l'argument en faveur de l'évaluation du chemin que vous exécutez réellement plutôt que d'un substitut pratique.
Pourquoi cela est pire en conformité qu'ailleurs
Dans la plupart des produits, "une sortie plus fine" est une imperfection de qualité. Dans nos flux de travail de conformité, ce n'est pas cosmétique : un tableau de mappage des contrôles avec chaque ligne présente mais sans analyse ressemble à un livrable complet sur une capture d'écran tout en ne fournissant à un auditeur aucune des raisonnements par clause dont il aurait besoin pour s'y fier. C'est ce qui rend une métrique d'auto-réparation véritablement dangereuse dans notre domaine. Elle n'était pas simplement imprécise. Elle était verte précisément sur le mode de défaillance le plus important dans notre domaine : un livrable qui semble confiant alors que le fond a été discrètement retiré.
La correction qui découle de cela consiste à faire passer chaque document par une analyse en profondeur autonome au lieu de tout regrouper en un seul décodage, et l'évaluation bascule vers une réussite une fois que c'est fait. Mais la correction est la partie facile. Nous n'aurions pas pu la construire tant que notre métrique phare insistait sur le fait que rien ne clochait. Le changement de métrique devait venir en premier, car on ne peut pas réparer ce que l'on ne peut pas voir.
Comment détecter une métrique d'auto-réparation
Une métrique d'auto-réparation est toute métrique qu'un modèle peut satisfaire sans effectuer le travail sous-jacent. Les métriques structurelles y sont les plus sujettes : décomptes de lignes, décomptes d'éléments, "JSON valide", "tous les champs requis présents", en-têtes de section. Elles sont peu coûteuses à calculer et peu coûteuses à contourner, souvent par le modèle lui-même plutôt que par vous. Avant de faire confiance à l'une d'elles, effectuez ces vérifications :
- Notez le fond, pas seulement la forme. Si une métrique ne vérifie que la structure (lignes, champs, en-têtes), associez-la à une autre qui vérifie le contenu (caractères, tokens, ou un juge LLM notant la thoroughness). La forme est nécessaire, jamais suffisante.
- Ajoutez un instrument indépendant. Un juge LLM peu coûteux qui note la qualité et qui est en désaccord avec votre métrique phare est le signal que vous recherchez. L'accord est une corroboration ; une divergence signifie que votre métrique structurelle s'auto-répare probablement.
- Testez à l'échelle de production. Une régression qui n'apparaît qu'à sept documents passera à deux. Dimensionnez vos fixtures comme l'entrée réelle, et non comme un test unitaire.
- Testez le modèle et le chemin que vous livrez. Notre dilution ne s'est pas reproduite sur un modèle différent ou une API directe. Un proxy plus facile à exécuter est un proxy qui peut manquer le bug que seul votre chemin de production possède.
- Demandez-vous à quoi ressemble la sortie la moins coûteuse pour réussir. Si un modèle pouvait satisfaire votre métrique tout en faisant presque aucun des travaux réels, supposez qu'il le fera tôt ou tard. Concevez la métrique de sorte que le moyen le moins coûteux de réussir consiste à effectuer réellement la tâche.
L'évaluation a fait son travail à la fin, mais seulement après avoir arrêté de faire confiance au chiffre flatteur. Lorsqu'une métrique est verte, la question la plus utile n'est pas "réussissons-nous ?" mais "le modèle pourrait-il réussir cette métrique sans faire le travail ?". Si la réponse est oui, la métrique s'auto-répare, et elle continuera à le faire jusqu'à ce qu'un client soit celui qui le remarque.
Les chiffres ci-dessus proviennent de notre exécution interne de référence de parité de profondeur multi-documents, exécutée le 2026-06-04 sur GLM-4.7 via OpenRouter, et sont ponctuels à cette date. Contexte du cadre : ISO/IEC 27001:2022, Annexe A.