Un benchmark est un contrat avec un dénominateur.

Les performances ne sont utiles que si le nombre reste associé à la charge de travail, au périmètre, au matériel, à la condition de qualité, à la référence...

Un benchmark est un contrat avec un dénominateur.

Le nombre qui oublie son dénominateur

Un résultat de benchmark peut être mesuré correctement et répondre néanmoins à la mauvaise question. Le coupable habituel n'est pas un minuteur défectueux ni un ingénieur malhonnête. C'est le dénominateur qui a disparu entre le banc d'essai et la diapositive de présentation. « Deux fois plus rapide » ressemble à une comparaison, mais cela ne précise pas deux fois plus rapide pour quel travail, sur quelle machine, avec quel logiciel, sous quelle condition de qualité, par rapport à quelle référence, ni pour quels utilisateurs. Retirez ces conditions et un chiffre de performance devient un fragment poli. Il peut rester numériquement vrai. Il ne dit plus à un acheteur ou à un opérateur ce qu'il peut attendre.

Le dénominateur est le travail par rapport auquel le résultat est exprimé. Pour le débit, c'est le travail accompli et le temps pendant lequel cet accomplissement est compté. Pour la latence, c'est la définition de la requête, le chemin inclus et la population des observations. Pour la précision, c'est l'ensemble étiqueté, la règle d'étiquetage et l'unité évaluée. Pour l'énergie, c'est la limite du système mesuré et le travail fourni à l'intérieur de cette limite. Pour le coût, c'est la période de coût, les ressources incluses et le volume de travail utile. Un benchmark est honnête lorsque son numérateur et son dénominateur voyagent ensemble.

C'est pourquoi un benchmark est mieux traité comme un contrat. Le contrat nomme la question, la charge de travail, le périmètre, le matériel et le logiciel, la métrique, la référence, l'incertitude et la méthode par laquelle une autre partie pourrait vérifier le résultat. Un contrat peut être étroit. Il peut être exploratoire. Il peut n'être utile que pour un seul déploiement. Ce qu'il ne peut pas être, c'est un chiffre impressionnant dont les conditions sont laissées à la devinette du lecteur. Deviner est une mauvaise façon d'allouer l'argent public, et une façon encore plus mauvaise de concevoir un service que quelqu'un d'autre doit maintenir en vie.

L'habitude européenne d'écrire les définitions est parfois moquée comme de la paperasse. Dans le travail de mesure, les définitions sont ce qui empêche la paperasse de devenir du folklore. Le tableau de benchmark n'est pas une annexe administrative au résultat. C'est la carte d'identité du résultat.

Lisez l'unité avant le titre

Commencez par l'unité, mais ne vous arrêtez pas là. Les requêtes par seconde, les tokens par seconde, les millisecondes, les joules par requête, les euros par millier de dossiers et les points de pourcentage vous disent tous quelque chose. Aucun ne vous dit ce qu'on a demandé au système de faire. Un résultat de 100 requêtes par seconde peut décrire de petites requêtes en cache ou de grandes requêtes non mises en cache qui incluent la récupération, la validation et une remise à un humain. Une latence de 20 millisecondes peut couvrir un seul noyau ou un chemin de décision entier. L'unité est une porte. La charge de travail est la pièce derrière elle.

Supposons qu'une diapositive d'appel d'offres dise qu'un nouveau service est 40 pour cent plus rapide que l'existant. La phrase n'est pas encore une preuve. Elle a besoin au moins de l'opération chronométrée, de la taille et de la distribution des entrées, du travail exclu du chronomètre, de la concurrence, de l'état d'échauffement, des versions logicielles, du matériel et de la configuration de référence. Elle a aussi besoin de la condition de qualité. Si le chemin plus rapide renvoie moins de résultats valides, abandonne les entrées longues ou saute une étape de vérification coûteuse, le numérateur a été réduit en changeant le travail.

Ce n'est pas une demande de tableau énorme avant que quiconque puisse parler. C'est une demande d'identifier les quelques champs qui changent le sens de l'affirmation. Un petit benchmark de parseur peut nécessiter la forme des enregistrements, la source d'entrée, la politique de validation, le compilateur et le processeur. Un benchmark d'inférence peut nécessiter le modèle, la précision, le lot, le scénario, la cible de qualité et la limite de puissance. Une file d'attente du secteur public peut nécessiter la définition du cas, l'horloge du service, la règle d'acheminement et le chemin d'escalade. Les champs diffèrent. L'obligation de les nommer, elle, ne diffère pas.

Il y a ici une discipline utile : écrire le résultat sous la forme d’une phrase qui pourrait survivre à une seconde lecture. « Sous cette charge de travail et cette exigence de qualité, sur ce système et cette version, la valeur mesurée était celle-ci, avec cette variation. » Si la phrase ne peut pas être complétée sans des mots comme typique, meilleur, proche de la production ou représentatif, la méthode n’est pas terminée. Ces mots peuvent être valides, mais ils ont besoin d’une définition opérationnelle, pas d’un ton chaleureux.

Une carte de référence n’est pas une décoration autour d’un chiffre. C’est la forme la plus petite et la plus utile du contrat de ce chiffre.

Le périmètre fait partie du résultat

Le périmètre répond à une question simple : que couvre ce résultat, et qu’est-ce qui reste hors du cadre ? Dans l’évaluation en apprentissage automatique, le périmètre comprend la tâche, le jeu de données, la répartition, la langue, la longueur des entrées, le scénario d’exploitation et les choix d’implémentation autorisés. Dans un service logiciel, il comprend la route, les magasins de données, le réseau, le cache et le travail qu’une équipe en aval effectue après le retour de la mesure. Un résultat mesuré sur une couche ne devrait pas devenir silencieusement une promesse sur l’ensemble du service.

MLCommons rend cela visible dans sa documentation MLPerf Inference. Le guide de soumission sépare les types de systèmes datacentre et edge, énumère des scénarios tels que offline, server, interactive, single-stream et multi-stream, et distingue une division fermée d’une division ouverte. La division fermée est destinée à une comparaison de type pommes avec pommes utilisant le même modèle et la même configuration de référence. La division ouverte autorise des choix tels que le réentraînement ou la substitution du modèle. Aucune des deux n’est la division universellement correcte. Elles répondent à des questions différentes. Un titre qui les mélange n’est pas une vue d’ensemble. C’est une erreur de catégorie avec une excellente typographie.

La même documentation montre pourquoi une référence a besoin d’un côté qualité explicite. Une entrée ResNet50 listée nomme l’ensemble de validation ImageNet-2012, ses tailles de jeu de données et de liste d’échantillons de requêtes, une précision de référence et une contrainte de latence serveur. Pour l’entrée ResNet50 listée, la page donne un ensemble de validation de 50 000 images, une liste d’échantillons de requêtes de 1 024, une précision de référence de 76,46 pour cent et une contrainte de latence serveur de 15 ms. Ces champs ne sont pas des détails pour les personnes qui aiment lire les règles. Ils expliquent ce que la vitesse rapportée était autorisée à signifier. Changez le jeu de données, le scénario ou l’exigence de qualité et la comparaison a changé, même si le nom du modèle semble familier.

Un acheteur européen devrait se méfier d’un périmètre implicite dans une étiquette de produit. « Plateforme IA », « accélérateur » et « qualité entreprise » ne définissent pas le travail. Un système excellent dans une opération bornée peut être exactement ce dont un service a besoin. Un système qui prétend tout couvrir peut avoir mesuré presque rien qui ressemble au service. Une vérité étroite est plus saine qu’un brouillard universel.

La couverture change le sens

La couverture n’est pas une note de bas de page sur la taille de l’ensemble de test. Elle décrit quels cas et quelles situations entrent dans la mesure. Un benchmark peut couvrir de nombreux exemples issus d’une distribution étroite et en dire pourtant très peu sur les cas limites qui comptent en exploitation. À l’inverse, un petit ensemble soigneusement sélectionné peut révéler un mode de défaillance important sans étayer une affirmation générale de performance. Ce choix est une décision de conception. Il doit être présenté comme tel.

Le cadre de l’OCDE pour caractériser les instruments d’évaluation de l’IA est utile parce qu’il refuse de réduire une évaluation à un score unique. Il propose 18 facettes, notamment la couverture, la finalité, le réalisme, la validité, la fiabilité, la transparence et les conditions dans lesquelles les résultats peuvent être interprétés. La couverture demande si l’évaluation représente ce qu’elle entend mesurer. La finalité distingue un benchmark destiné à la recherche d’un benchmark destiné à la conformité ou à un autre usage. Le réalisme demande si le cadre est un problème jouet, un environnement simulé ou de laboratoire, ou la vie réelle. Ces distinctions n’affaiblissent pas un benchmark. Elles rendent son affirmation lisible.

La couverture inclut aussi les cas qu’une évaluation exclut. Un service peut rapporter une latence moyenne après avoir retiré les délais d’attente dépassés. Un classifieur peut rapporter une exactitude après avoir écarté les étiquettes ambiguës. Un système de recherche peut ne compter que les requêtes ayant au moins un document pertinent. Un pipeline d’images peut ignorer les fichiers corrompus. Chaque exclusion peut être défendable. Le résultat doit indiquer ce qui a été retiré et pourquoi. Sinon, le dénominateur devient silencieusement une liste de cas qu’il était commode de traiter.

C’est ici que le dénominateur devient politique, avant même que quiconque prononce le mot. La population incluse bénéficie d’être mesurée. La population exclue reçoit un récit sur un système qui ne la décrit peut-être pas. Les institutions publiques européennes connaissent déjà cela grâce aux statistiques officielles. Le Code de bonnes pratiques de la statistique européenne d’Eurostat établit 16 principes et 84 indicateurs pour l’environnement institutionnel, les processus et les produits. Son cadre d’assurance de la qualité fournit des méthodes et des outils, tandis que les rapports sur la qualité indiquent aux utilisateurs comment les données ont été collectées et validées. Le message pour l’IA n’est pas que chaque modèle doit devenir un office statistique. Il est qu’un nombre destiné aux décisions publiques a besoin d’un récit visible de production et de qualité.

L’exactitude n’est pas une porte unique

Les affirmations de performance associent souvent la vitesse à un seul chiffre de qualité, puis traitent la paire comme complète. La qualité est généralement une famille de questions. Le résultat répond-il à la définition de la tâche ? Préserve-t-il les contraintes requises ? Échoue-t-il en toute sécurité lorsque des preuves manquent ? Se comporte-t-il de manière acceptable sur la population concernée ? Reste-t-il dans les limites de qualité lorsque le système est chargé ? Une réponse rapide qui échoue à la tâche n’est pas une solution plus rapide. C’est une charge de travail différente portant le même nom.

La structure de MLPerf est instructive parce que ses exécutions de performance côtoient la validation de l’exactitude et des exigences spécifiques au modèle. Le guide de soumission indique aux participants d’identifier la division, le type de système et le scénario, d’exécuter le benchmark prévu, de valider l’exactitude par rapport aux seuils, puis de préparer une soumission vérifiée. La page du benchmark liste l’exactitude de référence et les conditions de latence ou de débit pour chaque tâche. La séparation est pratique. Elle empêche un système de gagner la colonne performance en perdant silencieusement la tâche.

L’exactitude elle-même a besoin d’un dénominateur. « Exact à quatre-vingt-dix-huit pour cent » peut signifier un pourcentage d’enregistrements, de jetons, d’images, de requêtes ou de décisions. Cela peut utiliser une moyenne micro ou macro. Cela peut compter une abstention comme une erreur, comme un refus sûr, ou comme un résultat non mesuré. Cela peut comparer à des étiquettes créées par un ou plusieurs examinateurs. Une fiche de benchmark doit nommer l’unité, la règle d’étiquetage, l’agrégation, la confiance ou la variation, et tout seuil qui transforme une mesure en décision de publication.

Ne considérez pas un chiffre de qualité comme un laissez-passer décoratif. Un modèle peut atteindre un seuil publié et rester inadapté à un service particulier, car la tâche, la population ou le profil de préjudice diffère. À l’inverse, un score agrégé plus faible peut être acceptable pour un outil de rédaction qui maintient un humain comme auteur, alors que le même score est inacceptable pour une porte automatique. La qualité est une relation entre la sortie, l’objectif et la conséquence.

Le temps n’est pas un nombre unique

La latence est souvent présentée comme si un système avait une seule vitesse. Les systèmes réels ont une distribution. La première requête peut payer le coût de démarrage. Un cache peut modifier les requêtes suivantes. Les utilisateurs simultanés peuvent se disputer la mémoire ou une connexion à la base de données. Une entrée longue peut emprunter un chemin différent d’une entrée courte. La moyenne peut s’améliorer tandis que la queue se dégrade. Si la queue est l’endroit où un service manque son délai, la moyenne est une distraction avec une unité.

Un rapport de latence utile indique ce qui a été mesuré et comment les observations ont été résumées. Il peut inclure une médiane, des percentiles supérieurs, le taux de dépassement de délai et le nombre de requêtes. Il doit préciser si les requêtes d’échauffement ont été exclues, si les nouvelles tentatives ont été incluses et si le temps de file d’attente ou de réseau appartient au chemin mesuré. Ces choix ne sont pas interchangeables. Un benchmark de composant peut être précieux, mais il ne doit pas être présenté comme un comportement de bout en bout.

Le débit a un piège similaire. Un taux élevé peut être obtenu en traitant par lots, en augmentant la concurrence ou en assouplissant une exigence de qualité. Cela peut être tout à fait approprié pour un travail hors ligne. Cela peut être inutile pour un service interactif qui doit répondre à chaque requête dans un délai. Le benchmark doit indiquer le scénario et le point de fonctionnement, puis expliquer ce qui se passerait lorsque la demande s’en éloigne. Il n’y a aucune honte à avoir un point de fonctionnement étroit. Il y a de la honte à prétendre qu’il représente toute la carte.

Le temps a aussi un côté humain. Un service qui répond rapidement mais qui crée davantage de travail de révision, de correction ou d’appel peut être plus lent du point de vue de l’institution. Un benchmark qui arrête le chronomètre avant la remise peut donner l’impression que le système mesuré est rapide alors que le service réel accumule une file d’attente. Le dénominateur doit suivre le travail jusqu’à ce que la question posée soit répondue. Sinon, le chronomètre mesure une île.

Le matériel et le logiciel font partie du numérateur

« Sur un serveur » n’est pas un environnement reproductible. La génération du processeur, le jeu d’instructions, l’accélérateur, la mémoire, le stockage, l’état thermique, la limite de puissance, le système d’exploitation, le pilote, le compilateur, l’environnement d’exécution, la bibliothèque et la configuration peuvent tous modifier un résultat. Il en va de même pour un format de modèle, un réglage de quantification, une taille de lot, une sélection de noyau ou une politique de threads. Le benchmark n’a pas besoin de lister chaque câble. Il doit identifier les éléments qui peuvent modifier la mesure.

MLPerf appelle l’ensemble de la configuration mesurée le système sous test et organise les résultats par type de système et catégorie de disponibilité. Ce vocabulaire est utile au-delà de MLPerf. Un système sous test a une frontière. La frontière indique quel matériel et quel logiciel sont inclus, quels services sont externes et quel travail est omis. Une mesure de puissance prise au mur a une signification différente d’une mesure qui ne compte qu’un accélérateur. Une latence mesurée à l’intérieur d’un noyau a une signification différente de celle qui inclut la planification des requêtes.

Les versions comptent car un benchmark est une comparaison entre des états, et non une propriété intemporelle d’un nom de produit. Enregistrez la version du modèle ou de l’application, les versions des dépendances, les drapeaux du compilateur, le pilote et le firmware lorsqu’ils affectent le résultat. Enregistrez la configuration qui a sélectionné un backend ou une précision. Si un environnement d’exécution choisit un noyau différent sur une autre machine, cela fait partie du résultat, et non un détail d’implémentation à ranger plus tard.

La divulgation du matériel n'est pas une invitation à transformer un article de blog en catalogue de pièces détachées. C'est un moyen d'éviter les fausses équivalences. Un acheteur n'a pas besoin de s'intéresser à chaque détail si la promesse porte sur un service complet. En revanche, il doit savoir si la comparaison inclut le même travail, la même précision, le même cheminement des données et un système réellement accessible et exploitable dans le contexte européen visé.

Les références sont des engagements

Une référence est la comparaison qui donne une direction au résultat. Sans elle, un chiffre peut décrire un système, mais pas une amélioration. La référence doit répondre à la même question dans des conditions comparables. Si le nouveau parcours utilise un compilateur plus récent, une distribution des données différente ou un objectif de qualité différent, le résultat peut rester intéressant, mais la comparaison n'est plus propre. Dites ce qui a changé. Le lecteur pourra alors décider si la différence est utile.

Le choix de la référence relève de l'interprétation. Comparer avec le système en place que les utilisateurs exécutent réellement, avec une implémentation de référence, avec une version précédente ou avec une limite théorique, et vous apprendrez des choses différentes. Un nouveau système peut être meilleur que la référence et moins bon que le service qu'il remplace. Il peut être plus rapide sur un test propre et plus lent une fois la validation et le stockage inclus. Le banc d'essai doit nommer la référence et expliquer pourquoi elle répond à la question opérationnelle.

Des exécutions appariées sont souvent plus instructives qu'un seul tour de victoire. Gardez la charge de travail et la définition de l'évaluation fixes, modifiez un seul facteur matériel et notez la différence. Si plusieurs facteurs changent ensemble, décrivez la comparaison comme un ensemble plutôt que d'attribuer tout l'effet à un seul composant. Cela semble évident jusqu'à ce qu'une mise à niveau, une actualisation des données et une nouvelle politique de cache arrivent dans la même version. Le graphique a alors une seule flèche et trois causes possibles, ce qui est un petit mystère dont personne n'avait prévu le budget.

Une référence a aussi une durée de vie. Un flux de données, un fournisseur, un modèle, une politique ou une plateforme matérielle peuvent évoluer. La comparaison reste valable pour les versions et la période testées. Elle ne doit pas être réutilisée comme une garantie actuelle sans vérifier le contrat. C'est là que l'historique des versions montre toute sa valeur. Un résultat dépassé n'est pas un échec. C'est une affirmation historique dont les conditions doivent rester visibles.

L'incertitude n'est pas une excuse

Chaque mesure contient de la variation. Une partie provient du système, une autre de la charge de travail et une autre du processus de mesure. Des exécutions répétées peuvent la révéler, mais la répétition seule n'explique pas la cause. Un cache chaud peut être stable. Un voisin bruyant peut ne pas l'être. Un petit ensemble d'évaluation peut produire une large gamme de résultats plausibles. Un ensemble plus grand peut réduire le bruit d'échantillonnage tout en laissant une population biaisée intacte. L'incertitude indique au lecteur jusqu'où le résultat peut raisonnablement voyager.

Présentez l'incertitude sous une forme adaptée à la promesse. Cela peut être une plage sur des exécutions répétées, un intervalle de confiance, une erreur standard, une distribution des latences, une analyse de sensibilité ou une liste des limites connues. N'ajoutez pas un intervalle de confiance parce que le tableau semble vide. Indiquez ce qui a été répété, ce qui a été maintenu fixe et ce que l'intervalle représente ou ne représente pas. Le langage statistique n'est pas un sortilège. C'est un contrat sur la variation.

Il existe un deuxième type d'incertitude que les chiffres ne peuvent pas éliminer : l'incertitude quant à savoir si la mesure représente réellement le service visé. Un résultat peut présenter une variation minime d'une exécution à l'autre et une mauvaise couverture du monde réel. Un banc d'essai peut être parfaitement reproductible en laboratoire tout en ignorant les langues, les formats de saisie, les schémas de rotation ou les conséquences des pannes du déploiement. Un faible bruit de mesure ne crée pas la validité. Il rend simplement la mauvaise question plus systématiquement répondue.

L’incertitude doit donc figurer à côté de l’affirmation, et non dans une clause de non-responsabilité en bas de page. Si un seuil est proche de la limite mesurée, cela compte. Si un résultat change sensiblement selon la composition des données d’entrée, cela compte. Si le bilan énergétique exclut le refroidissement ou le déplacement des données, cela compte. La phrase honnête est peut-être moins triomphale, mais elle donne au décideur mieux que de l’optimisme : un endroit où placer la prudence.

La reproduction est une chaîne, pas un bouton de téléchargement

La reproductibilité est souvent réduite à la publication du code. Le code compte. Il n’est qu’un maillon de la chaîne. Une seconde partie a aussi besoin de la charge de travail ou d’une description légale de celle-ci, de la version des données, de la configuration, de l’environnement, de la commande ou du harnais, de la politique relative à l’état aléatoire, de la règle de sortie attendue, du fichier de résultats et de la méthode utilisée pour décider si l’exécution concorde. Si un maillon manque, la seconde partie peut reproduire une expérience similaire plutôt que celle qui a été rapportée.

La chaîne doit distinguer la relecture exacte de la réplication indépendante. La relecture exacte utilise l’artefact capturé, l’état, les entrées, la configuration et le chemin d’exécution pour vérifier si la même exécution peut être reconstruite. La réplication indépendante utilise un environnement préparé séparément pour tester si le résultat survit en dehors de la machine ou de l’équipe d’origine. Les deux sont précieuses. Elles répondent à des questions différentes. Un résultat identique octet pour octet sur une entrée capturée prouve une forte affirmation d’identité concernant cette exécution. Cela ne prouve pas que le monde réel restera inchangé.

Le cadre d’évaluation de l’OCDE rend cette distinction plus facile à voir en traitant la finalité, le réalisme, la couverture et la fiabilité comme des facettes distinctes. Une évaluation peut être excellente pour les tests de régression et médiocre pour estimer les performances d’un service en conditions réelles. Elle peut être utile pour la recherche et inadaptée à la conformité. La reproduction n’efface pas la finalité. Elle aide le lecteur à vérifier l’affirmation que la méthode soutient réellement.

Pour les données qui ne peuvent pas être publiées, publiez la limite et le parcours. Décrivez la population, le processus d’échantillonnage, la méthode d’étiquetage, les règles d’exclusion et les contrôles de validation. Fournissez un paquet de reproduction sûr lorsque c’est possible, et expliquez ce qui reste protégé. « Les données sont confidentielles » est une limite légitime, pas une méthode achevée. Un lecteur doit encore pouvoir comprendre ce qui a été mesuré et pourquoi le résultat devrait ou ne devrait pas être généralisé.

La reproduction n’est pas un bouton intitulé « relancer ». C’est une chaîne d’identités qui permet à une autre équipe de contester l’affirmation.

Les institutions publiques doivent refuser le théâtre de la démonstration

Les institutions publiques n'ont pas besoin de rejeter les benchmarks. Elles doivent refuser ceux qui ne peuvent pas énoncer leur contrat. Une démonstration soignée peut aider un comité à comprendre une possibilité. Elle ne peut pas remplacer les preuves concernant le service que l'institution doit faire fonctionner, les personnes qu'elle sert et les défaillances qu'elle doit réparer. La distinction importe parce qu'une démo est optimisée pour une rencontre brève, tandis qu'un service public est jugé au fil des saisons, des changements de personnel, des recours, de la maintenance et du droit.

Avant d'acheter, demandez au fournisseur de définir la charge de travail dans le langage du service. Qu'est-ce qui entre dans le système ? Qu'est-ce qui est mesuré ? Qu'est-ce qui est exclu ? Quelle règle de qualité doit tenir ? Quel rôle humain examine un résultat ? Comment détecte-t-on la dérive ? Comment l'institution peut-elle exporter ses preuves ? Que se passe-t-il lorsque le modèle, la source, le fournisseur ou la politique change ? Par rapport à quelle version fait-on la comparaison ? Quel est le chemin de retour arrière ? Un fournisseur peut répondre à certaines questions par un contrat, à d'autres par un test, et à d'autres encore par une limite honnête. Ce mélange est plus sain qu'une réponse faite entièrement d'adjectifs.

Le règlement européen sur l'IA exprime ce point en langage juridique pour les systèmes à haut risque. L'article 15 exige un niveau approprié d'exactitude, de robustesse et de cybersécurité, avec des performances constantes à ces égards tout au long du cycle de vie. Un benchmark ne peut pas, à lui seul, établir l'ensemble de l'obligation légale. Il peut étayer une partie des preuves si son périmètre, ses conditions de qualité et sa position dans le cycle de vie sont clairs. Traiter un score comme une conformité serait une autre erreur de dénominateur. La loi nomme le résultat ; l'ingénierie doit montrer le chemin.

L'achat public devrait aussi demander qui possède le benchmark après l'attribution. Un test préparé par un fournisseur peut être utile, mais l'institution a besoin de suffisamment d'informations pour surveiller le système dans son propre contexte. Elle a besoin d'une référence de base qui puisse être relancée lorsqu'une version change, d'un chemin de révision lorsque les résultats évoluent et d'un enregistrement des décisions prises concernant les performances acceptables. Sinon, le premier benchmark est un examen d'entrée et le système de production est autorisé à obtenir son diplôme sans autres questions.

Rendre la fiche de benchmark assez petite pour être utilisée

Les méthodes longues peuvent être nécessaires. Elles ne sont pas toujours la première chose dont un lecteur a besoin. Une fiche de benchmark est un index compact du contrat. Elle peut se trouver à côté d'un résultat dans un rapport, un registre d'évaluation ou un dossier d'achat. La fiche doit nommer la question, la charge de travail, le périmètre, le système, la métrique, l'exigence de qualité, la référence de base, l'incertitude, le chemin de reproduction, le propriétaire et le déclencheur d'expiration ou de changement. La méthode détaillée peut se trouver derrière. La fiche empêche l'affirmation de voyager seule.

Les bonnes fiches sont sélectives plutôt que surchargées. Elles mettent en avant les champs qui peuvent changer l'interprétation, puis renvoient au dossier de preuves. Une fiche de latence pourrait mettre en avant la taille des entrées, la concurrence, le percentile, l'échauffement, la version et la règle de délai d'attente. Une fiche d'énergie pourrait mettre en avant la limite du système, la charge de travail, l'instrument de mesure, la durée et l'infrastructure exclue. Une fiche d'exactitude pourrait mettre en avant la population, la règle d'étiquetage, l'agrégation, le traitement de l'abstention et la gravité des erreurs. La forme commune n'est pas un modèle fixe. C'est une promesse que le lecteur peut trouver le dénominateur.

La fiche doit indiquer le statut épistémique. La valeur est-elle mesurée, estimée, attendue, proposée ou illustrative ? La référence de base est-elle à jour ? La suite d'évaluation est-elle préparée mais pas encore exécutée ? Les résultats sont-ils protégés parce que le matériel de test contient des données personnelles ? Ces étiquettes empêchent qu'une méthode soit confondue avec un résultat. Elles permettent aussi à une organisation de publier des progrès sans fabriquer de succès. Un test préparé est une information utile. Ce n'est pas une preuve que le système l'a réussi.

Enfin, donnez une propriétaire et une règle de modification à la carte. Un résultat sans propriétaire se dégrade en diapositive. Un résultat sans règle de modification reste sur le mur après que la charge de travail a évolué. La propriétaire n'a pas à défendre le nombre éternellement. Elle doit dire quand l'affirmation doit être relancée, retirée ou restreinte. La mesure fait partie des opérations lorsque quelqu'un a l'autorité de la maintenir honnête.

Deux façons honnêtes de publier un résultat

Il existe deux modes de publication courants. Le premier est une comparaison stricte. Il fixe la tâche, les données, la règle de qualité, la limite du système et la référence afin qu'un lecteur puisse comparer les alternatives. Le second est une mesure exploratoire. Il demande ce qui se passe lorsqu'un design, une charge de travail ou un environnement change, et il rapporte les observations avec leurs limites. Le travail exploratoire peut être précieux avant qu'une référence stricte n'existe. Il ne doit pas emprunter le langage d'un résultat de conformité.

Les comparaisons strictes sont exigeantes car elles rendent les différences visibles. Si une équipe change le modèle et le matériel ensemble, il peut être impossible d'attribuer le résultat. Si une nouvelle charge de travail est plus réaliste mais ne correspond plus à la référence, l'affirmation doit être reformulée comme une nouvelle mesure. Si une optimisation améliore la vitesse tout en modifiant la qualité de sortie, rapportez les deux côtés. La discipline ne consiste pas à empêcher le progrès. Elle consiste à empêcher qu'une histoire de progrès n'efface la condition qui l'a rendue possible.

Les mesures exploratoires nécessitent leur propre honnêteté. Dites que l'échantillon est petit, que l'environnement est provisoire, que la charge de travail est synthétique, que le résultat n'a pas été reproduit indépendamment ou que le contrôle de qualité est incomplet. Ce ne sont pas des faiblesses à cacher jusqu'à une publication soignée. Ce sont les informations qui aident un lecteur à décider quoi faire ensuite. Une culture d'ingénierie européenne n'a pas besoin de prétendre que chaque test est un verdict final. Elle doit cesser d'appeler une question résolue avant que le test n'ait été lu.

Les deux modes bénéficient d'une archive de résultats. Gardez les anciennes définitions, configurations et résultats identifiables. Enregistrez la supersession plutôt que de supprimer le passé. Une référence modifiée peut être la bonne référence pour un service modifié, mais elle ne peut pas être utilisée pour réécrire le sens de l'ancien résultat. L'historique des versions est la mémoire du dénominateur.

Notre petite note

Chez Dweve, nous décrivons Core avec une cellule d'exécution et un contrat de déterminisme. La partie utile de ce vocabulaire n'est pas le nom du produit. C'est l'insistance sur le fait qu'une opération porte sa représentation numérique, son backend, son jeu d'instructions, sa politique de répartition et sa posture de relecture comme faisant partie du chemin évalué. C'est la même habitude qu'une référence nécessite : garder les conditions attachées au résultat au lieu de décrire la performance comme si elle flottait au-dessus du système.

Ceci est une petite note de conception, pas une affirmation concernant un déploiement externe ou un résultat mesuré. La leçon plus large ne dépend pas de Dweve. Que le système soit un service statistique public, un contrôleur industriel, un outil linguistique ou un prototype de recherche, un nombre gagne la confiance en nommant son travail et ses limites. Notre propre documentation est simplement un endroit où nous essayons de rendre cette limite explicite.

Le dénominateur est la partie qui voyage

Un titre de référence est facile à copier. Le dénominateur est plus difficile à transporter, c'est pourquoi il est souvent laissé de côté. Un acheteur copie un chiffre de débit dans un dossier d'affaires. Un régulateur voit un score de précision dans un dossier. Un ingénieur compare deux graphiques de différentes charges de travail. Un journaliste répète un pourcentage sans la population. Chaque lecteur reçoit un nombre qui a perdu le contrat qui le rendait significatif.

La réparation n’est pas compliquée, même si elle exige de la discipline. Nommer la question. Définir le travail. Énoncer le périmètre et les exclusions. Identifier le système et les versions. Choisir une métrique qui correspond au service. Conserver une référence de base. Mesurer les variations. Publier la méthode et les preuves. Signaler ce qui reste inconnu. Attribuer un responsable à l’affirmation et une raison de la relancer. Si le résultat ne peut pas étayer une déclaration générale, réduire la portée de la déclaration.

C’est ainsi que l’Europe peut résister au théâtre de démonstration sans devenir allergique à l’ambition. Une institution publique peut acquérir de nouvelles capacités et exiger néanmoins un benchmark qui respecte le service. Une équipe de recherche peut publier un résultat passionnant et indiquer tout de même la charge de travail qui l’a produit. Un fournisseur peut montrer un chemin rapide et préciser où ce chemin s’arrête. Un périmètre honnête n’est pas un frein à l’innovation. C’est la surface de la route qui permet à n’importe qui d’autre de conduire.

Le benchmark est un contrat avec un dénominateur, car le dénominateur indique ce qui a réellement été fait. Le garder à côté du chiffre. Le résultat deviendra moins magique, plus comparable et beaucoup plus utile. C’est un échange équitable. Les systèmes dont les gens doivent dépendre méritent des chiffres qui peuvent survivre à une lecture lente.

Quand une métrique voyage entre les mondes

Les chiffres de benchmark quittent souvent l’équipe qui les a mesurés et entrent dans un autre système de décision. Un chercheur publie un tableau. Une équipe produit transforme une ligne en objectif. Les achats transforment l’objectif en contrat. Les opérations transforment le contrat en attente de niveau de service. Chaque étape modifie ce que l’on demande au chiffre. Le dénominateur d’origine peut encore figurer dans le document ou le dépôt, mais il est devenu socialement éloigné de la décision. Une métrique a besoin d’une note de traduction chaque fois qu’elle franchit cette frontière.

La note de traduction peut être simple. Ce résultat concerne le débit des composants, pas les cas terminés. Ce chiffre de précision utilise un ensemble d’étiquettes fixe, pas des résultats en conditions réelles. Cette valeur énergétique exclut le périmètre de refroidissement du centre de données. Cette référence de base est une implémentation de référence, pas le service existant. Ces phrases empêchent une mesure utile de devenir une promesse trompeuse. Elles facilitent aussi le désaccord. Un lecteur peut contester le périmètre plutôt que de débattre de l’impression que donne le chiffre.

Différentes équipes peuvent délibérément choisir des dénominateurs différents. Une équipe de plateforme peut se soucier du travail par joule. Un responsable de service peut se soucier des décisions terminées par heure de personnel. Une autorité publique peut se soucier de résultats corrects et explicables pour une population définie et d’un temps de réponse. Ce ne sont pas des vérités concurrentes si chacune est nommée. Les problèmes commencent lorsque le dénominateur le plus facile est autorisé à représenter la mission. Le noyau le plus rapide ne fait pas automatiquement le meilleur service, de la même manière que le plus grand ensemble de test ne fait pas automatiquement le plus pertinent.

Avant de réutiliser un benchmark, demandez ce qui a changé : la charge de travail, le responsable, la conséquence ou l’horizon temporel. Si l’un d’eux a changé, relancez l’interprétation même si le chiffre sous-jacent est inchangé. La mesure n’est pas une relique à transporter entre les pièces. C’est une relation qui doit être renouvelée lorsque la pièce change.

Un résultat doit savoir quand expirer

Les résultats ont une durée de vie utile. Un benchmark lié à une version de modèle, à un instantané de source ou à une configuration matérielle devient historique lorsque ces conditions changent. Cela ne rend pas l’ancien résultat faux. Cela change la question à laquelle il peut répondre. Le rapport doit indiquer quel événement rend l’affirmation obsolète : un nouveau modèle, un compilateur modifié, une nouvelle distribution de données, une règle d’étiquetage révisée, un remplacement matériel, un changement de politique ou un signal de dérive observé. Une règle d’expiration est un petit morceau de mémoire institutionnelle.

Sans règle d'expiration, les nombres s'accumulent comme des manteaux sur une chaise. Chacun est techniquement toujours là, et personne ne sait lequel correspond à aujourd'hui. Un registre de résultats peut conserver l'historique complet tout en signalant la comparaison en cours, la définition remplacée et la raison du relancement. Le fait de relancer devient alors une opération de maintenance ordinaire plutôt qu'une réponse à une crise. C'est particulièrement important pour les services publics, où un résultat peut survivre à l'équipe qui l'a produit.

L'expiration protège aussi le progrès honnête. Si une nouvelle charge de travail révèle qu'un benchmark antérieur était trop restreint, l'organisation peut publier le changement, préserver l'ancienne méthode et expliquer la nouvelle limite. Elle n'a pas besoin de défendre un chiffre obsolète ni de prétendre que l'ancien chiffre n'a jamais existé. Un benchmark qui peut être restreint, remplacé et compris est plus utile qu'un benchmark qui doit rester impressionnant pour toujours.

Un benchmark est un contrat avec un dénominateur.