Partager via


Opérations de Machine Learning

Cet article décrit trois architectures Azure pour les opérations de machine learning qui ont des pipelines d’intégration et de livraison continues (CI/CD) de bout en bout et des pipelines de ré-entraînement. Les architectures sont destinées aux applications d’IA suivantes :

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

Ces architectures sont le produit du projet MLOps v2. Elles intègrent les bonnes pratiques identifiées par les architectes de solutions lors du développement de diverses solutions de machine learning. Le résultat est des modèles déployables, reproductibles et maintenables. Les trois architectures utilisent le service Azure Machine Learning.

Pour une implémentation avec des modèles de déploiement d’exemples pour MLOps v2, veuillez consulter la section Accélérateur de solution Azure MLOps v2.

Cas d’usage potentiels

  • Machine learning classique : Les prévisions de séries temporelles, la régression et la classification sur des données structurées tabulaires sont les cas d’utilisation les plus courants dans cette catégorie. Voici quelques exemples :

    • Classification binaire et multi-étiquettes.

    • Régression linéaire, polynomiale, ridge, lasso, quantile et bayésienne.

    • ARIMA, autoregressive, SARIMA, VAR, SES, LSTM.

  • CV : Le cadre MLOps dans cet article se concentre principalement sur les cas d’utilisation CV de segmentation et de classification d’images.

  • Traitement du langage naturel : Vous pouvez utiliser ce cadre MLOps pour implémenter :

    • 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

Les simulations AI, l’apprentissage par renforcement profond et d’autres formes d’IA ne sont pas décrits dans cet article.

Architecture

Le modèle architectural MLOps v2 a quatre principaux composants modulaires, ou phases, du cycle de vie MLOps :

  • Patrimoine de données
  • Administration et paramétrage
  • Développement du modèle, ou phase de boucle interne
  • Déploiement du modèle, ou phase de boucle externe

Les composants précédents, les connexions entre eux et les publics typiques impliqués sont standard dans tous les scénarios d’architectures MLOps v2. Les variations dans les détails de chaque composant dépendent du scénario.

L’architecture de base pour MLOps v2 pour le machine learning est le scénario de machine learning classique pour les données tabulaires. Les architectures CV et NLP s’appuient sur cette architecture de base et la modifient.

MLOps v2 couvre les architectures suivantes qui sont décrites dans cet article :

Architecture d’apprentissage automatique classique

Diagramme montrant l’architecture de machine learning 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

    Ce composant illustre l’infrastructure de données de l’organisation et les sources de données potentielles et les cibles pour un projet de science des données. Les ingénieurs de données sont les principaux responsables de ce composant du cycle de vie MLOps v2. Les plateformes de données Azure dans ce diagramme ne sont pas exhaustives ou prescriptives. Une coche verte indique les sources de données et les cibles qui représentent les bonnes pratiques recommandées basées sur le cas d’utilisation du client.

  2. Administration et paramétrage

    Ce composant est la première étape du déploiement de l’accélérateur MLOps v2. Il consiste en toutes les tâches liées à la création et à la gestion des ressources et des rôles associés au projet. Par exemple, l’équipe d’infrastructure pourrait :

    1. Créer des référentiels de code source de projet.
    2. Utiliser Bicep ou Terraform pour créer des espaces de travail Machine Learning.
    3. Créer ou modifier des ensembles de données et des ressources de calcul pour le développement et le déploiement de modèles.
    4. Définir les utilisateurs de l’équipe de projet, leurs rôles et les contrôles d’accès à d’autres ressources.
    5. Créer des pipelines CI/CD.
    6. Créer des composants de surveillance pour collecter et créer des alertes pour les métriques de modèle et d’infrastructure.

    Le public principal associé à cette phase est l’équipe d’infrastructure, mais une organisation pourrait également avoir des ingénieurs de données, des ingénieurs en machine learning ou des data scientists.

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

    La phase de boucle interne consiste en un workflow de science des données itératif qui agit au sein d’un espace de travail Machine Learning dédié et sécurisé. Le diagramme précédent montre un workflow typique. Le processus commence par l’ingestion de données, passe par l’analyse exploratoire des données, l’expérimentation, le développement et l’évaluation du modèle, puis enregistre un modèle pour une utilisation en production. Ce composant modulaire tel que mis en œuvre dans l’accélérateur MLOps v2 est agnostique 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

    Après que l’équipe de science des données développe un modèle qu’elle peut déployer en production, elle enregistre le modèle dans le registre de l’espace de travail 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 du modèle (phase de boucle externe)

    Le déploiement du modèle, ou phase de boucle externe, consiste en une mise en scène et des tests en préproduction, un déploiement en production et une surveillance du modèle, des données et de l’infrastructure. Lorsque le modèle répond aux critères de l’organisation et du cas d’utilisation, les pipelines CD promeuvent le modèle et les actifs connexes à travers la production, la surveillance et le ré-entraînement potentiel.

    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 scène et de test varie en fonction des pratiques des clients. Cette phase inclut généralement des opérations telles que le ré-entraînement et le test du modèle candidat sur les données de production, les déploiements de test pour la performance du point de terminaison, les contrôles de qualité des données, les tests unitaires et les contrôles d’IA responsables pour les biais du modèle et des données. Cette phase se déroule dans un ou plusieurs espaces de travail Machine Learning dédiés et sécurisés.

  7. Déploiement de production

    Après qu’un modèle passe la phase de mise en scène et de test, les ingénieurs en machine learning peuvent utiliser une approbation gated human-in-the-loop pour le promouvoir en production. Les options de déploiement du modèle incluent un point de terminaison batch géré pour les scénarios batch ou un point de terminaison en ligne géré ou un déploiement Kubernetes utilisant Azure Arc pour les scénarios en ligne, presque en temps réel. La production a lieu généralement dans un ou plusieurs espaces de travail Machine Learning dédiés et sécurisés.

  8. Surveillance

    Les ingénieurs en machine learning surveillent les composants en mise en scène, test et production pour collecter des métriques liées aux changements de performance du modèle, des données et de l’infrastructure. Ils peuvent utiliser ces métriques pour agir. La surveillance du modèle et des données peut inclure la vérification des dérives du modèle et des données, la performance du modèle sur de nouvelles données et les problèmes d’IA responsable. La surveillance de l’infrastructure pourrait identifier une réponse lente du point de terminaison, une capacité de calcul inadéquate ou des problèmes de réseau.

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

    En fonction des critères du modèle et des données, tels que les seuils de métriques ou les calendriers, des déclencheurs et des notifications automatiques peuvent mettre en œuvre les actions appropriées à entreprendre. Par exemple, un déclencheur pourrait ré-entraîner un modèle pour utiliser de nouvelles données de production, puis boucler le modèle vers la mise en scène et les tests pour une évaluation de préproduction. Ou un problème de modèle ou de données pourrait déclencher une action nécessitant un retour à la phase de développement du modèle où les data scientists peuvent enquêter sur le problème et potentiellement développer un nouveau modèle.

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

    Des déclencheurs et des notifications automatiques peuvent mettre en œuvre les actions appropriées à entreprendre en fonction des critères d’infrastructure, tels qu’un délai de réponse du point de terminaison ou une capacité de calcul insuffisante pour le déploiement. Des déclencheurs et des notifications automatiques pourraient déclencher un retour à la phase de configuration et d’administration où l’équipe d’infrastructure peut enquêter sur le problème et potentiellement reconfigurer les ressources de calcul et de réseau.

Architecture CV de Machine Learning

Diagramme montrant l’architecture de la vision par ordinateur.

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

Flux de travail pour l’architecture CV

L’architecture Machine Learning CV est basée sur l’architecture de machine learning classique, mais elle a des modifications spécifiques aux scénarios CV supervisés.

  1. Patrimoine de données

    Ce composant démontre l’infrastructure de données de l’organisation et les sources de données potentielles et les cibles pour un projet de science des données. Les ingénieurs de données sont les principaux responsables de ce composant dans le cycle de vie MLOps v2. Les plateformes de données Azure dans ce diagramme ne sont pas exhaustives ou prescriptives. Les images pour les scénarios CV peuvent provenir de diverses sources de données. Pour une efficacité lors du développement et du déploiement de modèles CV avec Machine Learning, nous recommandons Azure Blob Storage et Azure Data Lake Storage.

  2. Administration et paramétrage

    Ce composant est la première étape du déploiement de l’accélérateur MLOps v2. Il consiste en 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 en grande partie les mêmes que pour le machine learning classique mais incluent une étape supplémentaire. L’équipe d’infrastructure utilise la fonctionnalité d’étiquetage de Machine Learning ou un autre outil pour créer des projets d’étiquetage et d’annotation d’images.

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

    La phase de boucle interne consiste en un workflow 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 workflow et le scénario de machine learning classique est que l’étiquetage et l’annotation des images sont un composant clé de cette boucle de développement.

  4. Registres de Machine Learning

    Après que l’équipe de science des données développe un modèle qu’elle peut déployer en production, elle enregistre le modèle dans le registre de l’espace de travail Machine Learning. Les pipelines CI qui sont déclenchés automatiquement par l’enregistrement du modèle ou par une approbation gated human-in-the-loop promeuvent le modèle et toutes les autres dépendances du modèle à la phase de déploiement du modèle.

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

    Le déploiement du modèle, ou phase de boucle externe, consiste en une mise en scène et des tests en préproduction, un déploiement en production et une surveillance du modèle, des données et de l’infrastructure. Lorsque le modèle répond aux critères de l’organisation et du cas d’utilisation, les pipelines CD promeuvent le modèle et les actifs connexes à travers la production, la surveillance et le ré-entraînement potentiel.

  6. Mise en lots et test

    La phase de mise en scène et de test varie en fonction des pratiques des clients. Cette phase inclut généralement des opérations telles que des déploiements de test pour la performance du point de terminaison, des contrôles de qualité des données, des tests unitaires et des contrôles d’IA responsable pour les biais du modèle et des données. Pour les scénarios de vision par ordinateur (CV), les ingénieurs en machine learning n’ont pas besoin de réentraîner le modèle candidat sur les données de production en raison des contraintes de ressources et de temps. L’équipe de science des données peut plutôt utiliser les données de production pour le développement du modèle. Le modèle candidat enregistré à partir de la boucle de développement est évalué pour la production. Cette phase se déroule dans un ou plusieurs espaces de travail Machine Learning dédiés et sécurisés.

  7. Déploiement de production

    Après qu’un modèle passe la phase de mise en scène et de test, les ingénieurs en machine learning peuvent utiliser une approbation gated human-in-the-loop pour le promouvoir en production. Les options de déploiement du modèle incluent un point de terminaison batch géré pour les scénarios batch ou un point de terminaison en ligne géré ou un déploiement Kubernetes utilisant Azure Arc pour les scénarios en ligne, presque en temps réel. La production a lieu généralement dans un ou plusieurs espaces de travail Machine Learning dédiés et sécurisés.

  8. Surveillance

    Les ingénieurs en machine learning surveillent les composants en mise en scène, test et production pour collecter des métriques liées aux changements de performance du modèle, des données et de l’infrastructure. Ils peuvent utiliser ces métriques pour agir. 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 pourrait identifier une réponse lente du point de terminaison, une capacité de calcul inadéquate ou des problèmes de réseau.

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

    La surveillance des données et du modèle et les phases d’événement et d’action de MLOps pour le traitement du langage naturel sont les principales différences par rapport au machine learning 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, un processus human-in-the-loop est nécessaire pour examiner et annoter les nouvelles données textuelles pour le modèle qui fonctionne mal. L’action suivante revient souvent à la boucle de développement du modèle pour mettre à jour le modèle avec les nouvelles images.

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

    Des déclencheurs et des notifications automatiques peuvent mettre en œuvre les actions appropriées à entreprendre en fonction des critères d’infrastructure, tels qu’un délai de réponse du point de terminaison ou une capacité de calcul insuffisante pour le déploiement. Les déclencheurs et les notifications automatiques pourraient déclencher un retour à la phase de configuration et d’administration où l’équipe d’infrastructure peut enquêter sur le problème et potentiellement reconfigurer l’environnement, le calcul et les ressources réseau.

Architecture de traitement du langage naturel Machine Learning

Diagramme pour l’architecture de traitement du langage naturel.

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

Flux de travail pour l’architecture de traitement du langage naturel

L’architecture de traitement du langage naturel Machine Learning est basée sur l’architecture de machine learning classique, mais elle a quelques modifications spécifiques aux scénarios NLP.

  1. Patrimoine de données

    Ce composant démontre l’infrastructure de données de l’organisation et les sources de données potentielles et les cibles pour un projet de science des données. Les ingénieurs de données sont les principaux responsables de ce composant dans le cycle de vie MLOps v2. Les plateformes de données Azure dans ce diagramme ne sont pas exhaustives ou prescriptives. Une coche verte indique les sources et les cibles qui représentent les bonnes pratiques recommandées basées sur le cas d’utilisation du client.

  2. Administration et paramétrage

    Ce composant est la première étape du déploiement de l’accélérateur MLOps v2. Il consiste en 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 de traitement du langage naturel, l’administration et la configuration de l’environnement MLOps v2 sont en grande partie les mêmes que pour le machine learning classique, mais avec une étape supplémentaire : créer des projets d’étiquetage et d’annotation d’images en utilisant la fonctionnalité d’étiquetage de Machine Learning ou un autre outil.

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

    La phase de boucle interne consiste en un workflow 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 diffère du scénario de machine learning classique en ce que les étapes de développement typiques pour ce scénario incluent des annotateurs pour les phrases et la tokenisation, la normalisation et les embeddings pour les données textuelles.

  4. Registres de Machine Learning

    Après que l’équipe de science des données développe un modèle qu’elle peut déployer en production, elle enregistre le modèle dans le registre de l’espace de travail Machine Learning. Les pipelines CI qui sont déclenchés automatiquement par l’enregistrement du modèle ou par une approbation gated human-in-the-loop promeuvent le modèle et toutes les autres dépendances du modèle à la phase de déploiement du modèle.

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

    Le déploiement du modèle, ou phase de boucle externe, consiste en une mise en scène et des tests en préproduction, un déploiement en production et une surveillance du modèle, des données et de l’infrastructure. Lorsque le modèle répond aux critères de l’organisation et du cas d’utilisation, les pipelines CD promeuvent le modèle et les actifs connexes à travers la production, la surveillance et le ré-entraînement potentiel.

  6. Mise en lots et test

    La phase de mise en scène et de test varie en fonction des pratiques des clients. Cette phase inclut généralement des opérations telles que le ré-entraînement et le test du modèle candidat sur les données de production, les déploiements de test pour la performance du point de terminaison, les contrôles de qualité des données, les tests unitaires et les contrôles d’IA responsables pour les biais du modèle et des données. Cette phase se déroule dans un ou plusieurs espaces de travail Machine Learning dédiés et sécurisés.

  7. Déploiement de production

    Après qu’un modèle passe la phase de mise en scène et de test, les ingénieurs en machine learning peuvent utiliser une approbation gated human-in-the-loop pour le promouvoir en production. Les options de déploiement du modèle incluent un point de terminaison batch géré pour les scénarios batch ou un point de terminaison en ligne géré ou un déploiement Kubernetes utilisant Azure Arc pour les scénarios en ligne, presque en temps réel. La production a lieu généralement dans un ou plusieurs espaces de travail Machine Learning dédiés et sécurisés.

  8. Surveillance

    Les ingénieurs en machine learning surveillent les composants en mise en scène, test et production pour collecter des métriques liées aux changements de performance du modèle, des données et de l’infrastructure. Ils peuvent utiliser ces métriques pour agir. La surveillance du modèle et des données peut inclure la vérification des dérives du modèle et des données, la performance du modèle sur de nouvelles données textuelles et les problèmes d’IA responsable. La surveillance de l’infrastructure pourrait identifier des problèmes tels qu’une réponse lente du point de terminaison, une capacité de calcul inadéquate et des problèmes de réseau.

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

    Comme pour l’architecture CV, la surveillance des données et du modèle et les phases d’événement et d’action de MLOps pour le traitement du langage naturel sont les principales différences par rapport au machine learning classique. Le ré-entraînement automatisé n’est généralement pas effectué dans les scénarios de traitement du langage naturel lorsque la dégradation des performances du modèle sur un nouveau texte est détectée. Dans ce cas, un processus human-in-the-loop est nécessaire pour examiner et annoter les nouvelles données textuelles pour le modèle qui fonctionne mal. 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

    Des déclencheurs et des notifications automatiques peuvent mettre en œuvre les actions appropriées à entreprendre en fonction des critères d’infrastructure, tels qu’un délai de réponse du point de terminaison ou une capacité de calcul insuffisante pour le déploiement. Les déclencheurs et les notifications automatiques pourraient déclencher un retour à la phase de configuration et d’administration où l’équipe d’infrastructure peut enquêter sur le problème et potentiellement reconfigurer les ressources de calcul et de réseau.

Composants

  • Machine Learning est un service cloud que vous pouvez utiliser pour entraîner, évaluer, déployer et gérer des modèles de machine learning à grande échelle.

  • Azure Pipelines est un système de build et de test basé sur Azure DevOps et utilisé pour les pipelines de build et de release. Azure Pipelines divise ces pipelines en étapes logiques appelées tâches.

  • GitHub est une plateforme d’hébergement de code pour le contrôle de version, la collaboration et les workflows CI/CD.

  • Azure Arc est une plateforme qui utilise Azure Resource Manager pour gérer les ressources Azure et les ressources sur site. Les ressources peuvent inclure des machines virtuelles, des clusters Kubernetes et des bases de données.

  • Kubernetes est un système open-source que vous pouvez utiliser pour automatiser le déploiement, la mise à l’échelle et la gestion des applications conteneurisées.

  • Azure Data Lake est un 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 est un 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 est un service qui ingère des flux de données générés par des applications clientes. Il ingère ensuite et stocke les données en continu, ce qui préserve la séquence des événements reçus. Les clients peuvent se connecter aux points de terminaison du hub pour récupérer des messages pour le traitement. Cette architecture utilise l’intégration Data Lake Storage.

Autres considérations

Le modèle architectural MLOps v2 précédent comporte plusieurs composants critiques, y compris le contrôle d’accès basé sur les rôles (RBAC) qui s’aligne avec les parties prenantes de l’entreprise, une gestion efficace des packages et des mécanismes de surveillance robustes. Ces composants contribuent collectivement à la mise en œuvre et à la gestion réussies des workflows de machine learning.

RBAC basé sur les publics

Il est crucial de gérer l’accès aux données et aux ressources de machine learning. RBAC fournit un cadre robuste pour vous aider à gérer qui peut effectuer des actions spécifiques et accéder à des zones spécifiques au sein de votre solution. Concevez votre stratégie de segmentation d’identité pour s’aligner sur le cycle de vie des modèles de machine learning dans Machine Learning et les personas inclus dans le processus. Chaque public a un ensemble spécifique de responsabilités reflétées dans leurs rôles RBAC et leur appartenance à des groupes.

Exemple de publics

Pour prendre en charge une segmentation appropriée dans une charge de travail de machine learning, considérez les publics communs suivants qui informent la conception du groupe RBAC basé sur l’identité.

Data scientist et ingénieur en machine learning

Les data scientists et les ingénieurs en machine learning effectuent diverses activités de machine learning et de science des données tout au long du cycle de développement logiciel d’un projet. Leurs tâches incluent l’analyse exploratoire des données et le prétraitement des données. Les data scientists et les ingénieurs en machine learning sont responsables de l’entraînement, de l’évaluation et du déploiement des modèles. Les responsabilités de ces rôles incluent également les activités de dépannage pour les modèles de machine learning, les packages et les données. Ces tâches sont hors de portée de l’équipe de support technique de la plateforme.

Type : Personne
Spécifique au projet : Oui

Analyste de données

Les analystes de données fournissent les entrées nécessaires pour les activités de science des données, telles que l’exécution de requêtes SQL pour l’intelligence d’affaires. Les responsabilités de ce rôle incluent le travail avec les données, l’analyse des données et le soutien au développement et au déploiement des modèles.

Type : Personne
Spécifique au projet : Oui

Testeur de modèle

Les testeurs de modèles effectuent des tests dans des environnements de test et de mise en scène. Ce rôle assure une séparation fonctionnelle des processus CI/CD.

Type : Personne
Spécifique au projet : Oui

Parties prenantes de l’entreprise

Les parties prenantes de l’entreprise sont associées au projet, comme un responsable marketing.

Type : Personne
Spécifique au projet : Oui

Responsable de projet ou responsable scientifique des données

Le responsable scientifique des données est un rôle d’administration de projet pour l’espace de travail Machine Learning. Ce rôle effectue également des activités de dépannage pour les modèles et les packages de machine learning.

Type : Personne
Spécifique au projet : Oui

Responsable de projet ou produit (responsable métier)

Les parties prenantes de l’entreprise sont responsables de l’espace de travail Machine Learning en fonction de la propriété des données.

Type : Personne
Spécifique au projet : Oui

Support technique de la plateforme

Le support technique de la plateforme est le personnel de support technique responsable des activités de dépannage à travers la plateforme. Ce rôle couvre l’infrastructure ou le service, mais pas les modèles de machine learning, les packages ou les données. Ces composants restent sous la responsabilité du data scientist ou de l’ingénieur en machine learning et sont sous la responsabilité du chef de projet.

Type : Personne
Spécifique au projet : Non

Utilisateur final du modèle

Les utilisateurs finaux du modèle sont les consommateurs finaux du modèle de machine learning.

Type : personne ou processus
Spécifique au projet : Oui

Processus CI/CD

Les processus CI/CD publient ou annulent des modifications à travers les environnements de la plateforme.

Type : Processus
Spécifique au projet : Non

Espace de travail Machine Learning

Les espaces de travail Machine Learning utilisent des identités managées pour interagir avec d’autres parties d’Azure. Ce public représente les différents services qui composent une implémentation de Machine Learning. Ces services interagissent avec d’autres parties de la plateforme, comme l’espace de travail de développement qui se connecte au magasin de données de développement.

Type : Processus
Spécifique au projet : Non

Surveillance des processus

Les processus de surveillance sont des processus de calcul qui surveillent et alertent en fonction des activités de la plateforme.

Type : Processus
Spécifique au projet : Non

Processus de gouvernance des données

Les processus de gouvernance des données analysent le projet de machine learning et les magasins de données pour la gouvernance des données.

Type : Processus
Spécifique au projet : Non

Appartenance à un groupe Microsoft Entra

Lors de l’implémentation de RBAC, les groupes Microsoft Entra fournissent une manière flexible et évolutive de gérer les autorisations d’accès pour différents personas. Vous pouvez utiliser les groupes Microsoft Entra pour gérer les utilisateurs qui ont besoin du même accès et des mêmes autorisations aux ressources, telles que des applications et des services potentiellement restreints. Au lieu d’ajouter des autorisations spéciales à des utilisateurs individuels, vous créez un groupe qui applique les autorisations spéciales à chaque membre de ce groupe.

Dans ce modèle architectural, vous pouvez associer ces groupes à une configuration d’espace de travail Machine Learning, telle qu’un projet, une équipe ou un département. Vous pouvez associer des utilisateurs à des groupes spécifiques pour définir des politiques d’accès granulaires. Les politiques accordent ou restreignent les autorisations à divers espaces de travail Machine Learning en fonction des fonctions de travail, des exigences du projet ou d’autres critères. Par exemple, vous pouvez avoir un groupe qui accorde à tous les data scientists l’accès à un espace de travail de développement pour un cas d’utilisation spécifique.

RBAC d’identité

Considérez comment vous pouvez utiliser les rôles RBAC intégrés suivants d’Azure pour appliquer RBAC aux environnements de production et de préproduction. Pour l’architecture dans cet article, les environnements de production incluent les environnements de mise en scène, de test et de production. Les environnements de préproduction incluent les environnements de développement. Les rôles RBAC suivants sont basés sur les personas décrits plus tôt dans cet article.

Rôles standard

Rôles spécifiques aux composants

Ces abréviations de rôles Azure RBAC correspondent aux tableaux suivants.

Environnement de production
Utilisateur Espace de travail Machine Learning Azure Key Vault Container Registry compte Stockage Azure Azure DevOps Azure Artifacts Espace de travail Log Analytics Azure Monitor
Scientifique des données R LAR MR
Analyste de données
Testeur de modèle
Parties prenantes de l’entreprise MR
Responsable de projet (Responsable data science) R R, KVR R LAR MR
Propriétaire de projet/produit MR
Support technique de la plateforme O O, KVA DOPCA O O O
Utilisateur final du modèle
Processus CI/CD O O, KVA AcrPush DOPCA O O O
Espace de travail Machine Learning R C C
Surveillance des processus R LAR MR
Processus de gouvernance des données R R R R R
Environnement de préproduction
Utilisateur Espace de travail Machine Learning Key Vault Container Registry Compte de stockage Azure DevOps Azure Artifacts Espace de travail Log Analytics Azure Monitor
Scientifique des données ADS R, KVA C C C C LAC MC
Analyste de données R C LAR MC
Testeur de modèle R R, KVR R R R R LAR MR
Parties prenantes de l’entreprise R R R R R
Responsable de projet (Responsable data science) C C, KVA C C C C LAC MC
Propriétaire de projet/produit R R MR
Support technique de la plateforme O O, KVA O O DOPCA O O O
Utilisateur final du modèle
Processus CI/CD O O, KVA AcrPush O DOPCA O O O
Espace de travail Machine Learning R, KVR C C
Surveillance des processus R R R R R R LAC
Processus de gouvernance des données R R R

Remarque

Chaque public conserve l’accès pendant la durée du projet, sauf le support technique de la plateforme, qui a un accès temporaire ou juste-à-temps via Microsoft Entra Privileged Identity Management (PIM).

RBAC joue un rôle vital dans la sécurisation et la rationalisation des workflows MLOps. RBAC restreint l’accès en fonction des rôles assignés et empêche les utilisateurs non autorisés d’accéder aux données sensibles, ce qui atténue les risques de sécurité. Les données sensibles incluent les données d’entraînement ou les modèles et l’infrastructure critique, telles que les pipelines de production. Vous pouvez utiliser RBAC pour garantir la conformité aux réglementations sur la confidentialité des données. RBAC fournit également un enregistrement clair des accès et des autorisations, ce qui simplifie l’audit, facilite l’identification des failles de sécurité et suit l’activité des utilisateurs.

Gestion des packages

Les dépendances à divers packages, bibliothèques et binaires sont courantes tout au long du cycle de vie de MLOps. Ces dépendances, souvent développées par la communauté et en évolution rapide, nécessitent des connaissances d’experts en la matière pour une utilisation et une compréhension appropriées. Vous devez vous assurer que les personnes appropriées ont un accès sécurisé à divers actifs, tels que des packages et des bibliothèques, mais vous devez également prévenir les vulnérabilités. Les data scientists rencontrent ce problème lorsqu’ils assemblent des blocs de construction spécialisés pour les solutions de machine learning. Les approches traditionnelles de gestion des logiciels sont coûteuses et inefficaces. D’autres approches apportent plus de valeur.

Pour gérer ces dépendances, vous pouvez utiliser un processus de gestion des packages sécurisé et en libre-service basé sur le modèle de quarantaine. Vous pouvez concevoir ce processus pour permettre aux data scientists de se servir eux-mêmes à partir d’une liste de packages sélectionnés et garantir que les packages sont sécurisés et conformes aux normes organisationnelles.

Cette approche inclut la liste blanche de trois référentiels de packages de machine learning standard de l’industrie : Microsoft Artifact Registry, Python Package Index (PyPI) et Conda. La liste blanche permet le libre-service depuis des espaces de travail de machine learning individuels. Utilisez ensuite un processus de test automatisé pendant le déploiement pour scanner les conteneurs de solution résultants. Les échecs sortent élégamment du processus de déploiement et suppriment le conteneur. Le diagramme et le flux de processus suivants démontrent ce processus :

Diagramme montrant l’approche de package sécurisé pour le machine learning.

Flux de processus

  1. Les data scientists travaillant dans un espace de travail de machine learning disposant d’une configuration réseau peuvent se servir eux-mêmes des packages de machine learning à la demande depuis les référentiels de packages de machine learning. Un processus d’exception est requis pour tout le reste en utilisant le modèle de stockage privé, qui est semé et maintenu à l’aide d’une fonction centralisée.

  2. Machine Learning fournit des solutions de machine learning sous forme de conteneurs Docker. Lorsque ces solutions sont développées, elles sont téléchargées sur Container Registry. Microsoft Defender pour les conteneurs génère des évaluations de vulnérabilité pour l’image du conteneur.

  3. Le déploiement de la solution se fait via un processus CI/CD. Microsoft Defender pour DevOps est utilisé sur toute la pile pour fournir une gestion de la posture de sécurité et une protection contre les menaces.

  4. Le conteneur de solution est déployé uniquement s’il passe chacun des processus de sécurité. Si le conteneur de solution échoue à un processus de sécurité, le déploiement échoue avec des notifications d’erreur et des pistes d’audit complètes. Le conteneur de solution est alors éliminé.

Le flux de processus précédent fournit un processus de gestion des packages sécurisé et en libre-service pour les data scientists et garantit que les packages sont sécurisés et conformes aux normes organisationnelles. Pour équilibrer innovation et sécurité, vous pouvez accorder aux data scientists un accès en libre-service aux packages, bibliothèques et binaires courants de machine learning dans les environnements de préproduction. Exigez des exceptions pour les packages moins courants. Cette stratégie garantit que les data scientists peuvent rester productifs pendant le développement, ce qui empêche un goulot d’étranglement majeur lors de la livraison.

Pour rationaliser vos processus de livraison, conteneurisez les environnements pour une utilisation dans les environnements de production. Les environnements conteneurisés réduisent la charge de travail et garantissent une sécurité continue grâce à l’analyse des vulnérabilités. Ce flux de processus fournit une approche reproductible que vous pouvez utiliser à travers les cas d’utilisation jusqu’au moment de la livraison. Il réduit le coût global de construction et de déploiement des solutions de machine learning au sein de votre entreprise.

Surveillance

Dans MLOps, la surveillance est cruciale pour maintenir la santé et la performance des systèmes de machine learning et pour garantir que les modèles restent efficaces et alignés avec les objectifs commerciaux. La surveillance soutient la gouvernance, la sécurité et les contrôles de coûts pendant la phase de boucle interne. Et elle fournit de la visibilité sur la performance, la dégradation des modèles et l’utilisation lors du déploiement des solutions pendant la phase de boucle externe. Les activités de surveillance sont pertinentes pour des publics tels que les data scientists, les parties prenantes métier, les responsables de projet, les propriétaires de projet, le support technique de la plateforme, les processus CI/CD et les processus de surveillance.

Choisissez votre plateforme de surveillance et de vérification en fonction de votre configuration de l’espace de travail de machine learning, tel qu’un projet, une équipe ou un département.

Performances du modèle

Surveillez la performance du modèle pour détecter les problèmes du modèle et la dégradation de la performance dès le début. Suivez la performance pour vous assurer que les modèles restent précis, fiables et alignés avec les objectifs commerciaux.

Dérive de données

La dérive des données suit les changements dans la distribution des données d’entrée d’un modèle en les comparant aux données d’entraînement du modèle ou aux données de production récentes. Ces changements résultent de changements dans la dynamique du marché, des changements de transformation des fonctionnalités ou des changements en amont des données. De tels changements peuvent dégrader la performance du modèle, il est donc important de surveiller la dérive pour garantir une correction rapide. Pour effectuer une comparaison, la refactorisation de la dérive des données nécessite des ensembles de données et des sorties de production récentes.

Environnement : Production
Facilitation Azure : Machine Learning – Surveillance des modèles

Dérive de prédiction

La dérive des prédictions suit les changements dans la distribution des sorties de prédiction d’un modèle en les comparant aux données de validation, aux données de test étiquetées ou aux données de production récentes. Pour effectuer une comparaison, la refactorisation de la dérive des données nécessite des ensembles de données et des sorties de production récentes.

Environnement : Production
Facilitation Azure : Machine Learning – Surveillance des modèles

Ressource

Utilisez plusieurs métriques de points de terminaison de service de modèle pour indiquer la qualité et la performance, telles que l’utilisation du CPU ou de la mémoire. Cette approche vous aide à tirer des leçons de la production pour orienter les investissements ou les changements futurs.

Environnement : Tous
Facilitation Azure : Surveillance - Métriques des points de terminaison en ligne

Métriques d'utilisation

Surveillez l’utilisation des points de terminaison pour vous assurer que vous répondez aux indicateurs de performance clés spécifiques à l’organisation ou à la charge de travail, suivez les schémas d’utilisation et diagnostiquez et remédiez aux problèmes que rencontrent vos utilisateurs.

Requêtes de clients

Suivez le nombre de demandes clients au point de terminaison du modèle pour comprendre le profil d’utilisation active des points de terminaison, ce qui peut affecter les efforts de mise à l’échelle ou d’optimisation des coûts.

Environnement : Production
Facilitation Azure : Surveillance - Métriques des points de terminaison en ligne, telles que RequestsPerMinute. Remarques :

  • Vous pouvez aligner les seuils acceptables sur le dimensionnement des t-shirts ou les anomalies adaptées aux besoins de votre charge de travail.
  • Retirez les modèles qui ne sont plus utilisés de la production.
Les délais de limitation

Les délais de limitation (throttling) sont des ralentissements dans la demande et la réponse des transferts de données. La limitation se produit au niveau du gestionnaire de ressources et au niveau du service. Suivez les métriques à ces deux niveaux.

Environnement : Production
Facilitation Azure :

Remarques : Alignez les seuils acceptables sur les objectifs de niveau de service (SLO) ou les accords de niveau de service (SLA) de votre charge de travail et sur les exigences non fonctionnelles (NFR) de la solution.

Erreurs générées

Suivez les erreurs de code de réponse pour aider à mesurer la fiabilité du service et garantir la détection précoce des problèmes de service. Par exemple, une augmentation soudaine des réponses d’erreur serveur 500 pourrait indiquer un problème critique nécessitant une attention immédiate.

Environnement : Production
Facilitation Azure : Machine Learning - Activez les journaux de trafic des points de terminaison en ligne pour vérifier les informations sur votre demande. Par exemple, vous pouvez vérifier le nombre de XRequestId en utilisant ModelStatusCode ou ModelStatusReason. Vous pouvez utiliser un espace de travail Log Analytics pour traiter les journaux.
Remarques :

  • Tous les codes de réponses HTTP dans la plage 400 et 500 sont classés comme une erreur.

Optimisation des coûts

La gestion et l’optimisation des coûts dans un environnement cloud sont cruciales car elles aident les charges de travail à contrôler les dépenses, à allouer les ressources de manière efficace et à maximiser la valeur de leurs services cloud.

Calcul de l’espace de travail

Lorsque les dépenses opérationnelles mensuelles atteignent ou dépassent un montant prédéfini, générez des alertes pour notifier les parties prenantes pertinentes, telles que les responsables de projet ou les propriétaires de projet, en fonction des limites de configuration de l’espace de travail. Vous pouvez déterminer votre configuration de l’espace de travail en fonction des limites liées au projet, à l’équipe ou au département.

Environnement : Tous
Facilitation Azure : Microsoft Cost Management - Alertes budgétaires
Remarques :

  • Définissez des seuils budgétaires basés sur les exigences non fonctionnelles (NFR) initiales et les estimations de coûts.
  • Utilisez plusieurs niveaux de seuils. Les multiples niveaux de seuils garantissent que les parties prenantes reçoivent des avertissements appropriés avant que le budget ne soit dépassé. Ces parties prenantes peuvent inclure les responsables métier, les propriétaires de projet ou les responsables de projet, selon l’organisation ou la charge de travail.
  • Des alertes budgétaires constantes pourraient également être un déclencheur pour la refactorisation afin de soutenir une demande accrue.
Inactivité de l’espace de travail

Si un espace de travail de machine learning ne montre aucun signe d’utilisation active basé sur l’utilisation des ressources associées pour le cas d’utilisation prévu, un propriétaire de projet pourrait désaffecter l’espace de travail s’il n’est plus nécessaire pour un projet donné.

Environnement : Préproduction
Facilitation Azure :

Remarques :

  • Les cœurs actifs devraient être égaux à zéro avec agrégation de comptage.
  • Alignez les seuils de date sur le calendrier du projet.

Sécurité

Surveillez pour détecter les écarts par rapport aux contrôles de sécurité appropriés et aux bases de référence afin de garantir que les espaces de travail de machine learning sont conformes aux politiques de sécurité de votre organisation. Vous pouvez utiliser une combinaison de politiques prédéfinies et définies sur mesure.

Environnement : Tous
Facilitation Azure : Politique Azure pour Machine Learning

Sécurité des points de terminaison

Pour obtenir une visibilité sur les API critiques pour l’entreprise, mettez en œuvre une surveillance de sécurité ciblée de tous les points de terminaison de Machine Learning. Vous pouvez examiner et améliorer votre posture de sécurité des API, hiérarchiser des correctifs de vulnérabilité et détecter rapidement des menaces actives en temps réel.

Environnement : Production
Facilitation Azure : Microsoft Defender for APIs offre une protection, une détection et une réponse couvrant tout le cycle de vie des API. Remarques : Defender for APIs fournit une sécurité pour les API publiées dans Azure API Management. Vous pouvez intégrer Defender for APIs dans le portail Microsoft Defender for Cloud ou dans l’instance de gestion des API dans le portail Azure. Vous devez intégrer les points de terminaison en ligne de Machine Learning avec API Management.

Déploiement et surveillance

La surveillance du déploiement garantit que tous les points de terminaison que vous créez respectent les politiques de votre charge de travail ou de votre organisation et sont exempts de vulnérabilités. Ce processus nécessite que vous appliquiez des politiques de conformité à vos ressources Azure avant et après le déploiement, fournissez une sécurité continue grâce à l’analyse des vulnérabilités et assurez que le service respecte les objectifs de niveau de service (SLO) pendant son fonctionnement.

Normes et gouvernance

Surveillez pour détecter les écarts par rapport aux normes appropriées et assurez-vous que votre charge de travail respecte les garde-fous.

Environnement : Tous
Facilitation Azure :

  • Affectation et cycle de vie des politiques gérées via Azure Pipelines pour traiter la politique comme du code.
  • PSRule pour Azure fournit un cadre de test pour l’infrastructure Azure en tant que code.
  • Vous pouvez utiliser Politique Azure d’entreprise comme code dans un système basé sur CI/CD pour déployer des politiques, des ensembles de politiques, des affectations, des exemptions de politiques et des affectations de rôles.

Remarques : Pour plus d’informations, consultez les conseils Azure pour la conformité réglementaire de Machine Learning.

Analyse de la sécurité

Mettez en œuvre des analyses de sécurité automatisées dans le cadre des processus d’intégration et de déploiement automatisés.

Environnement : Tous
Facilitation Azure : Defender For DevOps
Remarques : Vous pouvez utiliser des applications dans Azure Marketplace pour étendre ce processus à des modules de test de sécurité non Microsoft.

Service continu

Surveillez le service continu d’une API pour l’optimisation des performances, la sécurité et l’utilisation des ressources. Assurez une détection rapide des erreurs, un dépannage efficace et la conformité aux normes.

Environnement : Production
Facilitation Azure :

Contributeurs

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

Auteurs principaux :

Autres contributeurs :

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

Étapes suivantes