Opérations d’apprentissage automatique (MLOps) v2

  • Article

Cet article décrit trois architectures Azure pour les opérations d’apprentissage automatique. Toutes disposent de pipelines de bout en bout d’intégration continue (CI), de livraison continue (CD) et de réapprentissage. Les architectures sont destinées aux applications d’IA suivantes :

  • Apprentissage automatique classique
  • Vision par ordinateur (CV)
  • Traitement en langage naturel

Les architectures sont le produit du projet MLOps v2. Elles intègrent les meilleures pratiques que les architectes de solutions ont découvertes dans le processus de création de plusieurs solutions d’apprentissage automatique. Il en résulte des modèles déployables, reproductibles et gérables, tels que décrits ici.

Toutes les architectures utilisent le service Azure Machine Learning.

Pour une implémentation avec des exemples de modèles de déploiement pour MLOps v2, consultez Accélérateur de solution Azure MLOps (v2) sur GitHub.

Cas d’usage potentiels

  • Apprentissage automatique classique : la prévision, la régression et la classification de série chronologique sur des données structurées tabulaires sont les cas d’usage les plus courants dans cette catégorie. Voici quelques exemples :
    • Classification binaire et multi-étiquette
    • Régression linéaire, polynomiale, ridge, lasso, quantile et bayésienne
    • ARIMA, autorégressive (AR), SARIMA, VAR, SES, LSTM
  • CV : l’infrastructure MLOps présentée ici se concentre principalement sur les cas d’usage CV de segmentation et de classification d’images.
  • NLP : cette infrastructure MLOps peut implémenter n’importe lequel de ces cas d’usage, et d’autres non répertoriés :
    • Reconnaissance d’entité nommée
    • Classification de texte
    • Génération de texte
    • analyse de sentiments
    • Traduction
    • Réponses aux questions
    • Résumé
    • Détection d’expression
    • Détection de la langue
    • Balisage morphosyntaxique

Cet article ne couvre pas les simulations, l’apprentissage de renforcement profond et d’autres formes d’utilisation de l’IA.

Architecture

Le modèle architectural MLOps v2 est constitué de quatre éléments modulaires principaux qui représentent ces phases du cycle de vie du MLOps :

  • Patrimoine de données
  • Administration et paramétrage
  • Développement de modèle (boucle interne)
  • Déploiement de modèle (boucle externe)

Ces éléments, les relations entre eux et les personnages qui y sont généralement associés sont courants pour toutes les architectures de scénario MLOps v2. Certains détails peuvent varier selon le scénario.

L’architecture de base pour MLOps v2 pour le Machine Learning est le scénario d’apprentissage automatique classique sur des données tabulaires. Les architectures CV et NLP s’appuient sur cette architecture de base et la modifient.

Architectures actuelles

Les architectures actuellement couvertes par MLOps v2 et abordées dans cet article sont les suivantes :

Architecture d’apprentissage automatique classique

Diagramme pour l’architecture d’apprentissage automatique classique.

Téléchargez un fichier Visio de cette architecture.

Flux de travail pour l’architecture d’apprentissage automatique classique

  1. Patrimoine de données

    Cet élément illustre le patrimoine de données de l’organisation, ainsi que les sources et cibles potentielles de données pour un projet de science des données. Les ingénieurs de données sont les principaux propriétaires de cet élément du cycle de vie MLOps v2. Les plateformes de données Azure de ce diagramme ne sont ni exhaustives ni normatives. Les sources et cibles de données qui représentent les meilleures pratiques recommandées en fonction du cas d’usage du client sont indiquées par une coche verte.

  2. Administration et paramétrage

    Cet élément est la première étape du déploiement de l’accélérateur MLOps v2. Il comprend toutes les tâches liées à la création et à la gestion des ressources et des rôles associés au projet. Il peut s’agir des tâches suivantes, voire d’autres :

    1. Création de référentiels de code source de projet
    2. Création d’espaces de travail Machine Learning à l'aide de Bicep ou Terraform
    3. Création ou modification de jeux de données et de ressources de calcul utilisés pour le développement et le déploiement de modèles
    4. Définition d’utilisateurs d’équipe de projet, de leurs rôles et de contrôles d’accès à d’autres ressources
    5. Création de pipelines de CI/CD
    6. Création de moniteurs pour la collecte et la notification de métriques de modèle et d’infrastructure

    Le principal personnage associé à cette phase est l’équipe d’infrastructure, mais il peut également y avoir des ingénieurs de données, des ingénieurs d’apprentissage automatique et des scientifiques des données.

  3. Développement de modèle (boucle interne)

    L’élément de boucle interne consiste en votre flux de travail itératif de science des données, qui agit dans un espace de travail Machine Learning dédié et sécurisé. Un flux de travail classique est illustré dans le diagramme. Il passe de l’ingestion des données, de l’analyse exploratoire de données, de l’expérimentation, du développement et de l’évaluation de modèle, à l’inscription d’un modèle candidat pour la production. Cet élément modulaire tel qu’implémenté dans l’accélérateur MLOps v2 est insensible et adaptable au processus que votre équipe de science des données utilise pour développer des modèles.

    Les personnages associés à cette phase sont les scientifiques des données et les ingénieurs d’apprentissage automatique.

  4. Registres de Machine Learning

    Une fois que l’équipe de science des données a développé un modèle candidat au déploiement en production, le modèle peut être inscrit dans le registre de l’espace de travail de Machine Learning. Les pipelines de CI déclenchés, soit automatiquement par une inscription de modèle, soit par approbation humaine, promeuvent le modèle et toutes ses dépendances vers la phase de déploiement.

    Les personnages associés à cette phase sont généralement des ingénieurs d’apprentissage automatique.

  5. Déploiement de modèle (boucle externe)

    La phase de déploiement de modèle ou de boucle externe comprend la mise en lots et les tests, le déploiement en production et la surveillance du modèle, des données et de l’infrastructure. Les pipelines de CD gèrent la promotion du modèle et des ressources associées par le biais de la production, de la surveillance et d’un réapprentissage potentiel, à mesure que les critères appropriés pour votre organisation et votre cas d’usage sont satisfaits.

    Les personnages associés à cette phase sont principalement des ingénieurs d’apprentissage automatique.

  6. Mise en lots et test

    La phase de mise en lots et de test peut varier selon les pratiques du client mais inclut généralement des opérations telles que le réapprentissage et le test du candidat modèle sur des données de production, des déploiements tests pour les performances de point de terminaison, des vérifications de qualité des données, des tests unitaires et des vérifications d’IA responsable pour les biais de modèle et de données. Cette phase se déroule dans un ou plusieurs espaces de travail de Machine Learning dédiés et sécurisés.

  7. Déploiement en production

    Après qu’un modèle a passé la phase de mise en lots et de test, il peut être promu en production à l’aide d’une approbation humaine. Les options de déploiement de modèle incluent un point de terminaison de lot managé pour les scénarios de traitement par lots ou, pour les scénarios en ligne, en quasi-temps réel, un point de terminaison en ligne managé ou un déploiement Kubernetes à l’aide d’Azure Arc. La production a généralement lieu dans un ou plusieurs espaces de travail de Machine Learning dédiés et sécurisés.

  8. Monitoring

    La surveillance de la mise en lots, des tests et de la production vous permet de collecter des métriques et d’agir sur les changements de performances du modèle, des données et de l’infrastructure. La surveillance du modèle et des données peut inclure la vérification de la dérive du modèle et des données, des performances du modèle sur de nouvelles données, et de problèmes d’IA responsable. La surveillance de l’infrastructure permet d’observer la lenteur de réponse de point de terminaison, l’inadéquation de la capacité de calcul ou des problèmes de réseau.

  9. Surveillance de modèle et de données : événements et actions

    En fonction de critères applicables aux questions de modèle et de données, comme des seuils de métrique ou des planifications, des déclencheurs et notifications automatisés peuvent implémenter des actions appropriées. Il peut s’agir d’un réapprentissage automatisé planifié régulièrement du modèle sur des données de production plus récentes, et d’un rebouclage de mise en lots et de test pour une évaluation de pré-production. Ou il peut s’agir de déclencheurs sur des problèmes de modèle ou de données qui nécessitent un rebouclage de la phase de développement du modèle où des scientifiques des données peuvent enquêter et éventuellement développer un nouveau modèle.

  10. Surveillance d’infrastructure : événements et actions

    En fonction de critères applicables aux questions d’infrastructure, comme un décalage de réponse de point de terminaison ou un calcul insuffisant pour le déploiement, des déclencheurs et notifications automatisés peuvent implémenter des actions appropriées. Ils déclenchent un rebouclage de la phase de configuration et d’administration où l’équipe d’infrastructure peut examiner et éventuellement reconfigurer les ressources de calcul et de réseau.

Architecture CV de Machine Learning

Diagramme de l’architecture de vision par ordinateur.

Téléchargez un fichier Visio de cette architecture.

Flux de travail pour l’architecture CV

L’architecture CV de Machine Learning est basée sur l’architecture d’apprentissage automatique classique, mais présente des modifications spécifiques des scénarios CV supervisés.

  1. Patrimoine de données

    Cet élément illustre le patrimoine de données de l’organisation, ainsi que les sources et cibles potentielles de données pour un projet de science des données. Les ingénieurs de données sont les principaux propriétaires de cet élément du cycle de vie MLOps v2. Les plateformes de données Azure de ce diagramme ne sont ni exhaustives ni normatives. Les images pour les scénarios CV peuvent provenir de nombreuses sources de données différentes. Par souci d’efficacité lors du développement et du déploiement de modèles CV avec Machine Learning, les sources de données Azure recommandées pour les images sont Stockage Blob Azure et Azure Data Lake Storage.

  2. Administration et paramétrage

    Cet élément est la première étape du déploiement de l’accélérateur MLOps v2. Il comprend toutes les tâches liées à la création et à la gestion des ressources et des rôles associés au projet. Pour les scénarios CV, l’administration et la configuration de l’environnement MLOps v2 sont similaires à celles de l’apprentissage automatique classique, mais avec une étape supplémentaire consistant à créer des projets d’étiquetage et d’annotation à l’aide de la fonctionnalité d’étiquetage de Machine Learning ou d’un autre outil.

  3. Développement de modèle (boucle interne)

    L’élément de boucle interne consiste en votre flux de travail itératif de science des données effectué dans un espace de travail Machine Learning dédié et sécurisé. La principale différence entre ce flux de travail et le scénario d’apprentissage automatique classique est que l’étiquetage et l’annotation d’image constituent un élément clé de cette boucle de développement.

  4. Registres de Machine Learning

    Une fois que l’équipe de science des données a développé un modèle candidat au déploiement en production, le modèle peut être inscrit dans le registre de l’espace de travail de Machine Learning. Les pipelines de CI déclenchés, soit automatiquement par une inscription de modèle, soit par approbation humaine, promeuvent le modèle et toutes ses dépendances vers la phase de déploiement.

  5. Déploiement de modèle (boucle externe)

    La phase de déploiement de modèle ou de boucle externe comprend la mise en lots et les tests, le déploiement en production et la surveillance du modèle, des données et de l’infrastructure. Les pipelines de CD gèrent la promotion du modèle et des ressources associées par le biais de la production, de la surveillance et d’un réapprentissage potentiel, à mesure que les critères appropriés pour votre organisation et votre cas d’usage sont satisfaits.

  6. Mise en lots et test

    La phase de mise en lots et de test peut varier selon les pratiques du client mais inclut généralement des opérations telles que des déploiements tests pour les performances de point de terminaison, des vérifications de qualité des données, des tests unitaires et des vérifications d’IA responsable pour les biais de modèle et de données. Pour les scénarios CV, le réapprentissage du candidat modèle sur des données de production peut être omis en raison de contraintes de ressources et de temps. À la place, l’équipe de science des données peut utiliser des données de production pour le développement de modèle, et le modèle candidat inscrit à partir de la boucle de développement est le modèle évalué pour la production. Cette phase se déroule dans un ou plusieurs espaces de travail de Machine Learning dédiés et sécurisés.

  7. Déploiement en production

    Après qu’un modèle a passé la phase de mise en lots et de test, il peut être promu en production via des approbations humaines. Les options de déploiement de modèle incluent un point de terminaison de lot managé pour les scénarios de traitement par lots ou, pour les scénarios en ligne, en quasi-temps réel, un point de terminaison en ligne managé ou un déploiement Kubernetes à l’aide d’Azure Arc. La production a généralement lieu dans un ou plusieurs espaces de travail de Machine Learning dédiés et sécurisés.

  8. Monitoring

    La surveillance de la mise en lots, des tests et de la production vous permet de collecter des métriques et d’agir sur les changements de performances du modèle, des données et de l’infrastructure. La surveillance de modèle et de données peut inclure la vérification des performances du modèle sur de nouvelles images. La surveillance de l’infrastructure permet d’observer la lenteur de réponse de point de terminaison, l’inadéquation de la capacité de calcul ou des problèmes de réseau.

  9. Surveillance de modèle et de données : événements et actions

    La surveillance de modèle et de données, et les phases d’événements et d’actions de MLOps pour NLP sont les principales différences par rapport à l’apprentissage automatique classique. Un réapprentissage automatisé n’est généralement pas effectué dans les scénarios CV quand une dégradation des performances du modèle sur de nouvelles images est détectée. Dans ce cas, les nouvelles images pour lesquelles le modèle fonctionne mal doivent être examinées et annotées par un processus avec intervention humaine, et souvent l’action suivante revient à la boucle de développement du modèle pour mettre à jour celui-ci avec les nouvelles images.

  10. Surveillance d’infrastructure : événements et actions

    En fonction de critères applicables aux questions d’infrastructure, comme un décalage de réponse de point de terminaison ou un calcul insuffisant pour le déploiement, des déclencheurs et notifications automatisés peuvent implémenter des actions appropriées. Cela déclenche un rebouclage de la phase de configuration et d’administration où l’équipe d’infrastructure peut examiner et éventuellement reconfigurer les ressources d’environnement, de calcul et de réseau.

Architecture NLP de Machine Learning

Diagramme de l’architecture NLP.

Téléchargez un fichier Visio de cette architecture.

Flux de travail pour l’architecture NLP

L’architecture NLP de Machine Learning est basée sur l’architecture d’apprentissage automatique classique, mais présente des modifications spécifiques des scénarios NLP.

  1. Patrimoine de données

    Cet élément illustre le patrimoine de données de l’organisation, ainsi que les sources et cibles potentielles de données pour un projet de science des données. Les ingénieurs de données sont les principaux propriétaires de cet élément du cycle de vie MLOps v2. Les plateformes de données Azure de ce diagramme ne sont ni exhaustives ni normatives. Les sources et cibles de données qui représentent les meilleures pratiques recommandées en fonction du cas d’usage du client sont indiquées par une coche verte.

  2. Administration et paramétrage

    Cet élément est la première étape du déploiement de l’accélérateur MLOps v2. Il comprend toutes les tâches liées à la création et à la gestion des ressources et des rôles associés au projet. Pour les scénarios NLP, l’administration et la configuration de l’environnement MLOps v2 sont similaires à celles de l’apprentissage automatique classique, mais avec une étape supplémentaire consistant à créer des projets d’étiquetage et d’annotation à l’aide de la fonctionnalité d’étiquetage de Machine Learning ou d’un autre outil.

  3. Développement de modèle (boucle interne)

    L’élément de boucle interne consiste en votre flux de travail itératif de science des données effectué dans un espace de travail Machine Learning dédié et sécurisé. La boucle de développement de modèle NLP typique peut différer sensiblement du scénario d’apprentissage automatique classique dans lequel des annotateurs pour les phrases et une tokenisation, une normalisation et des incorporations pour les données texte sont les étapes de développement typiques.

  4. Registres de Machine Learning

    Une fois que l’équipe de science des données a développé un modèle candidat au déploiement en production, le modèle peut être inscrit dans le registre de l’espace de travail de Machine Learning. Les pipelines de CI déclenchés, soit automatiquement par une inscription de modèle, soit par approbation humaine, promeuvent le modèle et toutes ses dépendances vers la phase de déploiement.

  5. Déploiement de modèle (boucle externe)

    La phase de déploiement de modèle ou de boucle externe comprend la mise en lots et les tests, le déploiement en production et la surveillance du modèle, des données et de l’infrastructure. Les pipelines de CD gèrent la promotion du modèle et des ressources associées par le biais de la production, de la surveillance et d’un réapprentissage potentiel, à mesure que les critères pour votre organisation et votre cas d’usage sont satisfaits.

  6. Mise en lots et test

    La phase de mise en lots et de test peut varier selon les pratiques du client mais inclut généralement des opérations telles que le réapprentissage et le test du candidat modèle sur des données de production, des déploiements tests pour les performances de point de terminaison, des vérifications de qualité des données, des tests unitaires et des vérifications d’IA responsable pour les biais de modèle et de données. Cette phase se déroule dans un ou plusieurs espaces de travail de Machine Learning dédiés et sécurisés.

  7. Déploiement en production

    Après qu’un modèle a passé la phase de mise en lots et de test, il peut être promu en production suite à une approbation humaine. Les options de déploiement de modèle incluent un point de terminaison de lot managé pour les scénarios de traitement par lots ou, pour les scénarios en ligne, en quasi-temps réel, un point de terminaison en ligne managé ou un déploiement Kubernetes à l’aide d’Azure Arc. La production a généralement lieu dans un ou plusieurs espaces de travail de Machine Learning dédiés et sécurisés.

  8. Monitoring

    La surveillance de la mise en lots, des tests et de la production vous permet de collecter les changements de performances du modèle, des données et de l’infrastructure, et d’agir sur ceux-ci. La surveillance du modèle et des données peut inclure la vérification de la dérive du modèle et des données, des performances du modèle sur de nouvelles données texte, et de problèmes d’IA responsable. La surveillance de l’infrastructure permet d’observer des aspects tels que la lenteur de réponse de point de terminaison, l’inadéquation de la capacité de calcul et des problèmes de réseau.

  9. Surveillance de modèle et de données : événements et actions

    Comme avec l’architecture CV, la surveillance de modèle et de données, et les phases d’événements et d’actions de MLOps pour NLP sont les principales différences par rapport à l’apprentissage automatique classique. Un réapprentissage automatisé n’est généralement pas effectué dans les scénarios NLP quand une dégradation des performances du modèle sur de nouveaux textes est détectée. Dans ce cas, les nouvelles données texte pour lesquelles le modèle fonctionne mal doivent être examinées et annotées par un processus avec intervention humaine. Souvent, l’action suivante consiste à revenir à la boucle de développement de modèle pour mettre à jour le modèle avec les nouvelles données texte.

  10. Surveillance d’infrastructure : événements et actions

    En fonction de critères applicables aux questions d’infrastructure, comme un décalage de réponse de point de terminaison ou un calcul insuffisant pour le déploiement, des déclencheurs et notifications automatisés peuvent implémenter des actions appropriées. Ils déclenchent un rebouclage de la phase de configuration et d’administration où l’équipe d’infrastructure peut examiner et éventuellement reconfigurer les ressources de calcul et de réseau.

Composants

  • Machine Learning : service cloud pour l’apprentissage, le scoring, le déploiement et la gestion de modèles d’apprentissage automatique à grande échelle.
  • Azure Pipelines : ce système de génération et de test s’appuie sur Azure DevOps et est utilisé pour les pipelines de build et de mise en production. Azure Pipelines fractionne ces pipelines en étapes logiques appelées tâches.
  • GitHub : plateforme d’hébergement de code pour les flux de travail de contrôle de version, de collaboration et de CI/CD.
  • Azure Arc : plateforme pour la gestion des ressources Azure et locales à l’aide d’Azure Resource Manager. Les ressources peuvent inclure des machines virtuelles, des clusters Kubernetes et des bases de données.
  • Kubernetes : système open source permettant d’automatiser le déploiement, la mise à l’échelle et la gestion d’applications dans des conteneurs.
  • Azure Data Lake : système de fichiers compatible Hadoop. Il offre un espace de noms hiérarchique intégré, ainsi que l’échelle et l’économie du Stockage Blob.
  • Azure Synapse Analytics : service d’analytique illimité qui réunit l’intégration de données, l’entreposage de données d’entreprise et des fonctionnalités analytiques pour le Big Data.
  • Azure Event Hubs. Service qui ingère des flux de données générés par des applications clientes. Il ingère et stocke ensuite des données de diffusion en continu, en préservant la séquence des événements reçus. Les consommateurs peuvent se connecter aux points de terminaison de hub afin de récupérer des messages à traiter. Ici, nous profitons de l’intégration avec Data Lake Storage.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes