Pourquoi un modèle étalon ?
Si vous êtes Data Scientist/ML Engineer en entreprise, on fera appel à vos compétences le plus souvent pour résoudre un problème métier difficile, où des méthodes traditionnelles échouent :
car elles sont d’une fiabilité relative ;
car elles se basent sur des hypothèses métiers très fortes et pas toujours vraies ;
car elles nécessitent beaucoup d’interventions humaines, laborieuses, coûteuses et parfois peu valorisantes pour les personnes concernées ;
car elles n’arrivent à détecter le problème que quand il est déjà trop tard.
Par conséquent, quand vous vous lancez dans vos expérimentations de nettoyage de données, de feature engineering et de test des modèles, vous devez en principe faire mieux que ces approches traditionnelles. On est donc tenu de mesurer le succès de nos initiatives ML en comparant leurs performances à celles des méthodes traditionnelles déjà existantes.
Ce point peut paraître évident une fois souligné, mais détrompez-vous ! Il est très commun de voir des projets dans lesquels des semaines sont investies pour élaborer, voir déployer un modèle de ML supervisé, en paradant son R² ou sa matrice de confusion très rassurante, sans l’avoir jamais comparé à une méthode traditionnelle existante !
Depuis tout à l’heure, on parle de “méthodes traditionnelles”… mais de quoi parle-t-on exactement ici ?
Commençons par l’exemple le plus commun en entreprise !
Découvrez les méthodes rule-based
Aussi appelées des méthodes à base de “logique métier” ou de “règles métier”, ce sont les méthodes que vous croiserez tout le temps (si ce n’est pas déjà fait !).
Le principe est très simple, on va définir un certain nombre de règles fixes qui aboutissent à un nombre fini de résultats ou d'actions possibles. Puis, on passe la donnée au crible de ces règles pour arriver à l’un des résultats ou actions.
Prenons un exemple plus concret avec notre projet fil rouge ! Si on souhaite estimer le prix d’un bien immobilier, on pourrait imaginer un ensemble de règles qui se basent sur les caractéristiques du bien pour réaliser l’estimation. Quelque chose de la sorte :
On commence par dire que le prix estimé du bien serait le prix moyen au m2 de la ville ;
Si c’est une maison, on augmente de 10% l’estimation ;
S’il y a une piscine, on rajoute 5% ;
Si c’est à moins de 10 min à pied d’une gare, on rajoute 10% ;
Par contre, si le bien est dans la proximité immédiate de la gare, on baisse de 5% à cause du bruit occasionné.
Et ainsi de suite. En général, ce sont des experts (dans notre exemple, des professionnels de l’immobilier) qui vont élaborer ces règles. L’intelligence derrière ce genre d’approche est contenue dans la conception des règles elles-mêmes, qui en principe devraient couvrir les cas de figure pertinents pour résoudre le problème métier.
En revanche, ce genre d’approches présente des limitations structurelles :
On peut complexifier indéfiniment les règles citées en rajoutant encore et encore des cas de figure, rendant l’approche difficile d’utilisation.
La conception de ces règles est souvent accompagnée d’hypothèses définies au doigt mouillé, avec une part d’arbitraire. On pourrait se dire : pourquoi une augmentation de 10% et pas de 7% ou 4% quand on a un bien à 10 minutes de la gare ?
Ce genre de règles mettent dans le même lot tous les biens immobiliers, alors que chaque région ou département a sa propre réalité locale. Or, on peut imaginer que ces règles fonctionnent mieux pour une région et pas pour une autre. Si on pousse la logique jusqu’au bout, il faudrait avoir autant de méthodes rule-based que de régions, voire de départements, ce qui devient rapidement fastidieux et ingérable.
Pour toutes les raisons citées ci-dessus, ces règles sont difficiles à maintenir, d’autant plus que le marché de l’immobilier peut rapidement changer, lors d’un évènement majeur ou d’une crise économique.
En effet, votre modèle supervisé sera en principe utilisé par d’autres membres de l’entreprise, moins technique, et qui ont souvent l’habitude de méthodes rule-based ! Si vous leur proposez un modèle supervisé très performant, sans avoir démontré de manière convaincante que ce modèle dépasse largement en fiabilité la méthode rule-based, vous risquez d’être confronté à de la résistance au changement, vous empêchant d’aller au bout de votre projet !
OK, d’accord, les méthodes rule-based sont importantes. Mais une fois que j’ai sécurisé un modèle de ML avec de meilleures performances, faut-il jeter à la poubelle ces méthodes rule-based ?
Pas nécessairement ! Il est courant dans un projet ML de déployer votre modèle “petit à petit”. En effet, des fois, vous n’avez pas accès à toute la donnée de l’entreprise qui serait pertinente pour utiliser votre modèle. Ou alors, parfois, certaines équipes sont prêtes à utiliser votre modèle mais pas d’autres, par manque de disponibilité ou de ressources, etc.
Dans ces cas-là, vous allez souvent avoir votre modèle de ML et votre méthode rule-based qui coexistent ! On en parlera plus en détail dans la partie 3 quand on parlera des stratégies de déploiement de votre modèle.
Une autre astuce intéressante pour faciliter l’adoption de votre modèle par vos clients tout en augmentant potentiellement la performance de l’algorithme serait d’utiliser les règles métiers de la méthode rule-based comme features pour entraîner votre modèle.;) Elles sont d’office pertinentes, car pensées par des personnes qui connaissent le problème métier en principe mieux que vous !
Utilisez les modèles “dummy” et linéaires comme étalons
Un autre étalon qu’on peut mettre en place pour évaluer votre modèle non-linéaire supervisé serait d’utiliser un modèle simple… voire bête ! Oui, je dis bien bête, car c’est bien le rôle de ce que l’on appelle un Dummy Regressor ou un Dummy Classifier !
Le Dummy Regressor est un modèle qui va prédire votre target du jeu de test… en disant qu’elle sera toujours égale à la moyenne des différentes valeurs de target du jeu de train !
En effet, c’est un modèle sans aucune features ! Ce n’est donc pas un modèle de ML (même si cela reste techniquement un modèle statistique ;)) et c’est pour cela qu’on appelle ce modèle bête, car l’intelligence derrière les modèles de ML réside dans leur capacité à trouver un lien fiable entre des features et des cibles.
Concernant le Dummy Classifier, c’est le même principe : le modèle va reprendre les proportions de vos classes dans le jeu de train et va décider aléatoirement de la classe associée à chaque observation de votre jeu de test en utilisant ces mêmes proportions.
Plus concrètement, reprenons le projet fil rouge :
Les proportions pour les 2 classes sont de 68% et 32%.
Donc pour chaque observation du jeu de test, le Dummy Classifier :
a une probabilité de 68% d’attribuer la classe 0 ;
a une probabilité de 32% d’attribuer la classe 1 ;
on suppose ici, qu’on a fait un split Train-Test avec stratification, ce qui est toujours une bonne idée, bien sûr. ;)
D'un point de vue code, les modèles Dummy sont à utiliser de la même manière que tous les autres modèles de Scikit-learn :
from sklearn.dummy import DummyRegressor, DummyClassifier
dummy_regressor = DummyRegressor()
dummy_classifier = DummyClassifier()
dummy_regressor.fit(X_train, y_train_regression)
dummy_classifier.fit(X_train, y_train_classification)
dummy_regressor.fit(X_train, y_train_regression)
dummy_classifier.fit(X_train, y_train_classification)Maintenant qu’on a parlé des modèles “bêtes”, parlons des modèles simples. Mais on ne va pas en parler longtemps car vous les connaissez déjà ! Il s’agit des modèles linéaires : Regression linéaire et logistique !
Comme expliqué lors de la partie précédente, ils ont l’avantage d’être plus simples à utiliser que leurs cousins non-linéaires et parfois leur performance est suffisamment bonne ! Utiliser un modèle non-linéaire comme XGBoost alors que votre modèle linéaire est déjà fiable serait comme employer un boulet de canon pour tuer une mouche.
On peut aussi inverser alors la logique et dire que les modèles linéaires sont de bons benchmarks dans votre projet de ML supervisé : Si votre modèle non-linéaire ne dépasse pas de très loin les performances du modèle linéaire, alors il pourrait valoir le coup d’utiliser ce dernier et profiter de sa transparence et de sa simplicité. ;)
À vous de jouer !
Réfléchissez à une logique de modèle étalon pour vos algorithmes de régression et codez là en Python.
Une fois que vous avez fini, vous avez ce corrigé à disposition qui vous propose une méthode de la sorte.
En résumé
Les modèles étalons sont essentiels pour comparer les performances de votre modèle supervisé avec des méthodes traditionnelles, comme les règles métiers (rule-based), et éviter de déployer un modèle inutilement complexe si une méthode simple fonctionne déjà mieux.
Les méthodes rule-based sont des ensembles de règles métiers fixes, souvent créées par des experts, mais elles sont limitées par leur rigidité et leur complexité croissante.
Les modèles "dummy" (comme le Dummy Regressor et le Dummy Classifier) servent de référence de base en prédisant des moyennes ou des proportions, sans utiliser de features. Si votre modèle supervisé ne fait pas mieux qu’un modèle dummy, c’est que vos features manquent de pertinence.
Les modèles linéaires (régression linéaire, logistique) peuvent aussi servir de benchmark. Si un modèle non-linéaire (comme XGBoost) n’apporte pas de gains significatifs, mieux vaut rester sur le modèle linéaire pour sa simplicité et sa transparence.
Maintenant que vous comprenez l'importance d'utiliser des modèles étalons pour évaluer vos algorithmes, il est temps d'aller plus loin en apprenant à évaluer vos modèles !
