Ensembles d'entraînement, de validation et de test : un exemple sans fuite de données

Il y a un moment que traversent beaucoup d'apprenants en IA appliquée : vous entraînez un modèle, il obtient un bon score sur votre ensemble de test, puis il déçoit lorsqu'il rencontre de vraies données nouvelles. Une cause possible est la fuite de données — lorsqu'une information qui devrait être cachée au modèle pendant l'entraînement s'introduit subrepticement, rendant votre score de test trop optimiste. La fuite n'est pas la seule raison pour laquelle un modèle déçoit en production : le décalage de distribution, le biais d'échantillonnage, le surapprentissage et les différences entre les pipelines d'entraînement et de déploiement comptent aussi. Mais la fuite est l'une des plus évitables, et comprendre le découpage en trois et quelques pièges courants aide beaucoup.

Les trois ensembles et leur rôle

L'ensemble d'entraînement est ce à partir de quoi le modèle apprend — il voit ces exemples et leurs étiquettes à plusieurs reprises. L'ensemble de validation est ce que vous utilisez pour régler vos décisions : quel type de modèle, quels hyperparamètres, quelles variables garder ou écarter. Le modèle ne s'entraîne jamais dessus, mais vous le consultez de nombreuses fois en décidant comment construire le modèle. L'ensemble de test est utilisé à la toute fin, pour estimer comment le modèle se comportera sur des données inédites. La discipline est simple en principe : l'ensemble de test est mis de côté jusqu'à la mesure finale, et vous évitez d'adapter les décisions sur le modèle à ses résultats.

Un exemple concret : découper un ensemble de streaming

Supposons que vous ayez 1 000 sorties de pistes, chacune avec une étiquette indiquant si elle a dépassé 10 000 écoutes en 14 jours. Un découpage illustratif courant est 600 pour l'entraînement, 200 pour la validation et 200 pour le test. Vous entraînez sur les 600, vous vérifiez sur les 200 exemples de validation, vous ajustez les hyperparamètres, vous réentraînez, vous vérifiez à nouveau — en répétant selon les besoins. Ce n'est que lorsque vous êtes satisfait que vous exécutez le modèle une fois sur les 200 exemples de test et que vous rapportez ce score. Comme l'ensemble de test n'a pas servi à prendre des décisions sur le modèle, son score est une estimation plus honnête. La fonction train_test_split de scikit-learn gère la mécanique d'un découpage ; la documentation officielle en montre l'usage exact (scikit-learn : train_test_split). Notez qu'un découpage aléatoire simple n'est qu'illustratif. Si votre but est de prédire des sorties futures, vous avez besoin de limites chronologiques, de variables disponibles au moment de la prédiction, de résultats à 14 jours arrivés à maturité et d'un regroupement approprié pour que les pistes répétées ou le même artiste n'apparaissent pas à la fois à l'entraînement et au test — un train_test_split aléatoire ne résout pas, à lui seul, cette fuite temporelle ou de groupe.

Où se cache réellement la fuite

Une fuite courante est la mise à l'échelle avant le découpage. Si vous calculez la moyenne et l'écart-type d'une variable sur les 1 000 lignes puis découpez, la mise à l'échelle de l'ensemble d'entraînement a été informée par les valeurs de l'ensemble de test. La solution est d'ajuster le scaler sur l'ensemble d'entraînement uniquement, puis de transformer les ensembles de validation et de test avec ces paramètres d'entraînement. Une deuxième fuite courante est les lignes dupliquées qui chevauchent le découpage : si la même piste apparaît deux fois et qu'une copie atterrit à l'entraînement et l'autre au test, le modèle a effectivement vu l'exemple de test. Dédupliquez avant de découper. Une troisième fuite, plus subtile, est le temps : si vos données ont un ordre temporel et que vous découpez au hasard, l'ensemble d'entraînement peut contenir une information qui n'aurait pas été disponible à la période de test. Pour les données ordonnées dans le temps, découpez chronologiquement — entraînez sur le passé, testez sur le futur.

Erreurs courantes et comment les repérer

Un signal d'alarme est un score de validation ou de test suspectement proche du score d'entraînement — les vrais modèles baissent généralement un peu sur les données inédites, et une quasi-parfaite correspondance peut signaler une fuite ou un découpage trop facile. Mais des scores d'entraînement et de test similaires à eux seuls ne prouvent pas la fuite ; ils peuvent aussi refléter une tâche facile ou un petit ensemble de données. Une autre erreur est de réutiliser l'ensemble de test après avoir vu son score : « le score de test était bas, alors essayons un autre modèle et retestons » transforme l'ensemble de test en un second ensemble de validation et affaiblit son indépendance. Une protection pratique est de noter, avant de regarder l'ensemble de test, exactement le modèle et les réglages que vous mesurez — puis de l'exécuter une fois et d'accepter le résultat. Relancer un rapport déterministe est correct ; adapter les décisions sur le modèle aux résultats du test compromet l'indépendance et, si cela arrive, exige une évaluation fraîche sur de nouvelles données.

Un exercice : construisez un pipeline conscient de la fuite

Prenez un ensemble de données et, dans le code, mettez d'abord de côté l'ensemble de test et stockez-le dans une variable distincte que vous ne touchez pas. Du reste, mettez de côté un ensemble de validation. Ajustez tout prétraitement (mise à l'échelle, imputation) sur la portion d'entraînement uniquement, et appliquez-le à la validation et au test. Entraînez un modèle, réglez-le sur la validation, puis exécutez-le une fois sur le test. Notez le score de test et ne relancez pas. Si vos données ont un ordre temporel, découpez chronologiquement plutôt qu'au hasard. La discipline de ne pas toucher une seconde fois à l'ensemble de test est tout le but de l'exercice.

Votre prochaine étape

Une fois votre découpage honnête, la compétence suivante est de bien lire les résultats — surtout quand une classe est rare et que la précision devient un chiffre trompeur. C'est le sujet du prochain article, sur la lecture d'une matrice de confusion avec des classes déséquilibrées. Pour le contexte plus large de l'inscription dans un programme d'IA structuré, voir les aperçus du programme d'IA appliquée ou le programme d'analyse de données.