En tant que développeur d’application embarquant une brique de Machine Learning notre principal objectif est d’avoir une application utilisée qui fonctionne sans bogue.
Une fois en production et utilisée, il faut anticiper ou identifier les bogues dans notre application et les résoudre au plus vite, afin de maintenir le service rendu et en tirer réellement profit.
Nous détaillerons plus précisément la notion de bogue en ML, mais pour commencer nous pouvons dire qu'un bogue en ML est soit une absence de prédiction, soit une erreur de prédiction acceptable mais trop fréquente soit une erreur de prédiction inacceptable.
Les bogues en Machine Learning (“ML” dans le reste de l’article) peuvent coûter très cher. Nous pouvons citer deux exemples parus ces dernières années dans la presse :
Maximiser l’utilisabilité du service (au sens de disponible et sans bogue) revient à raccourcir au plus court le temps entre le moment où un bogue apparaît, et le moment où il est corrigé. Ce délai se décompose en trois : le délai pour identifier le problème, le délai pour le diagnostiquer (passer de problème à cause) et le délai pour corriger (à la fois coder la correction et la déployer).
Figure 1 : Représentation du temps passé entre l’apparition et la résolution d’un bug
Monitoring et notification proactive visent à minimiser le délai pour identifier et peut avoir un impact positif sur le délai pour diagnostiquer en donnant des alertes précises. Le délai pour corriger lui sera diminué grâce à de nombreuses pratiques tels que les tests, le découplage de l’architecture, la CI/CD…
En Machine Learning nous décrivons comme erreur les inférences où le modèle ne fait pas la “prédiction idéale”. La prédiction idéale est la prédiction que l’on aurait aimé que le modèle fasse afin de maximiser l’impact du système. Elle n’est pas accessible au moment de l’inférence. (Cela a été défini dans cet article).
En logiciel sans ML, il est raisonnable de viser une application avec 0 erreur. En Machine Learning ceci est inimaginable, l’erreur est inhérente, les modèles feront toujours des erreurs. La question n’est donc plus “y a t-il des erreurs ?” mais “y a-t-il trop d’erreurs ?”.
Si vous vous trouvez dans une situation où votre modèle ne fait pas d’erreur, c’est soit que le problème aurait pu être résolu avec des règles métiers, soit qu’une erreur de modélisation a été commise.
En plus d’avoir nécessairement des erreurs, en ML, nous pouvons constater ces erreurs qu'a posteriori et parfois longtemps après que la prédiction ait été donnée.
Pour identifier efficacement les bogues en production, il est important d’avoir conscience des différentes sources d’erreurs.
Figure 2 : différentes raisons pour lesquelles l'application peut dysfonctionner
Les deux premières sources d’erreurs potentielles sont des changements dont le moment d’apparition sont connus :
La troisième est “facilement” anticipable, il s’agit des phénomènes d’accumulation. Un exemple classique en logiciel est le fait d’avoir une base de données pleine. En ML, cela peut avoir lieu lorsque l’on réalise du Continuous Training (entraînement continu) où à chaque inférence le modèle est légèrement modifié. Par exemple, si une classe n’apparaît pas dans les données depuis un moment et qu’un mécanisme de sous pondération pour les observations anciennes est mis en place au moment du réentraînement alors au bout d’un certain temps le modèle ne prédira plus du tout cette classe même si cela aurait été pertinent.
La dernière et la plus dure à anticiper : il s’agit de changement de comportement des utilisateurs.
Figure 3 : Illustration des data drift versus concept drift
Les changements sont sécurisables avant d’aller en production : le code peut être testé, les modèles validés sur des données de tests, nous pouvons réaliser des canary releases… Mais ces sécurisations ne seront jamais exhaustives, le monitoring est donc clef pour attraper les erreurs non identifiées.
NB : Une représentation classique des sources de changements est code, modèle et données. Nous avons choisi dans cet article de répartir d’une manière plus actionnable d’un point de vue monitoring. Les changements dans les données sont inclus dans les phénomènes d’accumulation, dans les changements du code (en introduisant une représentation différente des mêmes informations, ou un changement du métier) et dans les changements des comportements utilisateurs.
Sachant que l’on a nécessairement des erreurs, il convient d’identifier les différents types d’erreurs possibles, celles à éviter absolument, celles à éviter si elles sont trop fréquentes.
Au-delà des erreurs de code, des erreurs lors du déploiement (pipeline de CI/CD rouge) mais aussi les hotfixes qu’on doit réaliser suite à un déploiement causé par des régressions nécessitant des actions, intéressons-nous aux erreurs de ML en particulier.
Nous pouvons séparer les erreurs en 4 catégories présentées dans la figure ci-dessous :
Figure 4 : Représentation des 4 types d’erreurs que l’on peut rencontrer en ML
Pour illustrer ces erreurs, voici un exemple par catégorie :
Figure 5 : Exemple d’erreurs par type
Nous pouvons maintenant donner une définition formelle de bogue en ML :
Nous disons qu’il y a un bogue en Machine Learning lorsque le système ne donne pas de prédiction alors qu’elle est attendue, lorsque le modèle réalise trop fréquemment des erreurs acceptables, lorsque le modèle réalise au moins une erreur inacceptable.
Cette relation “compliquée” à l’erreur a des conséquences importantes sur le maintien en condition opérationnelle de nos modèles.
Le traitement des erreurs est plus complexe :
Les métriques sont changées. Les métriques de stabilité proposées par Accelerate (mean time to repair et change failure rate) sont à redéfinir en fonction des erreurs considérées. Le délai pour identifier les problèmes est allongé. En machine learning le temps pour avoir un coup de téléphone parce qu’un système bogue est plus lent que celui du logiciel sans ML. Par exemple, pour identifier qu’un modèle d’octroi de crédit n’a pas réalisé la prédiction idéale, il faut attendre plusieurs mois avant que le client soit défaillant.
Ainsi la question du monitoring devient centrale pour suivre les "bogues" qui viennent progressivement dans le temps. Laisser un modèle en production sans le monitorer est une erreur grave. Cela nous pousse à shift right : aller vite en production pour tester un certain nombre d'hypothèses. Dans la plupart des cas, les tests Shift Right vont mettre en évidence des dysfonctionnements du côté de la donnée ou de l’infrastructure.
“Le monitoring s’intéresse aux capacités de mesure et de débogage d’un système. L’équipe dispose-t-elle de moyens de suivi de l’état de ses ressources, services et applications ? L’équipe dispose-t-elle de moyens de recueil et de collecte d’informations (métriques, traces, logs) facilitant l’investigation et le débogage de ses systèmes ?” (source)
Le monitoring est en fait un maillon de la chaîne des boucles de feedback; c’est le test ultime.
“Monitoring. Yes, monitoring is a test too, or rather tests and monitoring are both forms of feedback. Monitoring abandons being predictive and to some degree being automated (modulo alerting).” Kent Beck
En fait, se demander ce que nous souhaitons mesurer pour nous assurer que le modèle fonctionne bien revient à définir des Service Level Indicator (SLI). La notion de SLI est proposée par le domaine du SRE (Site Reliability Engineering). Il s’agit d'indicateurs choisis soigneusement pour décrire une partie du niveau de service rendu aux utilisateurs. Un SLI classique est la disponibilité. Pour approfondir cette notion, vous pouvez lire le chapitre 4 du livre Site Reliability Engineering par Betsy Beyer & Al.
Les métriques que nous serons amenés à définir pourrons être préventives (anticiper les problèmes) ou réactives (identifier les problèmes dès qu’ils arrivent).
Nous cherchons à choisir des bonnes métriques, c’est-à-dire des métriques :
Souhaitant des métriques corrélées à un objectif organisationnel, il convient de commencer par les métriques métiers.
La plus importante, north star metric, est l’objectif de l’organisation (l’argent pour les entreprises, minimiser le nombre de demandeurs d’emploi pour Pôle Emploi, …)
Nous sommes souvent amenés à prendre des proxys (approximations) de cette north star metric car elle est souvent très difficile à mesurer. Les boucles de feedbacks qui nous intéressent le plus sont souvent les plus chères et les plus lentes, il faut des proxys pour s’assurer que lorsque l’on aura le feedback, il sera bon. (L’article Data science en production : les difficultés pour récupérer la prédiction idéale explique en quoi les feedbacks en ML peuvent être long).
Figure 6 : Illustration de la north star metric et de différents proxys
Pour trouver de bons proxys, il faut les construire avec le métier. Par exemple en réalisant un atelier matrice d’erreur (L’atelier matrice d’erreur : démystifier les performances du ML avec ses utilisateurs) .
Détaillons ci-dessous deux exemples en donnant la north star metric et les proxys envisageables.
Exemple 1 : Réaliser + 10% de bénéfices par rapport à l’année précédente
L’objectif est d’augmenter les bénéfices. Pour cela, nous pouvons proposer un modèle qui vise à cibler les bonnes personnes pour une campagne d’emailing afin d’augmenter les ventes.
La métrique de pertinence de ce modèle serait les bénéfices générés par cette campagne.
Comme cela est difficile à mesurer (en effet, traquer quelle vente est réalisée grâce à la campagne et quelle vente aurait eu lieu même sans campagne n’est pas évident), nous pouvons prendre le proxy raisonnable suivant : Le nombre de ventes suite à clic sur un lien dans notre mail. Ce proxy nous fait, cependant, perdre les personnes qui achètent grâce à la campagne, mais quelques jours plus tard en accédant directement au site.
La métrique la plus simple à suivre est le taux d’ouverture de mail, mais ce proxy est assez lointain du besoin métier : un titre accrocheur peut causer un grand nombre d'ouvertures sans générer aucune vente.
Figure 7 : Illustration de proxys qui sont corrélés à la north star metric, mais qu’ils convient de ne pas sur-optimiser
Exemple 2 : Diminuer le nombre de demandeurs d’emplois grâce à la formation
L’objectif est de diminuer le nombre de demandeurs d’emploi. Le modèle que l’on peut construire est un moteur de recommandation de formations pour maximiser le retour à l’emploi.
La métrique pour mesurer l’intérêt réel du modèle est le nombre de retours à l’emploi provoqués par des recommandations de bonnes formations.
Les différents proxys que l’on peut prendre sont le nombre de formations sur lesquels les demandeurs d’emploi s’inscrivent, puis le nombre de formations réellement suivies, puis le nombre de retours à l’emploi dans un emploi en lien avec cette formation.
NB : Selon les contextes, l'utilisateur peut avoir un rôle clef pour accélérer ces boucles de feedback. Notamment en lui proposant de signaler des erreurs de prédictions.
NB 2 : Les métriques métiers sont plutôt réactives, elles ne permettent pas d’anticiper les problèmes mais de les détecter.
Le monitoring technique se décline en 3 grands pans : l’infrastructure, les données et le modèle.
Figure 8 : Différentes techniques de monitoring en Data Science
Les métriques peuvent-être préventives, c’est à dire qu’elles permettent d’anticiper un problème, ou réactives, c’est à dire qu’elles permettent de détecter un problème en cours.
Le monitoring de métrique système (incluant CPU, GPU, RAM, …) doit être un non-sujet pour les Data Scientist. Il est souvent déjà mis en place par les équipes qui fournissent la plateforme ou à travers des services managés. Avoir ces métriques mises en place, disponibles et accessibles est un prérequis au déploiement de modèles de ML en production. Ces métriques sont préventives, être alertés lorsque nous sommes proches des 100% d’usage nous permettra d’augmenter la puissance disponible avant que le système soit défaillant.
Le monitoring des données se fait à plusieurs niveaux, au niveau du flux de données (Ex de métrique réactive : Est-ce que les données arrivent correctement dans mon système d’inférence ?), de la préparation de données (Exemple de métriques réactives : les données ont-elles la forme attendue ? les bonnes colonnes ? les bonnes modalités dans les colonnes ?), et enfin en entrée du modèle (Exemple de métrique proactive : la donnée utilisée pour prédire ressemble-t-elle à celles utilisées en entraînement, ou y a-t-il un drift de données ?).
Comme évoqué dans l’article “Une alternative au monitoring de distributions”, il faut être vigilant à ne pas monitorer des distributions de données dans tous les sens au risque d’avoir tellement d’indicateurs que l’on ne puisse plus en tirer de conclusions sur l’état du système. Si les données proviennent d’une source sûre gérée par des équipes matures en termes de monitoring, il est possible de leur faire confiance et limiter le monitoring des choses en double. Si vos données viennent d’un système cœur de votre organisation, (ex le système de virement inter-comptes pour une banque), alors vous pouvez sans doute faire confiance à la qualité de données, ou plus exactement il existe sûrement une équipe qui s’occupe de suivre la qualité des données.
Pour rappel, tout indicateur de monitoring doit être actionnable (i.e. s’il indique un problème l’équipe peut agir).
Le monitoring du modèle requiert de toujours stocker toutes les prédictions faites. La métrique la plus intéressante à suivre est celle choisie en phase d’entraînement, la suivre en phase d’inférence permet de s’assurer que le modèle se comporte comme lors du training. Si ce n’est pas le cas, c’est qu’une hypothèse prise se révèle fausse. Cette métrique est proactive, elle permettra de détecter des débuts de concept drift.
La mise en place d'un monitoring technique doit être parcimonieuse : Il faut trouver des sondes pertinentes; trouver un bon équilibre entre feedback loops exhaustives et feedback loops trop nombreuses. Il faut monitorer à tous les niveaux, mais ne pas tout monitorer.
En monitoring, quelques erreurs sont souvent commises, cela est vrai aussi bien en logiciel que en Machine Learning :
Figure 9 : Les 4 erreurs classiques en monitoring
Avoir des métriques pertinentes est une grosse première étape, mais n’est pas suffisante pour être informé au plus tôt d’un dysfonctionnement, il faut mettre en place des alertes ou des notifications proactives.
“Proactive Notification : Cette aptitude s’intéresse aux alertes mises en place sur notre SI afin d’assurer la détection des anomalies. Nous cherchons à valider que les erreurs de production (dépassement d’un seuil, variation trop importante d’une métrique…) remontent bien des alertes aux personnes susceptibles de résoudre le problème et que seules les alertes nécessitant une intervention humaine sont remontées. L’objectif est que le SI soit suffisamment bien monitoré pour qu’aucune anomalie ne soit remontée par les utilisateurs sans que les équipes ne soient au courant avant.” (source)
En Machine Learning il est impossible de mettre un critère “telle erreur d’inférence ne se produit pas” car cette alerte risque de sonner régulièrement sans qu’aucune action ne soit nécessaire. Il faut mettre un critère “telle situation ne se produit pas trop souvent” et il convient de qualifier le “trop”.
Sur les erreurs acceptables, il convient de fixer des seuils, en définissant des SLO / SLA (Service Level Objective / Agreement) avec votre métier. Pour cela, discutez avec eux du niveau minimum acceptable de performance pour votre modèle. Implémentez cette première version puis itérez, s'il y a trop d’alertes, rendez les seuils filtrants, sinon rendez les seuils moins filtrants.
Le niveau suivant peut être de s’intéresser à l’AI Ops, utiliser des modèles de ML pour prédire des valeurs non-normales pour les métriques de monitoring et remonter des alertes. Vous noterez le côté “meta” de cette approche, qui implique qu’il faudra monitorer à son tour ce système.
Sur les erreurs inacceptables, ce sont des problèmes que vous ne pouvez pas détecter seul sinon vous auriez déjà posé un filtre. Il est alors possible d’avoir deux approches : Une approche à base de feedback utilisateur : permettre à l’utilisateur de signaler des erreurs. Ou une approche exploratoire a posteriori pour identifier les erreurs passées non détectées. L’approche exploratoire peut consister à répondre aux questions suivantes (proposées par Google) étant donné un indicateur :
Figure 10 : Exemple d’une alerte automatique dans une messagerie instantanée
Pour les données, même si nous déconseillons le monitoring de distributions dans tous les sens, il est envisageable de créer des alertes lorsque les données en production semblent ne pas suivre la distribution type vue en entraînement :
Figure 11 : Exemple de distributions de données causant une alerte ou non
Une fois que vous aurez des alertes, vous rencontrerez les challenges suivants : grouper les alertes qui sont liées au même problème, séparer les alertes qui sont liées à des problèmes différents, tagger les alertes pour suivre les vrais positifs et les faux positifs. Pour approfondir cela, vous pouvez lire le chapitre 16 “Tracking Outages” du livre Site Reliability Engineering.
En parallèle de la définition des seuils d’alertes, il convient de définir à qui sont destinées ces alertes, comment les remonter efficacement et les actions à mettre en place suite à une alerte.
Les personnes recevant les alertes doivent être des personnes qui peuvent agir, les alertes doivent remonter dans des canaux régulièrement consultés (tel que mail, messageries instantanées) et non pas “cachées” dans une interface que personne ne regarde.
Figure 12 : Les 3 grands leviers d’actions post-alertes
Les alertes peuvent permettre les actions suivantes :
Agir sur le système :
Agir sur le métier en choisissant de pivoter la fonctionnalité servie par le modèle ou l’arrêter.
S’améliorer : en faisant des post-mortem; afin de comprendre comment une telle erreur est arrivée, identifier des actions à mettre en place pour limiter les risques de nouvelles alertes ou augmenter la résilience du système, et potentiellement alimenter les prochaines expérimentations sur le modèle.
À la lecture de cette partie, vous pouvez noter que la description des actions post-alertes est bien plus simple que la description de la méthode pour avoir des alertes pertinentes. Cela est sans doute dû au fait que face à la complexité des problèmes que l’on résout, déboguer est souvent rédhibitoire et nous choisissons de refaire une phase d’entraînement en modifiant les données en espérant que le problème sera ainsi résolu.
Les éléments suivants sont essentiels à une surveillance efficace :
Il convient de monitorer à tous les niveaux, mais de ne pas tout monitorer.
Une idée pour aller plus loin serait de mettre à disposition les métriques d’erreur aux utilisateurs (tel que proposé dans cet article)
Remerciements : Wassel Alazhar pour les nombreuses discussions qui ont permis d’aboutir à cet article. Sofia Calcagno, pour ses relectures et ses conseils qui ont contribué grandement à la qualité de cet article. Aurélien Massiot, Vincent Lafosse, Philippe Prados, Roberto Duarte, Godefroy Clair, Thu Hien Nguyen et Philippe Stepniewski pour leurs relectures.
Cet article fait partie de la série “Accélérer le Delivery de projets de Machine Learning”, traitant de l’application d’Accelerate [1] dans un contexte incluant du Machine Learning. Si vous n’êtes pas familier avec Accelerate, ou si vous souhaitez avoir plus de détails sur le contexte de cet article, nous vous invitons à commencer par lire l’article introduisant cette série. Vous y trouverez également le lien vers le reste des articles pour aller plus loin.