Depuis plus de 10 ans, AVISIA accompagne ses clients dans leurs projets et notamment leurs projets de machine learning qui deviennent presque incontournables  ; nul besoin de me croire sur parole, on peut aussi se fier aux sempiternels sondages de début d’articles data : 50% des entreprises ont adopté l’IA dans une de leurs fonctions (McKinsey, 2020) [1].

Si quelques années après, tous les acteurs des entreprises (experts métier, data scientists, direction informatique, …) commençaient à reconnaître la valeur et la spécificité de ses projets, il restait une composante qui pêchait souvent le suivi dans le temps de l’efficacité business du modèle de machine learning.

Comment s’assurer que les performances restent stable dans le temps ?

Les différents drifts et leurs implications

Le drift correspond à une dérive du modèle, qui peut générer une dégradation des performances. Ce changement s’opère lorsqu’une différence de distribution naît, entre la donnée utilisée pour entrainer le modèle et la distribution des données utilisées pour l’appliquer, ou lorsque le fonctionnement même de la variable à expliquer se modifie. Différentes sortes existent :

• Prior shift: la distribution sur la variable cible a changé entre les données d’apprentissage et d’application,
  
• Covariate shift: les distributions ont changé entre votre échantillon d’apprentissage et votre échantillon d’application. Par exemple, si le but du projet est de distinguer les hommes des femmes et seul votre échantillon de test / validation contient des personnes de couleur de peau non blanche, alors vos données souffriront de covariate shift (et bien sûr, d’un fort biais racial). Il peut être dû :
  • à la mauvaise création des échantillons d’apprentissage / test,
  • à la création de données d’apprentissage qui ne reflètent pas du tout la réalité de votre domaine d’application,
  • au fait que votre environnement change au cours du temps (clients de plus en plus jeunes ou âgés par exemple).
    

• Concept drift: ici, c’est la relation entre les variables explicatives et la variable à expliquer qui va changer entre apprentissage et application. Par exemple, si le but du projet est de détecter de potentiels acheteurs, alors le drift implique que ce qui faisait qu’une personne était susceptible d’acheter par le passé n’est plus la même aujourd’hui. Ce phénomène est aussi appelé concept shift, mais aussi model drift étant donné que le modèle qui explique nos données change.
  

Les méthodes d’identification du drift

Comment le détecter ? 🔎 Il faut déjà distinguer les méthodes antérieures à la création du modèle, et celles postérieures.

L’analyse de performance comme méthode postérieure

La manière la plus simple est de comparer la performance du modèle au moment du déploiement et la performance quelques temps plus tard avec de nouvelles données. Cela suppose bien entendu qu’une métrique quantifiable ait été choisie, que les prédictions du modèle soient stockées, et que la vraie valeur de la variable cible soit récupérable.

Le processus peut être effectué comme suit :

Ce processus peut être appliqué pour tous les différents types de drift.

• Hormis cette méthode, il est compliqué de mettre en évidence le concept shift, hormis une analyse détaillée des corrélations.
• Concernant le prior shift, il peut cependant être mis en évidence par une simple évolution descriptive de la variable cible. Ce shift est problématique si le déséquilibre devient trop important, ce qui suggérerait un potentiel covariate shift.

Si on dispose d’indicateurs de performance pour le modèle historique déployé et le modèle mis à jour, il est possible de choisir de conserver le modèle déployé ou de mettre en place le 2^e en fonction de celui qui est le meilleur ! Cette méthode possède aussi l’avantage d’être entièrement automatisable pour que, chaque mois par exemple, la version en production soit toujours la plus pertinente.

Mais les inconvénients sont doubles :

1. L’inconvénient logique qui en découle est que la solution est uniquement palliative ; elle met en évidence une perte de performance seulement quand celle-ci a baissé de manière effective, c’est-à-dire que cela a pu dégrader sur une courte période un processus de l’entreprise.
2. L’approche nécessite de disposer assez rapidement des « ground truths », c’est-à-dire les vrais labels de la variable cible pour des individus récents. Cela est souvent compliqué pour des projets qui visent à anticiper un comportement à moyen ou long-terme.

L’analyse des variables explicatives comme méthode antérieure

Le désavantage de la méthode précédente est qu’il est bien complexe de comprendre exactement le drift présent dans nos données : comment peut-on quantifier plus précisément le drift, quelles sont les variables explicatives qui présentent un drift, est-ce que celles-ci causent un drift du modèle.

Deux approches sont possibles : une qui considère les variables séparément, et une autre dans leur globalité.

L’analyse de chaque variable explicative

Chaque variable explicative peut être analysée séparément afin de déterminer s’il y a présence de covariate shift. De manière pratique, il s’agit de comparer la distribution de cette variable au moment où le modèle a été créé, versus la distribution de la variable à un instant t ultérieur (très proche d’aujourd’hui).

L’analyse est différente si la variable est quantitative ou qualitative :

• Pour les variables qualitatives, déjà, il s’agit de vérifier si les modalités ou plages de valeurs sont les mêmes entre les deux échantillons.
  • Si une modalité était présente au moment de l’apprentissage mais n’est pas présente au moment de l’application, alors il faut se poser la question de l’utilité de cette modalité (la supprimer ou bien la remplacer par une valeur manquante).
  • À l’inverse, si la modalité n’est présente qu’au moment de l’application, alors cela veut dire qu’un nouveau type d’individu statistique est apparu ; au-delà de la nécessité de prendre en compte dans son code et son application cette possibilité, il deviendra important de ré-entraîner son modèle pour prendre en compte ces nouveaux comportements.

Ensuite, l’analyse va s’intéresser au tableau croisé entre les fréquences des modalités de la variable explicative, et la variable indiquant si la modalité est comptée dans les données d’apprentissage (« reference » dans le graphique ci-dessous) ou d’application (« current »).

Source : dataiku.com

L’examen du tableau croisé est visuel et subjectif, mais il est possible de tester de manière statistique la présence ou l’absence de drift grâce par exemple au test du Chi 2.

• Pour les variables quantitatives, l’analyse s’effectue via les histogrammes et les courbes de densité. Un rapide examen visuel permet d’avoir une appréciation générale du drift d’une variable. Pour quantifier de manière plus précise la significativité de ces variations, deux tests statistiques sont disponibles : le test de Kolmogorov Smirnov, ainsi que le test de Wilcoxon-Mann-Whitney.

Source : dataiku.com

Il est possible d’améliorer cette analyse en créant un nuage de points représentant les différentes variables explicatives, avec en ordonnée l’importance de la variable dans un modèle prédictif, et en abscisse l’importance de la variable dans le modèle de drift (le modèle d’adversarial validation, qui est expliqué dans la partie suivante). L’idée est de mettre en évidence les variables qui ont à la fois un effet important dans le modèle initial mais qui causent une grande partie du drift ; une variable importante mais très peu génératrice de drift ne nécessitera pas d’opération correctrice ; idem pour une variable causant du drift mais très peu importante pour le projet prédictif (ces deux derniers cas pouvant changer dans le futur).

L’adversarial validation

Le désavantage des approches précédentes est qu’il faut analyser chaque variable une par une, et que la détection ne prend pas en compte des phénomènes de drift complexes. L’approche astucieuse est appelée adversarial validation.

L’idée est d’établir un modèle qui va déterminer si une observation appartient à l’un ou à l’autre des échantillons.

Deux possibilités :

1. Si le modèle ne fait pas mieux que le hasard (AUC très proche de 0,5), alors les deux échantillons sont quasiment identiques et il n’y aura pas de covariate shift (cette approche ne permet pas d’apprécier la présence ou l’absence de concept drift).
2. Si le modèle arrive à distinguer les deux échantillons (AUC supérieur à 0,5), alors il y aura covariate shift mais pas forcément de concept drift. Un exemple : le projet souhaite identifier les futurs acheteurs mais ceux-ci se féminisent ; il est cependant tout à fait possible qu’hommes et femmes achètent exactement de la même façon qu’avant.

Si on prend l’AUC comme métrique de drift, alors toute valeur supérieure à 0,55 est suspecte et demande alors une analyse des variables explicatives qui pourraient causer le drift.

La correction du drift

Au niveau des solutions, si un mouvement dans les données a été détecté, alors il faut d’abord traiter le problème à la racine, c’est-à-dire gérer les variables le causant. Il faudra ensuite réentraîner le ou les modèles avec des données plus récentes.

La fréquence de réentraînement dépend de la criticité du cas d’application du projet : un modèle de fraude bancaire ou de détection de menaces informatiques devront très fréquemment s’adapter aux nouveaux comportements d’intérêt. En revanche, un ré-entraînement trop fréquent peut générer une lourde charge sur les infrastructures et outils de l’entreprise et se révéler fastidieux à mettre en place. Une règle fonctionnelle peut être de relancer le processus d’apprentissage quand notre univers d’application change : au lancement d’un nouveau produit, à l’ouverture sur un nouveau marché, etc.

Les outils

Il existe des packages Python pour la détection du drift, par exemple Alibi Detect et Evidently. Notre partenaire Dataiku propose depuis peu de manière native des capacités d’analyse de drift (voir leur documentation ainsi que cet article).

Tout est clair ?

Grâce à cet article, vous êtes très certainement devenus experts dans le maintien de la performance de vos modèles et de la gestion du drift ! Problème, le diable se cache dans les détails, et nous ne pouvons tous les mettre en lumière dans cet article :

• À partir de quel moment choisit-on de conserver le modèle initial ou de mettre en place la nouvelle version ?
• Sur quelle période comparer le modèle initial et le modèle récent ? Comment la nature de notre projet peut nous aider à orienter notre choix ?
• Un réentraînement suffit-il, ou faut-il revoir de manière un peu plus exhaustive l’architecture et les choix du projet ?
• Comment peut-on grâce aux données estimer une vitesse de dégradation des performances et donc une fréquence de réentraînement ?
• Que faire quand le drift est par nature plus compliqué et plus long ? Comme par exemple la crise prédictive engendrée par la pandémie de Covid ?

Data Science & Covid : comment surmonter cette crise prédictive ?

Nous avons parlé de ces thématiques lors de notre participation au salon Big Data & AI Paris avec FLOA Bank et notre partenaire Dataiku. Mais pour replacer les problématiques du drift dans un contexte plus global, n’hésitez pas à consulter notre article sur tout ce à quoi doit penser un data scientist, dont le drift, lors de la mise en application d’un projet de data science :

Le rôle du data scientist dans la mise en production d’un projet de data science

Tout un tas de questions qu’en tant qu’experts AVISIA nous avons pu rencontrer dans nos missions. N’hésitez pas à surveiller les prochains articles sur le sujet et nous contacter pour vous aider sur vos projets !

 

[1] McKinsey (2020). The State of AI in 2020, https://www.mckinsey.com/capabilities/quantumblack/our-insights/global-survey-the-state-of-ai-in-2020.

[2] MIT Sloan Management Review (2020). Expanding AI’s Impact With Organizational Learning, https://sloanreview.mit.edu/projects/expanding-ais-impact-with-organizational-learning/.

Crédit photo : Evan Smogor pour Unsplash