Accueil › Glossaire › Validation Set

Validation Set

Le validation set (ou jeu de validation) est le sous-ensemble de données utilisé pendant le développement d’un modèle de machine learning pour régler les hyperparamètres, comparer les architectures et détecter l’overfitting, sans contaminer l’évaluation finale.

Si le training set est le manuel d’apprentissage et le test set l’examen final, le validation set est l’exercice corrigé que l’étudiant utilise pour s’auto-évaluer et ajuster sa méthode de travail. Il permet de prendre des dizaines de décisions de design (taux d’apprentissage, nombre de couches, stratégie de régularisation) sans jamais toucher au test set. C’est le garde-fou central de tout pipeline ML rigoureux.

Pourquoi le validation set est nécessaire

Sans validation set, vous n’avez que deux options pour évaluer vos choix de design : évaluer sur le training set (inutile, car le modèle peut simplement mémoriser les données) ou évaluer sur le test set (interdit, car chaque utilisation biaise l’estimation finale). Le validation set résout ce dilemme en offrant un terrain d’évaluation intermédiaire, distinct du training et du test.

Concrètement, le validation set répond à trois questions fondamentales pendant le développement :

Mon modèle overfitte-t-il ? Si la loss sur le training set continue à baisser mais que celle sur le validation set stagne ou remonte, c’est le signal classique d’overfitting. C’est ce monitoring qui déclenche l’early stopping (arrêter l’entraînement au moment optimal).

Quels hyperparamètres choisir ? Learning rate, nombre de couches, taille du batch, coefficient de dropout, poids de régularisation : tous ces choix se font en comparant les performances sur le validation set. Vous testez plusieurs configurations et retenez celle qui donne les meilleurs résultats de validation.

Quelle architecture est la meilleure ? Réseau de neurones vs gradient boosting, CNN vs Transformer, modèle simple vs modèle complexe : la comparaison se fait sur le validation set, jamais sur le test set.

Comment le validation set fonctionne en pratique

Monitoring pendant l’entraînement

À chaque epoch (passage complet sur le training set), vous évaluez la performance du modèle sur le validation set. Vous obtenez deux courbes : la training loss (qui descend en continu si le modèle apprend) et la validation loss (qui descend d’abord, puis remonte quand le modèle commence à overfitter). L’écart entre les deux courbes est le diagnostic principal :

Early stopping

L’early stopping est la technique de régularisation la plus simple et la plus universelle. Le principe : surveiller la validation loss à chaque epoch. Si elle ne s’améliore plus pendant N epochs consécutives (la « patience »), arrêter l’entraînement et restaurer les poids du modèle au point où la validation loss était minimale.

# Early stopping avec PyTorch (logique simplifiée)
best_val_loss = float('inf')
patience = 10
counter = 0

for epoch in range(max_epochs):
    train_loss = train_one_epoch(model, train_loader)
    val_loss = evaluate(model, val_loader)

    if val_loss = patience:
            print(f"Early stopping à l'epoch {epoch}")
            break

# Charger le meilleur modèle pour l'évaluation finale
model.load_state_dict(torch.load('best_model.pt'))

Sans early stopping, un entraînement trop long dégrade les performances de généralisation. Avec, le modèle s’arrête automatiquement au point optimal. C’est une pratique standard dans quasiment tous les projets de deep learning.

Sélection des hyperparamètres

Le validation set est le terrain de jeu pour la recherche d’hyperparamètres. Vous testez plusieurs valeurs de learning rate, de taille de batch, de nombre de couches ou de coefficient de régularisation, et vous retenez la configuration qui minimise la validation loss (ou maximise la métrique de validation choisie).

Les méthodes de recherche les plus courantes :

Grid search. Tester toutes les combinaisons possibles d’une grille prédéfinie d’hyperparamètres. Exhaustif mais coûteux : 5 valeurs × 5 valeurs × 5 valeurs = 125 entraînements.

Random search. Échantillonner aléatoirement dans l’espace des hyperparamètres. Souvent plus efficace que le grid search car il explore mieux l’espace, surtout quand certains hyperparamètres ont plus d’impact que d’autres.

Bayesian optimization. Utiliser un modèle probabiliste (processus gaussien) pour prédire quelles configurations sont les plus prometteuses et les tester en priorité. Plus efficace en nombre d’essais, mais plus complexe à implémenter. Outils : Optuna, Hyperopt, Weights & Biases Sweeps.

Construire un bon validation set

Taille

Le validation set doit être assez grand pour que les métriques soient stables (pas de variation excessive d’une évaluation à l’autre) mais pas trop grand au détriment du training set. Les proportions courantes :

Pour les grands datasets (>100K exemples) : 10% suffit (10 000+ exemples de validation). Pour les datasets moyens (1K-100K) : 15-20%. Pour les petits datasets (<1K) : la validation croisée k-fold est préférable à un split fixe.

Stratification

Comme pour le test set, le validation set doit refléter la distribution des classes du dataset. Utilisez l’échantillonnage stratifié pour garantir que chaque classe est proportionnellement représentée. En Python :

from sklearn.model_selection import train_test_split

# Premier split : séparer le test set (20%)
X_temp, X_test, y_temp, y_test = train_test_split(
    X, y, test_size=0.2, stratify=y, random_state=42
)

# Second split : séparer le validation set (25% des 80% = 20% du total)
X_train, X_val, y_train, y_val = train_test_split(
    X_temp, y_temp, test_size=0.25, stratify=y_temp, random_state=42
)
# Résultat : 60% train, 20% validation, 20% test

Cas des données temporelles

Pour les séries temporelles, le validation set correspond à une période chronologique intermédiaire entre le training set (le plus ancien) et le test set (le plus récent). Par exemple, pour des données 2020-2026 : training sur 2020-2024, validation sur janvier-juin 2025, test sur juillet 2025-mars 2026. Le split aléatoire est interdit car il introduit un leakage temporel.

Cas des données groupées

Si vos données contiennent des groupes naturels (plusieurs échantillons par patient, par utilisateur, par session), le split doit se faire au niveau du groupe. Utilisez GroupShuffleSplit ou GroupKFold de scikit-learn pour garantir qu’aucun groupe ne se retrouve à la fois dans le train et la validation.

La validation croisée comme alternative

Pour les petits datasets, allouer 15-20% à un validation set fixe réduit trop le training set. La validation croisée k-fold offre une alternative élégante.

Principe. Divisez les données en k parties (folds). Pour chaque fold, entraînez sur les k-1 autres et évaluez sur le fold retenu. Répétez k fois. La performance moyenne sur les k folds est votre estimation de validation. Chaque exemple sert exactement une fois de validation.

Avantages. Utilisation maximale des données (tout le dataset sert à la fois au training et à la validation). Estimation plus stable (moyenne de k évaluations au lieu d’une seule). Pas besoin de choisir quel sous-ensemble sera le validation set.

Inconvénients. k fois plus coûteux en calcul. Et si vous utilisez la cross-validation pour sélectionner les hyperparamètres, vous avez toujours besoin d’un test set séparé pour l’évaluation finale non biaisée.

Variantes. Stratified k-fold (préserve les proportions de classes), GroupKFold (respecte les groupes), TimeSeriesSplit (respecte l’ordre chronologique), Leave-One-Out (k = nombre d’exemples, utile pour les très petits datasets).

La validation dans l’entraînement des LLM

Le processus de validation des grands modèles de langage diffère sur plusieurs points des projets ML classiques.

Pendant le pré-entraînement

Les LLM sont pré-entraînés sur des corpus si vastes (milliers de milliards de tokens) qu’un split train/validation classique est impraticable. La validation se fait sur un sous-ensemble fixe du corpus, et la métrique principale est la perplexité (mesure de « surprise » du modèle face au texte de validation). Une perplexité qui baisse indique que le modèle s’améliore. Mais la perplexité seule ne capture pas les capacités émergentes du modèle (raisonnement, instruction following), d’où l’utilisation de benchmarks d’évaluation complémentaires.

Pendant le fine-tuning

Pour le fine-tuning supervisé (SFT) et l’alignement (RLHF, DPO), les datasets sont plus petits et un validation set classique est utilisé. La validation monitoring la loss mais aussi des métriques spécifiques : qualité des réponses, respect des instructions, taux de refus approprié, etc. L’early stopping est appliqué pour éviter que le modèle ne perde ses capacités générales en sur-ajustant aux données de fine-tuning (phénomène de « catastrophic forgetting »).

Évaluation humaine

Pour les LLM, les métriques automatiques ne capturent qu’une partie de la qualité. L’évaluation humaine (annotateurs qui jugent la pertinence, la factualité, le ton des réponses) joue un rôle de « validation qualitative » complémentaire aux métriques quantitatives. Des plateformes comme LMSYS Chatbot Arena permettent une évaluation comparative en conditions réelles.

La validation dans les projets concrets

Computer vision

En classification d’images, le validation set sert à comparer les architectures (ResNet vs EfficientNet vs Vision Transformer), les stratégies de data augmentation et les hyperparamètres d’entraînement. La pratique standard est de monitorer simultanément la validation loss et la validation accuracy (ou mAP pour la détection d’objets). Quand vous faites du transfer learning à partir d’un modèle pré-entraîné, le validation set est particulièrement important pour calibrer le nombre d’epochs de fine-tuning : trop peu et le modèle n’apprend pas votre domaine, trop et il oublie les features génériques apprises pendant le pré-entraînement.

NLP et classification de texte

En NLP, le validation set guide le choix entre modèles (BERT vs RoBERTa vs un modèle plus léger), le learning rate optimal (souvent entre 1e-5 et 5e-5 pour le fine-tuning de Transformers) et le nombre d’epochs (typiquement 3 à 5 pour le fine-tuning de modèles pré-entraînés). Pour les datasets déséquilibrés (sentiment, détection de toxicité), surveillez le F1-score par classe sur le validation set plutôt que l’accuracy globale.

Données tabulaires

Pour les problèmes tabulaires classiques (prédiction de churn, scoring de crédit, prévision de ventes), la validation croisée k-fold est souvent préférable à un split fixe, car elle produit une estimation plus robuste de la performance. Les algorithmes de gradient boosting (XGBoost, LightGBM) intègrent nativement la validation : le paramètre early_stopping_rounds arrête l’ajout d’arbres quand la performance de validation ne s’améliore plus.

Erreurs fréquentes

Confondre validation set et test set. C’est l’erreur la plus courante. Le validation set guide les décisions ; le test set évalue le résultat final. Si vous n’avez qu’un seul « holdout » que vous utilisez pour tout (choisir les hyperparamètres ET rapporter les résultats), votre évaluation est biaisée.

Validation set trop petit. Un validation set de 50 exemples produit des métriques très bruitées : un seul exemple mal classé change l’accuracy de 2%. Les décisions prises sur des métriques bruitées sont des décisions aléatoires. Assurez-vous que le validation set est assez grand pour des mesures stables.

Appliquer la data augmentation au validation set. La data augmentation s’applique uniquement au training set. Le validation set doit contenir des données « naturelles » qui reflètent les conditions réelles, sinon l’estimation de performance est faussée.

Fuite de données entre train et validation. Si des exemples (ou des groupes d’exemples) apparaissent dans les deux, le modèle est évalué sur des données qu’il a déjà vues. Vérifiez systématiquement l’absence de doublons et respectez les frontières de groupes.

Prendre les métriques de validation pour des résultats définitifs. La performance de validation est une estimation optimiste (puisque vous avez optimisé vos choix pour ce set). La performance de test est la seule estimation fiable de la performance en production. Rapportez toujours les métriques de test, pas celles de validation.