Benchmark Dataset

Un jeu de données de référence est un jeu de données public et fixe, doté de partitions prédéfinies et d’une métrique d’évaluation officielle, que la communauté de recherche utilise pour comparer des modèles sur une même tâche, dans les mêmes conditions. Les résultats sont exprimés par une valeur pour chaque métrique, comme la précision top-1 sur ImageNet ou mAP_50-95 sur COCO val2017. Ces valeurs ne sont comparables entre articles que parce que tout le monde utilise les mêmes images, annotations, code d’évaluation et règles. Les jeux de référence suivent les progrès de l’apprentissage automatique (ML), déterminent quelles méthodes sont adoptées et fournissent les chiffres phares des articles et des fiches de modèle.

Ce que définit un jeu de référence#

Un jeu de référence fixe tous les éléments susceptibles de rendre deux scores incomparables :

• Données et partitions : les images exactes d’entraînement, de validation et de test, afin que personne ne puisse évaluer le modèle sur un sous-ensemble plus facile.
• Tâche et ensemble d’étiquettes : ce que le modèle doit produire, par exemple l’une des 1 000 classes, ou une boîte et une classe pour chacune des 80 catégories d’objets.
• Métrique et code d’évaluation : l’implémentation officielle, comme l’évaluation COCO, qui calcule la moyenne de la précision sur dix seuils IoU compris entre 0.50 et 0.95.
• Règles : ce qui constitue une soumission valide, notamment l’autorisation ou non d’utiliser des données d’entraînement supplémentaires, une augmentation au moment du test ou des ensembles de modèles.

De nombreux jeux de référence gardent privées les étiquettes de test pour empêcher les équipes d’ajuster leurs modèles sur le jeu de test. Les participants entraînent leurs modèles sur les partitions publiques, téléversent les prédictions correspondant aux images de test et un serveur d’évaluation les compare aux étiquettes masquées avant d’afficher les résultats dans un classement. Lorsque les étiquettes de test ne sont jamais publiées, comme pour ImageNet, les articles présentent plutôt les résultats sur la partition publique de validation.

Jeux de données de référence courants#

• Classification d’images : ImageNet-1k, évalué avec la précision top-1 et top-5, ainsi que CIFAR-10 et CIFAR-100 pour les expériences de plus petite envergure.
• Détection d’objets et segmentation : COCO, avec 80 catégories et la précision moyenne (mAP) comme métrique principale ; Pascal VOC, avec 20 catégories ; et LVIS, avec 1 203 catégories, pour la reconnaissance à longue traîne.
• Conduite autonome : KITTI et le jeu de données ouvert Waymo, qui contiennent des enregistrements de la circulation réelle par caméra et lidar.
• Langage et raisonnement : questions scientifiques de niveau universitaire dans GPQA, questions d’experts dans de nombreux domaines dans l’examen ultime de l’humanité et problèmes de programmation dans LiveCodeBench.

Ultralytics publie la précision de détection de YOLO26 sous la forme d’un mAP_50-95 à modèle unique et à échelle unique, mesuré sur les 5 000 images de la division COCO val2017 à 640 pixels : de 40.9 pour YOLO26n à 57.5 pour YOLO26x. yolo detect val data=coco.yaml reproduit cette évaluation. Le classement VLM d’Ultralytics applique la même approche aux modèles de langage et de vision et attribue à chacun un score mAP₅₀ sur des jeux de données de détection du monde réel, dans des domaines comme l’imagerie médicale, les photos aériennes et les rayons des magasins.

Limites des jeux de référence#

• Surapprentissage du jeu de référence : des années de sélection de modèles sur un seul jeu de test peuvent conduire tout un domaine à s’adapter aux particularités de ce jeu. ImageNetV2 a évalué ce phénomène en constituant un nouveau jeu de test selon la procédure d’origine : la précision a diminué de 11 % à 14 %, mais le classement des modèles est resté le même. Les auteurs ont attribué cette baisse à des images légèrement plus difficiles plutôt qu’à la réutilisation du jeu de test.
• Erreurs d’annotation : une étude portant sur 10 jeux de test largement utilisés a estimé qu’au moins 3,3 % de leurs étiquettes étaient erronées. Sur ImageNet avec des étiquettes corrigées, ResNet-18 surpasse ResNet-50 dès que la proportion d’images de test mal étiquetées à l’origine augmente de seulement 6 %.
• Saturation : lorsque les meilleurs modèles approchent le plafond imposé par le bruit des étiquettes, les écarts de score ne permettent plus de les départager et des jeux plus difficiles prennent le relais. L’examen ultime de l’humanité a rassemblé 2 500 questions d’experts après que les grands modèles de langage ont dépassé 90 % de précision sur MMLU.
• Contamination : des éléments de test qui se retrouvent dans les données d’entraînement à l’échelle du Web gonflent les scores des grands modèles de langage. LiveCodeBench lutte contre ce phénomène en ajoutant continuellement de nouveaux problèmes de concours et leurs dates de publication. Chaque modèle peut ainsi être évalué sur des problèmes publiés après la fin de son entraînement.
• Décalage par rapport au déploiement : un jeu de référence mesure une seule distribution de données. Un modèle en tête sur COCO peut tout de même manquer de petits objets inhabituels ou propres à un domaine dans une usine ou un hôpital. C’est pourquoi les équipes conservent aussi un jeu de données de référence adapté à leur propre cas d’usage.

Jeux de données de référence et termes associés#

• Données de test : données mises à part pour mesurer une seule fois les performances d’un modèle finalisé. La partition de test d’un jeu de référence est partagée par tout un domaine, tandis que le jeu de test propre à une équipe mesure les performances sur les données de déploiement de cette équipe.
• Données de validation : données utilisées pendant le développement pour ajuster les hyperparamètres et sélectionner les points de contrôle. Les jeux de référence fournissent souvent une partition de validation officielle à cette fin.
• Évaluation comparative (vitesse) : mesure du temps de latence, du débit ou de l’utilisation de la mémoire d’un modèle sur un matériel et avec des environnements d’exécution donnés, comme ONNX Runtime ou TensorRT. Une vérification de la précision est généralement effectuée après chaque exportation pour confirmer que la conversion n’a pas dégradé le modèle.