Pratique avec scikit-learn

Pratique avec scikit-learn

1. Le pipeline, forme correcte d'un projet

   Le pipeline n'est pas une question de style : c'est ce qui garantit que le prétraitement appris sur les données d'entraînement s'applique ensuite exactement de la même façon à la production.

   Pourquoi l'ordre des étapes change tout

   Un scaler standardization doit calculer sa moyenne et son écart-type sur le jeu d'entraînement seulement. S'il voit aussi le test, il a laissé une information du test s'infiltrer dans l'apprentissage, et le score_final est faux. Enpipeline, chaque transformation est ajustée puis gelée : impossible d'oublier une étape.

   Entraînement complet, en une fois

   Le geste à prendre :

   from sklearn.pipeline import Pipeline
   from sklearn.preprocessing import StandardScaler
   from sklearn.linear_model import LogisticRegression
   
   pipeline = Pipeline([
       ("scaler", StandardScaler()),
       ("model", LogisticRegression(max_iter=1000)),
   ])
   pipeline.fit(X_train, y_train)

   On n'appelle fit_transform que dans fit. En validation croisée, cross_val_score réajuste le scaler sur chaque pli : c'est exactement le comportement voulu.

   Données mixtes

   Un vrai jeu de données mélange des colonnes numériques et des colonnes textuelles. ColumnTransformer applique une branche de traitement à chaque type et les recolle :

   from sklearn.compose import ColumnTransformer
   
   pre = ColumnTransformer([
       ("num", StandardScaler(), ["age", "revenu"]),
       ("cat", OneHotEncoder(handle_unknown="ignore"), ["ville"]),
   ])

   handle_unknown="ignore" n'est pas facultatif : sans lui, une ville inconnue vue à la production provoque une erreur, alors qu'elle ne peut pas faire échouer la production.

2. Validation croisée et recherche d'hyperparamètres

   Validation croisée

   Couper un jeu de données en deux en gaspille une ressource Précieuse : l'échantillon ne sera pas repris. La validation croisée en k plis répète l'entraînement k fois : chaque pli sert une fois de test, les autres d'entraînement. On obtient une estimation plus stable qu'un découpage unique.

   from sklearn.model_selection import cross_val_score, StratifiedKFold
   from sklearn.model_selection import GridSearchCV
   
   cv = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)
   scores = cross_val_score(pipeline, X, y, cv=cv, scoring="f1")

   StratifiedKFold plutôt que KFold en classification : il conserve la proportion de classes dans chaque pli, ce qui évite un pli sans aucun positif. random_state fixe le hasard : sans lui, deux exécutions ne donnent pas le même score et l'expérimentation devient ininterprétable.

   Recherche d'hyperparamètres

   Les hyperparamètres ne sont pas appris : ils sont choisis. On les nomme avec une double barre pour que la grille s'écrive dans l'espace des étapes du pipeline :

   grille = {
       "model__C": [0.01, 0.1, 1, 10],
       "model__class_weight": [None, "balanced"],
   }
   
   rech = GridSearchCV(pipeline, grille, cv=cv, scoring="f1", n_jobs=-1)
   rech.fit(X_train, y_train)
   print(rech.best_params_, rech.best_score_)

   Ce que la recherche ne pardonne pas

   • Chercher sur le test : le score final n'a plus de valeur.
   • Comparer avec des métriques différentes : on choisit la configuration qui gagne sur une métrique et on l'évalue sur une autre. Ce n'est pas une sélection, c'est du bruit.
   • Faire tourner un GridSearchCV sur l'ensemble X_train/y_train puis regarder best_score_ et le prendre pour une performance : best_score_ est déjà optimiste, car il retient le maximum d'une série d'essais. Il faut évaluer le modèle choisi sur un jeu test qui n'a jamais servi.

3. Biais, équité et coût du modèle

   Un modèle reproduit les biais de ses données

   Un jeu d'entraînement hérité d'un historique discriminatoire produit un modèle qui reproduit cette discrimination, avec un score excellent. La performance mesurée ne dit rien de l'équité.

   On ne « corrige » pas un biais en changeant d'algorithme. On agit en amont et à l'aval :

   • mesurer les écarts de performance par groupe (sexe, âge, situation, territoire) ;
   • rééquilibrer les données ou pondérer les erreurs ;
   • revoir la formulation du problème : certains critères sont eux-mêmes le biais ;
   • documenter la limite connue plutôt que la cacher.

   Le seuil de décision est un arbitrage

   Baisser le seuil de décision détecte plus de vrais positifs et produit plus de faux positifs. Ce n'est ni un bug ni un réglage technique : c'est une décision sur le coût relative de chaque erreur, à prendre avec le métier, et à écrire.

   Le coût, pas seulement le score

   Un modèle à 94 % d'exactitude peut coûter plus cher qu'un modèle à 88 % : inférence coûteuse, maintenance, explication obligatoire, reprise d'une mauvaise décision. Un projet se juge sur un ensemble de critères, dont le score n'est qu'un.

   Confortable, exact, et faux

   La vraie question n'est pas « le modèle est-il exact ? » mais « quand il se trompe, a-t-il tort avec confiance ? ». On mesure cela par la calibration : des prédictions annoncées à 80 % doivent être correctes environ 80 % du temps. Un modèle non calibré inspire une confiance injustifiée, et c'est ainsi que naissent les mauvaises décisions automatiques.