Évaluer sa maturité MLOps

Temps de lecture : 12 minutes

Introduction

La mise en production d’un modèle de Machine Learning est devenu un enjeu important pour les organisations qui ont investi dans l’intelligence artificielle. En effet beaucoup ont lancé des PoCs (Proof of Concepts) sans jamais réussir à mettre en production leurs modèles de Machine Learning ou Deep Learning pour diverses raisons : manque d’expertises, ou d’expériences, frilosité des cadres dirigeants devant une technologie inconnue, absence de processus adaptés ou encore réticence des métiers devant la perte de maîtrise ou de compréhension des décisions prises par le modèle.

Évaluer sa maturité dans la démarche MLOps, i.e. la démarche de mise en production des modèles façon DevOps, est une des premières étapes pour identifier les pistes d’amélioration. C’est pourquoi cet article propose de reprendre chacune des étapes du MLOps et de les qualifier en 3 niveaux de maturité suivant 3 axes : Personnes, Outils, Processus.

“DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.” Donovan Brown

Les différentes étapes du MLOps sont :

Définition du besoin
Préparation de la donnée
Expérimentations
Validation
Déploiement
Monitoring
Réentraînement

Évaluer sa maturité à chacun des étapes du MLOps

1- Définition du besoin

La définition du besoin est la genèse de tout projet de Machine Learning. Il est important dès cette étape de définir les objectifs du projet, les critères de succès et les acteurs qui seront nécessaires à sa réalisation. Un tel projet implique souvent les métiers, les data scientists, les data engineers, les machine learning engineers, ainsi que les cadres dirigeants qui apporteront du poids au projet de part leur parrainage.

Définition du besoin	Personnes	Outils	Processus
Maturité faible	Métiers	Ateliers d’acculturation à l’IA	À ce niveau de maturité, l’IA ne fait pas partie de l’organisation et les métiers peuvent avoir une certaine méfiance vis-à-vis de cette technologie méconnue. Parfois les métiers voient l’IA comme une potentielle menace plus qu’une aide, ou au contraire la voit comme un outil magique capable de résoudre tous les problèmes.
Maturité intermédiaire	Métiers Data scientists	Ateliers d’idéations et cas d’usage	Un processus d’acculturation à l’IA est en cours mais l’IA n’est pas encore perçue comme un vecteur de changement systématique.
Maturité forte	Métiers Data scientists Cadres dirigeants	Ateliers de cadrage réunissant tous les acteurs clés du projet	L’IA est au cœur de la stratégie de l’entreprise et est utilisée de manière systématique lors de nouveaux projets. Les cadres dirigeants ont confiance dans ce domaine et investissent dans tous les secteurs de l’entreprise. Le projet possède un sponsor haut placé qui va financer et porter le projet.

2- Préparation de la donnée

Cette étape est un prérequis essentiel aux opérations de machine learning à proprement parler. Une donnée fiable et accessible est une des clés de la réussite de la création d’un modèle performant. La préparation de la donnée contient elle-même de nombreuses étapes comme la collecte, le nettoyage, le formatage, la labellisation, le stockage.

Préparation de la donnée	Personnes	Outils	Processus
Maturité faible	Chaque métier est propriétaire d’une donnée fragmentée Data scientists	Fichiers éparses aux formats très différents (textes, tableurs, etc.)	La donnée est éparpillée au travers des différents processus métier sous des formats hétérogènes. Les data scientists récupèrent par eux-mêmes les données et assurent le traitement de celles-ci. Il assurent le stockage des données dans un nouveau format de façon temporaire ce qui ne favorise pas le versioning ou encore le réentraînement des modèles.
Maturité intermédiaire	Administrateurs de bases de données IT	Data lake	Les data engineers centralisent les données au sein d’un data lake. Les données sont versionnées.
Maturité forte	Administrateurs de bases de données IT Data Architect Chief Data Officer	Data lake / Data mesh Feature store	Les données sont orientées en service data mesh. La donnée est facilement accessible aux data scientists notamment grâce à un catalogue de la donnée. Tous les types de données sont gérés quel que soit leur format, leur production (stream ou batch). En plus de ces services, un feature store permet la réutilisation des features développées par les data scientists.

3- Expérimentations

La phase d’expérimentation est la première phase du cycle de MLOps. Lors de cette phase les data scientists vont tester différents modèles, différents hyperparamètres, différentes features. Lors de cette phase l’organisation et les outils utilisés sont cruciaux car le risque est de réitérer plusieurs fois les mêmes expériences, perdre les résultats ou encore ne pas pouvoir reproduire des résultats.

Expérimentations	Personnes	Outils	Processus
Maturité faible	Data scientists fraîchement diplômés	Les data scientists codent principalement sur Jupyter Notebooks ou aidés par des outils tels que Dataiku, Azure AutoML etc. Infrastructure : Ordinateurs en local ou sur quelques GPUs présents sur des serveurs on-premises.	Les environnements mis à disposition sont chaotiques et difficiles à configurer. Peu de traces des expérimentations ou stockage des expérimentations dans des fichiers textes ou tableurs. Difficultés à reproduire les résultats.
Maturité intermédiaire	Data scientists fraîchement diplômés Data scientists confirmés	Versioning du code Tests unitaires Scripts python Environnements virtuels / Docker etc. Logs des résultats Infrastructure : Mix entre GPUs sur serveur en propre et cloud	Les expérimentations sont reproductibles grâce à l’utilisation d’environnements définis. Les résultats sont stockés dans une base de données mais pas toujours de façon centralisée et standardisée ce qui rend la capitalisation difficile.
Maturité forte	Data scientists fraîchement diplômés Data scientists confirmés Data scientists seniors Experts dans leur domaine	Versioning du code Tests unitaires Scripts python organisés grâce à template de code utilisé de manière systématique Environnements virtuels / Docker etc. Fichiers de configuration Logs des résultats de manière standard et centralisé Registre des modèles Infrastructure : Utilisation de GPUs à la volée sur le cloud. Les droits de création et d’utilisation d’environnements sont gérés grâce à un outil dédié.	Les data scientists possèdent des environnements qui s’adaptent à leur besoin à la volée et sur des infrastructures adaptées. Les lead data scientists et managers accordent les droits et permissions de créer et utiliser les environnements demandés. Les résultats sont systématiquement logués et centralisés de manière à favoriser des itérations rapides et collaboratives. Les modèles sont versionnés.

4- Validation du modèle

La validation du modèle assure qu’il n’y aura pas de surprises une fois le modèle passé en production. Cette validation comporte 3 volets qui reflètent le niveau de maturité des organisations :

Les performances brutes du modèle (accuracy, precision, ROC etc.).
Les performances méta du modèle (temps d’inférence, besoins en CPU, GPU et/ou RAM).
Les considérations éthiques liées à l’intelligence artificielle.

Validation du modèle	Personnes	Outils	Processus
Maturité faible	Data scientists Métiers	Seuls les performances pures du modèle, i.e. les métriques comme l’accuracy, la précision, le recall sont prises en compte dans la validation du modèle.	Les data scientists valident le modèle seuls ou avec les métiers. Il est souvent difficile de lier les métriques du modèle à des KPIs métiers.
Maturité intermédiaire	Data scientists Métiers ML engineer IT	Un cahier des charges établi en amont avec l’IT permet de valider le modèle suivant des considérations d’infrastructure et de service telles que le temps d’inférence ou l’utilisation de ressources. Un environnement de pré-production est mis à disposition pour faire ces essais.	Une compréhension fine des enjeux métiers a permis de relier les performances brutes du modèle (accuracy, precision etc.) avec des KPIs métiers. Un ML engineer vient appuyer les data scientists afin de prendre en compte les contraintes de temps d’inférence notamment. Ainsi la performance du modèle en termes de temps d’inférence ou encore d’utilisation de ressources (CPU/ RAM) est aussi analysée.
Maturité forte	Data scientists Métiers ML engineer IT AI ethicists	Cahier des charges défini avec l’IT Environnement de pré-production Des outils permettant d’analyser l’éthique et la justesse du modèle sont utilisés également afin de vérifier que le modèle n’a pas appris avec des biais	En plus des précédents processus, l’accent est mis sur l’éthique du modèle. Un métier fournit les critères nécessaires à la vérification de l’absence de biais dans les prédictions des algorithmes. Le métier peut aussi être appuyé par un AI ethicist qui définit les enjeux globaux au niveau de l’entreprise et s’assure du respect de la charte éthique des modèles.

5- Déploiement du modèle

Le déploiement du modèle est l’étape la plus importante d’un projet de machine learning. Cette étape permet de valoriser tout le travail amont et, lorsqu’il est effectué avec succès, assure un retour sur investissement à l’organisation. Pourtant cette étape est souvent sous-estimée, est source de frictions et parfois même allonge significativement la durée du projet du fait de contraintes mal anticipées.

La clé est la définition d’un cahier des charges avec l’IT très en amont du projet. Celui-ci doit comprendre des éléments comme ce qui est attendu à la livraison : une image du modèle par exemple, une taille de modèle, un besoin en RAM et en CPU et/ou GPU. Le niveau de maturité de cette étape est fortement corrélé au niveau de maturité de l’étape précédente.

Déploiement du modèle	Personnes	Outils	Processus
Maturité faible	Data scientists IT	Le SI ne s’adapte pas aux contraintes des modèles et bien souvent il est impossible de mettre le modèle en production car l’infrastructure est inadaptée. Cela peut concerner les langages (le SI étant plus souvent habitué à du C, du COBOL ou du Java qu’à du Python) ou à l’architecture (besoin d’un cluster Kubernetes par exemple).	Il est très difficile voire impossible de déployer le modèle car il existe une trop grande différence entre les environnements du SI et ceux des data scientists. Ceci est fréquent lors de l’industrialisation du premier modèle. Une certaine méfiance est présente entre IT et data scientists du fait d’outils différents et des difficultés à comprendre les enjeux propres à chacun.
Maturité intermédiaire	Data scientists IT Data engineers	La mise à disposition d’un environnement de production prend beaucoup de temps par manque d’agilité ou à cause des contraintes de sécurité.	Le déploiement nécessite une refactorisation importante du code qui n’est pas industrialisable après développement. Cette refactorisation est faite par les data scientists ou les data engineers.
Maturité forte	Data scientists IT Software engineers ML engineers	Le déploiement fait souvent appel à des services managés du cloud qui répondent aux critères de mise à disposition rapide, de sécurité et de scalabilité. Pipeline CI/CD. Déploiements canary / shadow etc.	Le code développé répond déjà aux critères d’industrialisation notamment le respect d’un template, la présence de documentation et de tests. Le processus de déploiement est rôdé et répond à un cahier des charges établi à l’avance en concertation entre les data scientists, IT, software engineers et machine learning engineers. Le déploiement est agnostique de la plateforme utilisée soit on-premise ou sur le cloud.

6- Monitoring du modèle

Le monitoring du modèle assure un maintien du modèle en condition opérationnelle en vérifiant que les données d’entrée, les prédictions réalisées ou encore les performances méta du modèles sont conformes à ce qui a été obtenu pendant l’entraînement.

Monitoring du modèle	Personnes	Outils	Processus
Maturité faible	Data scientists Métiers	Aucun outil de monitoring Monitoring manuel, non standardisé, et non systématique	Pas de monitoring du modèle de manière automatique. Ce monitoring est parfois réalisé par les métiers qui remarquent des erreurs lors de tests aléatoires.
Maturité intermédiaire	Data scientists Métiers Software engineers	Logs	Les data scientists et les software engineers ont implémenté des logs qui permettent un monitoring; Ce monitoring est long et fastidieux car il faut réunir les métriques à la main.
Maturité forte	Data scientists Métiers Software engineers ML engineers	Logs agrégés et triés Dashboards spécifiques pour les data scientists, les ML engineers et les métiers	Les métiers et les personnes techniques sont en charge du monitoring du modèle dont les KPIs de performance ont été définis en amont. Ce sont ces métriques qui ont permis la validation du modèle (performances brutes, méta-performances, respect de l’éthique etc.). Différents niveaux de métriques sont utilisés pour éviter le biais d’aggrégation, notamment pour sur les considérations éthiques où une métrique peut paraître ok sur une population générale mais révéler des biais sur des sous-populations. Ce monitoring automatique et systématique est couplé d’un système d’alertes pour les métriques les plus critiques.

7- Réentraînement du modèle

Le réentraînement du modèle est nécessaire car les performances du modèle vont se dégrader au cours du temps : c’est ce que l’on appelle la dérive du modèle. Cela est notamment dû au fait que les données en entrée du modèle vont évoluer par rapport aux données d’entraînement car ces données représentent le monde réel et le monde réel évolue !

Réentraînement du modèle	Personnes	Outils	Processus
Maturité faible	Data scientists	Aucun outil spécifique pour le réentraînement. Celui-ci, si réalisé, est géré manuellement.	Pas de réentraînement du modèle, ce qui va souvent de paire avec une absence de monitoring du modèle. Ou le réentraînement est fastidieux et passe par la réécriture totale ou partielle du modèle.
Maturité intermédiaire	Data scientists Data engineers	Des scripts permettent le réentraînement du modèle	Un réentraînement est programmé à la suite de la constatation de la perte de performance du modèle. Un data engineer peut aider les data scientists à réaliser ce réentraînement grâce à la mise à disposition des nouvelles données.
Maturité forte	Data scientists Data engineers ML engineers Métiers	Pipeline CI/CD Outil d’orchestration	Le processus de réentraînement est clair et établi. Le déclenchement peut intervenir suivant trois méthodes : Manuel, à la demande des métiers ou des data scientists; à partir d’événements comme l’arrivée de nouvelles données; automatiquement si les performances du modèle sont en baisse. La pipeline de réentraînement est automatique mais le déploiement du nouveau modèle demande souvent une vérification et validation manuelle.

Conclusion

On remarque que plus la maturité en MLOps est grande et plus le travail des data scientists se recentre sur leur cœur de métier à savoir les expérimentations et la recherche du modèle le plus performant pour répondre aux besoins métiers exprimés lors de la phase de définition du besoin. D’autres métiers viennent alors l’aider pour répondre aux tâches amont et aval comme les data engineers pour la préparation de la donnée et les machine learning engineers pour la validation du modèle et son déploiement. Pour autant cette segmentation des tâches ne dédouane pas les data scientists de la prise en compte des critères cruciaux pour la mise en production comme un code prêt à être industrialisé ou un modèle dont le poids ou les temps d’inférence sont raisonnables. C’est notamment par la concertation avec l’IT que ces critères d’industrialisation sont définis. Si le data scientist reste la clé de voûte d’un projet de machine learning, le machine learning engineer est le bras droit qui va valoriser son travail et en assurer la pérennité grâce aux étapes de monitoring et de réentraînement.

Pour conclure, cet article permet de mesurer la maturité d’une organisation par rapport à la mise en production de modèles de machine learning et ainsi prendre, si nécessaire, les mesures pour une mise en production rapide, efficace et sereine assurant un fort ROI de ces projets.