Comprendre les approches Model-centric vs Data-centric
Avant d’illustrer l’importance de la préparation des données dans l’apprentissage supervisé, rappelons la distinction entre une approche Model Centric et Data Centric.
Ce concept est abordé en détail dans le chapitre sur le jeu de données du cours d’initiation. Mais en résumé :
L’approche Model-Centric consiste à figer le jeu de données (features, cible et observation) et à concentrer l’effort sur la recherche du meilleur modèle possible (c’est-à-dire meilleur algorithme + meilleurs hyperparamètres).
L’approche Data-Centric consiste à concentrer l’effort sur l’amélioration continue du jeu de données avant de s’intéresser à la question du meilleur modèle possible.
Aujourd’hui, dans la quasi-totalité des projets de ML en entreprise, c’est bien l’approche Data-Centric qui prime et qui porte ses fruits. En effet, si vous souhaitez améliorer votre modélisation supervisée, vous gagnerez toujours plus en termes de performances et de temps à miser sur les features plutôt que sur le modèle. C’est pour cela qu’une connaissance très fine des modèles et de leurs particularités n’est pas une compétence indispensable, comme évoqué dans le chapitre précédent.
Cette règle n’est pas une vérité absolue, parce que chaque jeu de données à ses propres spécificités. Mais elle reste une approche efficace qui vous évite de tester des modèles inutilement. Effectivement , intégrer une nouvelle feature très utile pour votre modèle peut invalider votre choix d’hyperparamètres obtenu via un assortiment initial de features, désormais obsolète.
D’accord, on verra dans les prochains chapitres la qualité d’évaluation des modèles. Mais comment travaille-t-on la qualité des features ?
Eh bien, nous y voici !
Le Feature Engineering… ou le bon sens !
On appelle Feature Engineering la procédure qui consiste à créer des features à partir d’autres features existantes, où à partir de la donnée source dont elles sont issues. L’objectif étant d’apporter de nouveaux ingrédients au modèle pour augmenter sa performance et/ou combattre de l’overfit.
Pour ce faire, on se base sur la compréhension du contexte métier derrière la donnée et aussi sur l’intuition. Oui ! J’ai bien dit l’intuition ! Car le feature engineering n’est pas une science exacte, certains le qualifient même d’art !
Nous allons éclairer tout ça dans le screencast qui suit via des exemples :
Nous avons exploré plusieurs pistes pour créer des features et sommes maintenant prêts pour construire des modèles, n'est-ce pas ? Eh bien... pas tout à fait ! Il y a une étape très importante à mener pour s'assurer que nos features ne vont pas perturber l'apprentissage du modèle. Il s'agit de l'analyse des corrélations !
Cette étape est spécifique aux features numériques, regardons ensemble comment se servir de la matrice de corrélation :
Maintenant, que vous en savez plus sur le Feature Engineering, on peut se permettre de complexifier légèrement le schéma qu’on a vu dans le chapitre précédent.
En effet, l’ensemble du feature engineering que l’on a vu ensemble pendant les screencasts se base sur des jeux de données qui ont déjà été nettoyés, filtrés et préparés pour rendre les différents calculs possibles et pertinents. Dans un projet de ML en entreprise, nous n’avons quasiment JAMAIS de données propres prêtes à l’emploi pour créer des features. En règle générale, vous devez réaliser à minima une partie du nettoyage par vous-même pour pouvoir élaborer les features que vous souhaitez.
Quels guidelines dans le feature engineering ?
Le feature engineering est un exercice très subjectif, chaque Data Scientist/ML Engineer aura sa propre compréhension du jeu de données et ses propres idées pour enrichir un modèle avec de nouvelles features. C’est pour cela que deux projets de ML peuvent ne pas se ressembler du tout, même quand ils utilisent la même donnée ! En revanche, il y a certains réflexes importants qu'il faut adopter pour guider la réflexion.
C’est une erreur très courante chez les profils débutants ! En effet, tout l’intérêt du Machine Learning est de laisser le modèle, et non l’humain, décider quelles sont les features qui aident le plus le modèle à réaliser une prédiction fiable.
Pourquoi ? Parce qu’en tant qu’êtres humains, nous avons tous nos biais, nos hypothèses et nos angles morts dans la compréhension d’un jeu de données. Ainsi, nous allons risquer d’arbitrairement de mettre plus de poids sur certaines features qui nous paraissent essentielles, et de sous-estimer d’autres features qui nous paraissent peu intéressantes.
C’est un raisonnement dangereux car il n’y a aucune garantie que les features que l’on trouve intéressantes soient effectivement celles qui vont plus aider le modèle dans son apprentissage, surtout quand on utilise des modèles non-linéaires complexes, capable de détecter des patterns dans notre jeu de données de plus de 3 features, alors qu’on est limité en tant qu’êtres humains à regarder en 3 dimensions.
Mais si on utilise des modèles non-linéaires, “boîtes noires", comment pouvons-nous mesurer si une feature l’influence positivement ou négativement ? Je croyais qu’on avait perdu cette interprétabilité typique des modèles linéaires…
Patience ! Nous verrons plusieurs méthodes pour ouvrir ces “boîtes noires” dans le Partie 3 de ce cours.;)
En attendant, revenons au feature engineering ! La règle précédente est primordiale, mais elle présente 2 exceptions.
La première concerne les features très corrélées entre elles. Comme vu lors des screencasts précédents, on supprime systématiquement les features très corrélées (au sens de Pearson ou de Spearman). Tout l'objectif derrière la création d'une nouvelle feature est d'apporter une nouvelle information au modèle, que les features déjà existantes ne reflètent pas.
Quant à la deuxième exception : Il faut éviter d’ajouter des features qui ne peuvent être connues que via votre target. C’est le fameux Data Leakage dont nous avons parlé pendant le screencast ! Autrement dit, on ne peut pas utiliser les conséquences pour expliquer des causes.
Un dernier conseil concernant les features catégorielles, il n’y a pas que le OneHotEncoding et le LabelEncoding ! C’est souvent un réflexe de base pour plusieurs Data Scientists de se ruer sur l’une ou l’autre des méthodes, mais notre boîte à outil favorite au nom de Scikit-learn en propose bien d’autres bien utiles, comme le TargetEncoding ou encore le FeatureHashing. Pour acquérir un niveau plus avancé, cela vaut le coup d’aller les tester ; (vous pouvez consulter l'article intitulé "The Complete Guide to Encoding Categorical Features" pour une démonstration) et pour comprendre leurs limites.
Jouez sur l’échelle des observations
Très bien, nous avons créé de nouvelles features, supprimé celles qui étaient corrélées ainsi que celles qui présentent du Data Leakage. On est prêt à lancer nos modélisations, non ? Eh bien, en fonction du type d’algorithme que nous comptons utiliser, on pourrait avoir besoin d’une étape supplémentaire. Il s’agit du scaling des features (ou “normalisation” en français).
Il s’agit d’une transformation où nous allons "écraser" les valeurs des features pour les ramener toutes à un ordre de grandeur commun (par exemple entre 0 et 1 ou entre 0 et 10).
Mais pourquoi certains algorithmes nécessitent cette mise en commun d’ordre de grandeur et pas d’autres ?
Pour pouvoir réaliser leurs prédictions, certains algorithmes réalisent certains calculs intermédiaires qui se basent sur des distances euclidiennes. Tout le problème est là : les distances euclidiennes ont une tendance naturelle à grandement favoriser les features avec les ordres de grandeur les plus importants et à ignorer les features à faible ordre de grandeur.
Ce serait dommage d’avoir fait tout ce travail de feature engineering pour qu’un algorithme en ignore potentiellement une bonne partie pour une question d’échelle de valeurs !
Maintenant que nous savons pourquoi nous devons faire du scaling, découvrons ensemble les deux méthodes de scaling les plus connues :
À vous de jouer !
Étendez la fonction "compute_features_price_per_m2" vue pendant le screencast du Feature Engineering, afin de calculer en plus :
la moyenne glissante sur 6 mois du prix au mètre carré de chaque ville ;
la moyenne glissante sur 6 mois du nombre de transactions de chaque ville.
Recalculez ensuite la matrice de corrélation pour juger s’il faut garder ces nouvelles features ou non.
Vous allez compléter ce template de code prérempli. Pour ce faire, vous pouvez utiliser Polars ou Pandas.
Ensuite, tentez de répondre à la question citée à la fin du chapitre : Pourquoi est-ce une erreur d’effectuer un scaling AVANT de séparer un jeu de données en jeu d’apprentissage et jeu de test ?
Une fois que vous avez fini, vous avez ce corrigé à disposition.
En résumé
L'approche Model-Centric consiste à fixer le jeu de données et à concentrer les efforts sur l'optimisation du modèle, en ajustant l'algorithme et les hyperparamètres.
L'approche Data-Centric se concentre sur l'amélioration continue des données avant d'optimiser le modèle. Cette approche est aujourd'hui largement privilégiée en entreprise.
Feature Engineering est la création de nouvelles features à partir de données existantes pour améliorer la performance du modèle. Cette étape, guidée par le contexte métier et parfois par l'intuition, est essentielle pour éviter le surapprentissage.
L'analyse des corrélations entre features numériques est cruciale pour éviter la redondance. On supprime les features très corrélées afin de garder des informations pertinentes et non répétitives.
Le scaling des features (ou normalisation) est une étape importante pour certains algorithmes de machine learning. Il permet de ramener toutes les valeurs des features à un ordre de grandeur commun, évitant ainsi que certaines features ne soient ignorées à cause de leur échelle différente.
Vous avez hâte d’en savoir plus sur les méthodes de test ? Rendez-vous dans le prochain chapitre !
