Les problématiques de Continuous Integration et Continuous Delivery (CI/CD) sont connues depuis longtemps dans les projets informatiques “classiques”. C’est pour cette raison qu’est né le terme de DevOps afin de désigner les principes de programmation qui promeuvent l’automatisation et le suivi de toutes les étapes du développement logiciel.

Dans nos systèmes de machine learning qui commencent de plus en plus à s’industrialiser et s’intégrer dans les systèmes informatiques existants (site web, application de gestion, …), l’enjeu se pose donc d’appliquer ces principes au monde de la datascience.

MLOps, qu’est-ce que c’est ?

Le MLOps tend à se définir comme le pendant du DevOps pour le machine learning. On peut donc en déduire que le MLOps permet l’automatisation et le suivi des étapes d’un projet de machine learning.

Mais avant de continuer plus loin dans le sujet, rappelons brièvement ces différentes étapes d’un projet de machine learning:

• Définition du besoin business
• Récolte et analyse des données
• Validation des données
• Pre-processing des données
• Exploration, entraînement, sélection et validation de modèles
• Déploiement d’un modèle en production

Et où intervient donc le MLOps dans tout ça ?

Et bien idéalement : partout ! Mais nous avons découpé cela en trois grandes parties qui nous paraissent importantes et que nous allons détailler plus bas : la gestion des expérimentations, l’automatisation de la pipeline et le monitoring du modèle (notamment fonctionnel).

Tous les principes ne seront pas forcément nécessaires pour vos projets. Ce sont des boîtes à outils qu’on peut décider d’appliquer ou non dépendamment des besoins.

Experiment tracking

Dans certaines situations, il peut devenir difficile de suivre toutes les expérimentations qui ont été effectuées au cours du temps (parce qu’elles sont très nombreuses, parce qu’elles se sont étalées sur de longs mois, parce que l’équipe est très grande, etc). Les codes ne sont pas toujours conservés (à quoi bon, puisqu’on a décidé de prendre un autre modèle ?). Pourtant conserver la trace de ces runs peut-être utile pour de l’audit, pour aider à déboguer ou justifier les choix qui ont été faits.

C’est ici que l’experiment tracking intervient: 

L’experiment tracking se concentre sur la phase de développement itératif du modèle, lorsqu’un data scientist essaye différentes approches avec différentes configurations pour arriver à la performance souhaitée. Comment éviter les captures d’écran pour historiser et partager les avancées du projet, comment reproduire rapidement une expérience précédente ?

L’experiment tracking peut être résumé en quelques principes simple:

• Concentrer et organiser toutes les expérimentations au même endroit
• Comparer les expériences, analyser les résultats pour déboguer le modèle 
• Améliorer la collaboration : voir ce que tout le monde fait, partager facilement les résultats d’expériences, accéder aux données d’expériences (input, métriques, …).
• Analyser et gérer les expériences.

Et techniquement, comment on fait ?

Chaque équipe peut utiliser ses propres outils pour manager et suivre les différentes étapes et expérimentations ML de son projet. Cependant, il convient, pour des raisons d’efficacité, de considérer des outils spécialisés sur le sujet. Il existe un grand nombre d’outils open-source ou logiciel répondant à ce besoin et s’intégrant facilement et de manière sécurisée au workflow souhaité.  

En fonction du besoin, un outil d’experiment tracking peut avoir différentes fonctionnalités. En substance, voici une liste non exhaustive d’un point de vue uniquement technique, des services que peut nous offrir un outil dédié.

• Création d’un modèle: Pour la phase de recherche et d’exploration de la donnée, il faut pouvoir: 
  • Enregistrer, logger, afficher les métadonnées du modèle (data, metrics, tags, …);
  • Comparer plusieurs exécutions: tableau comparatif, graphique, etc.
  • Créer ou générer automatiquement un tableaux de bord / rapports récapitulatif ;
  • Suivre la consommation du matériel, en terme de CPU, GPU, mémoire ;
  • Pouvoir collaborer sur le même projet et partager ces nouvelles intégrations ;

• Mise en production: Une fois un modèle sélectionné par la datascientist, un ML Engineer doit pouvoir le mettre en production. Pour cela, l’experiment tracking permet, avec l’aide d’un bon outil, de :
  • Facilement et rapidement reproduire et réexécuter les expériences ;
  • Suivre les expériences et sa metadata ;
  • Intégrer le modèle à la chaîne d’automatisation et CI/CD

Présentation d’un outil:

Neptune est un outil de stockage de métadonnées et de suivi d’expérimentation ML. Outil simple et fonctionnel, il permet de surveiller, de visualiser et de comparer des milliers de modèles ML en un seul endroit et de manière collaborative.

Il dispose d’un grand nombre de librairies R et Python et demande très peu d’efforts pour s’intégrer à votre code et environnement: seulement quelques lignes pour se connecter au client neptune.ai et pour suivre les métadonnées qui vous concernent.

Pipeline automation

L’enjeu de la pipeline automation est de répondre au besoin d’automatiser ce qui peut l’être dans le déploiement de notre modèle. Car, en effet, a-t-on vraiment besoin d’un humain pour aller lancer un code sous Jupyter Notebook tous les mois pour lancer le réentraînement du modèle qui est en production ? Ce data scientist ne serait-il pas plus utile à créer de nouveaux modèles ?

Alors regardons ensemble ce qu’il conviendrait de mettre en place:

• La gestion de version du code, des modèles en premier lieu, mais également des données et des prédictions : pour cette étape, il convient d’enregistrer le code des programmes dans un outil de gestion de code (Git par exemple) et de mettre en place des outils gérant des model registry, ML metadata store et Feature store 
• le réentraînement automatique : les performances d’un modèle en production se dégradent au cours du temps, on doit donc être capable de réentraîner le modèle avec plus de données ou bien des données plus fraîches pour rester au plus proche des dernières tendances. On notera que le réentraînement peut être déclenché selon un calendrier ou bien selon des déclencheurs (exemple : les performances descendent en dessous d’un seuil)
• Des tests automatiques : les tests doivent porter sur le code comme dans un cycle de développement classique mais également sur les données
• Le monitoring de la production pour pouvoir s’adapter par rapport au comportement du modèle en production

Si nous résumons, cela nous donnerait le schéma suivant :

Crédits: https://ml-ops.org/content/mlops-principles, inspiré de MLOps: Continuous delivery and automation pipelines in machine learning by Google Cloud

Présentation d’un outil: 

L’outil Vertex AI de Google Cloud Platform tend à rassembler au sein du même module toutes les fonctionnalités pour un entraînement de modèle. En particulier, il propose un outil Vertex AI Pipelines qui permet de définir une pipeline de ML (soit en appelant les fonctionnalités des autres API de GCP, soit en proposant l’exécution de code Python, ou autre). Une pipeline va donc encapsuler toutes les étapes nécessaires pour la création d’un modèle jusqu’à son déploiement. Cette pipeline pourra ensuite être ordonnancée au besoin et va automatiquement enregistrer ses données d’exécution dans un Metadata Store. Étant une brique de GCP, on peut interagir avec les autres services de la plateforme.

Functional monitoring

Les modèles de machine learning sont dynamiques et ils évoluent constamment dans le temps en fonction de la donnée d’entrée. On peut, sans trop se mouiller, dire qu’un modèle est à son meilleur juste avant son déploiement, au moment où les data scientists apportent les dernières modifications. Mais comment s’assurer que ce modèle reste performant dans le temps ?

En associant des outils de monitoring, de logging et d’alerting au flow de traitement de la donnée pour prévenir des risques.

Mais qu’est-ce qui pourrait mal tourner ?

Les sources ont changé, nouvelles données, erreur de manipulation, de normalisation de la donnée … Voici les différentes étapes ou nous pouvons rencontrer 

Si les données ne correspondent pas à ce que votre modèle attend, cela influencera très probablement les performances. 

On peut contrôler le type, le format, le nombre de données manquantes par variable en entrée. De plus, il existe une panoplie de tests statistiques et d’outil pour mesurer les écarts dans la donnée: 

• Pour les variables continues: tests de divergence et de distance tels que la divergence de Kullback-Leibler, la statistique de Kolmogorov-Smirnov (largement utilisée), l’indice de stabilité de la population (PSI), la distance de Hellinger, etc.
• Pour les variables catégorielles: chi-squared test, l’entropie, la cardinalité ou la fréquence des modalités.

Les relations entre les variables d’entrées et votre target peuvent aussi changer au cours du temps.

On peut contrôler les drifts de modèles avec les mêmes tests statistiques que ceux présentés ci-dessus. Aussi, il convient de placer des métriques et checks pour comparer la réalité aux prédictions faites précédemment. En utilisant les données de production (lorsqu’elles deviennent disponibles), nous pouvons calculer la vrai précision de notre modèle.

Un dernier point qui peut être abordé est également la création de KPI métier, car il ne faut pas oublier que nos modèles sont censés répondre à des problématiques métier et suivre de tels indicateurs peut également aider à la compréhension des performances de notre modèle.

Et maintenant que des écarts ont été détectés, que faire ?

• Documenter le problème et déterminer s’il s’agit d’un problème saisonnier ou d’une aberration ponctuelle.
• Réentraîner les modèles et appliquer ce modèles aux nouvelles données.
• Logging
• Alerting : plus besoin de regarder constamment les dashboard, nous sommes avertis lorsque des actions semblent nécessaires ou tout du moins qu’un regard humain est souhaitable.

Présentation d’un outil:

Comet.ml propose un module MPM (Model Production Monitoring) permettant de construire une couche d’interprétation et d’explicabilité des modèles qui sont en production. Malheureusement, ce module n’est disponible qu’en SaaS pour le moment, contrairement au reste de la plateforme qu’on peut installer en “on-premise”.
Cependant, le principe est extrêmement simple : la plateforme enregistre les modèles et les données d’entraînement (Comet.ml gère la partie Experiment tracking), puis on envoie les données de prédiction à l’outil et celui-ci se charge de calculer de lui-même un grand nombre d’indicateurs. Lorsque les données réelles sont disponibles, nous pouvons également les envoyer pour que d’autres indicateurs soient calculés.
Ce module permet également d’investiguer sur les causes possibles de mauvaises performances: outliers, data drift, … Des onglets dédiés au XAI permettent de visualiser les tendances feature par feature. De nombreuses fonctionnalités sont encore attendues dans les mois à venir mais c’est en tout cas un bon challenger dans le domaine.

Conclusion

Pour vous aider dans votre prise de décision au moment de la sélection des outils, nous vous avons préparé le diagramme ci-dessous. Nous avons sélectionné 5 logiciels et outils open source qui peuvent vous aider, partiellement ou totalement, dans l’automatisation et le suivi de toutes les étapes du développement et déploiement d’un projet de machine learning. Bien entendu, les outils MLOPS évoluant très vite, ce diagramme est à titre indicatif au moment de l’écriture de cet article…

N’hésitez pas à nous contacter pour vous accompagner dans vos réflexions autour de ces problématiques ML !