Ce document traite des techniques de mise en œuvre et d'automatisation de l'intégration continue (CI), de la livraison continue (CD) et de l'entraînement continu (CT) pour les systèmes de machine learning (ML).
La science des données et le ML deviennent des fonctionnalités essentielles pour la résolution des problèmes réels complexes, la transformation des secteurs d'activité et la génération de valeur dans tous les domaines. Tous les ingrédients nécessaires pour exploiter un ML efficace sont désormais à votre disposition :
- Ensembles de données volumineux
- Ressources de calcul à la demande peu coûteuses
- Accélérateurs spécialisés pour le ML sur diverses plates-formes cloud
- Avancées rapides dans différents domaines de recherche en ML : vision par ordinateur, compréhension du langage naturel et systèmes de recommandations basés sur l'IA, entre autres
Dès lors, de nombreuses entreprises investissent dans leurs équipes de science des données et leurs capacités de ML pour développer des modèles prédictifs pouvant apporter une valeur commerciale à leurs utilisateurs.
Ce document s'adresse aux data scientists et aux ingénieurs en ML qui souhaitent appliquer les principes DevOps aux systèmes de ML (MLOps). MLOps est une culture et une pratique d'ingénierie ML qui vise à unifier le développement (Dev) et les opérations (Ops) des systèmes de ML. Appliquer le MLOps signifie que vous ciblez l'automatisation et la surveillance à toutes les étapes de la construction d'un système de ML, y compris l'intégration, les tests, la publication, le déploiement et la gestion de l'infrastructure.
Les data scientists peuvent mettre en œuvre et entraîner un modèle de ML avec des performances prédictives sur un ensemble de données exclues hors connexion, en fonction des données d'entraînement pertinentes pour leur cas d'utilisation. Cependant, le véritable défi n'est pas 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. Notre longue expérience des services de ML en production chez Google nous a appris qu'exploiter des systèmes en production basés sur le ML comporte de nombreux pièges. Certains de ces pièges sont résumés dans l'article Machine Learning: The high-interest credit card of technical debt (Les contraintes techniques du machine learning : un crédit affichant un taux d'intérêt qui réserve des surprises).
Comme le montre le schéma suivant, seule une petite partie d'un système de ML réel est composée du code de ML. Les éléments environnants nécessaires sont vastes et complexes.
Figure 1 : Éléments requis pour les systèmes de ML. D'après l'article Hidden Technical Debt in Machine Learning Systems (Contraintes techniques cachées dans les systèmes de machine learning).
Dans ce schéma, le reste du système englobe la configuration, l'automatisation, la collecte de données, la vérification des données, les tests et le débogage, la gestion des ressources, l'analyse des modèles, la gestion des processus et des métadonnées, l'infrastructure de diffusion et la surveillance.
Pour développer et exploiter des systèmes complexes de ce type, vous pouvez appliquer les principes DevOps aux systèmes de ML (MLOps). Ce document traite des concepts à prendre en compte lors de la configuration d'un environnement MLOps pour vos pratiques de science des données telles que l'intégration continue (CI), la livraison continue (CD) et l'entraînement continu (CT) dans le ML.
Les sujets suivants sont abordés :
- DevOps et MLOps
- Étapes du développement de modèles de ML
- Niveaux de maturité MLOps
DevOps et MLOps
La pratique DevOps est courante dans le développement et l'utilisation de systèmes logiciels à grande échelle. Elle offre de nombreux avantages tels que la réduction des cycles de développement, l'augmentation de la vitesse de déploiement et la publication de versions fiables. Pour en tirer profit, vous devez introduire deux concepts dans le développement de systèmes logiciels :
Un système de ML est un système logiciel. Pour être certain de pouvoir créer et exploiter des systèmes de ML à grande échelle, vous devez donc appliquer les mêmes pratiques.
Cependant, les systèmes de ML présentent certaines différences par rapport aux autres systèmes logiciels :
Compétences de l'équipe : dans un projet de ML, l'équipe comprend généralement des data scientists ou des chercheurs en ML qui se concentrent sur l'analyse exploratoire des données, le développement de modèles et l'expérimentation. Ces membres peuvent ne pas être des ingénieurs logiciels expérimentés capables de créer des services de niveau production.
Développement : le ML est expérimental par nature. Vous devez tester différentes fonctionnalités, algorithmes, techniques de modélisation et configurations de paramètres pour trouver le plus rapidement possible ce qui convient le mieux au problème. La difficulté consiste à suivre ce qui a fonctionné et ce qui n'a pas fonctionné, et à garantir la reproductibilité tout en optimisant la réutilisation du code.
Tests : tester un système de ML est plus complexe que de tester d'autres systèmes logiciels. En plus des tests unitaires et d'intégration classiques, vous devez valider les données, évaluer la qualité du modèle entraîné, puis valider celui-ci.
Déploiement : dans les systèmes de ML, le déploiement est plus complexe que déployer un modèle de ML entraîné hors connexion comme un service de prédiction. Les systèmes de ML peuvent vous obliger à déployer un pipeline en plusieurs étapes en vue de réentraîner et de déployer le modèle automatiquement. Ce pipeline ajoute de la complexité et impose d'automatiser les étapes qui sont effectuées manuellement avant le déploiement par les data scientists, afin d'entraîner et de valider de nouveaux modèles.
Production : les modèles de ML peuvent réduire les performances non seulement en raison d'un codage pas toujours optimal, mais également en raison de l'évolution constante des profils de données. En d'autres termes, les modèles peuvent davantage se dégrader que dans les systèmes logiciels classiques, et vous devez en tenir compte. Vous devez donc suivre les statistiques récapitulatives de vos données et surveiller les performances en ligne de votre modèle, afin d'envoyer des notifications ou d'effectuer un rollback lorsque les valeurs s'écartent de vos attentes.
Le ML et les autres systèmes logiciels sont analogues en ce qui concerne l'intégration continue du contrôle des sources, les tests unitaires, les tests d'intégration et la livraison continue du module logiciel ou du package. Il existe cependant quelques différences notables côté ML :
- Pour l'intégration continue, il ne s'agit plus seulement de tester et de valider le code et les composants, mais également de tester et de valider des données, des schémas de données et des modèles.
- La livraison continue ne porte plus sur un seul package logiciel ou service, mais sur un système (pipeline d'entraînement ML) qui doit déployer automatiquement un autre service (service de prédiction de modèle).
- L'entraînement continu est une nouvelle propriété spécifique aux systèmes de ML, qui consiste à réentraîner et à diffuser automatiquement les modèles.
La section suivante décrit les étapes types de l'entraînement et de l'évaluation d'un modèle de ML à diffuser en tant que service de prédiction.
Étapes de science des données dans le cadre du ML
Dans tout projet de ML, après avoir défini le cas d'utilisation de l'entreprise et établi les critères de réussite, le processus de livraison d'un modèle de ML jusqu'à la production comprend les étapes suivantes. Ces étapes peuvent être effectuées manuellement ou à l'aide d'un pipeline automatisé.
- Extraction de données : vous sélectionnez et intégrez les données pertinentes de différentes sources de données pour la tâche de ML.
- Analyse des données : vous effectuez une analyse exploratoire des données (AED) pour comprendre celles qui sont disponibles pour la création du modèle de ML. Ce processus conduit aux étapes suivantes :
- Comprendre le schéma de données et les caractéristiques attendues par le modèle.
- Identifier la préparation des données et l'extraction des caractéristiques nécessaires au modèle.
- Préparation des données : les données sont préparées pour la tâche de ML. Cette préparation implique le nettoyage des données, qui consiste à les scinder en trois parties : ensemble d'entraînement, ensemble de validation et ensemble de test. Elle implique également des transformations de données et l'extraction de caractéristiques appliquées au modèle qui résout la tâche cible. Cette étape permet d'obtenir des divisions de données au format préparé.
- Entraînement de modèles : le data scientist met en œuvre différents algorithmes avec les données préparées pour entraîner différents modèles de ML. De plus, les algorithmes mis en œuvre font l'objet de réglages d'hyperparamètres afin de produire le modèle de ML le plus performant. Cette étape permet d'obtenir un modèle entraîné.
- Évaluation du modèle : le modèle est évalué sur un ensemble de test de données exclues pour évaluer la qualité du modèle. Le résultat de cette étape est un ensemble de métriques permettant d'évaluer la qualité du modèle.
- Validation du modèle : le modèle est adapté au déploiement, car ses performances prédictives sont supérieures à une certaine référence.
- Diffusion du modèle : le modèle validé est déployé dans un environnement cible pour réaliser des prédictions. Ce déploiement peut être l'un des suivants :
- Microservices avec une API REST pour réaliser des prédictions en ligne
- Modèle intégré à un appareil de périphérie ou mobile
- Partie d'un système de prédiction par lot
- Surveillance du modèle : les performances prédictives du modèle sont surveillées dans la perspective d'appeler une nouvelle itération dans le processus de ML.
Le niveau d'automatisation de ces étapes définit la maturité du processus de ML, qui reflète la vitesse d'entraînement de nouveaux modèles en fonction de nouvelles données ou de nouvelles mises en œuvre. Les sections suivantes décrivent trois niveaux de MLOps, du plus courant, qui n'implique aucune automatisation, au niveau d'automatisation complète des pipelines ML et CI/CD.
MLOps de niveau 0 : processus manuel
Un grand nombre d'équipes disposent de data scientists et de chercheurs en ML capables de créer des modèles de pointe, mais leur processus de création et de déploiement de modèles de ML est entièrement manuel. Il s'agit du niveau de maturité de base, ou niveau 0. Le schéma suivant illustre le workflow de ce processus.
Figure 2. Étapes manuelles de ML pour diffuser le modèle en tant que service de prédiction.
Caractéristiques
La liste suivante met en évidence les caractéristiques du processus MLOps de niveau 0, comme illustré à la figure 2 :
Processus manuel, interactif et s'appuyant sur des scripts : chaque étape est manuelle, y compris l'analyse des données, la préparation des données, l'entraînement du modèle et la validation. Il nécessite d'exécuter à la main chaque étape, et de passer manuellement de l'une à l'autre. Ce processus s'appuie généralement sur un code expérimental écrit et exécuté dans des notebooks de manière interactive par un data scientist, jusqu'à l'obtention d'un modèle fonctionnel.
Dissociation entre le ML et les opérations : le processus fait la distinction entre les data scientists, qui créent le modèle, et les ingénieurs qui le diffusent en tant que service de prédiction. Les data scientists transmettent un modèle entraîné sous forme d'artefact à l'équipe d'ingénieurs chargés de le déployer sur leur infrastructure d'API. Ce transfert peut consister à placer le modèle entraîné dans un emplacement de stockage, à vérifier l'objet du modèle dans un dépôt de code ou à l'importer dans un registre de modèles. Ensuite, les ingénieurs qui déploient le modèle doivent rendre disponibles en production les fonctionnalités requises pour une inférence à faible latence, ce qui peut entraîner un écart entraînement/inférence.
Itérations de version peu fréquentes : le processus suppose que votre équipe de science des données gère quelques modèles qui ne changent pas fréquemment (modifications de la mise en œuvre ou réentraînement du modèle avec de nouvelles données). Une nouvelle version de modèle n'est déployée que quelques fois par an.
Pas d'intégration continue : étant donné le peu de modifications de mise en œuvre attendues, la CI est ignorée. Généralement, le test du code fait partie des notebooks ou de l'exécution des scripts. Les scripts et les notebooks qui mettent en œuvre les étapes de test sont contrôlés par la source et produisent des artefacts tels que des modèles entraînés, des métriques d'évaluation et des visualisations.
Pas de livraison continue : étant donné qu'il n'y a pas de déploiements fréquents de versions de modèle, la CD n'est pas prise en compte.
Le déploiement référence le service de prédiction : le processus ne concerne que le déploiement du modèle entraîné en tant que service de prédiction (par exemple, un microservice avec une API REST), plutôt que le déploiement de l'ensemble du système de ML.
Absence de surveillance active des performances : le processus ne permet pas de suivre ni de consigner les prédictions et les actions du modèle, qui sont nécessaires pour détecter la baisse des performances du modèle et d'autres dérives comportementales.
L'équipe d'ingénierie peut avoir sa propre configuration complexe pour la configuration, les tests et le déploiement d'API, y compris la sécurité, la régression et les tests de charge et les tests en version Canary. En outre, le déploiement en production d'une nouvelle version d'un modèle de ML passe généralement par des tests A/B ou des tests en ligne avant que le modèle ne soit promu pour diffuser tout le trafic des requêtes de prédiction.
Difficultés
Le MLOps de niveau 0 est couramment utilisé par de nombreuses entreprises qui commencent à appliquer le ML à leurs cas d'utilisation. Ce processus manuel, piloté par les data scientists, peut être suffisant lorsque les modèles sont rarement modifiés ou entraînés. Toutefois, dans la pratique, les modèles présentent souvent des défaillances lorsqu'ils sont déployés en conditions réelles. Ils ne parviennent pas à s'adapter aux changements intervenant au niveau des dynamiques de l'environnement, ou des données décrivant cet environnement. Pour en savoir plus, consultez l'article Why Machine Learning Models Crash And Burn In Production (Pourquoi les modèles de machine learning échouent en production).
Pour relever ces défis et maintenir la justesse de votre modèle en production, procédez comme suit :
Surveillez activement la qualité de votre modèle en production : la surveillance vous permet de détecter les dégradations de performances et l'obsolescence du modèle. Elle sert de signal pour lancer une nouvelle itération de tests et un réentraînement (manuel) du modèle sur de nouvelles données.
Réentraînez fréquemment vos modèles en production : pour capturer les tendances en constante évolution, vous devez réentraîner votre modèle avec les données les plus récentes. Par exemple, si votre application recommande des articles de mode en s'appuyant sur le ML, ses recommandations doivent s'adapter aux dernières tendances et aux nouveaux produits.
Testez en permanence de nouvelles mises en œuvre pour produire le modèle : afin d'exploiter les dernières idées et avancées technologiques, vous devez tester de nouvelles mises en œuvre telles que l'extraction de caractéristiques, l'architecture de modèle et les hyperparamètres. Par exemple, si vous utilisez la vision par ordinateur dans la détection des visages, les modèles de visage sont fixes. Or, il existe de nouvelles techniques avancées qui améliorent la justesse de la détection.
Pour relever les défis de ce processus manuel, les pratiques MLOps de CI/CD et de CT sont utiles. En déployant un pipeline d'entraînement de ML, vous pouvez activer l'entraînement continu et configurer un système CI/CD pour tester, créer et déployer rapidement de nouvelles mises en œuvre du pipeline de ML. Ces fonctionnalités sont décrites plus en détail dans les sections suivantes.
MLOps de niveau 1 : automatisation du pipeline de ML
L'objectif du niveau 1 est d'effectuer un entraînement continu du modèle en automatisant le pipeline de ML, ce qui vous permet d'assurer la livraison continue du service de prédiction de modèle. Pour automatiser le processus d'utilisation de nouvelles données afin de réentraîner des modèles en production, vous devez intégrer au pipeline des étapes automatisées de validation des données et des modèles, ainsi que des déclencheurs de pipeline et une gestion des métadonnées.
La figure suivante est une représentation schématique d'un pipeline de ML automatisé pour l'entraînement continu.
Figure 3. Automatisation du pipeline de ML pour l'entraînement continu.
Caractéristiques
La liste suivante met en évidence les caractéristiques de la configuration MLOps de niveau 1, comme illustré à la figure 3 :
Test rapide : les étapes de tests de ML sont orchestrées. La transition entre les étapes est automatisée, ce qui permet une itération rapide des tests et une meilleure aptitude à déplacer l'ensemble du pipeline en production.
Entraînement continu du modèle en production : le modèle est automatiquement entraîné en production à l'aide de nouvelles données sur la base de déclencheurs de pipeline en direct, qui sont abordés dans la section suivante.
Symétrie expérimentale et opérationnelle : la mise en œuvre du pipeline exploité dans l'environnement de développement ou de test est appliquée à l'environnement de préproduction et de production, et constitue un aspect essentiel de la pratique MLOps d'unification du DevOps.
Code modulaire pour les composants et les pipelines : pour créer des pipelines de ML, les composants doivent être réutilisables, composables et potentiellement partageables entre les pipelines de ML. Par conséquent, bien que le code EDA puisse toujours être présent dans les notebooks, le code source des composants doit être modularisé. En outre, les composants doivent idéalement être conteneurisés pour effectuer les opérations suivantes :
- Dissocier l'environnement d'exécution de l'environnement d'exécution du code personnalisé
- Rendre le code reproductible entre les environnements de développement et de production
- Isoler chaque composant du pipeline (Les composants peuvent avoir leur propre version de l'environnement d'exécution, ainsi que différents langages et bibliothèques.)
Livraison continue de modèles : un pipeline de ML en production fournit en continu des services de prédiction à de nouveaux modèles entraînés sur de nouvelles données. L'étape de déploiement du modèle, qui diffuse le modèle entraîné et validé en tant que service de prédiction pour les prédictions en ligne, est automatisée.
Déploiement du pipeline : au niveau 0, vous déployez un modèle entraîné en tant que service de prédiction en production. Au niveau 1, vous déployez un pipeline d'entraînement complet, qui s'exécute automatiquement et de manière récurrente pour diffuser le modèle entraîné en tant que service de prédiction.
Composants supplémentaires
Cette section décrit les composants que vous devez ajouter à l'architecture pour activer l'entraînement ML continu.
Validation des données et du modèle
Lorsque vous déployez votre pipeline de ML en production, un ou plusieurs déclencheurs décrits dans la section Déclencheurs de pipeline de ML exécutent automatiquement le pipeline. Le pipeline s'attend à ce que de nouvelles données en ligne produisent une nouvelle version de modèle, entraînée sur ces nouvelles données (comme illustré à la figure 3). Par conséquent, des étapes automatiques de validation des données et de validation du modèle sont nécessaires dans le pipeline de production pour garantir le comportement attendu suivant :
Validation des données : cette étape est nécessaire avant l'entraînement du modèle pour décider si vous devez réentraîner le modèle ou arrêter l'exécution du pipeline. Cette décision est prise automatiquement si les éléments suivants ont été identifiés par le pipeline.
- Écarts du schéma de données : ces écarts sont considérés comme des anomalies dans les données d'entrée, ce qui signifie que les étapes du pipeline en aval, y compris le traitement des données et l'entraînement du modèle, reçoivent des données non conformes au schéma attendu. Dans ce cas, vous devez arrêter le pipeline afin que l'équipe de science des données puisse l'examiner. L'équipe peut publier une correction ou une mise à jour du pipeline pour gérer ces modifications dans le schéma. Les écarts de schéma incluent la réception de caractéristiques inattendues, la réception d'une partie seulement des caractéristiques attendues ou la réception de caractéristiques avec des valeurs inattendues.
- Écarts de valeur des données : ces écarts sont des changements significatifs dans les propriétés statistiques des données, ce qui signifie que les modèles de données changent. Vous devez déclencher un nouvel entraînement du modèle pour capturer ces changements.
Validation du modèle : cette étape intervient après que le modèle a été entraîné avec les nouvelles données. Vous évaluez et validez le modèle avant qu'il soit promu en production. Cette étape de validation du modèle hors connexion comprend les sous-étapes suivantes.
- Produire des valeurs de métriques d'évaluation à l'aide du modèle entraîné sur un ensemble de données de test pour évaluer la qualité prédictive du modèle.
- Comparer les valeurs des métriques d'évaluation générées par votre modèle nouvellement entraîné avec celles du modèle actuel, par exemple le modèle de production, le modèle de référence ou d'autres modèles d'exigences commerciales. Vous devez vous assurer que le nouveau modèle produit de meilleures performances que le modèle actuel avant de le promouvoir en production.
- S'assurer de la cohérence des performances du modèle sur différents segments de données. Par exemple, votre modèle de perte de clientèle nouvellement entraîné peut produire une justesse prédictive globale supérieure à celle du modèle précédent, mais les valeurs de justesse par région client peuvent présenter une variance importante.
- Assurez-vous de tester votre modèle pour le déploiement, y compris la compatibilité et la cohérence de l'infrastructure avec l'API du service de prédiction.
En plus de la validation du modèle hors connexion, un modèle nouvellement déployé fait l'objet d'une validation de modèle en ligne (dans un déploiement Canary ou une configuration de test A/B) avant de réaliser des prédictions pour le trafic en ligne.
Magasin de caractéristiques
Un magasin de caractéristiques est un composant supplémentaire facultatif pour l'automatisation d'un pipeline de ML de niveau 1. Il s'agit d'un dépôt centralisé dans lequel vous standardisez la définition, le stockage et l'accès des caractéristiques pour l'entraînement et l'inférence. Un magasin de caractéristiques doit fournir une API pour l'inférence par lot à haut débit et l'inférence en temps réel à faible latence pour les valeurs de caractéristiques, ainsi que pour les charges de travail d'entraînement et d'inférence.
Le magasin de caractéristiques offre aux data scientists les avantages suivants :
- Pouvoir identifier et réutiliser les ensembles de caractéristiques disponibles pour leurs entités, au lieu de devoir recréer des ensembles identiques ou similaires.
- Éviter d'avoir des caractéristiques similaires avec des définitions différentes en conservant les caractéristiques et leurs métadonnées associées.
- Diffuser des valeurs de caractéristiques à jour à partir du magasin de caractéristiques.
Éviter les écarts entraînement/inférence en utilisant le magasin de caractéristiques comme source de données pour les tests, l'entraînement continu et l'inférence en ligne. Cette approche garantit que les caractéristiques utilisées pour l'entraînement sont les mêmes que celles utilisées lors de l'inférence :
- Pour effectuer leurs tests, les data scientists peuvent obtenir un extrait hors connexion à partir du magasin de caractéristiques.
- Pour un entraînement continu, le pipeline d'entraînement ML automatisé peut récupérer un lot de valeurs de caractéristiques à jour de l'ensemble de données, qui sont utilisées pour la tâche d'entraînement.
- Pour la prédiction en ligne, le service de prédiction peut récupérer un lot de valeurs de caractéristiques liées à l'entité demandée, telles que les caractéristiques démographiques du client, les caractéristiques du produit et les caractéristiques d'agrégation de la session en cours.
Gestion des métadonnées
Les informations sur chaque exécution du pipeline de ML sont enregistrées pour faciliter la traçabilité, la reproductibilité et la comparaison des données et des artefacts. Elles vous aident également à déboguer les erreurs et les anomalies. Chaque fois que vous exécutez le pipeline, le magasin de métadonnées ML enregistre les métadonnées suivantes :
- Les versions du pipeline et du composant qui ont été exécutées.
- Les dates et heures de début et de fin, et le temps nécessaire au pipeline pour effectuer chacune des étapes.
- L'exécuteur du pipeline.
- Les arguments de paramètre transmis au pipeline.
- Les pointeurs vers les artefacts produits par chaque étape du pipeline, tels que l'emplacement des données préparées, les anomalies de validation, les statistiques calculées et le vocabulaire extrait des caractéristiques catégorielles. Le suivi de ces résultats intermédiaires vous permet de reprendre le pipeline à partir de la dernière étape si celui-ci s'est arrêté en raison de l'échec d'une étape, sans avoir à réexécuter celles déjà terminées.
- Un pointeur dirigé vers le modèle entraîné précédent si vous devez revenir à une version précédente du modèle ou si vous devez produire des métriques d'évaluation pour une version précédente du modèle lorsque le pipeline reçoit de nouvelles données de test lors de l'étape de validation du modèle.
- Des métriques d'évaluation du modèle générées lors de l'étape d'évaluation pour les ensembles d'entraînement et de test. Ces métriques vous permettent de comparer les performances d'un modèle nouvellement entraîné aux performances enregistrées du modèle précédent lors de l'étape de validation du modèle.
Déclencheurs de pipeline de ML
Vous pouvez automatiser les pipelines de ML en production pour réentraîner les modèles avec de nouvelles données, en fonction de votre cas d'utilisation :
- À la demande : exécution manuelle ponctuelle du pipeline.
- Selon un programme : de nouvelles données étiquetées sont systématiquement disponibles pour le système de ML sur une base quotidienne, hebdomadaire ou mensuelle. La fréquence de réentraînement dépend également de la fréquence à laquelle les modèles de données changent et des coûts liés au réentraînement de vos modèles.
- En fonction de la disponibilité de nouvelles données d'entraînement : de nouvelles données ne sont pas systématiquement disponibles pour le système de ML. Elles le sont au cas par cas, lorsque de nouvelles données sont collectées et mises à disposition dans les bases de données sources.
- En fonction de la dégradation des performances du modèle : le modèle est réentraîné en cas de baisse sensible des performances.
- En fonction de changements significatifs dans la distribution des données (dérive conceptuelle). Il est difficile d'effectuer une évaluation complète des performances du modèle en ligne. Vous remarquez cependant des changements significatifs dans la distribution des données des caractéristiques utilisées pour effectuer la prédiction. Ces modifications indiquent que votre modèle est devenu obsolète et doit être réentraîné sur de nouvelles données.
Difficultés
En partant du principe que le déploiement de nouvelles mises en œuvre du pipeline est peu fréquent et que vous ne gérez que quelques pipelines, vous testez généralement le pipeline et ses composants de manière manuelle. Les nouvelles mises en œuvre de pipeline sont également déployées manuellement. De plus, vous envoyez le code source testé du pipeline à l'équipe informatique pour son déploiement dans l'environnement cible. Cette configuration est adaptée lorsque vous déployez de nouveaux modèles basés sur de nouvelles données, plutôt que sur de nouvelles idées de ML.
Cependant, vous devez tester les nouvelles idées de ML et déployer rapidement de nouvelles mises en œuvre des composants de ML. Si vous gérez de nombreux pipelines de ML en production, vous avez besoin d'une configuration CI/CD pour automatiser les opérations de création, de test et de déploiement des pipelines de ML
MLOps de niveau 2 : automatisation du pipeline CI/CD
Pour une mise à jour rapide et fiable des pipelines en production, vous avez besoin d'un système CI/CD robuste et automatisé. Ce système CI/CD automatisé permet à vos data scientists d'explorer rapidement de nouvelles idées sur l'extraction de caractéristiques, l'architecture de modèle et les hyperparamètres. Ils peuvent mettre en œuvre ces idées, puis créer, tester et déployer automatiquement les nouveaux composants du pipeline dans l'environnement cible.
Le schéma suivant montre la mise en œuvre du pipeline de ML avec intégration CI/CD, qui présente les caractéristiques de la configuration des pipelines de ML automatisés et les routines CI/CD automatisées.
Figure 4. Pipeline de ML automatisé avec CI/CD.
Cette configuration MLOps comprend les composants suivants :
- Contrôle des sources
- Tests et création des services
- Services de déploiement
- Registre de modèles
- Magasin de caractéristiques
- Magasin de métadonnées de ML
- Orchestrateur de pipeline de ML
Caractéristiques
Le schéma suivant montre les étapes du pipeline de ML avec routines CI/CD automatisées :
Figure 5. Étapes du pipeline de ML avec routines CI/CD automatisées.
Le pipeline comprend les étapes suivantes :
Développement et expérimentation : vous orchestrez les étapes de test et testez de manière itérative de nouveaux algorithmes de ML et une nouvelle modélisation. Le résultat de cette étape est le code source des étapes du pipeline de ML qui sont ensuite transférées vers un dépôt source.
Intégration continue du pipeline : vous créez le code source et exécutez divers tests. Les résultats de cette étape sont les composants du pipeline (packages, exécutables et artefacts) qui seront déployés ultérieurement.
Livraison continue du pipeline : vous déployez les artefacts produits par l'étape CI dans l'environnement cible. Le résultat de cette étape est un pipeline déployé avec la nouvelle mise en œuvre du modèle.
Déclenchement automatisé : le pipeline est automatiquement exécuté en production en fonction d'un programme ou en réponse à un déclencheur. Le résultat de cette étape est un modèle entraîné qui est transmis au registre de modèles.
Livraison continue du modèle : vous diffusez le modèle entraîné en tant que service pour les prédictions. Le résultat de cette étape est un service de prédiction de modèle déployé.
Surveillance : vous collectez des statistiques sur les performances du modèle en fonction des données en ligne. Le résultat de cette étape est un déclencheur permettant d'exécuter le pipeline ou d'exécuter un nouveau cycle de tests.
L'étape d'analyse des données reste un processus manuel pour les data scientists avant que le pipeline ne commence une nouvelle itération de tests. L'étape d'analyse du modèle est également un processus manuel.
Intégration continue
Dans cette configuration, le pipeline et ses composants sont créés, testés et empaquetés lorsqu'un nouveau code est validé ou transféré vers le dépôt de code source. En plus de créer des packages, des images de conteneurs et des exécutables, le processus CI peut inclure les tests suivants :
Tests unitaires de votre logique d'extraction de caractéristiques.
Tests unitaires des différentes méthodes mises en œuvre dans votre modèle. Par exemple, vous avez une fonction qui accepte une colonne de données catégorielles et vous l'encodez en tant que fonctionnalité one-hot.
Tests du point de convergence de l'entraînement de votre modèle (surapprentissage de quelques exemples d'enregistrements après diminution de la perte par itérations).
Tests visant à vérifier que l'entraînement du modèle ne produit pas de valeurs NaN générées par la division par zéro ou la manipulation de valeurs petites ou grandes.
Tests visant à vérifier que chaque composant du pipeline produit les artefacts attendus.
Tests de l'intégration entre les composants du pipeline.
Livraison continue
À ce niveau, votre système fournit en continu de nouvelles mises en œuvres de pipeline à l'environnement cible, qui fournit à son tour des services de prédiction du modèle nouvellement entraîné. Pour une livraison continue rapide et fiable des pipelines et des modèles, vous devez tenir compte des points suivants :
Vérifier la compatibilité du modèle avec l'infrastructure cible avant de déployer votre modèle. Par exemple, vous devez vérifier que les packages requis par le modèle sont installés dans l'environnement de diffusion et que les ressources de mémoire, de calcul et d'accélérateur nécessaires sont disponibles.
Tester le service de prédiction en appelant l'API de service avec les entrées attendues, en vous assurant d'obtenir la réponse prévue. Ce test capture généralement les problèmes qui peuvent survenir lorsque vous mettez à jour la version du modèle et qu'une autre entrée est attendue.
Tester les performances du service de prédiction, ce qui implique d'effectuer des tests de charge afin de capturer des métriques telles que les requêtes par secondes (RPS) et la latence du modèle.
Valider les données à des fins de réentraînement ou de prédiction par lot.
Vérifier que les modèles atteignent les objectifs de performances prédictifs avant leur déploiement.
Déploiement automatisé dans un environnement de test, par exemple, un déploiement déclenché par l'envoi de code à la branche de développement.
Déploiement semi-automatisé dans un environnement de préproduction, par exemple, un déploiement déclenché par la fusion du code dans la branche principale après l'approbation des modifications par les évaluateurs.
Déploiement manuel dans un environnement de production après plusieurs exécutions réussies du pipeline dans l'environnement de préproduction.
Pour résumer, la mise en œuvre du ML dans un environnement de production ne consiste pas seulement à déployer votre modèle en tant qu'API pour la prédiction. Il s'agit aussi de déployer un pipeline de ML capable d'automatiser le réentraînement et le déploiement de nouveaux modèles. La configuration d'un système CI/CD vous permet de tester et de déployer automatiquement de nouvelles mises en œuvre de pipeline. Avec un tel système, vous pouvez faire face à l'évolution rapide de vos données et de votre environnement professionnel. Vous n'avez pas besoin de déplacer immédiatement tous vos processus d'un niveau à un autre. Vous pouvez mettre en œuvre progressivement ces pratiques pour améliorer l'automatisation du développement de votre système de ML et sa promotion en production.
Étapes suivantes
- Apprenez-en plus sur l'architecture pour les opérations de machine learning avec TensorFlow Extended, Vertex AI Pipelines et Cloud Build.
- Découvrez le Guide des professionnels du MLOps (Machine Learning Operations).
- Découvrez comment configurer un pipeline CI/CD pour votre workflow de traitement des données.
- Regardez la vidéo MLOps Best Practices on Google Cloud (Cloud Next '19) [Bonnes pratiques MLOps sur Google Cloud (Cloud Next '19)] sur YouTube.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.