Comment industrialiser le développement de l’IA en assemblant une plateforme MLOps Open source ?
I – Qu'est-ce que le MLOps ?
Le MLOps, ou DevOps pour le Machine Learning, est en train de devenir un élément incontournable pour le déploiement efficace de l'intelligence artificielle (IA) à grande échelle. Il y a quelques années, le défi majeur résidait dans la transition d'un simple prototype ou preuve de concept vers une application réelle, déployée et fonctionnelle. Toutefois, les enjeux ont évolué et se sont complexifiés très rapidement.
Dans le contexte actuel, les projets d'IA sont confrontés à une dynamique accélérée de changement, tant en ce qui concerne les données que les besoins métiers. Les données peuvent changer rapidement, tant en volume qu'en nature, et les exigences métiers peuvent évoluer tout aussi rapidement, nécessitant des ajustements constants des modèles d'IA pour rester pertinents et efficaces. Il faut arriver à s’adapter aux contraintes du marché en modifiant les modèles d’IA rapidement tout en garantissant leur performance.
Pourquoi le MLOps ?
C'est là que les pratiques MLOps entrent en jeu. Elles proposent un cadre pour la gestion et l'orchestration des modèles d'IA, permettant un développement continu, une mise à jour et un processus d’optimisation fluide, ainsi qu'une surveillance de leur performance. Grâce à l'adoption croissante de ces pratiques, les défis liés à la mise à l'échelle des projets d'IA, à la gestion des changements rapides des données et à la réponse aux besoins métiers en constante évolution peuvent être efficacement relevés.
En somme, le MLOps est désormais essentiel pour assurer la pérennité et l'efficacité des solutions basées sur l'IA dans un environnement de plus en plus dynamique. Le MLOps fait le pont entre l’expérimentation et la mise en production, en permettant le développement, le déploiement et la gestion de modèles de ML à grande échelle tout en favorisant la collaboration, la reproductibilité et la fiabilité.
Principaux défis
Malgré une adoption grandissante, le MLOps fait face à de nombreux défis qui se matérialisent autour de trois piliers :
• Faciliter la collaboration et les échanges entre les diverses équipes
Le défi premier est d'abolir les cloisonnements potentiels entre les Data Scientists, les Data Engineers, les équipes DevOps, voire au sein d'une même équipe (nous parlons souvent de silos). Cette démarche implique principalement la création d'espaces de développement mutualisés et l'instauration de procédures de travail uniformisées.
• Garantir la reproductibilité des résultats et gérer le cycle de vie des modèles
Des questions se posent inévitablement : comment orchestrer chacune de mes expérimentations ? Pourquoi mon modèle ne reflète plus la réalité ? Comment m'assurer qu'il est toujours à jour et comment faire face à des anomalies dans les données ? Il est ardu de répondre à ces interrogations lorsque les processus de traitement ne sont pas reproductibles et les exécutions non traçables. Le contexte où les modèles sont fréquemment amenés à évoluer force à gérer leur transition de manière fluide, sans entraver le fonctionnement existant.
• Scalabilité et déploiement à grande échelle
L'industrialisation et la garantie de la durabilité des déploiements sont des aspects cruciaux. Comment puis-je déployer mon modèle pour répondre efficacement à mon problème métier ? Comment puis-je assurer la fiabilité de mon service et réduire les coûts de fonctionnement ? La réponse réside dans l'automatisation des déploiements (lorsque cela est faisable), la mise à l'échelle dynamique de l'infrastructure et des services, et l'établissement de systèmes de surveillance et d'alerte.
II – Une architecture MLOps Open Source
Nos contraintes pour une plateforme MLOps
Chaque organisation présente des exigences et des restrictions spécifiques qui peuvent affecter l’architecture de la plateforme MLOps. Dans notre situation, nous avons identifié les caractéristiques suivantes :
• Adoption de composants open source : cela permet non seulement d'éviter les frais associés aux licences, mais aussi d'éviter le verrouillage par un fournisseur, tout en maintenant le contrôle sur les outils déployés.
• Contrôle total des données : l'emploi de services gérés par le cloud (comme AWS Sageaker, Vertex AI, etc.) n'est alors pas une option envisageable.
• Réduction au minimum des opérations manuelles (DEVOPS)
- Automatisation maximale des tâches liées au déploiement des services, à la configuration et à la maintenance
- Diminution de l'interdépendance entre les composants pour simplifier les procédures de dépannage et minimiser l'impact potentiel d'une défaillance ou d'une opération de maintenance.
- Usage exclusif des composants indispensables(selon le principe YAGNI - "You Aren't Gonna Need It"), car l'ajout de composants supplémentaires accroît le besoin d'interventions.
Une plateforme MLOps Open Source
Les fonctions servies par cette plateforme sont :
- Extraire et transformer automatiquement la donnée en s’assurant de sa conformité
- Développer et expérimenter dans un environnement collaboratif
- Automatiser, orchestrer et suivre le déroulé des chaînes de traitements et d’apprentissage
- Développer les modèles de manière collaborative, traçable et reproductible
- Effectuer des prédictions automatiquement avec les modèles
- Suivre leurs performances (sans nécessité de temps réel)
Pour les mettre en place, nous allons nous attacher à déployer les composants suivants :
Experiment tracking
Le suivi des expériences consiste à enregistrer et à surveiller toutes les expériences menées. Autrement dit, il s'agit de créer et de conserver des métadonnées associées aux modèles (par exemple, les métriques, la date de l'entraînement, le volume des données, les artefacts...) et également de documenter systématiquement toutes les exécutions des sessions d'entraînement.
Environnement d’expérimentation collaboratif & Templating
Un hub central doit servir à unifier tous les environnements de développement dans le cadre d'un projet. Cela signifie que les membres d'une équipe utilisent les mêmes outils et les mêmes configurations, facilitant ainsi la communication, rendant le flux de travail plus fluide et réduisant le risque de problèmes de configuration.
L'aspect collaboratif d'un projet favorise le partage d'un environnement commun au sein d'une équipe, permet la centralisation du travail accompli, facilite le partage d'idées et offre une vue claire et en temps réel sur les contributions de chaque membre de l'équipe.
Orchestration & Automatisation
Il est nécessaire d’organiser et de monitorer les différentes étapes entre l’ingestion des données jusqu’au serving du modèle de ML. Un orchestrateur va apporter une vue et un contrôle sur l’ensemble du processus. Pour automatiser l’exécution des différentes briques du projet, il lui est nécessaire de connaître les dépendances entre chacune, rendant possible la représentation sous forme de graphe des différentes étapes.
Model Versioning / Registry
Lorsque plusieurs versions de modèles sont déployées, il est crucial de pouvoir suivre le cycle de vie de chacune d’entre elles. De la même manière que dans le développement logiciel, celles-ci passent généralement par plusieurs étapes : développement, staging et production. De plus, il est important de pouvoir centraliser les fichiers de modèles, les packages et le code au sein d’un même espace afin d’avoir une gestion globale de ceux-ci.
Serving de modèles
Servir les modèles de machine Learning signifie les mettre à disposition dans le but de les utiliser pour effectuer des prédictions. Celles-ci peuvent se faire en temps réel, en batch ou en streaming. Les principaux points d’attention se trouvent au niveau de la facilité de déploiement (Dois-je créer un service « from scratch » ? Utiliser de l’existant ?), de la résilience (Mon service, peut-il se mettre à l’échelle ?) et du suivi/intégration continue (Puis-je automatiser le déploiement d’une nouvelle version ?).
Revue des composants utilisés
a) Coder avec JupyterLab & VScode
La plateforme Coder est un hub permettant de gérer des environnements de développement à l’aide de templates. Il propose à chacun de disposer de ses propres outils distants configurés de manière unifiée. Cela évite ainsi les problèmes liés aux différences de configurations entre postes de travail. VSCode et JupyterLab sont deux outils disponibles en son sein offrant un service de notebooking et un IDE au même endroit. De plus, des possibilités de collaboration sont offertes via le partage d’espace de travail.
b) MLFlow
MLFlow est un outil open-source d'historisation d’expérimentations, de gestion de modèles et de serving très populaire. En son sein, chaque experiment est organisée sous forme de runs qui représentent chacun une exécution unique du script d’entraînement. Les utilisateurs peuvent y associer des paramètres (hyperparamètres du modèle, learning rate...), des métriques mesurant la performance et des artefacts (fichiers, graphiques...).
Une interface web permet de visualiser et de comparer celles-ci, simplifiant la collaboration entre Data Scientists et le suivi des avancées. De plus, elle peut également être utilisée pour monitorer les exécutions automatiques des pipelines d’entraînement lorsque les modèles sont mis en production.
Le module Model Registry de MLFlow permet de répondre à ce besoin en proposant un hub centralisé, se présentant sous forme d’un catalogue de modèles avec chacun leurs versions.
Il est aisé de passer une version d’une étape à une autre (staging vers production par exemple) et il est possible d’ajouter des tags, des commentaires et des métriques à chacune d’entre elles pour faciliter la comparaison.
MLFlow Models permet de servir les modèles et d’effectuer des prédictions. Il simplifie le processus de déploiement en proposant une approche standardisée et des modèles sous forme de packages utilisables pour de l’inférence via API REST ou par batch (à l’aide d'Apache Spark par exemple). De plus, des intégrations avec de nombreux frameworks de machine learning populaires existent : PyTorch, Spark MLlib, XGBoost...
c) Airflow
Apache AirFlow est une plateforme open-source pour créer, planifier et monitorer des workflows. Chaque workflow est un DAG (graphe direct acyclique) représentant les différentes étapes du processus. Les étapes peuvent être créées soit à l’aide de fonctions ou d’opérateurs prédéfinis permettant une intégration facile avec d’autres composants.
Dans l’exemple ci-dessus le worflow est contenu dans la fonction download_rocket_launch() dans laquelle le décorateur @dag est passé pour signaler à AirFlow la présence d’un DAG. AirFlow fournit une interface web pour monitorer et planifier les différents DAG de l’infrastructure. C'est l’interface principale à utiliser pour gérer AirFlow, exécuter les workflows et les planifier.
d) Airbyte / DBT
Airbyte est un outil open source qui permet d’extraire et de charger des données. Il dispose d’une UI moderne pour visualiser et gérer les connexions. Il s’intègre avec des orchestrateurs comme Airflow, Prefect ou encore Dagster et peut être couplé avec DBT (aussi open-source) pour effectuer le T (Transformation) d’un ELT. Les connexions Airbyte sont définies dans des fichiers de configurations qu’il est possible de générer via le client octavia, en spécifiant les différents paramètres.
Il est possible de spécifier au sein d’une connexion Airbyte, une transformation de données à appliquer :
En association avec Airbyte, DBT permet de définir des Data Model As Code ainsi que de les documenter, versionner et tester. C’est un outil léger qui va traduire le SQL de ses modèles directement dans les datastores pour effectuer ses transformations. Il est possible de variabiliser son SQL via Jinja apportant plus de flexibilité, comme dans l’exemple suivant :
Conclusion
L'implémentation d'une plateforme MLOps s'est effectuée en suivant une série de phases clé :
• L'identification des contraintes spécifiques à notre environnement
• La définition des besoins essentiels pour stimuler le développement
• L'installation et l'assemblage des composants individuels de manière progressive et indépendante
Nous avons tiré de ce projet un apprentissage important : bien que certains outils puissent couvrir un large éventail de fonctions, il n'y a pas de solution universelle pour le MLOps. Il est essentiel de rester flexible dans la sélection des composants. Le MLOps est un domaine d'activité récent, en constante évolution, il faut donc s’attendre à ce que les outils et technologies disponibles changent avec le temps. Pour accélérer le déploiement de projets d'IA, il est crucial d'adopter les principes fondamentaux du MLOps (automatisation, collaboration, traçabilité, mise à l'échelle, etc.), avec la plateforme agissant comme le moteur principal de cette mise en œuvre.
La plateforme décrite dans cet article a été mise en place pour les besoins d’un projet client, vous pouvez consulter le code associé sur GitHub et nous contacter. ;)
