Fuite de données en apprentissage automatique : comment des informations issues du futur ou de l'ensemble de test s'infiltrent dans un modèle

Ce que c'est

La page de scikit-learn consacrée aux pièges définit la fuite de données comme l'utilisation, lors de la construction du modèle, d'informations qui ne seraient pas disponibles au moment de la prédiction, et indique que le résultat est une estimation de performance excessivement optimiste, suivie d'une performance moindre sur des données réellement nouvelles. Sa règle générale : les données de test ne doivent jamais servir à faire des choix concernant le modèle, et fit n'est jamais appelé sur les données de test, y compris le fit des étapes de prétraitement telles que les normaliseurs, les imputateurs et les encodeurs. La page recommande un Pipeline afin que chaque étape soit ajustée uniquement sur le pli d'entraînement, y compris au sein de la validation croisée.

Pourquoi c'est important

La fuite ne déclenche aucune erreur. Le score de validation paraît excellent, le modèle est mis en production, et l'écart n'apparaît que lorsque les prédictions réelles sont comparées aux résultats réels, des semaines plus tard. D'ici là, le chiffre obtenu hors ligne aura déjà été cité dans des décisions.

Comment l'appliquer

• Placer chaque transformation dépendante des données (normalisation, imputation, encodage, sélection de caractéristiques, rééchantillonnage) à l'intérieur du pipeline soumis à la validation croisée, jamais avant la partition.
• Auditer chaque caractéristique pour détecter une fuite de la cible : une colonne renseignée après que le résultat est connu (un indicateur « remboursement émis » pour prédire l'attrition, un code de diagnostic pour prédire une admission) prédit parfaitement la cible et est inutile au moment de la prédiction.
• Vérifier les horodatages : chaque valeur de caractéristique doit pouvoir être calculée à partir de données qui existaient au moment où la prédiction aurait été faite. Des agrégats comme « total des achats » doivent être arrêtés à cet instant.
• Garder les lignes d'une même entité d'un seul côté de la partition à l'aide de répartiteurs sensibles aux groupes tels que GroupKFold, que le guide de validation croisée décrit précisément pour ce cas.
• Se méfier des scores très supérieurs à la référence ou à ce que les experts du domaine jugent possible ; la fuite est la première hypothèse à tester.

Pièges

Une déduplication effectuée après la partition laisse des quasi-doublons des deux côtés. Une sélection de caractéristiques sur l'ensemble du jeu de données avant la validation croisée fait fuiter la cible à travers les colonnes sélectionnées. Un encodage de cible ajusté sur les mêmes lignes qu'il encode fait fuiter l'étiquette dans la caractéristique.