
Votre modèle n’est pas terminé : comprendre et corriger la dérive du modèle
Vous avez mis votre modèle en production.
Il s’agit de faire des prédictions et de les proposer aux parties prenantes.
Le pipeline est automatisé.
Il est maintenant temps de vous détendre, votre travail est terminé.
J’aime aussi rêver.
Bon, revenons à la réalité. Discutons de la dérive du modèle : de quoi s’agit-il, pourquoi elle se produit, comment la détecter et comment y remédier avant qu’elle ne détruise secrètement les performances et la confiance des parties prenantes dans le modèle.
Qu’est-ce que la dérive de modèle ?
La dérive du modèle est la détérioration des performances d’un modèle prédictif au fil du temps, et même les modèles les plus puissants et les plus précis courent un risque. La dérive du modèle n’est pas le reflet de mauvaises techniques de formation ou d’une mauvaise collecte de données, mais plutôt quelque chose que tous les data scientists doivent surveiller de près.

Regardons un exemple. Un modèle de classificateur binaire est formé sur deux années de données historiques. Les performances sont bonnes, l’AUC dans les 0,9 s, la précision et le rappel sont tous deux suffisamment élevés. Le modèle passe l’étape d’examen par les pairs et entre dans l’environnement de production. Ici, il commence à faire des pronostics en direct. Après 90 jours, le data scientist interroge les prédictions faites par le modèle en production et les exécute via un script de validation qui calcule les mesures de performances. Les performances sont à la hauteur des attentes du POC (preuve de concept) et sont relayées aux parties prenantes : « Le modèle fonctionne comme prévu. Les prédictions sont exactes. »
Avance rapide de deux ans. Une demande arrive pour étudier le modèle. Il semblerait que les prévisions soient systématiquement incorrectes et que les parties prenantes perdent confiance dans le modèle. Il est même question d’utiliser potentiellement leur ancienne méthode de feuille de calcul Excel si les choses continuent ainsi. Le data scientist interroge les données des 6 derniers mois et les exécute via le script de validation. Le data scientist se frotte les yeux, vérifie ses notes et est sidéré. L’ASC se situe à 0,6, la précision et le rappel sont tous deux extrêmement faibles. « Comment est-ce possible ? J’ai formé un bon modèle. J’ai même validé le modèle après sa mise en ligne ! Que s’est-il passé ? » » s’interroge le data scientist. C’est la dérive du modèle qui s’est produite. Il s’est infiltré sans être détecté pendant des mois et a bouleversé les prévisions.
C’est la dure réalité à laquelle de nombreux modèles prédictifs sont confrontés en production. Parlons de pourquoi cela se produit.
Pourquoi une dérive du modèle se produit-elle ?
En résumé, la dérive des modèles se produit parce que les modèles vivent dans le monde réel. Le modèle a été formé sur une réalité, et cette réalité a changé d’une manière ou d’une autre depuis qu’il a été déployé en production.
L’une des causes les plus courantes de dérive du modèle est un changement dans la manière dont les données sont enregistrées. Lorsque les données étaient initialement collectées à des fins de formation, les fonctionnalités prédictives et la cible ne ressemblaient qu’à une seule direction, mais aujourd’hui, elles sont différentes. L’algorithme a appris la relation spécifique entre eux, mais maintenant, cette relation a changé. Le modèle n’a pas appris à gérer la nouvelle relation, il continue donc à faire des prédictions du mieux qu’il peut, compte tenu de la manière dont il a été formé.
La dérive du modèle se divise généralement en deux catégories :
Dérive des données (les fonctionnalités changent)
Dérive conceptuelle (changement de relations/changement de population)
Regardons quelques exemples.
Exemple n°1 : dérive des données
La taille et le poids sont utilisés pour prédire le risque de diabète. Le scientifique des données a rassemblé deux années de données sur les patients, en s’assurant d’indiquer la taille de chaque patient en pouces, son poids en livres et si ce patient a fini par développer ou non le diabète un an après avoir été mesuré. Deux ans plus tard, un nouveau processus de mesure oblige les infirmières à documenter la taille en centimètres et le poids en kilogrammes et le modèle commence à faire des prédictions extrêmement inexactes à cause de cela. Par exemple, un patient mesurant 6 pieds avait une taille documentée de 72 pouces, mais sa taille est désormais documentée à 183 centimètres. Ce patient pèse 200 livres, ce qui correspond désormais à 91 kilogrammes. Le modèle ne sait pas qu’une conversion doit avoir lieu pour tenir compte du changement d’unités. Il s’attend à recevoir les caractéristiques des unités dans lesquelles il a été formé, il prédit donc comme si la personne mesurait 183 pouces (plus de 15 pieds) grand et 91 livres. Pas étonnant que cette prédiction n’ait aucun sens !
Exemple n°2 : Dérive du concept
Un modèle de risque de réadmission est construit pour un système hospitalier par leur équipe de data scientists. Trois ans après sa mise en service, leur système acquiert quatre grands hôpitaux de l’État voisin. Ces hôpitaux ont une démographie de patients très différente, très différente de la population d’origine sur laquelle le modèle a été formé. Lorsque le modèle est déployé dans les nouveaux hôpitaux, les prestataires remarquent qu’il fait de nombreuses prédictions faussement positives et faussement négatives. Le modèle devrait être recyclé pour inclure les données de ces nouveaux hôpitaux.
Comment détecter et corriger la dérive du modèle
La dérive du modèle peut se produire progressivement, avec une dégradation lente des performances sur une longue période, ou elle peut se produire rapidement, avec une baisse soudaine et évidente des performances. Cette nature variable peut rendre difficile la préparation et encore plus la détection sans les bons outils.

Surveiller régulièrement les performances en production est le meilleur moyen de détecter la dérive du modèle.
Si vous ne surveillez pas votre modèle en production, vous ne remarquerez aucune dérive tant que les parties prenantes ne le feront pas.
Un tableau de bord ou un bloc-notes rapide pouvant être exécuté toutes les deux semaines peut être un moyen simple de visualiser les performances du modèle et de détecter toute détérioration au fil du temps. Tracez simplement la précision, le rappel, l’AUC, la MAE, la MSE ou toute autre mesure de performance appropriée pour votre modèle sur l’axe des y et la date sur l’axe des x. Ce à quoi vous devez vous attendre, c’est une légère variation d’une semaine à l’autre, mais de grands écarts par rapport au signal moyen ont changé et une dérive pourrait se produire. Un tracé des caractéristiques manquantes et de la distribution des caractéristiques peut également vous aider à approfondir les prédicteurs individuels, vous aidant ainsi à déterminer la cause de la dérive. Cela pourrait ressembler au nombre de valeurs NA ou NULL par fonctionnalité au fil du temps, ou à la valeur moyenne par fonctionnalité au fil du temps.
En fait, j’ai détecté une dérive de modèle dans l’un de mes modèles en utilisant la méthode ci-dessus. J’ai remarqué une baisse de précision dans mon modèle Difficult IV Access. Après quelques semaines de valeurs de précision constamment inférieures aux attentes, je suis devenu méfiant. Mon responsable a suggéré d’examiner l’absence de fonctionnalités comme cause potentielle. Et voilà, la troisième caractéristique la plus importante, les antécédents de malnutrition, a connu une énorme augmentation des valeurs NULL la même semaine où les performances de mon modèle ont commencé à se détériorer. Nous avons découvert que le code SQL à l’origine de la création de la fonctionnalité en production avait fait l’objet de quelques ajustements et qu’une jointure ne se comportait pas comme prévu. Nous avons mis à jour le SQL et la précision est revenue à des niveaux normaux à partir de ce jour.

Cela m’amène à mon dernier point : comment corriger la dérive du modèle. Il existe plusieurs façons de corriger la dérive, chacune étant adaptée à différents scénarios. Comme vous l’avez vu ci-dessus, une façon de corriger la dérive consiste à réparer les entrées/données dans le même format dans lequel elles existaient pour la formation du modèle. Il s’agit du moyen le plus simple et le plus rapide de corriger la dérive et devrait si possible être le moyen par défaut. Cela peut être effectué n’importe où dans le processus de chargement des données, depuis l’ETL de la base de données jusqu’au code du notebook en aval où les préditions sont effectuées. Si la hauteur est enregistrée en centimètres et que votre modèle s’attend à ce qu’elle soit en pouces, une conversion peut être effectuée avant les prédictions.
Parfois, cependant, les données ne peuvent pas être modifiées. Peut-être que la gouvernance des données a défini un point de données de manière plus formelle, et que désormais les unités sont standardisées, et ces unités sont différentes de celles sur lesquelles votre modèle a été formé. Ou encore, un workflow empêche le chargement des données dans le même format. Une autre solution, même si elle nécessite un peu plus d’efforts, consiste à recycler le modèle. Le recyclage du modèle sur de nouvelles données lui permet de réapprendre la relation entre les variables, établissant ainsi un modèle qui fonctionne de manière fiable sur les nouvelles données qui lui sont fournies. Les changements dans la population nécessitent presque toujours un recyclage du modèle.
Conclusion
La dérive du modèle peut surprendre tout data scientist sans méfiance. Si cela dure suffisamment longtemps, cela peut détruire les performances et la confiance des utilisateurs. Mais ce n’est pas quelque chose à craindre. Avec les bons outils, il est possible de détecter la dérive et de la corriger. Être capable de reconnaître quand une dérive du modèle se produit et avoir le savoir-faire nécessaire pour identifier la cause et déterminer la solution est ce qui sépare les data scientists qui se contentent de mettre un modèle en production, de ceux qui savent comment construire un modèle qui peut avoir un impact durable.



