Pour une opérationnalisation simplifiée des modèles de Machine Learning : les outils de MLops
Le déploiement d’un modèle de machine learning peut être comparé au décollage d’une fusée. C’est le moment de vérité où l’on tire profit des étapes de construction, de programmation et d’entraînement effectuées préalablement. Son succès dépendant de tout le travail fait en amont, cette étape se prépare dès le début du cycle de vie projet. C’est là tout l’enjeu de l’opérationnalisation des modèles de machine learning.
Le spécialiste de l’opérationnalisation, c’est le ML Ops. Ses responsabilités sont d’anticiper les problématiques techniques de l’exploitation — intégration, orchestration, supervision et sécurité — et de s’assurer du succès du déploiement. Pour faire face à la complexité croissante des systèmes, le ML Ops doit s’appuyer sur des outils lui permettant « d’industrialiser » le processus. Dans cet article, nous aborderons les challenges de l’opérationnalisation et nous comparerons différents outils disponibles.
Du développement des modèles à leur industrialisation
Le cycle de vie d’un modèle de Machine learning peut-être divisé en trois grandes phases : le cadrage du besoin, le développement du modèle et son industrialisation.
Cadrage du besoin : Avant de lancer un projet de machine learning, le besoin opérationnel est cadré par le chef de projet. Il répond aux questions suivantes : Quel problème doit être résolu ? Quelles sont les données disponibles ? Quels outils sont pertinents ? Quel est le niveau de performances de l’algorithme attendu ?…
Développement du modèle : Le data scientist est le principal responsable de cette phase. Il se charge d’analyser la donnée de la préparer — retirer les données fausses, merger certaines sources, remettre les valeurs sur la même échelle / devise, … — d’entraîner le modèle et de tester ses performances.
Sans démarche d’opérationnalisation, l’ensemble du processus de développement est itératif et exécuté manuellement. Cela peut fonctionner à petite échelle, mais à plus grande échelle ou dans un contexte de collaboration, un travail d’opérationnalisation dès la phase de développement est indispensable.
Pour cela, le ML Ops met à disposition du data scientist un environnement de travail managé, simple d’utilisation, contrôlé et supervisé. Ces ressources permettent au Data Scientist de travailler en équipe, de comparer, de versionner, d’historiser et de reproduire ses expériences. De son côté, le ML Ops prépare la phase d’industrialisation en connaissant l’environnement en amont.
L’Industrialisation : Le ML Ops garantit l’industrialisation du modèle livré par les data scientists. Il s’assure de l’exposition du modèle, que celui-ci soit exploitable par ses consommateurs par exemple avec les mode de batch transform ou d’inférence unitaire. Il s’assure aussi de l’orchestration, soit que le modèle s’active selon un schéma prévu. Sur le long terme, le ML Ops se charge de la supervision du modèle. Il veille au bon fonctionnement du modèle autant sur la partie IT — gestion de l’API, des utilisateurs … — que sur la performance du modèle pour prévenir le risque de drift.
Pourquoi outiller le ML Ops ?
A mesure que les modèles se multiplient et se complexifient, le ML Ops a besoin d’être outillé pour « industrialiser » le processus d’opérationnalisation. Nous avons identifié trois grands challenges:
Besoin de collaboration : La tour de Babel
Différents experts sont impliqués dans la construction et l’industrialisation du modèle. Si leur objectif est le même et leurs travaux sont interdépendants, leurs savoir-faire, leurs outils et leurs langages de développement sont différents !
Dans ce contexte d’interdépendance, la communication est un sujet critique et le partage d’informations est crucial. Pour cela, les informations clés doivent être centralisées, enregistrées et standardisées.Ci-dessous un exemple de la répartition des tâches entre ML Ops, Data Scientist et data engineer
Après le go live : attention au drift
Une fois le modèle construit et déployé, le travail n’est pas terminé !
Il y a un risque que ses performances se dégradent. Certains modèles sont même obsolètes avant leur déploiement. Pour un algorithme de prédiction tarifaire par exemple, un fournisseur racheté par son principal concurrent pourra impacter les dynamiques de prix dans un marché oligopolistique.
Pour faire face à ce challenge, les experts doivent être capables d’évaluer le profil des données en input du modèle et ses performances régulièrement et de le reprendre à n’importe quelle étape de son développement : repartir dans un cycle complet ou entrer en cours de cycle pour intégrer de nouvelles données (open data, owned ou paid), re-cleaner, refaire du feature engineering, re-modéliser, réentrainer, réévaluer les performances… puis redéployer.
Le suivi des différentes versions d’un modèle :
Enfin, une entreprise peut avoir besoin de différentes versions d’un modèle en production de manière concomitante pour des entités distinctes (régions, usines, chaînes de production, etc.). Cela implique plusieurs développements en parallèle avec différentes données d’entraînement et contraintes.
Suivre le développement d’un modèle est une tâche exigeante ; sa complexité augmente de manière exponentielle avec le nombre de versions.
La standardisation des processus de développement permet d’avoir une vue d’ensemble sur les projets. Ce qui s’avère particulièrement utile pour suivre plusieurs développements en parallèle. Cette standardisation permet également de décommissionner un modèle tout en le gardant quelque part par soucis d’archivage, de reproductibilité ou de rollback….
Vous l’aurez deviné, les catégories d’outils et de services de ML Ops que nous allons comparer permettent aux humains de collaborer efficacement dans la construction de modèles machine learning en répondant notamment aux besoins de :
- Centralisation, enregistrement et standardisation des informations clefs
- Reproductibilité des modèles
- Standardisation et industrialisation des processus
Cloud ou plateforme?
Plusieurs solutions sur le marché existent, nous allons nous concentrer sur deux types d’offres : l’approche plateforme et l’approche cloud provider.
Approche plateforme :
L’approche plateforme, qui est compatible avec un environnement cloud offerte par des acteurs comme Databricks ou Dataiku a l’avantage d’être agnostique vis-à-vis des infrastructures sous-jacentes : un gage de liberté.
En revanche, l’écosystème est en général difficilement portable. La couche d’intégration avec les infrastructures est à configurer (déploiement, monitoring, sécurité, etc.) et ces outils demandent à leurs utilisateurs un haut niveau d’expertise.
Approche cloud provider :
Les cloud providers offrent des solutions à la pointe des problématiques d’automatisation et d’industrialisation. L’intégration se fait automatiquement à leur écosystème natif (monitoring, sécurité, etc.) : un utilisateur de AWS se lancera donc plus facilement sur Sagemaker que sur la solution équivalente proposée par Microsoft Azure ou Google Cloud. Par ailleurs, plus un utilisateur est intégré avec son cloud provider, plus il sera à même de profiter des futures innovations de son fournisseur, une sorte d’exposition positive à l’innovation.
En revanche, ce service rend l’utilisateur encore plus dépendant de son fournisseur. Beaucoup de méthodes sont spécifiques et non portables, ce qui signifie qu’en changeant de fournisseur, l’utilisateur repartira de quasiment 0 …
Conclusion : Que choisir alors ?
Les deux approches répondent aux mêmes besoins et présentent des bénéfices différents et complémentaires. Le choix de la solution doit se baser sur les performances intrinsèques de la solution mais aussi et surtout sur sa pertinence vis-à-vis du système préexistant.
Le risque d’ignorer l’aspect opérationnel de la compatibilité système est l’effet patchwork. Un biais orienté poussant à prendre la solution la mieux notée au dépens de sa compatibilité avec le reste du système. Des solutions qui ne s’interfèrent pas de façon optimale créent de réels chantiers pour la supervision des outils et peuvent empiéter sur le terrain les unes des autres.
A moins que les besoins d’une entreprise soient très pointus, il est probable que les solutions répondent de façon comparable aux problématiques rencontrées, en revanche, elles ne s’intégreront pas toutes aussi bien au système d’information.
Notre conseil, commencez par faire appel aux services proposés par votre cloud provider si vous en avez déjà un. Vous pourrez vous familiariser aux outils par un paiement à l’usage sans vous lancer dans de lourds projets d’intégration . Si votre besoin n’est pas satisfait vous pourrez alors vous tourner vers des solutions alternatives en connaissance de cause.
