Comment se construit un benchmark métier

Un benchmark du hub ne commence pas par un modèle, ni par une technologie. Il commence par une question qu'un dirigeant poserait : combien de mes factures passeront sans qu'un humain ait à corriger ? Si la question ne tient pas en une phrase, dite à quelqu'un qui n'a jamais ouvert une documentation technique, le benchmark n'est pas prêt.

Viennent ensuite les documents. Ils sont réels et publics, jamais empruntés à un client ni fabriqués par nous : le dépôt est public, et une facture inventée ne ressemble jamais tout à fait au terrain. La vérité terrain ne vient pas de nous non plus — ce sont les annotations déjà faites par des humains sur ces documents, avant ce test et sans connaître les modèles qui y passeraient. C'est la contrainte la plus dure du hub : elle limite les tâches testables à celles pour lesquelles un tel jeu existe, et c'est pour cela que la plupart des benchmarks du catalogue sont encore au programme plutôt que mesurés.

Troisième étape, le barème. Chaque élément noté reçoit un poids de 1 à 3, fixé par ce qu'une erreur coûte au métier, pas par sa difficulté technique. Sur une facture, le montant TTC pèse 3 et la date d'échéance 1. Certains champs sont dits critiques : un seul champ critique faux, et la facture entière bascule en « à relire ». Un champ vaut son poids ou zéro, sans demi-point : un montant est juste ou il est faux.

La notation est automatique, et elle est tatillonne là où le métier l'est. Les montants se comparent au centime. Les dates suivent la convention du pays du document, déclarée champ par champ : sur une facture américaine, 03/04/2020 est le 4 mars ; sur une facture française, le 3 avril. Elle est indulgente là où le métier l'est aussi : un identifiant s'écrit avec ou sans espaces. Et quand le comparateur ne sait pas trancher, la réponse part en relecture plutôt que d'être comptée comme fausse.

Quatrième étape, l'arbitrage humain. Le code de notation n'est pas une autorité, c'est un outil de tri. Trois sortes de cas passent sous les yeux d'un humain : toutes les hallucinations, parce qu'elles décident de la mesure la plus lourde ; les réponses jugées justes mais écrites autrement que la référence, parce que c'est là que le comparateur peut être trop indulgent ; et un échantillon de contrôle parmi les réponses jugées justes. L'humain tranche, et son verdict prime. Sur le classement publié à ce jour, cette étape n'a pas encore été jouée, et la page méthodologie le dit.

Dernière étape, la publication. Un run est un dossier horodaté et immuable : les réponses brutes de chaque modèle y sont conservées telles qu'elles ont été produites, avec la version exacte du modèle qui a répondu, le coût et le temps de chaque appel. Rien n'est jamais réécrit. Changer le barème et relancer la notation ne coûte aucun appel, et c'est ce qui rend les comparaisons dans le temps honnêtes.

Deux garde-fous encadrent la publication. Un modèle qui échoue sur plus d'un dixième du jeu la bloque : mieux vaut pas de classement qu'un classement calculé sur les seuls documents qu'un modèle a bien voulu traiter. Et les appels en échec restent comptés : ils n'entrent dans aucune moyenne, mais ils figurent dans le classement.

Aujourd'hui, un seul benchmark a parcouru les cinq étapes : la lecture de factures, sur de vraies factures publiques annotées. Les vingt-et-un autres en sont à la première — la question est posée, le protocole est rédigé — et attendent leur jeu de test.