Maîtrisez l'apprentissage supervisé

Nous savons élaborer des modèles bien rodés, en rendre le fonctionnement transparent et les conteneuriser pour un déploiement dans le Cloud, afin que d’autres personnes en bénéficient !

On a fini notre projet ML alors ! Sauf que non, comme pour n’importe quelle application, nous avons des bugs et de la maintenance à faire. Les algorithmes de ML ne font pas exception. Seulement, leur forme particulière de bug s’appelle le drift (ou dérive en français).

Comprenez pourquoi et comment un modèle dérive

Vous le savez bien maintenant, votre modèle de ML apprend à réaliser ses prédictions en se basant sur un certain nombre d’exemples (les observations du jeu d’apprentissage), pour ensuite reproduire ce qu’il a appris dans de nouvelles situations, en espérant que celles-ci soient suffisamment semblables aux exemples vus en apprentissage.

Dans l’exemple du projet fil rouge, il y a deux exemples clairs qui illustrent cela :

• La crise sanitaire du Covid : les transactions immobilières ont été très impactées. Entre autres, il y a eu un attrait plus accru que d’habitude pour les maisons en banlieue Parisienne. Sans doute, car les Parisiens ne voulaient pas prendre le risque d’être confinés de nouveau dans de petites surfaces.

• La hausse des taux d’intérêts suite à l’inflation amplifiée par la guerre entre l’Ukraine et la Russie : Nous savons que la hausse des taux d’intérêts immobiliers a un impact direct sur le prix des transactions immobilières ainsi que la capacité des ménages à acquérir un bien.

Par conséquent, un modèle entraîné sur un historique entre 2018 et 2019 ne pourra pas prendre en compte un changement de contexte derrière la donnée comme celui du Covid. En effet, la seule façon de faire adopter un nouveau contexte à un modèle de ML est via un ré-entraînement !

Dans n’importe quel jeu de données, ce changement de contexte peut se traduire :

• Par un changement dans la distribution des features ou les corrélations entre celles-ci. C’est ce que l’on appelle le Data Drift (on parle également parfois de Covariate Shift) ;

• Par un changement dans la distribution de la target, ou des liens entre la feature et la target, il s’agit d’un Target Drift (nous avons aussi d’autres appellations  comme Label Shift ou Prior Probability Shift) ;

• Par une évolution majeure de la réalité de la donnée qui va venir rendre obsolètes les features ou ce qu’a appris le modèle avec. C’est ce que l’on appelle un Concept Drift.

Le Concept Drift n’est pas simple à illustrer avec notre projet fil rouge, alors prenons un autre cas de figure : Si un modèle de reconnaissance d'images a été entraîné sur des images de chats et de chiens, mais que de nouvelles images de lions commencent à arriver, le modèle ne peut que se tromper. L’explication est la suivante : le contexte qui a servi à l'entraînement du modèle n’a pas prévu l’existence d’images de lions. En plus, le modèle ne va pas ajouter une 3ᵉ classe dans la foulée et de manière autonome pour s’adapter à ce changement.

Apprenez comment détecter le Data Drift

Commençons par le Data Drift ! Ici, nous avons deux types de méthodes :

• Des méthodes “unidimensionnelles” : C'est-à-dire qui sont capables de détecter la dérive d’une feature en particulier.

• Des méthodes “multidimensionnelles” : C’est-à-dire qui sont capables de détecter des drifts qui ne seraient pas visibles en ne regardant qu’une seule feature, mais plusieurs à la fois.

Pour choisir votre méthode unidimensionnelle, tout dépend de la taille de votre jeu de données et de la nature de votre feature (numérique ou catégorielle).

Nous donnons ici comme exemple un test pour les features quantitatives dans un jeu de données de petite taille (quelques milliers de lignes au maximum), il s’agit du test de Kolmogorov-Smirnov, ou KS test pour faire court :

• C’est un test qui peut déterminer si la distribution de votre feature quantitative est similaire à une autre, qu’elle soit théorique (comme la loi Gaussienne) ou empirique, comme la distribution d’une autre feature.

C’est un test statistique très puissant, car il n’exige aucune contrainte particulière concernant votre distribution, contrairement à la majorité des autres tests statistiques.

Ce test présente par contre le défaut de sa qualité : Si votre donnée est assez volumineuse (plus d’une dizaine de milliers d’observations) le KS test peut être amené à conclure que vos deux distributions sont différentes, à cause d’effets de bords ou d’outliers relativement peu importants. Nous allons voir un exemple dans le screencast qui suit ! Dans cette situation, il faudrait alors utiliser une autre technique de mesure de drift.

Plus vous en connaissez, le mieux c'est ! Toutefois, il existe un package assez pratique et de plus en plus populaire qui nous aide à automatiser la détection de drift, y compris le choix de la technique de mesure ! Découvrons ensemble le package Evidently :

Le contexte et des exemples visuels de drift

L'automatisation de la mesure de drift avec Evidently

Nous avons présenté la fonctionnalité la plus fondamentale d’Evidently, mais vous pouvez aller clairement plus loin avec ce package, en définissant par exemple des méthodes personnalisées de détection de drift, adaptées à votre contexte métier !

Même si notre jeu de données ne présente que peu ou pas du tout de drift quand on regarde chaque feature individuellement, nous pouvons quand même avoir du Data Drift “multidimentionel”.

Illustrons par un exemple comment cela peut se manifester. Prenons les deux features de ce jeu de données fictif à un instant t.

Peu importe le sens métier des deux features, nous remarquons que la feature 1 prend des valeurs entre -3.5 et 2.5 alors que la feature 2 est distribuée entre 7.4 et 13.

Maintenant, imaginons que le jeu de données ressemble à ceci, quelques semaines plus tard :

Il nous faut alors une méthode capable de déceler ce type de phénomènes. Nous allons utiliser un algorithme de ML pour cela !

Sauf que celui-ci ne va pas être entraîné à estimer le prix d’une transaction ou à déterminer si elle est en dessous du marché. Pas du tout ! Nous allons apprendre au modèle de prédire si notre transaction est issue du jeu d’apprentissage ou du jeu de test ! Cela peut paraître étrange comme choix de target, mais l’idée derrière est assez pratique :

• Nous définissions notre jeu d’apprentissage comme étant notre jeu de données jusqu’à un instant t.

• Nous définissons notre jeu de test comme étant notre jeu de données entre l’instant t et un instant t + quelques jours/semaines/mois.

• Si votre modèle non-linéaire obtient d'excellentes performances en apprentissage et en test, cela signifie qu’il est très facile pour un modèle de distinguer entre les observations d’avant et celles d’après. Nous avons alors du Data Drift !

• Si votre modèle overfit sur le jeu d’apprentissage, alors la distinction entre votre jeu d’apprentissage et votre jeu de test n’est pas simple à faire. A priori, pas de Data Drift flagrant à signaler.

En clair, nous utilisons notre modèle comme appareil de mesure de similarité entre les observations du passé et d’aujourd’hui.

Eh bien, vous savez déjà le faire en utilisant le package SHAP ! Eh oui ! Vous allez calculer les valeurs de Shapley de ce nouveau modèle “appareil de mesure” afin de comprendre le raisonnement qui le pousse à dire qu’une combinaison de features n’existe pas dans le jeu de données initial.

Que faire quand on a du drift ?

C’est la question centrale ! La réponse courte serait : tout dépend de la nature du drift. Pour la réponse longue : présentons quelques cas de figure.

Dans notre projet filé, nous avons vu que la situation macro-économique post-Covid a causé un drift de certaines features comme le taux d’intérêt ou le prix au mètre carré moyen. Cette nouvelle situation du marché de l’immobilier s’est installée sur le long terme et notre modèle n’est pas aligné avec cette réalité s’il a été entraîné sur une période pré-Covid. Dans ce cas de figure, il faudrait :

• Ré-entraîner le modèle sur un jeu de données rafraichi, qui contient majoritairement les nouvelles valeurs types des features qui ont drifté ;

• Éventuellement, rajouter de nouvelles features adaptées au nouveau contexte macro-économique.

Le dicton est toujours le même : plus de données ne signifie pas plus de performances, que ce soit pour le nombre de features comme pour le nombre d’observations !

N’oubliez pas que votre modèle va chercher à obtenir les meilleures performances possibles “au global”, ou toutes situations confondues. Si l’on donne au modèle dans son apprentissage toutes les valeurs possibles de taux d’intérêt, par exemple (pré-Covid comme post-Covid), on pourrait finir avec un modèle suffisamment bon pour tous les contextes, mais excellent nulle part. Or, le contexte immobilier pré-Covid est révolu ! On n’a même pas envie que le modèle soit fiable là-dessus, comme il ne sera pas amené à réaliser des prédictions sur des biens avec ces valeurs de features. Il faut alors réduire le périmètre à ce qui compte.

Par contre, si c’est la feature VEFA qui a drifté, alors une solution viable pourrait être… de ne rien faire ! Eh oui, un changement dans la distribution de cette feature signifie que nous avons plus de plans VEFA qu’avant (ou l’inverse). Cela ne veut pas nécessairement dire que le contexte immobilier sous-jacent à notre donnée a évolué suffisamment pour rendre notre modèle obsolète, surtout si la performance du modèle n’est pas impactée ! Cela peut être simplement un effet saisonnier, ou une nouvelle tendance avec laquelle le modèle a réussi à s’adapter sans réentraînement.

Maintenant prenons le cas le plus sévère : Faire face à un Concept Drift. Le projet fil rouge n’est pas le meilleur pour illustrer cette situation, donc prenons un autre exemple :

• Vous avez développé pour une entreprise de marketplace (comme Leboncoin) un algorithme de classification pouvant détecter des annonces frauduleuses avant qu’elles soient publiées.

• La proportion des classes que vous aviez est de 90% pour les annonces normales et 10% pour les annonces frauduleuses.

• Votre modèle rencontre un succès flamboyant et vous arrivez à faire baisser le nombre d’annonces frauduleuses, les proportions passent à 96% et 4% après quelques mois.

• Au même moment, les performances de votre modèle commencent à baisser drastiquement.

Dans cette situation, il se passe deux choses. En premier lieu, votre modèle est victime de son propre succès ! Il a été construit dans un contexte dans lequel les annonces frauduleuses sont assez nombreuses. Sauf que ce n’est désormais plus le cas et qu’il est de plus en plus difficile pour votre modèle de détecter des annonces de moins en moins nombreuses, ou des cas de fraude moins évidents que les 6% qu’il avait détectés.

Deuxièmement, les fraudeurs ne vont pas cesser leur activité illicite juste parce que vous avez élaboré un modèle prédictif. Ils vont plutôt tester de nouvelles façons d’écrire leurs annonces pour contourner le fonctionnement de votre algorithme. Ces nouvelles annonces frauduleuses pourraient être invisibles par votre target, et pourraient être catégorisées à tort dans la classe majoritaire, causant ainsi un décalage complet entre les features, la cible et la réalité sous-jacente, c’est un Concept Drift.

Pour faire face à ce phénomène, il faut revoir la définition de votre target et s’assurer qu’elle représente bien ce qu’elle est censée décrire. Autrement dit, il faut revoir le calcul de la target de telle sorte que toutes les annonces frauduleuses post-drift du nouveau soient bien au sein de la classe 1. Naturellement, vous aurez un nouveau jeu de données d’apprentissage et aurez besoin de reconstruire votre modèle. Ici, nous avons également deux cas de figure types :

• Meilleur des cas : Avec les mêmes features et les mêmes observations que le jeu de données pré-drift, vous arrivez à sécuriser un modèle fiable.

• Pire des cas : Avec les mêmes features et les mêmes observations que le jeu de données pré-drift, votre modèle ne réussit pas à être fiable.

Malheureusement, vous ne pourrez pas savoir dans quel cas vous allez être avant de mettre la main à la pâte !

Si vous finissez dans le pire des cas, cela signifie que vous devez remettre en chantier votre modélisation, vos features, vos hypothèses de filtrage de la donnée, vos analyses exploratoires… potentiellement dans leur entièreté.

En effet, tous vos choix techniques sont conditionnés par votre target ! Si vous aviez sélectionné des features pour votre modèle final pré-drift, c’est parce qu’elles étaient responsables de la performance de votre modèle. Ainsi, changer de nature de target peut vous ramener à la case de départ. Vous devez refaire une analyse exploratoire, recalculer les statistiques descriptives et comprendre le lien entre cette nouvelle cible et le restant de la donnée. C’est un mini-projet ML dans le projet ML et vous ne pouvez pas nécessairement procéder autrement !

À vous de jouer !

Pendant ce chapitre, nous avons exploré ensemble le Data Drift et nous avons évoqué le Target Drift.

Cet exercice vous fera prendre en main les fonctionnalités d'Evidently pour la détection du Target Drift ! En vous basant sur cette page de la documentation.

d’Evidently, établissez l'existence ou non d'un drift des deux targets en comparant la donnée de la période covid et de la période post-covid.

Vous pouvez partir de ce notebook template.

Une fois que vous avez fini, vous avez ce corrigé à disposition.

En résumé

• Le drift (ou dérive) est un phénomène courant dans les modèles de ML, causé par un changement de contexte dans les données avec le temps. Il peut affecter la distribution des features (Data Drift), la distribution de la target (Target Drift), ou même rendre le modèle obsolète (Concept Drift).

• Le Data Drift peut être détecté avec des tests statistiques comme le test de Kolmogorov-Smirnov ou des outils comme Evidently qui facilitent l’identification des dérives unidimensionnelles dans les features.

• Un modèle de ML peut également être utilisé pour mesurer la similarité entre les observations passées et actuelles. Un modèle performant à cette tâche indique la présence de drift multidimensionnel, et des outils comme SHAP peuvent aider à comprendre quelles combinaisons de features causent ce drift.

• En cas de drift, il est essentiel d'adapter le modèle : parfois en le réentraînant sur de nouvelles données, parfois en ajustant les features ou la target. Si le drift est sévère (Concept Drift), cela peut nécessiter une révision complète du modèle et de l'approche de modélisation.

• Il est crucial d'anticiper ces drifts dès le début d’un projet ML et de suivre l'évolution des données pour ajuster le modèle au bon moment, surtout si son succès même peut entraîner des changements de comportement dans la réalité métier.

Super, vous savez maintenant comment repérer les drifts ! Passons à la prochaine étape : structurer efficacement vos futures modélisations.