Comment détectez-vous une fuite de données dans un modèle ?

Soupçonnez une fuite dès que la performance est étonnamment bonne. Les contrôles principaux : cherchez des variables à l'importance invraisemblablement élevée, confirmez que chaque variable était connaissable au moment de la prédiction, vérifiez que le prétraitement a été ajusté à l'intérieur du pli d'entraînement, et vérifiez qu'aucune entité n'apparaît à la fois en entraînement et en test. Une chute brutale entre le hors ligne et la production est souvent une fuite qui se révèle.

Mon déclencheur, c'est la bonne nouvelle. Si un modèle bondit à 0,97 d'AUC sur un problème que le métier trouve difficile, je pars du principe que j'ai fait fuir quelque chose tant que je n'ai pas prouvé le contraire. Le test principal que je fais passer à chaque variable est une question d'horodatage : au moment où on score cet enregistrement en production, cette valeur existerait-elle, et vaudrait-elle ceci ? Un nombre surprenant d'entre elles échouent. La pire que j'aie attrapée était une variable appelée statut du compte. Elle avait l'air innocente, mais l'équipe des opérations la passait à clôturé après le départ d'un client, et l'instantané d'entraînement contenait la valeur actuelle plutôt que la valeur à la date de prédiction : le modèle lisait donc la réponse. La retirer a fait chuter l'AUC d'environ 0,94 à 0,79, ce qui était le vrai chiffre. Au-delà de ça, je vérifie que les scalers, les encodeurs et tout rééchantillonnage ont été ajustés à l'intérieur du pli, qu'aucun identifiant client ne se retrouve à la fois en entraînement et en test, et que les encodages de la cible ont été calculés hors pli. Et je regarde l'importance des variables tôt plutôt qu'en fin de parcours comme étape de reporting, parce qu'une variable qui porte l'essentiel du modèle est en général une fuite, pas une découverte.