Golden Dataset

Un golden dataset est une collection d'exemples soigneusement sélectionnés, étiquetés avec précision et représentatifs, utilisée comme référence de confiance pour évaluer un système d'IA. Plutôt que de maximiser la taille, il privilégie l'exactitude, la couverture et la pertinence par rapport à l'application visée. Les équipes l'utilisent comme une « clé de réponse » stable pour comparer des modèles, vérifier les régressions, analyser les échecs et décider si un système est prêt pour le déploiement.

En machine learning, « golden dataset » est un terme technique informel plutôt qu'un type de jeu de données universellement standardisé. Son contenu exact dépend de la tâche : des images avec des boîtes englobantes vérifiées pour la détection d'objets, des invites avec des réponses approuvées pour un modèle de langage, ou des transactions avec des résultats confirmés pour la détection de fraudes.

Ce qui rend un jeu de données golden#

Un golden dataset contient des entrées ainsi que des sorties attendues de confiance, souvent appelées ground truth. En computer vision, ces sorties peuvent être des étiquettes de classe, des boîtes englobantes, des masques de segmentation ou des points clés produits par une data annotation rigoureuse.

Ses principales qualités sont :

• Précision des étiquettes : Des experts du domaine ou des réviseurs formés vérifient les annotations à l'aide de directives claires. Les exemples ambigus sont résolus de manière cohérente plutôt que d'être laissés à l'interprétation individuelle.
• Couverture représentative : Le jeu de données reflète des conditions de production importantes, incluant des cas courants, des exemples difficiles, des événements rares et des groupes d'utilisateurs ou environnementaux pertinents.
• Alignement des tâches : Chaque exemple aide à mesurer une exigence définie, telle que la détection de colis endommagés sous l'éclairage d'un entrepôt.
• Indépendance : Les exemples sont séparés des données d'entraînement pour éviter la data leakage, ce qui peut rendre les performances signalées faussement élevées.
• Traçabilité : Les équipes enregistrent les sources de données, les conditions de collecte, les règles d'annotation, les réviseurs et les modifications. Le MLflow dataset tracking illustre comment les hachages, les schémas, les sources et la traçabilité des jeux de données peuvent favoriser la reproductibilité.
• Modification contrôlée : Les mises à jour sont versionnées et examinées. Le score d'un modèle n'a de sens que lorsque la version exacte du jeu de données et les paramètres d'évaluation sont connus.

Golden ne signifie pas infaillible ou définitivement correct. Les conditions et définitions du monde réel peuvent changer, le jeu de référence doit donc être audité et mis à jour sans réécrire silencieusement les résultats historiques.

Golden Dataset vs. Termes associés#

Un golden dataset chevauche plusieurs concepts familiers mais met l'accent sur la confiance et la gouvernance :

• Une ground-truth label est la réponse acceptée pour un exemple ; un golden dataset est une collection d'exemples examinés et de leurs réponses acceptées.
• Un benchmark dataset est généralement partagé pour comparer des systèmes sur une tâche commune. Un golden dataset est souvent privé et adapté à une seule organisation, un seul produit ou un seul environnement de déploiement.
• Les Validation data guident la sélection et le réglage des modèles pendant le développement. Des décisions répétées basées sur celles-ci peuvent progressivement surajuster le processus de développement.
• Les Test data sont réservées à l'évaluation finale. Un golden dataset sert souvent de jeu de test ou de régression de haute qualité, bien qu'il puisse également contenir des portions distinctes de développement et de test final.
• Les données d'entraînement enseignent les paramètres du modèle et sont généralement beaucoup plus grandes. Un golden dataset doit rester en dehors de l'entraînement à moins qu'une copie versionnée ne soit délibérément retirée de l'évaluation.

Les Google guidance on dataset splitting recommandent de garder les exemples d'entraînement, de validation et de test distincts. Lorsque les données sont rares, les cross-validation techniques peuvent améliorer l'estimation, mais un jeu de référence final protégé reste précieux.

Applications concrètes#

Inspection des défauts de fabrication : Une usine peut créer un golden dataset d'images examinées montrant des produits acceptables et des défauts confirmés tels que des fissures, des composants manquants ou un assemblage incorrect. Il inclut plusieurs lignes de production, positions de caméras, matériaux et conditions d'éclairage. Chaque modèle candidat est évalué sur le même ensemble avant sa sortie. Si le rappel chute pour les petites fissures, l'équipe peut bloquer le déploiement même lorsque la métrique globale semble acceptable.

Surveillance des rayons en magasin : Un détaillant peut conserver des images de magasin vérifiées contenant des étagères encombrées, des espaces vides, des produits partiellement cachés, des emballages saisonniers et des reflets. Ce jeu de données mesure si un système de vision détecte de manière fiable les produits et les ruptures de stock dans tous les environnements de magasin. L'examen des performances par scénario ou catégorie de produit suit la pratique plus large de recherche de cohortes à fort taux d'erreur décrite dans les Microsoft’s responsible AI guidance.

Applications : Ces applications montrent pourquoi la seule précision globale est insuffisante. Le golden dataset doit prendre en charge l'évaluation par tranche pour les classes rares, les emplacements, les appareils ou les conditions où les erreurs entraînent des conséquences différentes. Le NIST AI Risk Management Framework Core met de même l'accent sur les ensembles de test documentés, les métriques appropriées et l'évaluation dans des conditions similaires au déploiement.

Création et maintenance d'un Golden Dataset#

Commence pas par définir le comportement prévu du modèle et les modes d'échec importants. Collecte des exemples représentatifs, rédige des instructions d'annotation précises, exécute l'étalonnage des réviseurs et résous les désaccords avec des experts du domaine. Conserve les quasi-doublons et les images vidéo associées dans la même division pour qu'un contenu visuellement similaire ne puisse pas franchir la frontière entre entraînement et évaluation.

Pour les projets de vision, Ultralytics Platform prend en charge la gestion des jeux de données cloud, l'annotation, l'entraînement et le déploiement. Son annotation workflow permet aux équipes de créer et d'affiner des étiquettes, tandis que les vues de jeux de données aident à inspecter les distributions de classes, les images non annotées, les divisions, les doublons et les valeurs aberrantes.

Versionne chaque version approuvée et documente les ajouts, les suppressions, les corrections d'étiquettes et les modifications de politique. Le NIST guidance on AI testing, evaluation, validation, and verification fournit un cadre plus large pour une évaluation significative. Après le déploiement, compare les données entrantes avec la référence dorée et surveille les conditions changeantes ; le Azure model monitoring guidance explique comment les signaux de dérive et de qualité des données peuvent révéler quand un ensemble de référence a besoin d'être révisé.

Évaluation d'un modèle de vision#

Ultralytics YOLO peut évaluer des prédictions par rapport à des étiquettes examinées en utilisant le Validation mode :

from ultralytics import YOLO

# Load a pretrained object detection model
model = YOLO("yolo26n.pt")

# Evaluate predictions against a labeled reference split
metrics = model.val(data="coco8.yaml", split="val")

# Report the primary detection metric
print(f"mAP50-95: {metrics.box.map:.3f}")

Ce flux de travail démontre le rôle côté modèle d'un golden dataset : exécuter un modèle fixe sur une division étiquetée fixe et enregistrer une métrique reproductible. Dans les projets de production, les équipes doivent également inspecter les résultats par classe, les matrices de confusion, les exemples difficiles et les seuils d'acceptation spécifiques à l'application avant d'approuver une version.