Sommaire
- Introduction
- Pièges à éviter
2.1. Analyser toutes les données
2.2. Ne pas discuter avec les experts du domaine
2.3. Créer un leak entre l'entraînement et le test
2.4. Ne pas anticiper le volume de données nécessaire
2.5. Ne pas réfléchir aux problématique de déploiement
2.6. Entraîner l'hyperparametrisation sur le test ou la validation
2.7. Utiliser l'accuracy sur un dataset déséquilibré
2.8. Généraliser au-delà des données disponible - Conclusion
- Références
Introduction
Le machine learning, et plus généralement la data science, sont des domaines en expansion et qui sont de plus en plus utilisés de nos jours. Cela par un panel de profils divers et avec des objectifs variés. Certains ont suivi une formation de mathématiques ou de statistiques, d'autres viennent du développement, se sont reconvertis ou encore sont autodidactes. Peu importe le niveau de compréhension que chacun souhaite avoir en utilisant un algorithme ensembliste robuste, en important la dernière librairie de NLP ou d'hyper-paramétrisation, il est important de suivre certaines bonnes pratiques pour s'assurer de la bonne utilisation des technologies et des concepts. Cela permet de limiter l'introduction de biais, de fiabiliser ses résultats, ou encore d'avoir des évaluations précises de son approche.
C'est ce dont traite le papier How to avoid machine learning pitfalls: a guide for academic researchers[^1]. On propose ici d'en faire une note de lecture. On essaiera de restituer ces informations sans nécessairement se les approprier.
Aussi, on ne parlera que des points qu'on pense être proche et applicable dans un contexte industriel, les autres étant assez proches de l'académique.
Pièges à éviter
Analyser toutes les donnees
En regardant et analysant toute la data sans faire de séparation au préalable, on risque de s'orienter vers
certains choix. Le problème c'est dès lors qu'on s'est construit des apriori sur toutes nos données il est
difficile de vérifier et de backer nos actions et nos choix. En général, on préfère garder un échantillon de
données qui servira à valider nos a priori et nos choix.
La taille de l'échantillon est souvent entre 10% et 30% mais cela dépendra du use case. La convention est même
de se baser sur une partie train d'abord pour ce travail, un set de validation (parfois appelé
évaluation) par rapport auquel vous allez essayer de performer. Enfin, un dataset de test qui doit servir
à évaluer votre modèle que vous pensez le plus évolué.
L'idée du Machine Learning est de pouvoir généraliser un modèle. Si on utilise un modèle sans vérifier sa
capacité à généraliser on fait un pas vers l'inconnu et on perd de la maîtrise.
Ne pas discuter avec les experts du domaine
La datascience doit rester pragmatique et proche des problématiques business. Si on n'est pas familier du sujet ou qu'on a une connaissance limitée du domaine applicatif, il est facile d'opter pour des modélisations sous optimales par exemple, ou encore d'adresser le mauvais problème. En échangeant avec un expert, on peut repérer quelle feature il serait intéressant de tester, de développer une meilleure compréhension des données et acquérir des insights.
Par exemple, dans notre cas, notre produit est appliqué au domaine de l'intérim. On se doit donc d'avoir une idée précise sur les enjeux liés. On procéde donc régulièrement à des échanges avec des consultants en recrutement et autre responsable d'implants.
Créer un leak entre l'entraînement et le test
Si il ne fallait garder une chose à éviter, celui-ci serait sûrement le meilleur candidat. Lorsque vous
développez votre modèle vous ne devez surtout pas utiliser de données issues de votre dataset de validation.
Par exemple, pour normaliser vos données avec un MinMaxScaler il faut seulement utiliser le max sur le
train. Même pour normaliser vos données de test pendant l'évaluation il faudra toujours utiliser le même max
issu du train. Autrement vous allez lier vos données de test à vos données de train. Votre algorithme pourrait
se baser sur ce data leakage et vous aurez une évaluation trompeuse et imprécise. Assez facile à
implementer avec sklearn
from numpy import asarray
from sklearn.preprocessing import MinMaxScaler
# Define Data
# # Train Data
data_train = asarray([
[100, 0.001],
[8, 0.05],
[50, 0.005],
[88, 0.07],
[4, 0.1]
])
# # Validation Data
data_val = asarray([
[67, 0.01],
[4, 0.35],
[70, 0.028],
])
# Fit the minmax transformer on train data
scaler = MinMaxScaler()
scler.fit(data_train)
# Apply the minmax transformer
data_train_scaled = scaler.transform(data_train)
data_val_scaled = scaler.transform(data_val)
Ne pas anticiper le volume de données nécessaire
Une grande partie de la datascience est de repérer des signaux dans les données pour en tirer un modèle de prédiction. Une des principales contraintes est la généralisation du modèle et on doit donc s'assurer que ce dernier ne produise pas d'overfitting. Ceci étant dit, si les signaux repérés sont faibles ( à travers la corrélation, une méthode d'explicabilité, de la data visualization etc) on doit s'assurer d'avoir un volume suffisant sur les données. Un modèle entraîné sur peu de données et où les patterns sont faibles aura du mal à généraliser convenablement et à être performant sur de nouvelles data.
Il faudra alors envisager d'enrichir ses données (data augmentation) ou alors de faire le compromis en optant pour un modèle moins complexe car ils overfit moins.
Ne pas réfléchir aux problématique de déploiement
Si notre produit de machine learning doit répondre à une problématique "real-world" il est nécessaire de prévoir les contraintes liées à ce use case. Ces contraintes peuvent aller du technique à de la UX. Par exemple, dans un contexte où une latence de 5 secondes constituerait une mauvaise UX, on sera amené éventuellement à préférer un modèle ou système avec un temps de réponse plus court même si moins performant. Un autre exemple serait les ressources dont disposera le système utilisant notre produit. Il ne serait pas très avisé de développer un modèle complexe, coûteux ou non optimisé sur un environnement ayant peu de ressources.
Il est important de réfléchir en scalabilité, maintenabilité, latence etc. Le rôle d'un Machine Learing
Engineer ou d'un MLOps pourrait être nécessaire pour apporter une expertise sur ces questions là.
Une analogie que j'apprécie pour comprendre le rôle d'un Machine Learning Engineer est celle donnée par Cassie
Kozyrkov, Chief Decision Scientist chez Google, dans la préface de Machine Learning Engineering par Andriy
Burkv [^2]:
I’d like to let you in on a secret: when people say “machine learning” it sounds like there’s only one discipline here. Surprise! There are actually two machine learnings, and they are as different as innovating in food recipes and inventing new kitchen appliances. Both are noble callings, as long as you don’t get them confused; imagine hiring a pastry chef to build you an oven or an electrical engineer to bake bread for you!
Entraîner l'hyperparametrisation sur le test ou la validation
Une fois que vous avez essayé et comparé plusieurs modèles entre eux et que vous avez choisi l'algorithme le plus approprié par rapport à votre problématique, vous allez éventuellement entraîner une hyperparamétrisation. Les hyperparamètres sont des scalaires qui vont affecter la manière avec laquelle votre modèle va apprendre, tous les modèles ne sont pas concernés. Un SVM ou random forest ont des hyperparamètres ( respectivement le noyau ou le nombre d'arbres) mais une OLS n'en a pas. On entraîne une hyperparamétrisation pour améliorer les performances d'un modèle. Cependant, il est dangereux de choisir vos hyperpramètres sur un jeu de données différent de celui sur lequel vous avez entraîné votre modèle. Le choix des hyperparamètres est une étape de l'entraînement à part entière et elle ne doit pas être faite sur les données de test ou de validation mais de train. Autrement, cela constituerait un sujet de data leakage.
Utiliser l'accuracy sur un dataset déséquilibré
Pour des données issues du monde réel vous risquez de vous heurter à des problèmes d'imbalanced learning ou d'apprentissage déséquilibré. Par exemple, dans un contexte d'application à la santé, si vous travaillez sur des images radio pour des patients dont on suspecte qu'ils sont atteints d'une pneumothorax, il y aura certainement beaucoup plus de personnes saines (label 0) que de personnes atteintes (label 1). Mettons que votre dataset soit constitué de 90% de label 0 et seulement 10 % de label 1. Dans ce cas là un modèle renvoyant systématiquement 0 aura une accruacy de 90%. Vous avez dans ce cas là fait une évaluation qui n'est pas appropriée à vos données.
Généraliser au-delà des données disponibles
On peut parfois être tenté de généraliser un modèle ou un insight mais il est important de l'utiliser dans son contexte. Éventuellement, vous pouvez subir un de ces problèmes :
- Le biais d'échantillonnage : les données utilisées ne sont pas suffisamment représentatives de toute votre base d'utilisateur.
- Qualité de la donnée : vos dataset contiennent beaucoup de bruits et peu d'instance de qualité
- Biais communs des dataset : vous avez effectué votre analyse et/ou tester votre modèle sur plusieurs jeux de données mais ils portent les mêmes biais
Il faut donc toujours garder des précautions quand on veut généraliser son modèle en l'utilisant sur des données différentes ou lorsqu'on communique des informations ou des insights au business
Conclusion
On a proposé ici une revue des pièges à éviter lorsqu'on vous utiliser des techniques de machine learning. Ces
notions sont pour la plupart plutôt basiques mais demeurent des sources de lacunes qu'on peut souvent
retrouver.
Il demeure tout de même intéressant de revenir à ces lectures basiques pour réviser un petit peu ma théorie et
de remettre en question ses manières de faire.
La liste qu'on a faite n'est pas exaustive et aurait par exmple pu contenir des sujets plus spécifiques (NLP, Computer Vision, Speech to text, etc).
Références
[^1]: Michael A Lones. 2021. How to avoid machine learning pitfalls: a guide for academic researchers. arXivpreprint arXiv:2108.02497.
[^2]: Machine Learning Engineering par Andriy Burkov. Éditeur True Positive Incorporated, 2020 ISBN 1777005442, 9781777005443