Test Data

Les données de test, également appelées jeu de test ou jeu de réserve, constituent la partie d’un jeu de données réservée à la mesure des performances d’un modèle d’apprentissage automatique (ML) terminé. Elles ne servent ni à ajuster les poids du modèle, ni à prendre des décisions de développement, par exemple sur l’architecture, les hyperparamètres, le point de contrôle ou le seuil de confiance ; le modèle est évalué une fois ces décisions arrêtées. Comme ni le modèle ni ses développeurs ne se sont adaptés à ces données, sa précision, son rappel ou sa précision moyenne (mAP) fournit une estimation non biaisée de ses performances sur de nouvelles données issues de la même distribution. C’est cette mesure que les équipes utilisent pour décider si un modèle est prêt à être déployé.

Jeux d’entraînement, de validation et de test#

Un jeu de données est généralement réparti en trois sous-ensembles disjoints, chacun ayant un rôle différent :

• Données d’entraînement : Les exemples à partir desquels l’optimiseur apprend en ajustant les poids pour réduire la perte.
• Données de validation : Évaluées à plusieurs reprises pendant le développement pour comparer les hyperparamètres, arrêter l’entraînement de façon anticipée et choisir le meilleur point de contrôle.
• Données de test : Évaluées une seule fois à la fin pour communiquer la métrique sur laquelle le projet est jugé.

Les répartitions 80/10/10 ou 70/15/15 sont courantes pour les jeux de données contenant des milliers d’exemples, tandis que les jeux de données de plusieurs millions d’exemples peuvent en réserver quelques pour cent. La taille nécessaire du jeu de test dépend de la précision requise : l’erreur type d’une précision p mesurée sur n exemples est la racine carrée de p(1 − p)/n. Ainsi, 1 000 images de test avec une précision de 90 % donnent un intervalle de confiance à 95 % d’environ ±1,9 point de pourcentage, tandis que 10 000 images le ramènent à environ ±0,6. La terminologie varie selon les domaines, et de nombreux articles présentent leurs résultats finaux sur ImageNet à partir du jeu de validation officiel, car les étiquettes de test d’ImageNet ne sont pas publiques. Dans Ultralytics YOLO, un fichier YAML de jeu de données exige les chemins train et val, et accepte un chemin facultatif test ; l’entraînement évalue val après chaque époque pour choisir best.pt, et model.val(data="data.yaml", split="test") évalue le modèle terminé sur les images mises de côté en mode validation.

Pourquoi le jeu de test doit rester intact#

Chaque décision prise en consultant un score adapte un peu le modèle à ces données. Lorsque de nombreuses configurations sont comparées sur le jeu de validation, la configuration gagnante est en partie celle qui a eu de la chance sur ces exemples précis ; son score de validation surestime donc ses performances ailleurs. L’expérience suivante avec scikit-learn choisit le meilleur nombre de voisins pour un classificateur des k plus proches voisins sur un petit jeu de données bruité, puis compare la précision en validation et en test de la configuration gagnante sur 30 jeux de données aléatoires :

import numpy as np
from sklearn.datasets import make_classification
from sklearn.model_selection import train_test_split
from sklearn.neighbors import KNeighborsClassifier

val_scores, test_scores = [], []
for seed in range(30):
    # A small, noisy dataset split 60/20/20 into train, validation, and test
    X, y = make_classification(n_samples=400, n_features=20, n_informative=4, flip_y=0.2, random_state=seed)
    X_train, X_rest, y_train, y_rest = train_test_split(X, y, test_size=0.4, random_state=seed)
    X_val, X_test, y_val, y_test = train_test_split(X_rest, y_rest, test_size=0.5, random_state=seed)

    # Model selection: keep the neighbor count with the best validation accuracy
    scores = {k: KNeighborsClassifier(k).fit(X_train, y_train).score(X_val, y_val) for k in range(1, 51)}
    best_k = max(scores, key=scores.get)
    val_scores.append(scores[best_k])

    # The test set is scored once, after the choice is final
    test_scores.append(KNeighborsClassifier(best_k).fit(X_train, y_train).score(X_test, y_test))

print(f"Chosen model, mean of 30 runs: validation {np.mean(val_scores):.3f}, test {np.mean(test_scores):.3f}")

Les modèles choisis obtiennent en moyenne 0,805 en validation et 0,758 en test ; la sélection parmi 50 candidats a donc gonflé l’estimation de validation de près de cinq points. Régler le modèle en fonction du jeu de test masquerait cet écart et introduirait le même biais optimiste dans le résultat publié : c’est une forme de fuite de données. Les benchmarks publics s’en prémunissent en gardant les étiquettes secrètes : les résultats sur le jeu de test de COCO sont obtenus en soumettant les prédictions à un serveur d’évaluation. Pour les grands modèles de langage (LLM), les questions de test présentes dans les données de préentraînement à l’échelle du Web contaminent un benchmark. C’est pourquoi LiveCodeBench ajoute continuellement de nouveaux problèmes de concours et évalue chaque modèle sur des problèmes publiés après la fin de son entraînement.

Constituer un jeu de test fiable#

Un score de test ne prédit les performances en situation réelle que si le jeu de test ressemble aux données rencontrées par le modèle, qu’il s’agisse de scènes de rue pour les véhicules autonomes ou d’examens pour l’analyse d’images médicales :

• Reproduis les conditions de déploiement : Les caméras, l’éclairage, les saisons, la géographie et l’équilibre des classes doivent refléter la production. Le jeu de test d’un détecteur de conduite doit inclure des scènes nocturnes, pluvieuses et enneigées, même si la plupart des trajets ont lieu par beau temps.
• Garde-les indépendants : Les images d’une même vidéo, les scans d’un même patient et les photos d’une même scène doivent appartenir à une seule séparation. Les données ordonnées dans le temps sont séparées par date, afin que le modèle soit testé sur le futur.
• Teste sur plusieurs sources : En imagerie médicale, une validation externe sur des examens provenant d’autres hôpitaux et modèles de scanner montre si le modèle a appris l’anatomie ou le matériel d’un seul établissement.
• Nettoie les étiquettes : Les erreurs dans les étiquettes de test plafonnent la précision mesurable et peuvent modifier le classement des modèles ; les étiquettes de test méritent donc une vérification particulièrement minutieuse.
• Présente les résultats par sous-ensemble : Les métriques par classe et par condition révèlent des échecs qu’une moyenne unique masque.

Même un jeu de test reconstitué avec soin peut faire évoluer les résultats : lorsque des chercheurs ont recréé le jeu de test ImageNet en suivant le processus de collecte original, la précision a baissé de 11 à 14 points de pourcentage pour un large éventail de modèles. Les gains obtenus sur le jeu de test original se sont toutefois maintenus, et les auteurs ont attribué la baisse à des images légèrement plus difficiles plutôt qu’à des années de réutilisation du jeu de test.

Les données de test et les notions apparentées#

• Validation croisée : Fait varier la partie des données de développement utilisée pour la validation, ce qui fournit une estimation plus stable pour la sélection du modèle. Un jeu de test distinct fournit toujours le résultat final.
• Jeu de données de référence : Un jeu de test public partagé par un domaine de recherche. Comme toutes les équipes l’évaluent pendant des années, il finit peu à peu par ne plus être constitué de données inédites.
• Jeu de données de référence de haute qualité : Un jeu de référence sélectionné avec soin et de haute qualité, dont les réponses ont été vérifiées ; il sert souvent de jeu de test fixe pour les tests de régression des applications LLM.