Framework des opérations de Machine Learning (MLOps) pour améliorer le cycle de vie du Machine Learning avec Azure Machine Learning

Ce projet client a aidé une entreprise alimentaire reprise au classement Fortune 500 à améliorer ses prévisions de demande. L’entreprise envoie des produits directement à plusieurs points de vente au détail. Cette amélioration a permis à l’entreprise d’optimiser le stockage de ses produits dans divers magasins disséminés dans plusieurs régions des États-Unis. Pour ce faire, l’équipe de génie logiciel commercial (Commercial Software Engineering, CSE) de Microsoft a collaboré avec des scientifiques Données du client en vue de conduire une étude pilote pour le développement de modèles de machine learning personnalisés pour les régions sélectionnées. Les modèles prennent en compte :

• données démographiques du client ;
• météo historique et prévisionnelle ;
• expéditions passées ;
• retours de produits ;
• événements spéciaux.

Cet objectif visant à optimiser le stockage constituait une composante majeure du projet et le client a bénéficié d’une augmentation significative des ventes lors des premiers essais sur le terrain. De plus, l’équipe a constaté une réduction de 40 % de l’erreur absolue moyenne en pourcentage (EMAP) des prévisions par rapport à un modèle de référence moyen historique.

Une partie essentielle du projet a consisté à déterminer comment faire évoluer le flux de travail de science des données du niveau étude pilote à un niveau production. Pour ce flux de travail de niveau production l’équipe CSE a dû :

• développer des modèles pour de nombreuses régions ;
• mettre à jour et surveiller en permanence les performances des modèles ;
• Facilitez la collaboration entre les équipes responsables des données et de l’ingénierie.

Le flux de travail typique de la science des données est plus proche d’un environnement de labo ponctuel que d’un flux de travail de production. Un environnement pour les scientifiques des données doit être adapté aux éléments suivants :

• préparer les données ;
• expérimenter différents modèles ;
• optimiser les hyperparamètres ;
• instaurer un cycle de compilation/test/évaluation/perfectionnement.

La plupart des outils utilisés pour ces tâches ont des objectifs spécifiques et ne sont pas bien adaptés à l’automatisation. Pour des opérations d’apprentissage automatique au niveau production, il convient d’être plus attentif à la gestion du cycle de vie des applications (Application Lifecycle Management) et au DevOps.

L’équipe CSE a aidé le client à effectuer un scale-up de l’opération vers les niveaux de production. Ils ont implémenté différents aspects des fonctionnalités d’intégration continue et de livraison continue et ont résolu des problèmes tels que l’observabilité et l’intégration avec les fonctionnalités Azure. Au cours de l’implémentation, l’équipe a découvert des lacunes dans les conseils MLOps existants. Celles-ci devaient être résolue afin que le MLOps soit mieux compris et appliqué à grande échelle.

La compréhension des pratiques liées au MLOps aide une organisation à s’assurer que les modèles d’apprentissage automatique que le système produit sont des modèles de qualité production qui améliorent les performances. Lorsque MLOps est implémenté, l’organisation n’a plus besoin de consacrer le plus clair de son temps aux détails associés aux travaux d’infrastructure et d’ingénierie requis pour développer et exécuter des modèles d’apprentissage automatique pour des opérations au niveau production. L’implémentation de MLOps aide également les communautés de science des données et d’ingénierie logicielle à apprendre à travailler ensemble pour fournir un système prêt pour la production.

L’équipe CSE a mis à profit ce projet pour répondre à divers besoins d’apprentissage automatique de la communauté en s’attaquant à des aspects tels que le développement d’un modèle de maturité MLOps. Ces efforts visent à améliorer l’adoption de MLOps en comprenant les défis typiques des principaux acteurs du processus MLOps.

Scénarios d’engagement et techniques

Le scénario d’engagement décrit les défis concrets que l’équipe CSE a dû relever. Le scénario technique définit les conditions requises pour créer un cycle de vie de MLOps aussi fiable que le cycle de vie de DevOps établi.

Scénario d’engagement

Le client livre des produits directement à des magasins de détail sur la base d’un programme régulier. Chaque magasin de détail ayant des habitudes d’utilisation des produits qui lui sont propres, l’inventaire des produits varie à chaque livraison hebdomadaire. Les méthodologies de prévision de la demande que le client utilise ont pour but de maximiser les ventes et de minimiser les retours de produits et les pertes d’opportunités de vente. Ce projet se concentre sur l’utilisation du machine learning pour améliorer les prévisions.

L’équipe CSE a divisé le projet en deux phases. La phase 1 portait sur le développement de modèles de machine learning opérationnels pour accompagner une étude de terrain pilote concernant l’efficacité des prévisions de l’apprentissage automatique pour une région de vente sélectionnée. Le succès de la phase 1 a conduit à la phase 2, qui a permis à l’équipe d’étendre l’étude pilote initiale, passant d’un groupe minimal de modèles appliqués à une seule région géographique, à une série de modèles effectifs de niveau production pour toutes les régions de vente du client. L’un des principaux aspects à prendre en considération pour la réalisation d’un scale-up de la solution fut la nécessité de composer avec le grand nombre de régions géographiques et la multiplicité de leurs magasins de détail locaux. L’équipe a dédié les modèles d’apprentissage automatique aux magasins de détail de toutes tailles dans chaque région.

L’étude pilote en phase 1 a permis de déterminer qu’un modèle dédié aux magasins d’une région pouvait utiliser l’historique des ventes, les données démographiques, la météo et les événements locaux spéciaux pour optimiser la prévision de la demande pour les magasins de la région. Quatre modèles de prévision par apprentissage automatique d’ensemble desservaient les magasins de détail d’une même région. Les modèles traitaient les données par lots hebdomadaires. Par ailleurs, l’équipe a développé deux modèles de référence à l’aide de données historiques à des fins de comparaison.

Pour la première version de la solution en phase 2 mise à l’échelle, l’équipe CSE a sélectionné 14 régions géographiques pour participer, y compris les magasins sur de petits et grands marchés. Elle a utilisé plus de 50 modèles de prévision par apprentissage automatique. L’équipe s’attendait à une nouvelle croissance du système et à un perfectionnement continu des modèles d’apprentissage automatique. Il est rapidement devenu évident que cette solution d’apprentissage automatique à plus grande échelle n’était viable que si elle se basait sur les principes de meilleures pratiques de DevOps pour l’environnement d’apprentissage automatique.

Environnement	Région de vente	Format	Modèles	Subdivision du modèle	Description du modèle
Environnement de développement	Chaque région/marché géographique (par exemple, Nord-Texas)	Magasins de grande taille (supermarchés, grandes surfaces, etc.)	2 modèles d’ensemble	Produits à rotation lente	Les produits tant à rotation lente qu’à rotation rapide ont un ensemble composé modèle de régression linéaire LASSO (Least Absolute Shrinkage and Selection Operator) et d’un réseau neuronal avec des incorporations catégorielles
				Produits à rotation rapide	Les produits tant à rotation lente qu’à rotation rapide ont un ensemble composé d’un modèle de régression linéaire LASSO et d’un réseau neuronal avec des incorporations catégorielles
			1 modèle d’ensemble	N/A	Moyenne historique
		Magasins de petite taille (pharmacies, commerces de proximité, etc.)	2 modèles d’ensemble	Produits à rotation lente	Les produits tant à rotation lente qu’à rotation rapide ont un ensemble composé d’un modèle de régression linéaire LASSO et d’un réseau neuronal avec des incorporations catégorielles
				Produits à rotation rapide	Les produits tant à rotation lente qu’à rotation rapide ont un ensemble composé d’un modèle de régression linéaire LASSO et d’un réseau neuronal avec des incorporations catégorielles
			1 modèle d’ensemble	N/A	Moyenne historique
	Identique à ce qui précède pour 13 régions géographiques supplémentaires
Identique à ce qui précède pour l’environnement de production

Le processus de MLOps a fourni une infrastructure pour le système mis à l’échelle, qui prendrait en compte le cycle de vie complet des modèles d’apprentissage automatique. L’infrastructure inclut le développement, le test, le déploiement, l’opération et la supervision. Il répond aux besoins d’un processus CI/CD classique. Toutefois, en raison de l’immaturité relative de cette infrastructure par rapport au DevOps, il est devenu évident que les directives existantes relatives au MLOps présentaient des lacunes. Les équipes de projet ont travaillé pour combler certains de ces lacunes. Elles voulaient fournir un modèle de processus fonctionnel, qui garantisse la viabilité de la solution d’apprentissage automatique à plus grande échelle.

Le processus de MLOps développé à partir de ce projet a fait un pas réel important pour amener le MLOps à un niveau supérieur de maturité et de viabilité. Le nouveau processus s’applique directement à d’autres projets d’apprentissage automatique. L’équipe CSE a tiré parti de ses apprentissages pour créer un projet de modèle de maturité MLOps que tout le monde peut appliquer à d’autres projets d’apprentissage automatique.

Scénario technique

MLOps, également appelé DevOps pour le Machine Learning, est un terme générique qui englobe les philosophies, les pratiques et les technologies liées à l’implémentation de cycle de vie du Machine Learning dans un environnement de production. Il s’agit néanmoins d’un concept relativement nouveau. De nombreuses tentatives ont été effectuées pour définir MLOps, et de nombreuses personnes ont demandé si MLOps pouvait tout remplacer, de la façon dont les scientifiques des données préparent les données à la façon dont ils fournissent, surveillent et évaluent les résultats du Machine Learning. Si DevOps a mis des années pour développer un ensemble de pratiques fondamentales, MLOps n’en est encore qu’à un stade précoce de son développement. À mesure MLOps évolue, nous découvrons les défis associés à l’union deux disciplines qui fonctionnent souvent avec différents ensembles de compétences et priorités : l’ingénierie logicielle/opérationnelle et la science des données.

L’implémentation du MLOps dans des environnements de production réels présente des défis uniques qui doivent être relevés. Les équipes peuvent utiliser Azure en appui de leur modèles de MLOps. Azure peut également fournir aux clients des services de gestion et d’orchestration des services pour gérer efficacement le cycle de vie du machine learning. Les services Azure constituent le fondement de la solution de MLOps décrite dans cet article.

Conditions requises pour le modèle d’apprentissage automatique

Une grande partie du travail au cours de l’étude de terrain pilote en phase 1 a impliqué la création de modèles d’apprentissage automatique que l’équipe CSE a appliqué aux magasins de détail de toutes tailles dans une seule région. Les conditions requises notables pour le modèle étaient les suivantes :

• Utilisation d’Azure Machine Learning service.

• Modèles expérimentaux initiaux développés dans Jupyter Notebook et implémentés dans Python.

  Notes

  Utilisation par les équipes d’une approche commune de l’apprentissage automatique pour les magasins de toutes tailles, mais données d’apprentissage et de scoring dépendant de la taille du magasin.

• Préparation indispensable des données destinées à l’usage du modèle.

• Données traitées par lots plutôt qu’en temps réel.

• Réapprentissage du modèle chaque fois que le code ou les données changent, ou que le modèle est obsolète.

• Affichage des performances du modèle dans les tableaux de bord Power BI.

• Performances du modèle en termes de scoring considérées comme significatives lorsque la valeur de MAPE <= 45 % par rapport à un modèle de référence moyen historique.

Conditions requises pour le MLOps

L’équipe a dû répondre à plusieurs exigences clés pour mettre à l’échelle la solution à partir de l’étude de terrain pilote en phase 1, dans laquelle seuls quelques modèles ont été développés pour une seule région de vente. La phase 2 a implémenté des modèles de machine learning personnalisés pour plusieurs régions. L’implémentation inclut :

• traitement par lots hebdomadaire pour les magasins de toutes tailles dans chaque région afin de réentraîner les modèles avec de nouveaux jeux de données ;

• affinement continu des modèles d’apprentissage automatique ;

• intégration du processus de développement/test/empaquetage/test/déploiement commun aux opérations de CI/CD dans un environnement de traitement de type DevOps pour le MLOps ;

  Notes

  Cela constitue une évolution par rapport à la façon dont les scientifiques et les ingénieurs des données travaillaient ordinairement par le passé.

• modèle unique représentant chaque région pour les magasins de toutes tailles, en fonction de l’historique, des données démographiques et d’autres variables clés des magasins ; le modèle devant traiter le jeu de données entier pour minimiser le risque d’erreur de traitement ;

• possibilité de mise à l’échelle initiale pour prendre en charge 14 régions de vente, avec des plans d’augmentation d’échelle ultérieure ;

• plans pour des modèles supplémentaires permettant des prévisions à plus long terme pour certaines régions et autres clusters de magasins.

Solution de modèle d’apprentissage automatique

Le cycle de vie de l’apprentissage automatique, également appelé cycle de vie de la science des données, correspond à peu près au flux de processus de haut niveau suivant :

L’étape Deploy Model (Déployer le modèle) ici peut représenter toute utilisation opérationnelle du modèle d’apprentissage automatique validé. Par rapport au DevOps, le MLOps présente le défi supplémentaire lié à l’intégration du cycle de vie de l’apprentissage automatique dans le processus de CI/CD classique.

Le cycle de vie de la science des données ne suit pas le cycle de vie du développement de logiciels classique. Il inclut l’utilisation de Azure Machine Learning pour entraîner et noter les modèles. Ces étapes doivent donc être incluses dans l’automatisation CI/CD.

Le traitement par lots des données constitue la base de l’architecture. Deux pipelines Azure Machine Learning sont au centre du processus, l’un pour l’apprentissage, et l’autre pour le scoring. Ce diagramme illustre la méthodologie de science des données utilisée pour la phase initiale du projet client :

L’équipe a testé plusieurs algorithmes. Ils ont finalement choisi une conception d’ensemble constitué d’un modèle de régression linéaire LASSO et d’un réseau neuronal avec incorporations catégorielles. L’équipe a utilisé le même modèle, défini par le niveau de produit que le client peut stocker localement pour les magasins de toutes tailles. L’équipe a ensuite subdivisé le modèle en produits à rotation rapide et à rotation lente.

Les scientifiques des données effectuent l’apprentissage des modèles de machine learning quand l’équipe met en production un nouveau code et quand de nouvelles données sont disponibles. L’apprentissage se produit généralement de façon hebdomadaire. Par conséquent, chaque exécution de traitement implique une grande quantité de données. Puisque l’équipe collecte les données à partir de nombreuses sources dans différents formats, elle a besoin d’un conditionnement pour les convertir dans un format permettant aux scientifiques des données de les traiter. Ce conditionnement de données nécessite un travail manuel conséquent, et l’équipe CSE l’a identifié comme un candidat de choix pour l’automatisation.

Comme nous l’avons mentionné précédemment, les scientifiques des données ont développé et appliqué les modèles Azure Machine Learning expérimentaux à une seule région de vente dans le cadre de l’étude de terrain pilote en phase 1 pour évaluer l’utilité de cette approche de la prévision. L’équipe CSE a estimé que les ventes relevées pour les magasins dans le cadre de l’étude pilote étaient significatives. Ce succès a justifié l’application de la solution à des niveaux de production complets dans la phase 2, avec pour commencer 14 régions géographiques et des milliers de magasins. L’équipe a ensuite pu utiliser le même modèle pour ajouter des régions.

Le modèle pilote a servi de base pour la solution mise à l’échelle, mais l’équipe CSE savait que le modèle nécessitait un perfectionnement pour améliorer ses performances.

Solution de MLOps

Au fur et à mesure que les concepts MLOps mûrissent, les équipes découvrent souvent des défis pour réunir les disciplines de science des données et de DevOps. C’est pourquoi les principaux acteurs des disciplines, les ingénieurs logiciels et les scientifiques des données fonctionnent avec différents ensembles de compétences et priorités.

Mais il y a des similitudes à exploiter. À l’instar du DevOps, le MLOps est un processus de développement implémenté par une chaîne d’outils. Le chaîne d’outils MLOps inclut des éléments tels que les suivants :

• Gestion de versions
• Analyse du code
• Automatisation de la génération
• Intégration continue
• Infrastructures et automatisation des tests
• Stratégies de conformité intégrées dans les pipelines de CI/CD
• Automatisation du déploiement
• Surveillance
• Récupération d’urgence et haute disponibilité
• Gestion de package et du conteneur

Comme indiqué ci-dessus, la solution tire parti de directives de DevOps existantes, mais elle est augmentée pour créer une implémentation de MLOps plus mûre répondant aux besoins du client et de la communauté de science des données. Le MLOps s’appuie sur les directives de DevOps en y ajoutant les exigences suivantes :

• Le contrôle de version des données/modèles diffère du contrôle de version de code : il doit y avoir un contrôle de version des jeux de données quand le schéma et les données d’origine changent.
• Exigences relatives à la piste d’audit numérique : suivez toutes les modifications de code et de données client.
• Généralisation : sur le plan de la réutilisation, les modèles diffèrent du code, car les scientifiques des données doivent les ajuster en fonction des données et du scénario d’entrée. Pour réutiliser un modèle dans un nouveau scénario, il se peut que vous deviez effectuer un ajustement, un transfert ou un apprentissage. Vous avez besoin du pipeline d’apprentissage.
• Modèles obsolètes : les modèles ont tendance à décliner au fil du temps et vous devez pouvoir les reformer à la demande pour vous assurer qu’ils restent pertinents en production.

Défis du MLOps

Standard de MLOps immature

Le modèle standard pour le MLOps est toujours en cours d’évolution. Une solution est généralement développée à partir de rien et s’adapte aux besoins d’un client ou d’un utilisateur particulier. Consciente de cette lacune, l’équipe CSE a cherché à utiliser les meilleures pratiques de DevOps dans ce projet. Elle a augmenté le processus de DevOps pour répondre aux exigences supplémentaires du MLOps. Le processus que l’équipe a développé est un exemple viable de ce à quoi doit ressembler un modèle de MLOps standard.

Différences au niveau des ensembles de compétences

Les ingénieurs logiciels et les scientifiques des données apportent des compétences uniques à l’équipe. Ces compétences différentes peuvent compliquer la recherche d’une solution adaptée aux besoins des chacun. Il est important de mettre en place un flux de travail bien compris pour la livraison du modèle, de l’expérimentation à la production. Les membres de l’équipe doivent comprendre comment ils peuvent intégrer les modifications dans le système sans entraver le processus de MLOps.

Gestion de plusieurs modèles

Plusieurs modèles sont souvent nécessaires pour résoudre des scénarios d’apprentissage automatique complexes. L’un des défis du MLOps est la gestion de ces modèles, à avoir :

• disposer d’un schéma de contrôle de version cohérent ;
• évaluer et surveiller continuellement tous les modèles.

Une traçabilité du code et des données est également nécessaire pour diagnostiquer les problèmes de modèle et créer des modèles reproductibles. Des tableaux de bord personnalisés peut être utile pour pouvoir suivre les performances des modèles déployés et indiquer quand intervenir le cas échéant. L’équipe a créé de tels tableaux de bord pour ce projet.

Besoin d’un conditionnement des données

Les données utilisées avec ces modèles proviennent de nombreuses sources privées et publiques. Étant donné que les données d’origine sont désorganisées, il est impossible que le modèle d’apprentissage automatique les utilise dans leur état brut. Les scientifiques des données doivent conditionner les données dans un format standard que le modèle d’apprentissage automatique peut utiliser.

Une grande partie du test de terrain pilote s’est concentrée sur le conditionnement des données brutes afin que le modèle d’apprentissage automatique puisse le traiter. Dans un système de MLOps, l’équipe doit automatiser ce processus et suivre les sorties.

Modèle de maturité MLOps

L’objectif du modèle de maturité MLOps est de clarifier les principes et pratiques, ainsi que d’identifier des lacunes dans une implémentation de MLOps. Il s’agit également d’un moyen de montrer à un client comment augmenter de façon incrémentielle sa capacité de MLOps au lieu de devoir tout tenter en même temps. Le client doit l’utiliser comme guide pour effectuer les opérations suivantes :

• estimer l’étendue du travail pour le projet ;
• établir des critères de réussite ;
• Identifiez les livrables.

Le modèle de maturité MLOps définit cinq niveaux de capacité technique :

Level	Description
0	Pas d’Ops
1	DevOps mais pas de MLOps
2	Apprentissage automatisé
3	Modèle de déploiement automatisé
4	Opérations automatisées (MLOps complet)

Pour la version actuelle du modèle de maturité MLOps, consultez l’article Modèle de maturité MLOps.

Définition du processus de MLOps

MLOps inclut toutes les activités d’acquisition de données brutes à la sortie du modèle, également appelées scoring :

• Conditionnement des données
• Apprentissage du modèle
• Test et évaluation du modèle
• Définition et pipeline de build
• Pipeline de mise en production
• Déploiement
• Notation

Processus d’apprentissage automatique de base

Le processus d’apprentissage automatique de base est similaire au développement logiciel traditionnel, mais il existe des différences importantes. Ce diagramme illustre les principales étapes du processus d’apprentissage automatique :

La phase d’expérimentation est unique au cycle de vie de la science des données, qui reflète la façon dont les scientifiques des données effectuent traditionnellement leur travail. Cela diffère de la façon dont les développeurs de code effectuent leur travail. Le diagramme suivant illustre ce cycle de vie plus en détail.

L’intégration de ce processus de développement de données dans MLOps est un défi. Ici, vous voyez le modèle que l’équipe a utilisé pour intégrer le processus dans un formulaire que le MLOps prend en charge :

Le MLOps a pour rôle de créer un processus coordonné capable de prendre en charge efficacement des environnements de CI/CD à grande échelle courants dans des systèmes au niveau production. Conceptuellement, le modèle de MLOps doit inclure toutes les exigences du processus, de l’expérimentation au scoring.

L’équipe CSE a affiné le processus MLOps afin de répondre aux besoins spécifiques du client. Le besoin le plus notable était celui d’un traitement par lots au lieu d’un traitement en temps réel. À mesure que l’équipe développait le système à plus grande l’échelle, elle a identifié et résolu certaines lacunes. La plus importante de ces lacunes a entraîné le développement d’un pont entre Azure Data Factory et Azure Machine Learning, que l’équipe a implémenté en tant que connecteur intégré dans Azure Data Factory. Ils ont créé cet ensemble de composants pour faciliter le déclenchement et la surveillance d’état nécessaires au fonctionnement de l’automatisation du processus.

Un autre changement fondamental était que le scientifique des données avait besoin de la capacité d’exporter du code expérimental de notebooks Jupyter vers le processus de déploiement de MLOps au lieu de déclencher directement l’apprentissage et le scoring.

Voici le concept final du modèle de processus de MLOps :

Flux du processus de MLOps

Le diagramme suivant décrit comment appliquer des flux de travail de développement et de mise en production CI/CD au cycle de vie de l’apprentissage automatique :

• Quand une demande de tirage (pull request) est créée à partir d’une branche de fonctionnalité, le pipeline exécute des tests de validation de code pour valider la qualité du code via des tests unitaires et des tests de qualité du code. Pour valider la qualité en amont, le pipeline exécute également des tests de validation du modèle de base pour valider les étapes de formation et de scoring de bout en bout avec un exemple d’ensemble de données factices.
• Quand la demande de tirage (pull request) est fusionnée dans la branche primaire, le pipeline de CI exécute les mêmes tests de validation de code et de modèle de base avec une époque incrémentée. Le pipeline contient alors les artefacts incluant le code et les fichiers binaires à exécuter dans l’environnement d’apprentissage automatique.
• Une fois les artefacts disponibles, un pipeline de CD de validation du modèle est déclenché. Il exécute une validation de bout en bout sur l’environnement d’apprentissage automatique de développement. Un mécanisme de scoring est publié. Pour un scénario de scoring par lot, un pipeline de scoring est publié dans l’environnement d’apprentissage automatique et déclenché pour produire des résultats. Si vous souhaitez utiliser un scénario de scoring en temps réel, vous pouvez publier une application web ou déployer un conteneur.
• Une fois qu’un jalon est créé et fusionné dans la branche de mise en production, les mêmes pipeline de CD et pipeline de CD de validation du modèle sont déclenchés. Cette fois-ci, ils s’exécutent sur le code en fonction de la branche de mise en production.

Vous pouvez considérer le flux de données du processus de MLOps présenté ci-dessus comme une infrastructure d’archétype pour des projets qui opèrent des choix architecturaux similaires.

Tests de validation de code

Les tests de validation de code pour l’apprentissage automatique se concentrent sur la validation de la qualité de la base de code. Il s’agit du même concept que tout projet d’ingénierie impliquant des tests de qualité du code (linting), des tests unitaires et des mesures de la couverture du code.

Tests de validation du modèle de base

La validation du modèle fait généralement référence à la validation de l’intégralité des étapes du processus de bout en bout requises pour produire un modèle d’apprentissage automatique valide. Elle inclut des étapes telles que :

• Validation des données : veille à ce que les données d’entrée soient valides.
• Validation de l’apprentissage : veille à ce que l’apprentissage du modèle puisse être effectué correctement.
• Validation du scoring : veille à ce que l’équipe puisse utiliser avec succès le modèle formé pour le scoring avec les données d’entrée.

L’exécution de cette série complète d’étapes sur l’environnement d’apprentissage automatique est coûteuse et laborieuse. En conséquence, l’équipe a effectué des tests de validation de base du modèle sur une machine de développement. Il a exécuté les étapes ci-dessus et utilisé les éléments suivants :

• Jeu de données de test local : un petit jeu de données, souvent masqué, archivé dans le référentiel et consommé comme source de données d’entrée.
• indicateur local : indicateur ou argument dans le code du modèle, qui indique que le code vise à ce que le jeu de données s’exécute localement. L’indicateur permet au code de contourner tout appel à l’environnement d’apprentissage automatique.

L’objectif de ces tests de validation n’est pas d’évaluer les performances du modèle formé. Ils vont plutôt valider le fait que le code du processus de bout en bout est de bonne qualité. Il garantit la qualité du code qui est envoyé en amont, comme l’incorporation de tests de validation du modèle dans la build de demande de tirage et de CI. Il permet aussi aux ingénieurs et aux scientifiques des données d’insérer un point d’arrêt dans le code à des fins de débogage.

Pipeline de CD de validation du modèle

L’objectif du pipeline de validation du modèle est de valider les étapes de formation et de scoring du modèle de bout en bout sur l’environnement d’apprentissage automatique avec des données réelles. Tout modèle entraîné produit sera ajouté au registre de modèles et étiqueté pour attendre la promotion une fois la validation terminée. Pour une prédiction par lot, la promotion peut publier un pipeline de scoring utilisant cette version du modèle. Pour un scoring en temps réel, le modèle peut être marqué pour indiquer qu’il a été promu.

Pipeline de CD de scoring

Le pipeline de CD de scoring est applicable au scénario d’inférence de lot, où le même orchestrateur de modèle utilisé pour la validation du modèle déclenche le pipeline de scoring publié.

Environnements de développement et de production

Il est recommandé de séparer les environnements de développement (dev) et de production (prod). Cela permet au système de déclencher les pipelines de CD de validation du modèle et de CD de scoring selon des planifications différentes. Pour le flux de MLOps décrit, les pipelines ciblant la branche primaire s’exécutent dans l’environnement de développement, et le pipeline ciblant la branche de mise en production s’exécute dans l’environnement de production.

Modifications du code et modifications des données

Les sections précédentes ont principalement trait à la façon de gérer les modifications de code, du développement à la mise en production. Cependant, les modifications des données nécessitent la même rigueur que les modifications du code pour offrir la même qualité de validation et la même cohérence en production. Avec un déclencheur de modification de données ou un déclencheur de minuteur, le système peut déclencher le pipeline de CD de validation du modèle et le pipeline de CD de scoring à partir de l’orchestrateur du modèle pour exécuter le même processus que celui exécuté pour les modifications de code dans l’environnement de production de la branche de mise en production.

Personas et rôles de MLOps

Une exigence essentielle pour tout processus de MLOps est que celui-ci réponde aux besoins d’un grand nombre de ses utilisateurs. Pour des raisons de conception, considérez ces utilisateurs comme des personas individuelles. Pour ce projet, l’équipe a identifié les personas suivantes :

• Scientifique des données : crée le modèle d’apprentissage automatique et ses algorithmes.
• Ingénieur
  • Ingénieur des données : gère le conditionnement des données.
  • ingénieur logiciel : gère l’intégration du modèle dans le package de ressources et le flux de travail de CI/CD.
• Opérations ou informatique : supervise les opérations système.
• Partie prenante commerciale : s’occupe des prédictions effectuées par le modèle d’apprentissage automatique et de la manière dont elles aident l’entreprise.
• Utilisateur final des données : Utilise la sortie du modèle d’une manière qui aide à prendre des décisions métier.

L’équipe a dû traiter trois des résultats clés des études de persona et de rôle :

• Les scientifiques et les ingénieurs des données diffèrent sur les plans de l’approche du travail et des compétences. La facilitation de la collaboration entre scientifiques et ingénieurs des données est une considération majeure dans la conception du flux du processus de MLOps. Cela nécessite l’acquisition de nouvelles compétences par tous les membres de l’équipe.
• Il est indispensable d’unifier l’ensemble des principales personas sans aliéner qui que ce soit. Voici une manière de le faire :
  • Assurez-vous qu’elles comprennent le modèle conceptuel pour MLOps.
  • Donnez votre accord pour que les membres de l’équipe travaillent ensemble.
  • Établissez des directives de travail pour atteindre des objectifs courants.
• Si les parties prenantes métier et l’utilisateur final des données ont besoin d’un moyen d’interagir avec la sortie des données des modèles, une interface utilisateur conviviale est la solution standard.

D’autres équipes rencontreront certainement des problèmes similaires dans d’autres projets d’apprentissage automatique à mesure qu’elles augmenteront l’échelle pour une utilisation en production.

Architecture de solution de MLOps

Architecture logique

Les données proviennent de nombreuses sources dans de nombreux formats différents, donc elles sont conditionnées avant d’être insérées dans le lac de données. Le conditionnement est effectué à l’aide de microservices fonctionnant comme Azure Functions. Les clients personnalisent les microservices en fonction des sources de données, et les transforment dans un format de CSV standardisé que les pipelines d’apprentissage et de scoring peuvent utiliser.

Architecture du système

Architecture de traitement par lots

L’équipe a élaboré la conception architecturale pour prendre en charge un schéma de traitement de données par lot. Il existe des alternatives, mais ce qui est utilisé doit prendre en charge les processus MLOps. L’utilisation complète des services Azure disponibles était une exigence de conception. Le diagramme suivant présente l’architecture :

Vue d’ensemble de la solution

Azure Data Factory effectue les opérations suivantes :

• déclenche une fonction Azure pour démarrer l’ingestion des données et une exécution du pipeline Azure Machine Learning.
• Lance une fonction durable pour interroger le pipeline Azure Machine Learning afin de déterminer s’il a aboutit.

Des tableaux de bord personnalisés dans Power BI affichent les résultats. D’autres tableaux de bord Azure, connectés à Azure SQL, Azure Monitor et Application Insights via le kit de développement logiciel (SDK) Python OpenCensus effectuent le suivi des ressources Azure. Ces tableaux de bord fournissent des informations sur l’intégrité du système d’apprentissage automatique. Ils génèrent également les données que le client utilise pour la prévision des commandes de produits.

Orchestration de modèle

L’orchestration de modèle suit les étapes suivantes :

1. Quand une demande de tirage (pull request) est soumise, le DevOps déclenche un pipeline de validation du code.
2. Le pipeline exécute des tests unitaires, des tests de qualité de code et des tests de validation du modèle.
3. Quand ils sont fusionnés dans la branche primaire, les mêmes tests de validation de code s’exécutent et le DevOps empaquète les artefacts.
4. La collecte d’artefacts par DevOps entraîne les actions suivantes par Azure Machine Learning :
   1. Validation des données.
   2. Validation de l’apprentissage.
   3. Validation du scoring.
5. Une fois la validation terminée, le pipeline de scoring final est exécuté.
6. La modification des données et l’envoi d’une nouvelle demande de tirage déclenche à nouveau le pipeline de validation, suivi du pipeline de scoring final.

Activer l’expérimentation

Comme nous l’avons vu, le cycle de vie traditionnel de l’apprentissage automatique de la science des données ne prend pas en charge le processus de MLOps sans modification. Il utilise différents types d’outils manuels, ainsi que des fonctionnalités d’expérimentation, de validation, d’empaquetage et de transfert de projet, qui ne peuvent pas être facilement mis à l’échelle pour un processus de CI/CD efficace. Le MLOps exige un niveau élevé d’automatisation du processus. Qu’un nouveau modèle de machine learning soit développé ou qu’un ancien modèle soit modifié, il est nécessaire d’automatiser le cycle de vie du modèle de machine learning. Dans la phase 2 du projet, l’équipe a utilisé Azure DevOps pour orchestrer et republier des pipelines Azure Machine Learning pour des tâches d’apprentissage. La branche primaire durable effectue les test de base des modèles et pousse les versions stables via la branche de mise en production durable.

Le contrôle de code source devient une partie importante de ce processus. Git est le système de contrôle de version utilisé pour suivre le notebook et le code du modèle. Il prend également en charge l’automatisation du processus. Le flux de travail de base implémenté pour le contrôle de code source applique les principes suivants :

• Utilisez le contrôle de version formel pour le code et les jeux de données.
• Utilisez une branche pour le développement de nouveau code jusqu’à ce que le code soit entièrement développé et validé.
• Une fois le nouveau code validé, il peut être fusionné dans la branche principale.
• Pour une version, une branche versionnée permanente est créée distinctement de la branche principale.
• Utilisez les versions et le contrôle de code source pour les jeux de données que vous avez conditionnés pour l’apprentissage ou la consommation, afin de pouvoir préserver l’intégrité de chaque jeu de données.
• Utiliser un contrôle de code source pour suivre vos expériences Jupyter Notebook.

Intégration avec des sources de données

Les scientifiques des données utilisent de nombreuses sources de données brutes et des jeux de données traités pour expérimenter les différents modèles d’apprentissage automatique. Le volume de données dans un environnement de production peut être écrasant. Pour expérimenter différents modèles, les scientifiques des données doivent utiliser des outils de gestion tels qu’Azure Data Lake. L’exigence relative à l’identification formelle et au contrôle de version s’applique à l’ensemble des données brutes, aux jeux de données préparés et aux modèles d’apprentissage automatique.

Dans le projet, les scientifiques des données ont conditionné les données suivantes comme entrée dans le modèle :

• Données hebdomadaires historiques depuis janvier 2017
• Données météorologiques quotidiennes historiques et prévues pour chaque code postal
• Données de l’acheteur pour chaque ID de magasin

Intégration avec le contrôle de code source

Pour préparer les scientifiques des données à l’application des meilleures pratiques en matière d’ingénierie, il est nécessaire d’intégrer aisément les outils qu’ils utilisent avec des systèmes de contrôle de code source tels que GitHub. Cette pratique permet le contrôle de version du modèle d’apprentissage automatique, la collaboration entre les membres de l’équipe et la récupération d’urgence si les équipes subissent une perte de données ou une interruption de système.

Prise en charge de modèle d’ensemble

La conception de modèle dans ce projet était un modèle d’ensemble. Autrement dit, les scientifiques des données ont utilisé de nombreux algorithmes dans la conception du modèle final. Dans ce cas, les modèles ont utilisé la même conception d’algorithme de base. La seule différence était qu’ils utilisaient des données d’apprentissage et de scoring différentes. Les modèles utilisaient la combinaison d’un algorithme de régression linéaire LASSO et d’un réseau neuronal.

L’équipe a envisagé, sans toutefois l’implémenter, la possibilité de poursuivre le processus jusqu’à ce qu’il permette de faire fonctionner en production de nombreux modèles en temps réel pour répondre à une demande donnée. Cette option peut permettre l’utilisation de modèles d’ensemble dans des tests A/B et des expériences entrelacées.

Interfaces pour utilisateur final

L’équipe a développé des interfaces pour utilisateur final pour l’observabilité, la surveillance et l’instrumentation. Comme mentionné, les tableaux de bord affichent visuellement les données du modèle d’apprentissage automatique. Ces tableaux de bord affichent les données suivantes dans un format convivial :

• Étapes du pipeline, y compris le prétraitement des données d’entrée.
• Pour surveiller l’intégrité du traitement du modèle d’apprentissage automatique :
  • Quelles métriques collectez-vous à partir de votre modèle déployé ?
    • MAPE : Mean Absolute Percentage Error (erreur absolue moyenne en pourcentage, métrique clé de suivi des performances globales ; (Ciblez une valeur de MAPE <= 0,45 pour chaque modèle.)
    • RMSE 0 : Root Mean Squared Error (erreur quadratique moyenne) lorsque la valeur cible réelle = 0.
    • RMSE All : RMSE sur le jeu de données entier.
  • Comment évaluer si votre modèle fonctionne comme prévu en production ?
  • Existe-t-il un moyen de savoir si les données de production s’écartent trop des valeurs attendues ?
  • Votre modèle fonctionne-t-il mal en production ?
  • Avez-vous un état de basculement ?
• Ils effectuent le suivi de la qualité des données traitées.
• Ils affichent le scoring et les prédictions produites par le modèle d’apprentissage automatique.

L’application remplit les tableaux de bord en fonction de la nature des données et de la façon dont il les traite et les analyse. Par conséquent, l’équipe doit concevoir la disposition exacte des tableaux de bord pour chaque cas d’usage. Voici deux exemples de tableaux de bord :

Les tableaux de bord ont été conçus pour fournir des informations facilement utilisables pour la consommation par l’utilisateur final des prédictions de modèle d’apprentissage automatique.

Components

• Azure Machine Learning
  • Capacité de calcul Azure Machine Learning
  • Pipelines Azure Machine Learning
  • Registre de modèles Azure Machine Learning
• Stockage Blob Azure
• Azure Data Lake Storage
• Azure Pipelines
• Azure Data Factory.
• Azure Functions pour Python
• Azure Monitor
  • Journaux d’activité
  • Application Insights
• Azure SQL Database
• Tableaux de bord Azure
• Power BI

À propos de l’installation

Vous trouverez ici une liste de considérations à explorer. Elles sont basées sur les leçons que l’équipe CSE a apprises pendant le projet.

Considérations relatives à l’environnement

• Les scientifiques des données développent la plupart de leurs modèles Machine Learning en utilisant Python, en commençant souvent dans des notebooks Jupyter. Il peut être difficile d’implémenter ces blocs-notes en tant que code de production. Les blocs-notes Jupyter sont essentiellement un outil expérimental, tandis que les scripts Python sont plus adaptés à la production. Les équipes doivent souvent passer du temps à refactoriser le code de création de modèle en scripts Python.
• Faites en sorte que les clients qui découvrent DevOps et le machine learning sachent que l’expérimentation et la production nécessitent une rigueur différente. Il est donc recommandé de séparer les deux.
• Des outils tels que le Concepteur visuel d’Azure Machine Learning ou AutoML peuvent être efficaces pour mettre en œuvre des modèles de base, tandis que le client démarre avec des pratiques de DevOps standard à appliquer au reste de la solution.
• Azure DevOps dispose de plug-ins qui peuvent s’intégrer avec Azure Machine Learning pour vous aider à déclencher des étapes de pipeline. Le référentiel MLOpsPython contient quelques exemples de tels pipelines.
• Le machine learning nécessite souvent des machines dotées de puissants processeurs graphiques (GPU) pour l’entraînement. Si le client ne dispose pas encore d’un tel matériel, les clusters de calcul Azure Machine Learning peuvent apporter une solution efficace pour l’approvisionnement rapide d’un matériel puissant et économique qui se met à l’échelle automatiquement. Si un client a besoin d’une sécurité et/ou d’une surveillance avancées, il peut explorer d’autres options, telles que des machines virtuelles standard, la plateforme Databricks ou une solution de calcul local.
• Pour qu’un client réussisse, ses équipes de construction de modèle (scientifiques des données) et ses équipes de déploiement (ingénieurs de DevOps) doivent disposer d’un canal de communication robuste. Il peut y parvenir avec des réunions quotidiennes ou un service de conversation en ligne formel. Les deux approches permettent d’intégrer leurs efforts de développement dans une infrastructure MLOps.

Considérations relatives à la préparation des données

• La solution la plus simple pour l’utilisation d’Azure Machine Learning consiste à stocker les données dans une solution de stockage de données prise en charge. Des outils tels que le service Azure Data Factory sont efficaces pour la canalisation des données entre ces emplacements selon une planification.

• Il est important pour les clients de capturer fréquemment des données de reformation supplémentaires afin de tenir leurs modèles à jour. S’ils ne disposent pas encore d’un pipeline de données, la création d’un pipeline est une partie importante de la solution globale. L’utilisation d’une solution telle que des jeux de données dans Azure Machine Learning peut être utile pour le contrôle de version des données afin de faciliter la traçabilité des modèles.

Considérations relatives à l’apprentissage et à l’évaluation du modèle

• Il est oppressant pour un client qui vient d’entamer son parcours d’apprentissage automatique d’essayer d’implémenter un pipeline de MLOps complet. Si nécessaire, il peut faciliter les choses en utilisant Azure Machine Learning pour suivre des expériences et en utilisant la capacité de calcul d’Azure Machine Learning comme cible d’apprentissage. Ces options pourraient créer une solution à faible barrière d’entrée pour commencer à intégrer les services Azure.

• Passer d’une expérience de notebook à des scripts reproductibles est une transition assez difficile pour de nombreux scientifiques des données. Plus tôt vous pourrez écrire leur code d’apprentissage dans des scripts Python, plus il sera facile pour eux de commencer à effectuer le contrôle de version de leur code d’apprentissage et à activer la reformation.

  Il ne s’agit pas de la seule méthode possible. La plateforme Databricks prend en charge la planification des notebooks en tant que travaux. Toutefois, en fonction de l’expérience client actuelle, cette approche est difficile à mettre en œuvre avec des pratiques de DevOps complètes en raison des limitations de test.

• Il est également important de comprendre quelles mesures sont utilisées pour considérer un modèle comme un succès. La précision seule est souvent insuffisante pour déterminer les performances globales d’un modèle par rapport à un autre.

Considérations relatives à la capacité de calcul

• Les clients doivent envisager d’utiliser des conteneurs pour normaliser leurs environnements de calcul. Presque toutes les cibles de calcul d’Azure Machine Learning prennent en charge l’utilisation de Docker. L’utilisation d’un conteneur pour gérer les dépendances peut réduire considérablement les frictions, en particulier si l’équipe utilise de nombreuses cibles de calcul.

Considérations relatives au déploiement de modèles

• Le Kit de développement logiciel (SDK) Azure Machine Learning fournit une option permettant d’opérer un déploiement directement sur un environnement Azure Kubernetes Service à partir d’un modèle inscrit, en créant ainsi des limites quant à la sécurité et aux métriques en place. Vous pouvez essayer de trouver une solution plus facile pour permettre aux clients de tester leur modèle, mais il est préférable de développer un déploiement plus robuste sur un environnement AKS pour les charges de travail de production.

Étapes suivantes

• En savoir plus sur le MLOps
• MLOps sur Azure
• Visualisations d’Azure Monitor
• Cycle de vie de Machine Learning
• Extension de Machine Learning pour Azure DevOps
• Interface CLI Azure Machine Learning
• Déclenchement des applications, des processus et des workflows CI/CD en fonction d’événements Azure Machine Learning
• Configurer l’apprentissage et le déploiement de modèle avec Azure DevOps

Ressources associées

• Modèle de maturité MLOps
• Orchestrer les opérations MLOps sur Azure Databricks à l’aide de Databricks Notebook
• Modèles MLOps pour Python avec Azure Machine Learning
• Science des données et Machine Learning avec Azure Databricks
• IA citoyenne avec Power Platform
• Déployer l’IA et le computing du Machine Learning localement et en périphérie