Dans ce deuxième billet de notre série sur le churn, nous vous proposons un protocole de développement de l’algorithme d’identification du churn. Sans rentrer dans les détails d’implémentation nous présentons ici toutes les étapes du processus et leurs enjeux techniques.
Développement d’un algorithme d’identification du churn
En pratique nous recommandons de découper le développement en deux étapes minimum : l’étude de faisabilité et le développement d’une preuve de concept.
Le but de l’étude de faisabilité est d’effectuer une audit des données et d’obtenir une baseline (performance de base du modèle sans effort d’optimisation). Dans cette étape, il est nécessaire d’aller vite et il ne faut pas s’attarder sur les détails techniques (qualité du code, automatisation etc).
A l’inverse, le but de la preuve de concept est de produire un produit fonctionnel qui pourra aller en production. Il faut donc fournir un effort de développement beaucoup plus important et optimiser au mieux les performances du modèle.
Collecte et nettoyage de données
Une fois le cadrage de mission fait, l’étape suivante est de rassembler des données de sources diverses et les nettoyer afin de produire un jeu de données sur lequel sera entraîné le modèle.
Les sources de données à utiliser doivent être identifiées en collaboration avec les experts métiers (qui ont la compréhension des facteurs clés de churn) et les urbanistes/architectes du SI (qui connaissent la modélisation et la circulation de la donnée dans le SI).
En général, on utilise l’historique des achats clients, l’historique des usages des services (quand il s’agit de services en partie digitaux), l’historique des échanges avec le support client, l’historique des interactions avec le marketing (engagement site web, courriel, pub etc.) ainsi que des données décrivant la nature des clients (taille, secteur, CA etc.), en provenance du SI ou de sources tierces.
Les données collectées, il faut maintenant les explorer afin d’en définir la qualité (audit des données). Les problèmes les plus fréquents étant liés au format et/ou aux valeurs nulles (i.e. données partiellement manquantes). Il est aussi possible que les données comportent des anomalies (i.e. valeurs aberrantes). Afin d’identifier ces anomalies, il est utile de transmettre un rapport statistique des données aux experts métiers pour validation.
Feature engineering et mise en forme des données
Une fois les données brutes nettoyées il faut les mettre en forme et calculer les variables prédictives (i.e. features) et la variable à prédire.
L’identification du churn est un problème temporel (i.e. on utilise des données du passé pour prédire le futur). Il faut donc créer un jeu de données où chaque observation (i.e. lignes) décrit l’état d’un client à un instant t et est associée à son statut churn (oui ou non) à l’instant t+n (n : horizon de prévision).
Pour se faire, on se place à différents instants t (par exemple toutes les semaines ou tous les 2 mois) pour lesquels on calcule l’état des clients (i.e. les variables prédictives) à l’instant t et la variable à prédire (i.e. churn) en se projetant dans le futur (relativement par rapport à l’instant t).
Dans certains cas, il peut être intéressant de ne pas agréger les données clients en un état (agréger des données implique une perte d’information) mais de les traiter comme une séquence d’engagements. Il faut alors utiliser des modèles spécifiques au traitement de séquences ce qui implique une charge de travail plus importante.
Preprocessing
Les données produites à la fin du processus de feature engineering et de mise en forme des données ne sont pas encore exploitables par un modèle de machine learning.
Les modèles de machine de learning ne savent pas interpréter les données catégorielles. Il faut les transformer en données numériques, la technique employée consiste généralement à transformer les variables à n catégories en n variables binaires.
Dans certains cas, il faut également normaliser les variables, c’est à dire les transformer afin qu’elles évoluent toutes sur la même tranche de valeurs.
Certains algorithmes d’apprentissage sont sensibles à l’ordre de grandeur des variables. Si une variable évolue sur une tranche de valeurs supérieures aux tranches de valeurs des autres variables (ex : salaire vs poids, taille, âge) ces algorithmes seront fortement enclins à estimer un modèle pour lequel elle un impact plus important sur ses prédictions.
Modelling
Une fois le jeu de données propre et préprocessé, l’estimation de modèles peut commencer. Le terme modèle est volontairement mis au pluriel puisque ce n’est pas un modèle qui va être estimé sur les données mais des dizaines voire des centaines selon la difficulté du problème.
Notions clés de data science
Avant de détailler notre démarche d’estimation et sélection de modèles, il est important de comprendre certaines notions clés de data science.
Un modèle
Un modèle peut être considéré comme une boite noire qui sur la base de données d’entrée retourne une prédiction en sortie. Un modèle est estimé grâce à un algorithme de machine learning sur la base de données d’entraînement. Les algorithmes de machine learning sont généralement des composants open source prêts à l’usage.
La performance
La performance du modèle est une évaluation de sa capacité à effectuer des prédictions justes.
La métrique de performance doit être choisie avec grande attention. Une bonne valeur pour une métrique donnée ne signifie pas toujours que les prédictions du modèle sont bonnes.
Dans le cas du churn on a une majorité de client (disons 90%) qui ne churn pas et une minorité qui churn, il est donc préférable de ne pas évaluer les modèles sur la base du pourcentage de bien classé. En effet, notre modèle pourrait classer correctement 90% des clients en classant tous les clients comme « pas à risque de churner ». Il faut donc utiliser des métriques insensibles à la répartition des classes (ex : f1_score).
Le sur-apprentissage et le sous-apprentissage.
Le sur-apprentissage d’un modèle signifie qu’il est trop sensible aux variations propres à son jeu de données d’entraînement au détriment de sa performance sur les données à venir (i.e. les données pour lesquelles il devra faire des prédictions une fois mis en production). En général une situation de sur-apprentissage implique que le modèle est trop complexe par rapport au problème, qu’il ne généralise pas suffisamment celui-ci.
Le sous-apprentissage d’un modèle signifie qu’il n’est pas assez sensible aux variations qu’elles soient propres aux jeux de données d’entraînement ou pas. Une situation de sous-apprentissage implique que le modèle n’est pas assez complexe par rapport au problème.
Les situations de sous/sur apprentissage sont également étroitement liées à la nature des données. Plus le nombre de variables est important plus le risque de sur apprentissage est élevé. Plus le nombre d’observations est faible plus le risque de sur apprentissage est élevé.
Afin d’identifier ces deux situations, il convient de couper le jeu de données en deux : un jeu de données d’entraînement (train) sur lequel le modèle sera entraîné et un jeu de données de test sur lequel la performance du modèle sera mesurée.
Lorsque que la performance du modèle est proche sur le jeu de données de test et d’entraînement on se trouve dans une situation de sous-apprentissage. Lorsque la performance du modèle est bien meilleure sur le jeu de données de test on se trouve dans une situation de sur-apprentissage.
Dans les cas où on entraîne plusieurs centaines de modèles il est judicieux de constituer un troisième jeu de données d’évaluation afin d’obtenir une estimation non biaisée de la performance du modèle. En effet, en sélectionnant nos modèles sur la base de leurs performances sur le jeu de données de test on finit par sur-apprendre les données de test.
Modèles tuning
L’objectif de la phase de modelling est donc de maximiser la performance du modèle sur le jeu de test en l’entraînant sur les données d’entraînement (train). Autrement dit, il faut trouver le juste milieu entre sous-apprentissage et sur-apprentissage ; la bonne complexité du modèle par rapport au problème traité.
On peut gérer la complexité d’un modèle à l’aide de paramètres qui vont impacter son mécanisme d’apprentissage. On appelle ces paramètres des hyper paramètres. La phase de modelling consiste en l’optimisation de ces hyper paramètres afin de trouver un modèle ayant une complexité adaptée au problème.
Cette optimisation peut se faire sur la base de l’intuition en mode essai erreur mais elle peut également être automatisée en déléguant à un algorithme le test de différents hyper paramètres.
En pratique, on fonctionne en essai erreur pour trouver le bon ordre de grandeur de ces hyper paramètres et on va ensuite déléguer la recherche de la valeur optimale à un algorithme.
L’autoML n’est autre qu’un mécanisme de recherche automatisé de la valeur optimale des hyper paramètres sur un ensemble de modèles.
Dans le cadre de la phase de modelling, il faut également sélectionner les variables maximisant la performance sur le jeu de test. On ne peut pas tester toutes les combinaisons de variables, il faut donc tester les différentes combinaisons de manière stratégique sur la base de l’expertise métier et du savoir-faire technique.
Dans le cas où la performance obtenue après optimisation des hyper paramètres ne serait pas suffisante. Il faut s’interroger sur les données utilisées, il se pourrait qu’elles ne comportent pas assez d’information pour traiter le problème. On peut alors retourner aux phases de collecte des données et feature engineering pour intégrer de nouvelles variables.
Afin de faciliter l’identification de données complémentaires permettant d’améliorer la performance du modèle, on peut utiliser l’error-analysis. Cette technique consiste à identifier les groupes sur lesquels la performance du modèle est mauvaise. Une fois ces groupes identifiés on peut rechercher des données les décrivant plus en détail.
Évaluation du modèle sur la métrique métier
En parallèle de l’évaluation sur les données d’évaluation il est judicieux de consulter régulièrement la valeur de la métrique métier définie lors du cadrage. C’est cette métrique que l’on cherche à optimiser.
Dans certains cas on peut même aller jusqu’à optimiser le modèle uniquement vis à vis de la métrique métier.
Dans ce billet nous avons présenté un protocole de développement d’algorithme de prédiction du churn. Certaines parties de ce protocole sont propres au sujet du churn, notamment les parties sur la collecte de données et le feature engineering, cependant la partie sur le modelling est relativement indépendante du cas d’utilisation.
Dans le prochain billet de cette série, nous aborderons les sujets d’interprétation du modèle et de test en situation réelle au moyen d’A/B test , le traitement de ces deux sujets clés étant indispensable à la réussite de n’importe quel projet de machine learning.