IA en Python : 7 frontières à sécuriser pour éviter les faux positifs

Des scores flatteurs peuvent masquer des pipelines défaillants. Fuites entre entraînement et validation, séparation inadaptée, biais entre entraînement et service, graines trompeuses, états PyTorch mal gérés, broadcasting silencieux et artéfacts non sûrs figurent parmi les causes. Des contrôles ciblés permettent de détecter ces erreurs à l’endroit exact où elles naissent.

Sécuriser les artéfacts : chargement risqué et dérives de versions

Un modèle enregistré avec pickle, joblib ou cloudpickle peut exécuter du code lors du chargement. Un fichier de cinq lignes doté d'une méthode reduce malveillante peut déclencher une charge utile à l'appel de pickle.load sans générer d'exception. Il est donc impératif de ne jamais charger un artéfact qui n'a pas été vérifié par une source de confiance. Par ailleurs, scikit-learn ne garantit pas la compatibilité des modèles enregistrés entre différentes versions de la bibliothèque. Chaque artéfact doit être accompagné de sa recette d'entraînement, d'une référence de données, des versions de dépendances et du score de validation revendiqué. Avant toute promotion, il est recommandé de charger l'artéfact dans l'environnement de service réel et de faire passer un fixture fixe à travers le prétraitement et la prédiction. Changer de format ne supprime pas ces risques, mais les déplace. Il est essentiel de charger uniquement depuis des sources de confiance et de tester la validation dans l'environnement de service.

Fuites et séparations : éviter d’entraîner sur des lignes « invisibles »

Ajuster des transformations avant la séparation des données provoque une fuite d'information : sur 100 échantillons de bruit avec 1 000 caractéristiques et des étiquettes tirées au sort, un SelectKBest ajusté sur l'ensemble puis validé en validation croisée affiche une précision de 0,83. Déplacer la sélection dans un pipeline scikit-learn pour que chaque pli ajuste sa propre transformation ramène la précision à 0,49, ce qui correspond à la performance attendue sur du bruit. Cette règle s'applique aussi à la mise à l'échelle, à l'imputation et à la réduction de dimension. Le diagnostic consiste à repérer chaque fit et fit_transform et à documenter quelles lignes étaient visibles à ce moment. Les séparations doivent aussi correspondre à la vraie frontière à généraliser. Par exemple, un jeu synthétique avec 60 utilisateurs et des lignes presque dupliquées par utilisateur atteint 0,97 avec train_test_split, puis chute à 0,89 avec GroupShuffleSplit qui isole chaque utilisateur d'un côté : l'écart de huit points reflète de la mémorisation. Les données groupées exigent GroupKFold ou GroupShuffleSplit ; les séries temporelles, TimeSeriesSplit, car une séparation aléatoire peut entraîner sur le futur pour prédire le passé. La stratification sur l'étiquette ne résout pas le problème de groupes et train_test_split ne prend pas en compte cette notion. Il faut choisir le séparateur après avoir décidé si l'on souhaite généraliser à des entités ou à des instants.

Aligner entraînement et service pour éliminer le biais de prétraitement

Réimplémenter un prétraitement côté service peut introduire des écarts importants. Par exemple, réapprendre un scaler sur cinq lignes de production au lieu de réutiliser celui ajusté à l'entraînement peut décaler une même fixture de près de quatre unités standard. L'inférence doit impérativement réutiliser les paramètres appris, l'ordre des caractéristiques, les types de données et les règles sur les valeurs manquantes définis lors de l'entraînement. La solution la plus fiable consiste à expédier l'objet de pipeline ajusté sur les deux chemins. La vérification se fait en poussant un fixture brut à travers les chemins d'entraînement et de service, puis en comparant noms, ordre, types, formes et valeurs des sorties : toute divergence indique un écart côté service.

Reproductibilité : une graine ne suffit pas, il faut tout enregistrer

Définir random.seed(42) ne suffit pas à rendre une expérience reproductible : Python, NumPy et PyTorch disposent chacun de leur propre générateur aléatoire, et un DataLoader multi-processus applique ses propres règles de semence. Les noyaux déterministes doivent être explicitement demandés et cela peut affecter les performances, comme le précisent les notes de reproductibilité de PyTorch. Même avec des graines définies, des résultats identiques ne sont pas garantis entre versions de PyTorch, entre plateformes ou entre CPU et GPU. La reproductibilité dépend de l'enregistrement des graines, des données, de la version du code, de la configuration et des dépendances. Un cours accéléré de Weights & Biases propose une méthode pour automatiser cet enregistrement.

PyTorch modifie les modules avec model.eval tandis que torch.no_grad agit sur autograd

model.eval() bascule des modules comme dropout et batch norm en mode inférence, tandis que torch.no_grad() désactive autograd sans modifier l'état des modules. Si dropout est actif, deux passages sous no_grad mais en mode entraînement peuvent produire des sorties différentes, comme illustré par les valeurs -0,1410 et 0,0071. Avec eval(), deux appels sur la même entrée donnent une réponse identique. En mode évaluation sans no_grad, les gradients continuent d'être enregistrés. Une boucle de validation doit donc combiner eval() et no_grad(), puis remettre le modèle en mode entraînement. Quand aucun gradient n'est requis, torch.inference_mode() verrouille plus strictement l'absence de gradients. Même sans dropout actuellement, il est recommandé d'appeler explicitement eval().

Formes de tenseurs : empêcher le broadcasting de fausser la perte

Si la prédiction a la forme [batch, 1] et la cible [batch], MSELoss diffuse en une matrice batch × batch. Avec un lot de 32, cela crée une grille 32 par 32 ; une perte de 1,63 peut sembler plausible alors que la version correctement formée donne 1,85 sur les mêmes tenseurs. PyTorch émet alors un UserWarning, que les tests devraient transformer en erreur. MSELoss exige que la cible ait la même forme que l'entrée : il faut donc décider du contrat de forme et l'appliquer, par exemple en utilisant squeeze(1) pour obtenir [batch] et en affirmant l'égalité des shapes avant le calcul de la perte. Tous les broadcasts ne sont pas des bugs, mais une expansion implicite est fautive aux frontières où un accord exact est requis.