Évaluer les LLM : des benchmarks publics à votre golden set

Presque toutes les disputes sur l’évaluation opposent deux personnes qui mesurent des choses différentes. Il y a trois projets, et ils ne partagent aucun instrument.

La confusion coûte cher dans un sens. Un leaderboard vous dit qu’un modèle est fort en raisonnement de niveau universitaire ; il ne peut pas vous dire s’il routera vos tickets de support. Et une évaluation d’application qui note une réponse par entrée ne peut pas voir un agent du tout, parce qu’un agent a une distribution de trajectoires et qu’une réponse est un seul échantillon de cette distribution. Le chapitre 22 nommait cette troisième ligne et la laissait vide : la mesure de performance, la partie de la spécification d’un agent que les équipes écrivent en dernier, ou jamais.

L’ordre compte aussi, et le fournisseur qui vous vend le modèle le dit lui-même. Le guide d’OpenAI sur les agents réduit la sélection de modèle à trois étapes, dans cet ordre : « Mettre en place des evals pour établir une baseline de performance », « Se concentrer sur l’atteinte de votre objectif de précision avec les meilleurs modèles disponibles », « Optimiser les coûts et la latence en remplaçant les grands modèles par des modèles plus petits lorsque c’est possible ».¹ L’évaluation vient d’abord, parce que les étapes deux et trois n’ont aucun sens sans un nombre.

Un golden set est une liste d’entrées, chacune avec la réponse écrite, et un évaluateur qui décide si une sortie correspond. C’est ennuyeux, c’est petit, et c’est le seul artefact de ce chapitre qui vous appartient. Celui construit ici contient vingt tâches sur un répertoire de cinq fichiers — pas les trois du chapitre 23, donc les réponses ne sont pas les mêmes — et l’évaluateur est écrit avant que l’agent ne s’exécute :

export type Task = {
  id: string;
  prompt: string;
  answer: string;          // the fact, in words, for a human and for a judge
  must: RegExp[];          // ALL must match the final answer
  mustNot?: RegExp[];      // NONE may match
};

export const GOLDEN: Task[] = [
  { id: "t04", prompt: "Which file is the largest?", answer: "access.log",
    must: [/access\.log/i], mustNot: [/errors\.log/i, /notes\.txt/i] },       
  { id: "t12", prompt: "Which HTTP status codes appear in access.log? List all of them.",
    answer: "200, 429 and 500", must: [/200/, /429/, /500/] },                
  // ...eighteen more
];

Deux propriétés sont essentielles. La liste mustNot existe parce qu’un modèle qui nomme trois fichiers, dont le bon, n’a pas répondu. Et answer est écrit en prose aussi bien qu’en patterns, parce qu’un humain et un juge en auront tous deux besoin plus tard — et écrire le même fait deux fois dans deux notations est la façon de découvrir que vous n’étiez pas d’accord avec vous-même sur ce qu’était la tâche.

Maintenant, le tableau qui tranche. Quatre systèmes candidats, les mêmes vingt tâches, l’accuracy avec son intervalle, et les deux colonnes qu’un tableau d’accuracies seul cache toujours :

Lisez les intervalles avant le gagnant. Les exécutions du bras B vont de 11 % à 47 % ; celles du bras A de 3 % à 30 %. Ils se chevauchent sur la majeure partie de leur longueur, ce qui est la conclusion du chapitre 4 arrivant exactement là où elle était annoncée : vingt cas ne peuvent pas classer quatre systèmes. Le chapitre 15 l’a rendu plus précis en posant plutôt la question appariée — parmi les cas où deux bras ne sont pas d’accord, à quel point le partage est-il déséquilibré ? — parce que la difficulté commune du set s’annule. Voici toutes les paires :

A vs B  +0 / -3   p = 0.2500       B vs C  +4 / -1   p = 0.3750
A vs C  +2 / -2   p = 1.0000       B vs D  +4 / -0   p = 0.1250
A vs D  +2 / -1   p = 1.0000       C vs D  +1 / -0   p = 1.0000

Aucune des six comparaisons n’est établie. Le meilleur bras bat le bras sans aucun outil de quinze points, et cela repose sur trois cas discordants. Vingt cas montrent un mécanisme et ne peuvent pas choisir un fournisseur ; prétendre l’inverse en réunion, c’est ainsi qu’un mauvais modèle se fait acheter.

Il y a une chose que ce tableau établit, et c’est la colonne que personne ne met. Le bras D coûte treize fois le bras B par tâche résolue, parce qu’échantillonner trois trajectoires et prendre la réponse modale triple la facture, que cela triple ou non l’accuracy. Les tableaux d’accuracy qui omettent le coût rendent cet arbitrage invisible.

Voici maintenant la découverte qui change votre lecture de tous les benchmarks que vous verrez. Prenez les mêmes deux cents transcriptions — vingt tâches, dix exécutions, pas un token régénéré — et notez-les de trois façons :

Zéro, treize, vingt-six. Le système n’a pas changé. L’évaluateur a changé. La correspondance exacte renvoie zéro non pas parce que l’agent est inutile, mais parce qu’aucune réponse en texte libre n’est jamais identique octet par octet à une référence : elle mesure le formatage et le rapporte comme une capacité.

Ce n’est pas une curiosité, c’est un mécanisme, et il a un nom. Une métrique à seuil dur note une tâche en tout-ou-rien sur plusieurs sous-faits, donc elle se compose de façon multiplicative. La tâche t12 demande trois codes de statut à la fois. Sur les dix exécutions :

per-code presence   200: 9/10    429: 6/10    500: 8/10    (mean 0.77 per fact)
all three at once   5/10

Chaque fait est correct environ trois quarts du temps ; exiger les trois à la fois divise le score par deux, et $0.77^3 = 0.457$ est assez proche du 0,50 mesuré pour montrer d’où vient la chute. Généralisez :

Lisez la ligne 0,90 contre la ligne 0,95 à $k = 10$ : une amélioration de cinq points par fait devient vingt-cinq points sur la conjonction. Rien de discontinu n’est arrivé au modèle. Une courbe lisse lue à travers une métrique tout-ou-rien ressemble à un saut — ce qui est précisément l’argument de Schaeffer, Miranda et Koyejo sur les capacités émergentes, et que le chapitre 10 renvoyait ici.² Leur audit a constaté qu’au plus 5 des 39 métriques préférées de BIG-Bench affichent une émergence, deux métriques discontinues expliquant plus de 92 % des cas revendiqués.

La discipline tient donc en une ligne : un saut dans un graphique est une preuve sur la métrique jusqu’à preuve du contraire. Avant de croire qu’une capacité est apparue, tracez les mêmes exécutions avec une métrique qui accorde un crédit partiel et voyez si la falaise survit.

Il existe une version de second ordre de ce phénomène qui, selon Kalai et ses collègues, cause des dégâts en amont : les benchmarks notés vrai-ou-faux récompensent le fait de deviner plutôt que de dire « je ne sais pas », donc un modèle optimisé contre eux apprend à deviner. Leur correctif proposé n’est pas un autre benchmark d’hallucination, mais « modifier le scoring des benchmarks existants qui sont désalignés mais dominent les leaderboards ».³ Votre golden set a le même levier, et il tient en une ligne : décider si une abstention compte comme un échec ou comme sa propre catégorie. La plupart des gens ne décident jamais, donc elle compte silencieusement comme un échec, et le système qu’ils livrent devine.

Jusqu’ici, tout notait une tentative par tâche. Un agent n’est pas une tentative. Le chapitre 17 a établi que vous n’avez pas de déterminisme même à température zéro, donc la même entrée produit une distribution de trajectoires, et un benchmark qui exécute chaque tâche une seule fois rapporte un échantillon de cette distribution.

La contribution de τ-bench est la métrique pour cela. L’article la définit clairement : « nous proposons une nouvelle métrique – pass^k (pass hat k), définie comme la probabilité que les k essais i.i.d. d’une tâche réussissent tous, moyennée sur les tâches ».⁴ Exécutez chaque tâche $n$ fois, comptez les $c$ succès, et les estimateurs sans biais sont :

Le second est le pass@k familier de la génération de code : la probabilité qu’au moins une des $k$ tentatives réussisse. Mettez-les côte à côte sur les mêmes comptes mesurés et ils bougent en sens inverse :

Mêmes exécutions, même évaluateur, mêmes vingt tâches. Une colonne dit que le système s’améliore avec davantage de tentatives et l’autre dit qu’il se détériore, et les deux sont correctes, parce qu’elles répondent à des questions différentes. pass@k est la bonne métrique lorsqu’un humain filtre la sortie — génération de code, brouillons, brainstorming — et que les tentatives supplémentaires sont bon marché. pass^k est la bonne métrique lorsque l’agent agit sans filtre, ce que signifie « agent ». Publier la première là où la seconde s’applique est la surestimation la plus courante dans ce domaine, et le titre de τ-bench en donne la version honnête : gpt-4o à environ 61 % pass^1 sur retail tombe à environ 25 % à pass^8.⁴

Maintenant, le piège dans mes propres chiffres. pass^10 sur mes vingt tâches est de 5,0 % : exactement une tâche sur vingt résolue sur les dix exécutions. Cette tâche est t19, « Did deploy 42 succeed? », et voici deux des dix réponses que la rubrique a notées comme correctes :

run 2  "To check if 'deploy.log' succeeded in deploying 42, I will list the file
        names in the working directory using the list_files function..."
run 8  "Yes, deploy 42 has successfully deployed. Deploying was successful for 41
        as well."

La première ne répond jamais. La seconde ajoute une affirmation fausse — deploy 41 a été annulé. Les deux correspondaient à /succe|yes/. La seule tâche qui maintenait pass^10 au-dessus de zéro est un artefact d’évaluateur, donc le vrai chiffre est zéro, et aucun agrégat ne me l’aurait montré. Échantillonner les transcriptions derrière votre tâche au meilleur score, c’est là que les évaluateurs vont mourir.

Et encore un nombre, celui qui donne son nom à cette section. Dix évaluations identiques — même système, mêmes vingt tâches, même code, rien de changé sauf les graines :

per-run correct: 5 2 5 5 8 5 8 5 4 5   ->  10 % .. 40 %,  mean 26.0 %,  sd 8.8 points

Une plage de trente points sur un système qui n’a pas changé. Si vous exécutez votre suite une fois avant une release et une fois après, une « amélioration » de huit points est à l’intérieur de cette dispersion, et vous la livrerez en pensant l’avoir causée. C’est pourquoi l’intervalle groupé ci-dessus — 26,0 % [20,4, 32,5] — est trop étroit pour être cité seul : il traite deux cents essais corrélés comme deux cents essais indépendants. Le résumé honnête d’une évaluation d’agent est une moyenne et une dispersion entre répétitions, et presque personne ne publie la seconde.

Les rubriques ne passent pas à l’échelle pour les réponses ouvertes, donc la manœuvre standard consiste à faire noter la sortie par un modèle. Cela fonctionne assez bien à l’échelle frontier pour être le défaut, et cela a trois modes de défaillance nommés : biais de position, biais de verbosité et biais d’auto-amélioration.⁵

Mesurez-le avant de lui faire confiance. Les mêmes soixante réponses — trois des dix exécutions — ont été étiquetées de trois façons. L’étiquette humaine est la mienne : j’ai lu les soixante avec les cinq fichiers ouverts et appliqué une règle écrite, réussite si et seulement si la réponse énonce le fait demandé par la question et ne contient rien de contredit par les fichiers.

Le juge a dit PASS soixante fois sur soixante. Il aurait rapporté cet agent à 100 % d’accuracy sur un set où l’humain le note à 18 %. Un juge sans pouvoir discriminant n’est pas un instrument bruité ; c’est une fonction constante, et une fonction constante donne le même score à votre meilleur système et à votre pire système.

Le prompting ne l’a pas sauvé. Quatre variantes, les mêmes soixante items :

Inverser l’ordre des deux labels dans l’instruction a déplacé quatre verdicts. C’est un effet mesurable, et c’est le mauvais type d’effet : le juge réagit à la forme du prompt plutôt qu’à la réponse devant lui.

La démonstration propre est par paires. Vingt questions, chacune avec un candidat manifestement correct et un candidat manifestement faux, présentés dans les deux ordres :

picked the FIRST option              40/40 = 100.0 %
order-consistent (same winner both ways)   0/20 = 0.0 %   [Wilson 0.0, 16.1]
picked the CORRECT answer            20/40 = 50.0 %

Il a choisi la position A quarante fois sur quarante. Les 50 % de correctness ne sont pas une compétence partielle — c’est de l’arithmétique, parce que la bonne réponse se trouve en position A dans exactement la moitié des essais. La cohérence est ici définie comme MT-Bench la définit, « le pourcentage de cas où un juge donne des résultats cohérents lorsque l’ordre de deux assistants est inversé », ce qui permet une comparaison à armes égales : GPT-4 obtient 65,0 % sur cette mesure, et le few-shot prompting l’a fait monter à 77,5 %.⁵ Le mien obtient zéro.

L’atténuation standard vient aussi de cet article : « appeler un juge deux fois en inversant l’ordre de deux réponses et ne déclarer une victoire que lorsqu’une réponse est préférée dans les deux ordres ».⁵ Appliquez-la ici et le juge produit zéro verdict utilisable sur vingt paires — ce qui est le bon résultat, et infiniment meilleur que vingt verdicts confiants.

Une note méthodologique qui vaut davantage que le résultat. J’ai aussi exécuté un test de verbosité : la même réponse correcte, avec une copie allongée par une phrase de 36 mots qui n’ajoute rien. Le juge a préféré la version plus longue dans exactement 50 % des essais — ce qui ressemble à une absence de biais de verbosité et n’en est absolument pas une, parce qu’un juge qui choisit toujours la position A obtient 50 % sur n’importe quel appariement équilibré. Vous ne pouvez pas mesurer un second biais tant que le premier n’est pas contrôlé. Inverser les positions n’est pas un raffinement à ajouter plus tard ; c’est ce qui rend toutes les autres mesures interprétables.

La réserve honnête : ce juge est un modèle d’un demi-milliard de paramètres, et personne ne devrait noter avec cela. Le point n’est pas que les juges sont mauvais. C’est que les chiffres ci-dessus ont coûté huit minutes à produire, et que sans eux le verdict de ce juge sur une décision de mise en production aurait été 100 %.

C’est le troisième et dernier panneau Python déclaré du cours, et la raison se trouve là où naissent les chiffres publics. lm-evaluation-harness couvre « plus de 60 benchmarks académiques standard pour les LLMs, avec des centaines de sous-tâches et de variantes implémentées » et constitue « le backend du populaire Open LLM Leaderboard de Hugging Face » ; HELM, SWE-bench et τ-bench sont des packages Python avec des points d’entrée Python.⁶ Comparer votre modèle à un chiffre publié signifie exécuter leur code, et le jour où vous voulez vous comparer à un nombre cité par quelqu’un, voici l’écosystème dans lequel vous êtes :

lm_eval --model hf \
    --model_args pretrained=EleutherAI/gpt-j-6B \
    --tasks hellaswag \
    --device cuda:0 \
    --batch_size 8

La seconde raison est qu’une mesure de ce chapitre est impossible via HTTP. La contamination — le test set ayant fuité dans les données d’entraînement — est la défaillance qui rend silencieusement un benchmark public insignifiant, et la sonde la plus nette pour la détecter a besoin de la perte du modèle lui-même, qu’aucune API de chat ne renvoie. C’est l’entropie croisée par token du chapitre 8, dirigée vers une question de mémoire :

def nll(text: str) -> float:
    """Mean negative log-likelihood per token, in nats."""
    ids = tok(text, return_tensors="pt").input_ids.to(model.device)
    with torch.no_grad():
        out = model(ids, labels=ids)
    return float(out.loss)

Dix paires de phrases : cinq présentes dans tous les crawls du web depuis qu’il existe, cinq écrites pour ce chapitre ce matin, chacune appariée à une version reformulée portant le même contenu.

Le modèle est quatre fois plus surpris par une phrase écrite ce matin que par une phrase qu’il a vue un million de fois, et reformuler coûte deux fois plus cher sur les phrases célèbres — le surcoût étant la partie qui a été mémorisée plutôt que comprise. La perte absolue confond mémorisation et naturalité ordinaire, donc l’écart est la meilleure statistique, et le test de continuation est encore meilleur. Donnez-lui les six premiers mots :

famous  "Permission is hereby granted, free of"
     -> "charge, to any person obtaining a copy of this software and associated
         documentation files (the "
famous  "All human beings are born free"
     -> "and equal in dignity and rights. The right to life, liberty, and security"
fresh   "All evaluation harnesses are born tiny"
     -> ", and the most common way to measure their size is by using a ruler."

Trois des cinq chaînes célèbres ont continué mot pour mot à partir de six mots ; aucune des cinq chaînes fraîches ne l’a fait. Voilà un modèle d’un demi-milliard de paramètres qui récite la licence MIT. Si votre benchmark est sur le web public, partez du principe qu’il est dans les weights. C’est aussi l’argument de tout le chapitre : un golden set que vous avez écrit à partir de vos propres données, gardé hors de tout dépôt lu par un crawler, est le seul test set dont vous pouvez être sûr qu’il n’a jamais été utilisé pour l’entraînement.

Ils valent toujours la peine d’être lus, à condition de lire ce que chacun mesure plutôt que le nombre unique qui lui est attaché.

Prenez le tableau plutôt qu’une seule ligne. Les benchmarks agentiques placent tous les humains très au-dessus des modèles, ce qui est l’inverse des benchmarks de connaissances et le meilleur résumé en une ligne de l’état du domaine ; leurs chiffres vieillissent en quelques mois, donc citez-les avec la date à laquelle vous les avez lus ; et chacun mesure une tâche qui n’est pas la vôtre.

L’accuracy est la métrique sur laquelle on débat. Celles-ci sont celles qui décident si la chose est livrée. Les quatre sortent des deux cents exécutions déjà mesurées.

Coût par tâche résolue, pas par appel. L’agent coûte $0,001345 par tentative et $0,005172 par tâche réellement résolue — 3,85 fois plus, parce que les trois quarts des tentatives ne produisent rien. La latence se comporte de la même façon : 1 213 ms par tentative, 4 667 ms par tâche résolue. Chaque retry, chaque re-question, chaque trajectoire abandonnée est dans le second nombre et invisible dans le premier.

Un diagnostic qui bat l’accuracy. Dans 123 tentatives sur 200, l’agent a répondu sans appeler un seul outil — il a deviné au lieu de regarder. En divisant selon ce critère :

answered without reading anything   8/123  =  6.5 %  [3.3, 12.3]
answered after reading something   44/77   = 57.1 %  [46.0, 67.6]

Les intervalles sont loin de se toucher. Cela vaut plus que l’agrégat à 26 %, parce que cela nomme ce qu’il faut corriger — le modèle n’échoue pas à raisonner, il échoue à regarder — et le correctif est dans le harness, pas dans le modèle. Une réserve que ce chapitre doit à ses propres standards : les deux groupes sont des tâches différentes, pas les mêmes tâches appariées, donc une partie de cet écart peut venir du fait qu’il saute les outils précisément sur les questions qu’il trouve difficiles. La division est un diagnostic, pas une affirmation causale.

Le taux d’intervention humaine est la métrique qu’un acheteur demande en premier : quelle fraction des exécutions s’est arrêtée sur une approbation, un guardrail ou un handoff. Les interruptions typées du chapitre 23 le rendent comptable, et compté par type de tâche et par semaine, c’est ce qui sépare un agent qui apprend son travail d’un agent qui devient silencieusement une file d’attente.

L’abandon est celui qu’aucune suite hors ligne ne peut voir : l’utilisateur qui a lu la réponse, fermé l’onglet et fait la tâche lui-même. L’évaluation hors ligne est une porte ; l’évaluation en production est un échantillon continu du trafic réel, noté avec le même évaluateur plus ces quatre métriques.

Et une règle héritée du chapitre 17 : n’assert jamais sur la sortie exacte. Assertez sur des propriétés — JSON valide, schéma correct, bon outil appelé, nombre dans une tolérance, sous-chaîne requise présente. La colonne de correspondance exacte au début de ce chapitre montre ce qui arrive quand cette règle est enfreinte.

Évaluer un fournisseur ne concerne pas seulement l’accuracy, et c’est la seconde moitié de l’éthique de ce cours, avec son propre titre plutôt qu’une annexe.

Mesurez le biais, ne le supposez pas. Quoi que vous croyiez du comportement d’un modèle sur les noms, dialectes, genres ou nationalités, c’est une propriété mesurable de votre pipeline, et l’instrument est celui que vous avez déjà : prenez votre golden set, ne variez que l’attribut, comparez par paires. HELM existe précisément parce que l’accuracy seule était rapportée là où le biais, la toxicité, la calibration et la robustesse étaient également décidables.⁸ La model card d’un fournisseur est un point de départ, pas une preuve sur vos entrées.

La contamination est aussi une question fournisseur. La sonde ci-dessus est la raison de demander sur quoi un nombre publié a été mesuré, et à quelle date les données du modèle ont été coupées.

Rétention, entraînement et résidence, lus le 7 septembre 2026. Ces éléments changent, donc notez la date à côté de la réponse. La page de politique d’Anthropic indique : « Par défaut, nous n’utiliserons pas vos entrées ou sorties issues de nos produits commerciaux (par exemple Claude for Work, Anthropic API, Claude Gov, etc.) pour entraîner nos modèles », à l’exception du contenu que vous soumettez explicitement comme feedback, qui est stocké « jusqu’à 5 ans ».¹⁶ La documentation des contrôles de données d’OpenAI indique que « les données envoyées à l’OpenAI API ne sont pas utilisées pour entraîner ou améliorer les modèles OpenAI (sauf si vous acceptez explicitement de partager des données avec nous) », décrit une rétention par défaut de trente jours pour les logs de surveillance des abus, et propose Zero Data Retention, qui « exclut le contenu client des logs de surveillance des abus », ainsi qu’une résidence des données configurable sur une liste de régions.¹⁷

Quatre questions à obtenir par écrit avant le premier appel de production, parce que chacune a un propriétaire différent : mes données sont-elles utilisées pour l’entraînement ; combien de temps sont-elles conservées et par qui ; où sont-elles traitées et stockées ; et qu’advient-il de tout cela si j’utilise un revendeur, une passerelle ou un agrégateur plutôt que le fournisseur directement. C’est dans cette dernière question que vivent la plupart des surprises, et aucun benchmark ne vous le dira.

Vous avez maintenant l’instrument : un golden set qui vous appartient, un intervalle sur chaque nombre, un test apparié pour chaque comparaison, pass^k pour les exécutions que vous n’avez montrées à personne, un juge mesuré, et une sonde pour savoir si un score public signifie quelque chose. L’affirmation finale du chapitre 23 peut maintenant être vérifiée au lieu d’être assertée — un harness rend un agent gouvernable, pas correct — et la vérifier a pris deux cents exécutions et huit minutes.

Il existe une propriété d’un agent que rien de tout cela ne mesure, et c’est celle qui fait licencier des gens.

Chaque tâche du golden set de ce chapitre a été écrite par moi, et chaque fichier que l’agent a lu a été écrit par moi. Rien dans ce répertoire n’essayait de faire quoi que ce soit. Changez une ligne dans un fichier qu’on dit à l’agent de lire — une ligne qui se termine par une instruction adressée à ce qui la lira ensuite — et l’agent qui a obtenu 26 % la suivra avec les mêmes outils, les mêmes permissions et la même trace propre, et tous les nombres de ce chapitre resteront exactement où ils sont. Une suite d’évaluation mesure à quelle fréquence un système atteint votre objectif. Elle ne mesure pas avec quelle facilité quelqu’un d’autre peut y substituer le sien.

Le chapitre 30, c’est cela : la prompt injection, la trifecta létale des données privées, du contenu non fiable et de la communication externe, et ce qu’il en coûte de donner de vraies permissions à un agent. Il s’ouvre sur l’observation que ce chapitre a évitée — à savoir que le même score de réussite est compatible avec un agent qui fait exactement ce qu’un attaquant a écrit dans un fichier qu’on lui a dit de lire.

Tous les nombres ci-dessus ont été produits sur une seule machine et aucun n’a touché un endpoint payant. L’agent est la boucle du chapitre 23 avec deux de ses quatre outils sur un répertoire de cinq fichiers ; le modèle derrière le port est Qwen/Qwen2.5-0.5B-Instruct, exposé via un petit serveur de la même forme qu’un endpoint de chat completions exactement comme au chapitre 23, mais en demi-précision sur un GPU grand public plutôt que sur le CPU de ce chapitre. Les coûts utilisent les tarifs du chapitre 16 — $2,00 par million de tokens d’entrée et $12,00 par million de sortie — appliqués aux comptes de tokens mesurés. Les exécutions répétées utilisent une température de 0,7 avec des graines fixes afin que l’ensemble se reproduise ; le tableau à quatre bras est greedy. Les intervalles sont des Wilson à 95 %, les comparaisons appariées sont des tests exacts bilatéraux des signes sur les paires discordantes ; l’intervalle de Wilson est celui du chapitre 4 et le test exact apparié des signes celui du chapitre 15, tous deux réutilisés sans changement. Les étiquettes humaines sont les miennes, appliquées à soixante réponses selon la règle écrite citée dans le texte. Lisez chaque ordre de grandeur ici comme une propriété d’un modèle d’un demi-milliard de paramètres et chaque méthode comme transférable : un plus grand modèle fait monter tous les nombres et ne déplace aucun des instruments.