Définition en une phrase
Conjunto de tareas, condiciones y métricas usado para comparar un comportamiento concreto de uno o varios sistemas.
Définition d’un benchmark en intelligence artificielle
Un benchmark en intelligence artificielle est une évaluation spécifiée qui associe une ou plusieurs tâches, des données, un protocole d’exécution et une ou plusieurs métriques afin de décrire le comportement d’un système dans ces conditions. Le terme peut aussi désigner l’ensemble du dispositif d’évaluation. Dans cette fiche, il renvoie à cette conception évaluative, et non aux seules données ni au chiffre figurant dans un tableau de résultats.
Cette définition pratique est importante, car un score a toujours une portée limitée. Il peut, par exemple, indiquer la proportion de problèmes d’un corpus qu’un modèle a résolus avec une méthode d’exécution donnée. Sans éléments complémentaires, il ne permet pas de conclure que le système est bon en mathématiques de manière générale, qu’il répondra correctement à toutes les personnes qui l’utilisent ou qu’il fonctionnera de façon sûre et fiable dans un produit.
Un benchmark est utile pour observer des performances de manière structurée, comparer des systèmes dans des conditions communes ou repérer des points forts et des points faibles. Pour comprendre ce que son résultat signifie, il faut d’abord identifier la tâche représentée et les décisions qui définissent le protocole. Le terme benchmark ne garantit pas, à lui seul, que l’évaluation soit représentative, impartiale, reproductible ou adaptée à une décision particulière.
Fonctionnement : tâche, données, protocole et métrique
La tâche décrit ce qui est demandé au système : répondre à une question, trouver une information, modifier du code ou réaliser une autre activité délimitée. Les données regroupent les cas concrets utilisés pour évaluer cette tâche. Un benchmark peut également spécifier des exemples d’entraînement ou de développement, mais il est essentiel de les distinguer des cas réservés à l’évaluation finale : utiliser ces derniers pour ajuster le système peut modifier ce que mesure le test.
Le protocole précise la manière dont l’évaluation est exécutée. Il peut définir le format des entrées et des réponses, les outils disponibles, les instructions, les limites de temps ou de calcul, le nombre de tentatives et la méthode de notation. Pour les systèmes qui utilisent des outils, l’environnement et le harnais — le code qui relie le modèle aux tâches, exécute des actions et recueille les résultats — font partie des conditions d’évaluation. Si ces éléments changent, le résultat peut lui aussi changer, même si le modèle reste identique.
La métrique transforme les réponses observées en une mesure. Certaines métriques comptent les bonnes réponses ; d’autres évaluent des propriétés telles que la qualité ou la sécurité. Le résultat agrégé peut résumer de nombreux cas en une seule valeur, mais une moyenne masque les différences entre types de tâches et entre exemples. Il est donc utile de consulter, lorsqu’ils sont disponibles, les résultats détaillés, le nombre de cas, la variabilité et les règles appliquées aux réponses ambiguës.
Enfin, la configuration du modèle décrit le système évalué et la manière dont il a été exécuté : version, instructions, outils et paramètres pertinents. Le nom d’un modèle, sans ces précisions, ne suffit pas à reconstituer le test. Une description méthodologique claire aide à interpréter le résultat et à déterminer si une autre évaluation reproduit réellement les mêmes conditions.
Étapes pour interpréter une évaluation
- 01Identifier la tâche et la population de cas : ce qui est demandé et les situations qui ne sont pas couvertes.
- 02Examiner les données, leur version et les éventuelles règles d’exclusion ou de sélection.
- 03Vérifier le protocole : configuration, outils, budget et conditions d’exécution.
- 04Lire la métrique et le dénominateur : ce qui compte comme une réussite et le nombre de cas pris en compte.
- 05Vérifier si les conditions sont comparables avant de confronter les résultats, et si les cas ressemblent à l’usage visé.
Trois exemples dans des domaines différents
Ces exemples portent sur des tâches dont les réponses ou les critères d’évaluation diffèrent. Ils ne sont pas interchangeables et ne couvrent pas, à eux seuls, toutes les capacités d’un système. Le fait qu’une évaluation utilise un ensemble connu de problèmes ou d’incidents ne transforme pas non plus son score en mesure universelle.
AIME 2024 relève du domaine des connaissances et du raisonnement mathématiques. L’épreuve comprend des problèmes de mathématiques ; les solutions officielles constituent une référence pour vérifier les réponses. Si ces problèmes sont utilisés pour évaluer un système, l’interprétation dépend des questions retenues, des instructions, de l’autorisation ou non d’utiliser des outils et de la manière dont les réponses ont été jugées. Le résultat décrit ce protocole et ce corpus, pas l’ensemble des compétences mathématiques du système.
BrowseComp a été conçu pour évaluer des agents qui naviguent sur le Web et cherchent des informations difficiles à trouver. Dans ce type d’évaluation, la réponse finale ne suffit pas à tout expliquer : les conditions de navigation, les outils et la méthode de vérification de l’information trouvée comptent également. Un bon score à BrowseComp ne prouve pas que le système trouvera correctement n’importe quelle donnée sur le Web, quelle que soit la source ou la date de mise à jour.
SWE-bench porte sur des incidents issus de dépôts de logiciels : le système doit proposer des modifications permettant de résoudre des problèmes décrits sur GitHub. SWE-bench Verified est une version sélectionnée et révisée du benchmark. La documentation du projet décrit un corpus de cinq cents cas vérifiés par annotation humaine et par des tests ; elle signale aussi que la configuration de l’environnement, la contamination et la couverture du corpus limitent les conclusions possibles. Le résultat dépend donc de l’ensemble de cas et du harnais employés. Il ne garantit pas que le système puisse assurer la maintenance de n’importe quel code en production.
Comment lire un score et quand comparer
Avant de comparer deux résultats, vérifiez qu’ils portent sur la même tâche, la même version des données, la même partition, la même métrique et les mêmes règles de notation. Examinez aussi la configuration du modèle, les instructions, les outils, le budget et l’environnement. Un chiffre plus élevé ne signifie pas nécessairement de meilleures performances si l’un de ces éléments a changé. Même lorsque les conditions sont proches, les différences peuvent relever de la variabilité d’exécution ou dépendre d’un petit nombre de cas.
Le dénominateur aide à apprécier la portée des éléments disponibles : un taux calculé sur peu d’exemples ne vaut pas la même chose qu’un taux calculé sur un grand nombre de cas. Il est également utile de savoir quels cas ont été exclus et comment les réponses incomplètes ou ambiguës ont été traitées. Si le rapport ne présente qu’un score agrégé, demandez les résultats ventilés par tâche ou par catégorie avant de vous en servir pour choisir un système.
La comparaison est plus défendable lorsque les systèmes sont évalués selon un protocole commun et que les détails susceptibles d’influencer le résultat sont documentés. BetterBench analyse notamment la finalité, la portée, la documentation, la contamination, la reproductibilité et la comparabilité des benchmarks. HELM présente pour sa part des évaluations de modèles à partir de scénarios et de métriques multiples, tout en documentant les conditions d’évaluation. Ces approches montrent pourquoi un classement dépourvu de contexte méthodologique constitue un ensemble d’éléments incomplet.
À vérifier avant de comparer deux scores
| Élément | Question de contrôle | Si les conditions diffèrent |
|---|---|---|
| Tâche et données | Les mêmes cas et la même version ont-ils été évalués ? | L’écart peut venir de la sélection ou de la difficulté des exemples. |
| Métrique et agrégation | La réussite est-elle comptée de la même manière et avec le même dénominateur ? | Les chiffres peuvent mesurer des choses différentes. |
| Modèle et exécution | La version, les instructions, les outils et le budget sont-ils identiques ? | L’écart ne peut pas être attribué au seul modèle. |
| Environnement et évaluateur | L’environnement d’exécution et les règles de validation sont-ils les mêmes ? | Les réponses acceptées ou la possibilité d’accomplir une tâche peuvent changer. |
Benchmark, dataset, métrique, classement et évaluation interne
Un dataset est un ensemble de données ou d’exemples. Il peut faire partie d’un benchmark, mais ne définit pas à lui seul la tâche, le protocole complet ni la méthode de notation. Un même ensemble peut servir à plusieurs évaluations ; connaître le nom du corpus ne suffit donc pas pour savoir ce qui a été mesuré.
Une métrique est une règle qui sert à résumer ou à juger les résultats, par exemple un taux de réussite défini d’une certaine façon. Elle ne constitue pas le benchmark dans son ensemble : différentes métriques appliquées aux mêmes données peuvent répondre à des questions différentes. Un leaderboard est un tableau ou un système de classement qui présente les résultats des participants selon certaines règles. C’est une manière d’afficher des scores, pas la preuve que toutes les entrées ont été obtenues dans des conditions comparables.
Une évaluation interne adapte les cas et les conditions à un besoin particulier, par exemple aux demandes adressées à l’assistant d’assistance d’une organisation. Elle peut ressembler à un benchmark, mais doit être documentée avec la même rigueur : critères de sélection, données, protocole, métriques et limites. Un test d’acceptation vérifie, quant à lui, des exigences convenues pour un produit ou un système dans un contexte défini. Il peut faire partie d’une évaluation, sans être automatiquement un benchmark général.
Ces distinctions évitent les raccourcis : un tableau comportant de nombreux scores n’est pas nécessairement une évaluation complète ; la popularité d’un dataset ne garantit pas qu’il représente un usage réel ; et le nom connu d’une métrique ne suffit pas à expliquer le critère de réussite.
Des termes proches, mais non équivalents
| Terme | Ce qu’il désigne | Ce qu’il ne permet pas de présumer à lui seul |
|---|---|---|
| Benchmark | Dispositif d’évaluation : tâche, données, protocole et notation. | Qu’il soit représentatif, équitable ou suffisant pour une décision réelle. |
| Dataset | Ensemble d’exemples ou de données. | Le protocole ou la métrique utilisés pour les évaluer. |
| Métrique | Règle de notation ou de synthèse d’un résultat. | Les tâches évaluées ou l’adéquation de la mesure à l’usage visé. |
| Leaderboard | Présentation classée de résultats selon certaines règles. | La comparabilité de tous les résultats ou leur reproduction indépendante. |
| Évaluation interne | Test conçu pour un cas d’usage ou une population déterminée. | La généralisation de ses résultats au-delà de ce contexte. |
Limites : contamination, surapprentissage et validité externe
Il y a contamination lorsque des informations issues des cas d’évaluation — ou des réponses qui leur sont très proches — figurent parmi les données utilisées pour entraîner ou ajuster un système. Dans ce cas, une réponse correcte peut refléter une familiarité antérieure avec le contenu, et pas seulement la capacité que l’on voulait mesurer. La contamination n’est pas toujours facile à détecter : les données d’entraînement peuvent ne pas être publiques, et une recherche de correspondances exactes ne repère pas toutes les formes de chevauchement.
Le surapprentissage au benchmark peut se produire lorsque les développeurs optimisent à répétition un système pour obtenir de bons résultats sur un test connu. Cette adaptation peut améliorer le score sans entraîner une amélioration équivalente face à des tâches inédites. Conserver des ensembles d’évaluation réservés, documenter les changements et compléter le test par des cas différents contribue à réduire ce risque, sans toutefois l’éliminer complètement.
La validité externe concerne la mesure dans laquelle un résultat renseigne sur des situations en dehors du benchmark : d’autres utilisateurs, domaines, langues, outils, versions logicielles ou conditions de production. Un corpus contrôlé facilite la comparaison, mais peut laisser de côté des exigences importantes du monde réel, telles que la latence, le coût, la confidentialité, les interactions prolongées, la gestion des erreurs ou la supervision humaine.
Les exécutions peuvent également varier. Un système peut produire des réponses différentes d’un essai à l’autre ; les environnements peuvent connaître des défaillances ; et, si un juge automatique ou humain est utilisé, les règles et les désaccords de jugement influent sur le résultat. Il est utile de publier la méthode d’évaluation, les instructions et l’environnement, ainsi que, dans la mesure du possible, des exemples d’entrées et de sorties. Un chiffre unique, arrondi, peut masquer l’incertitude, des résultats inégaux entre sous-groupes ou des échecs graves sur certains cas.
Les scores agrégés simplifient la lecture, mais condensent plusieurs choix : les tâches prises en compte, le poids attribué à chacune et le traitement des erreurs. Une moyenne élevée peut coexister avec de faibles résultats dans une catégorie importante. Pour prendre une décision pratique, examinez la distribution des résultats et les échecs qui auraient le plus de conséquences, plutôt que le seul classement général.
Quand un benchmark est utile, et quand il ne l’est pas
Un benchmark permet de comparer des systèmes dans des conditions déclarées, de suivre les changements d’une version à l’autre, de repérer des domaines faibles et de disposer d’un point de référence commun pour une tâche délimitée. Il peut aussi aider à formuler des questions complémentaires : quels types de cas concentrent les erreurs, quelles ressources ont été nécessaires et une amélioration se retrouve-t-elle dans plusieurs évaluations ?
Il ne suffit pas si on l’utilise comme seul argument pour déployer un système, prédire sa qualité dans un contexte qui n’est pas représenté ou affirmer qu’une capacité est générale. Dans ces situations, d’autres évaluations sont nécessaires : tests avec des données et des utilisateurs pertinents, analyse des défaillances, vérifications de sécurité et de confidentialité, ainsi que mesures opérationnelles comme le coût ou la latence, selon l’objectif.
Avant d’adopter un benchmark, définissez la décision qu’il doit éclairer. Si la question est précise — par exemple, savoir si un assistant classe correctement les incidents d’un service —, une évaluation interne bien conçue et documentée peut être plus pertinente qu’un classement public. Elle peut être combinée à des benchmarks établis, mais ne doit pas être confondue avec eux.
Conseils pratiques pour utiliser un benchmark
- 01Formuler la question de décision avant de choisir un test.
- 02Vérifier que les tâches et les cas ressemblent à l’usage qui vous intéresse.
- 03Lire le protocole, la métrique, la version, la configuration et le nombre d’exemples.
- 04Ne comparer les résultats que lorsque les conditions sont suffisamment équivalentes.
- 05Examiner les erreurs et les résultats détaillés ; ne pas s’appuyer sur un seul score agrégé.
- 06Compléter le benchmark par une évaluation du cas d’usage et expliciter les incertitudes.
Concepts associés
Pour approfondir le sujet, consultez les fiches consacrées au benchmark, à l’évaluation, à la reproductibilité et à la contamination des données, ainsi que le glossaire général. Ces notions permettent de préciser ce qui a été mesuré, si d’autres personnes peuvent répéter le test et si le résultat risque d’être gonflé par une exposition préalable aux cas.
L’idée essentielle est simple : demandez quelle tâche a été réalisée, avec quelles données, selon quel protocole et d’après quel critère. Si ces éléments ne sont pas clairs, le score ne constitue pas une base suffisante pour comparer des systèmes ni pour anticiper leurs performances dans un environnement différent.