Benchmark

À quoi sert une épreuve standard

Un benchmark propose une série de tâches avec une réponse attendue : questions à choix multiples, problèmes de calcul, exercices de code, compréhension de texte. Le même jeu est passé sur plusieurs modèles, et le taux de réussite donne un point de comparaison. L'intérêt principal est la reproductibilité : n'importe qui peut relancer l'épreuve et retrouver un résultat proche, ce qui rend la discussion technique possible entre des équipes qui n'ont pas les mêmes moyens de calcul.

Ces épreuves ont orienté la recherche pendant des années, en donnant une cible mesurable aux architectures successives. Elles servent aussi de test de non-régression : une nouvelle version d'un modèle doit faire au moins aussi bien que la précédente sur les tâches déjà couvertes, faute de quoi l'éditeur doit expliquer l'écart. Pour un fournisseur, publier un score est devenu un argument de communication, ce qui a déplacé l'usage du terrain technique vers le terrain commercial.

Les limites du classement

Un score élevé ne dit rien de votre cas. Les épreuves portent sur des questions académiques, en anglais le plus souvent, et ne mesurent ni la tenue d'un format imposé, ni la capacité à citer un document interne, ni le coût réel d'une réponse. Un modèle peut réussir un examen de droit sans savoir lire un devis de plomberie rédigé en français mêlé de créole, avec ses abréviations, ses renvois et ses unités locales.

Deux défauts reviennent dans les comparaisons publiées. La contamination d'abord : les questions des jeux publics circulent sur internet et peuvent se retrouver dans les données d'entraînement, ce qui flatte artificiellement le score obtenu. La saturation ensuite : quand tous les modèles réussissent la même épreuve, elle cesse de discriminer et seul le coût les sépare. Les comparaisons les plus utiles publient leurs questions, leur méthode de notation et la date des passes.

Construire son propre banc d'essai

Un banc d'essai interne tient souvent en une centaine de cas, tirés de votre activité réelle. Chaque cas comprend une consigne, le document d'entrée et la réponse attendue, rédigée par un expert du métier et non par l'équipe technique. On y ajoute les cas limites : document incomplet, scan de travers, demande ambiguë, information contradictoire entre deux pièces. Ce sont eux qui distinguent réellement les modèles et qui révèlent les fragilités d'un enchaînement.

La notation doit rester simple et stable. Pour une extraction de champs, on compte les champs exacts. Pour une réponse rédigée, on note la présence des éléments obligatoires, l'absence d'invention et le respect du format demandé. Un modèle peut aider à pré-trier les réponses, mais la décision finale revient à un humain qui connaît le dossier. Relancer ce banc à chaque changement de modèle ou de consigne évite les régressions découvertes trop tard, chez le client.

Ce qu'un score ne mesure pas

Un classement ne dit rien de la stabilité dans le temps. Deux modèles également notés peuvent se comporter très différemment lorsqu'une même question est posée dix fois : l'un variera dans la forme, l'autre dans le fond, et seul le second est dangereux pour un usage administratif. La régularité, la tenue d'un format et la capacité à dire qu'une information manque sont des qualités peu mesurées par les épreuves publiques.

Il ne dit rien non plus du coût d'exploitation. Un modèle légèrement meilleur mais deux fois plus lent ou plus cher à servir peut ruiner l'économie d'un projet dont le volume est élevé. Pour un usage interne de quelques dizaines de requêtes par jour, la différence est négligeable ; pour un service client qui traite des milliers de demandes, elle décide de la viabilité. Le classement doit donc toujours être lu à côté d'une estimation de coût par dossier traité.