Cet article est destiné aux data scientists et data engineers ayant un premier niveau d’expertise sur Google cloud Platform (GCP). Il s’agit d’un retour d’expérience d’un cas d’industrialisation d’une solution de Machine learning (ML) avec Kubeflow (un service managé de GCP dédié au ML). Il s’agit ici de mettre en application les grands principes du MLOps pour mettre en lumière un nouveau métier qui a émergé depuis peu, le MLOps Engineer.
Le constat était le suivant : un modèle de ML seul ne suffit plus pour apporter de la valeur en entreprise. Il a besoin d’une infrastructure automatisée pour être mis en production.
Or, lorsqu’une entreprise utilise du ML en production, la création de modèles de ML est trop souvent déconnectée de leurs déploiements. Les modèles sont ainsi créés et déployés par des data scientists qui expérimentent, sans réel passage à l’échelle. Il n’y a pas de système de développement unifié ou de tâches automatiques de versionnement ou de test. Le déploiement et le management de l’infrastructure est souvent fait manuellement, avec peu d’automatisme.
Ce papier vous donnera donc quelques techniques pour l’industrialisation d’un modèle de ML avec automatisation de l’intégration continue, de la livraison continue et de l’entraînement continu de votre modèle de ML.
Nous allons détailler ces nouveaux concepts.
Qu’est ce que le MLOps ?
Le MLOps s’inscrit dans la continuité du DevOps qui est un mouvement en ingénierie informatique visant à unifier les activités de développement (DEV) et les opérations (Ops). Il s’agit de l’union des processus, des compétences métiers et des technologies destinée à fournir en continu de la valeur aux clients.
Le DevOps permet la coordination et la collaboration des rôles autrefois cloisonnés tels que le développement, les opérations informatiques, l’ingénierie qualité et sécurité. Le DevOps promeut l’automatisation et le monitoring de toutes les étapes depuis la création d’un logiciel, le développement, l’intégration, les tests, la livraison jusqu’au déploiement, à l’exploitation et à la maintenance des infrastructures. Les principes Devops soutiennent des phases de développement plus raccourcies, une augmentation du nombre de déploiements de modèle et des livraisons plus rapprochées, en continu, pour une meilleure atteinte des objectifs économiques de l’entreprise.
Le MLOps s’inscrit dans la même logique que DevOps mais appliqué au Machine Learning. Faire du MLOps veut dire que l’automatisation et la surveillance de votre solution de ML est effective à toutes les étapes depuis l’intégration, les tests, la publication de résultats et le déploiement du modèle.
Ainsi, le nouveau défi pour les data scientists, data engineers et MLOps engineers n’est plus uniquement de créer un modèle de ML, mais de créer un système de ML intégré et de le faire fonctionner en production de manière continue.
On parle de framework MLOps pour désigner tous les éléments qui gravitent autour du modèle ML et qui lui permettent d’être industrialisé.
Le Framework MLOps
Le MLOps contient :
- Une étape ML pour expérimenter avec les données. Il s’agit, dans un premier temps, d’extraire et de préparer les données, puis dans un second temps, de réfléchir et de comprendre le business case
- Une étape DEV pendant laquelle on va développer/coder le modèle ML, le tester, le confronter aux attentes métier, l’intégrer et enfin, le déployer dans l’architecture cible .
- Une étape OPS qui aura pour objet de s’assurer de la bonne gestion des opérations. Cette étape assure la livraison en continu de nouveaux résultats en fonction des nouvelles données qui arrivent au fil du temps. Le data feedback et le monitoring permettent de vérifier les performances du modèle de ML et d’éviter la dérive des résultats dans le temps.
(Source : What is MLOps? A Complete Hands-On Guide | CloudxLab Blog)
Composition du Framework MLOps
Pour aller dans le détail, la composition d’un framework MLOps est la suivante :
Le code de ML (scripts de programmation) représente une très petite partie du framework ML mais reste une partie centrale
Un environnement d’expérimentation stable et permettant une reproductibilité des résultats.
Le Versioning des modèles : il est possible de tracer un historique des versions de codes et un historique des modèles, leurs paramètres/hyperparamètres et des données d’entrée (et métadonnées) associées.
Le Test : le MLOps permet aussi le monitoring, le suivi des performances du modèle et plus largement le process management. Les tests de suivi de modèle se basent sur l’étude de la déviation de mesures (métriques) diverses, comme celle des performances de prédictions (accuracy, roc, R2, …) qui peuvent décroître avec le temps. Généralement, on fixe des seuils de validation de modèle pour contrôler qu’un modèle ne dérive pas trop au fur et à mesure du temps. Et dans le cas d’un modèle qui aurait trop dérivé, on peut prévoir un déclenchement automatique du réentraînement du modèle via une pipeline complexe. Cette pipeline permet :
- L’extraction des données
- Le nettoyage et la préparation pertinente des données extraites
- L’entraînement du modèle ML
- L’évaluation du modèle ML et sa validation
- La diffusion des résultats
La Surveillance (Monitoring) du modèle ML : Des outils de surveillance doivent permettre de suivre ses évolutions, les modèles, données et les performances en production.
L’Intégration, le développement et l’entraînement continue des modèles de ML.
- On parle de “CI” (acronyme anglais pour “Continuous Integration”) pour désigner l’intégration continue du code (le test et la validation).
- “CD” (acronyme anglais pour “Continuous Deployment”) correspond au déploiement en continu : ce ne sont pas des librairies ou logiciels que l’on déploie mais des pipelines (une suite de composants qui met en exécution toutes les étapes pour la mise en oeuvre du modèle ML). Cette chaîne “CD” va des données brutes, vers leurs préparations, l’entraînement du modèle, sa validation puis son déploiement. Il y a un versionnement et une reproductibilité qui est assuré.
- “CT” (acronyme anglais pour “Continuous Training”) correspond à une chaîne d’entraînement en continu pour la mise à jour du modèle ML (en fonction des nouvelles données ingérées). C’est purement une étape centrée MLOps.
Pour aller plus loin, je vous recommande la lecture de l’article de Google Cloud : MLOps : pipelines de livraison continue et d’automatisation dans le machine learning | Centre d’architecture Cloud | Google Cloud
Dans le prochain article, nous verrons ensemble avec quels outils faire du MLOps et nous verrons plus particulièrement le cas de Kubeflow.
