Gouverner le cycle de vie de l’apprentissage automatique à grande échelle, Partie 1 Un cadre pour l’architecture des charges de travail d’apprentissage automatique utilisant Amazon SageMaker

Gérer le cycle de vie de l'apprentissage automatique à grande échelle, Partie 1 Un cadre pour l'architecture des charges de travail d'apprentissage automatique avec Amazon SageMaker

Les clients de toutes tailles et de tous secteurs innovent sur AWS en intégrant l’apprentissage automatique (ML) dans leurs produits et services. Les récents développements des modèles d’intelligence artificielle générative ont accéléré davantage l’adoption du ML dans tous les secteurs. Cependant, la mise en place de mesures de sécurité, de protection des données et de gouvernance reste un défi clé auquel les clients sont confrontés lorsqu’ils déploient des charges de travail de ML à grande échelle. En abordant ces défis, on établit le cadre et les fondations nécessaires pour atténuer les risques et assurer une utilisation responsable des produits basés sur le ML. Bien que l’IA générative puisse nécessiter des mesures de contrôle supplémentaires, telles que l’élimination de la toxicité, la prévention du jailbreaking et des hallucinations, elle partage les mêmes composantes fondamentales que le ML traditionnel en matière de sécurité et de gouvernance.

Nos clients nous font part de leur besoin de connaissances spécialisées et d’un investissement pouvant aller jusqu’à 12 mois pour mettre en place leur propre implementation personnalisée de la plateforme ML d’Amazon SageMaker afin de garantir des environnements ML évolutifs, fiables, sécurisés et gouvernés pour leurs lignes de business (LOBs) ou leurs équipes ML. Si vous ne disposez pas d’un cadre pour gérer le cycle de vie du ML à grande échelle, vous risquez de rencontrer des difficultés telles que l’isolement des ressources au niveau de l’équipe, l’évolution des ressources d’expérimentation, l’opérationnalisation des flux de travail de ML, l’évolution de la gouvernance des modèles et la gestion de la sécurité et de la conformité des charges de travail de ML.

La gouvernance du cycle de vie du ML à grande échelle est un cadre qui vous aide à construire une plateforme ML avec des mesures de sécurité et de gouvernance intégrées, en fonction des meilleures pratiques de l’industrie et des normes de l’entreprise. Ce cadre répond aux défis en fournissant des conseils préscriptifs grâce à une approche de cadre modulaire, en étendant un environnement multi-comptes AWS Control Tower et l’approche discutée dans l’article “Mise en place d’environnements d’apprentissage automatique sécurisés et bien gouvernés sur AWS”.

Il fournit des conseils préscriptifs pour les fonctions suivantes de la plateforme ML :

• Intégrer l’IA générative et l’apprentissage par renforcement pour s’améliorer soi-même
• 10 meilleurs outils de gestion de mots de passe (octobre 2023)
• Les chercheurs de KAIST proposent SyncDiffusion un module plug-and-play qui synchronise plusieurs diffusions à l’aide de la descente de gradient à partir d’une perte de similarité perceptive.

• Fondations multi-compte, sécurité et réseau – Cette fonction utilise AWS Control Tower et les principes bien-architecturés pour la mise en place et le fonctionnement d’un environnement multi-compte, de services de sécurité et de réseau.
• Fondations de données et de gouvernance – Cette fonction utilise une architecture de mesh de données pour la mise en place et le fonctionnement d’un lac de données, d’un référentiel centralisé de fonctionnalités et de fondements de gouvernance des données, afin de permettre un accès aux données à granularité fine.
• Services partagés et de gouvernance de la plateforme ML – Cette fonction permet la mise en place et le fonctionnement de services communs tels que CI/CD, le AWS Service Catalog pour la provision d’environnements, ainsi qu’un référentiel central de modèles pour la promotion et la traçabilité des modèles.
• Environnements d’équipe ML – Cette fonction permet la mise en place et le fonctionnement d’environnements pour les équipes ML pour le développement, les tests et le déploiement de leurs cas d’utilisation, en intégrant des mesures de sécurité et de gouvernance.
• Observabilité de la plateforme ML – Cette fonction aide au dépannage et à l’identification des causes profondes des problèmes dans les modèles ML grâce à la centralisation des journaux et à la fourniture d’outils de visualisation de l’analyse des journaux. Elle fournit également des conseils pour générer des rapports de coûts et d’utilisation pour les cas d’utilisation ML.

Bien que ce cadre puisse être bénéfique pour tous les clients, il est particulièrement utile pour les entreprises de grande taille, matures, réglementées ou mondiales qui souhaitent étendre leurs stratégies de ML de manière contrôlée, conforme et coordonnée au sein de l’organisation. Il facilite l’adoption du ML tout en atténuant les risques. Ce cadre est utile pour les types de clients suivants :

• Les grandes entreprises qui disposent de nombreux LOBs (lignes de business) ou départements souhaitant utiliser le ML. Ce cadre permet à différentes équipes de créer et déployer des modèles ML de manière indépendante tout en offrant une gouvernance centrale.
• Des entreprises ayant une maturité moyenne à élevée en ML. Elles ont déjà déployé certains modèles ML initiaux et cherchent à développer leurs efforts en ML. Ce cadre peut accélérer l’adoption du ML dans toute l’organisation. Ces entreprises reconnaissent également la nécessité d’une gouvernance pour gérer des éléments tels que le contrôle d’accès, l’utilisation des données, la performance des modèles et les biais injustes.
• Des entreprises opérant dans des secteurs réglementés tels que les services financiers, la santé, la chimie et le secteur privé. Ces entreprises ont besoin d’une gouvernance solide et d’une traçabilité pour les modèles ML utilisés dans leurs processus métier. L’adoption de ce cadre peut faciliter la conformité tout en permettant le développement local de modèles.
• Des organisations mondiales ayant besoin de concilier un contrôle centralisé et local. L’approche fédérée de ce cadre permet à l’équipe d’ingénierie de la plateforme centrale d’établir des politiques et des normes à haut niveau, tout en laissant aux équipes LOB la flexibilité de s’adapter en fonction des besoins locaux.

Dans la première partie de cette série, nous parcourons l’architecture de référence pour la mise en place de la plateforme ML. Dans un article ultérieur, nous vous fournirons des conseils précis sur la mise en œuvre des différents modules de l’architecture de référence au sein de votre organisation.

Les fonctionnalités de la plateforme ML sont regroupées en quatre catégories, comme le montre la figure suivante. Ces fonctionnalités constituent la base de l’architecture de référence discutée ultérieurement dans cet article :

• Établir les fondations de l’apprentissage automatique (ML)
• Prendre en charge les opérations de ML à grande échelle
• Observer le ML
• Sécuriser le ML

Aperçu de la solution

Le cadre de gouvernance du cycle de vie de l’apprentissage automatique à grande échelle permet aux organisations d’intégrer des contrôles de sécurité et de gouvernance tout au long du cycle de vie de l’apprentissage automatique, ce qui aide les organisations à réduire les risques et à accélérer l’intégration de l’apprentissage automatique dans leurs produits et services. Le cadre facilite la configuration et la gouvernance d’environnements ML sécurisés, évolutifs et fiables, capables de prendre en charge un nombre croissant de modèles et de projets. Le cadre offre les fonctionnalités suivantes :

• Provisionnement de compte et d’infrastructure avec des ressources d’infrastructure conformes à la politique de l’organisation
• Déploiement en libre-service d’environnements de sciences des données et de modèles d’opérations ML de bout en bout (MLOps) pour des cas d’utilisation ML
• Isolation des ressources au niveau de la ligne de métier (LOB) ou de l’équipe pour se conformer aux exigences de sécurité et de confidentialité
• Accès réglementé à des données de qualité production pour l’expérimentation et les flux de travail prêts pour la production
• Gestion et gouvernance des dépôts de code, des pipelines de code, des modèles déployés et des fonctionnalités de données
• Un registre de modèles et un stockage de fonctionnalités (composants locaux et centraux) pour améliorer la gouvernance
• Contrôles de sécurité et de gouvernance pour le processus de développement et de déploiement de modèles de bout en bout

Dans cette section, nous vous donnons un aperçu des conseils précis pour vous aider à construire cette plateforme ML sur AWS avec des contrôles de sécurité et de gouvernance intégrés.

L’architecture fonctionnelle associée à la plateforme ML est représentée dans le diagramme suivant. L’architecture associe les différentes fonctionnalités de la plateforme ML aux comptes AWS.

L’architecture fonctionnelle avec les différentes fonctionnalités est mise en œuvre à l’aide de plusieurs services AWS, notamment AWS Organizations, SageMaker, les services DevOps AWS et un lac de données. L’architecture de référence de la plateforme ML avec les différents services AWS est représentée dans le diagramme suivant.

Ce cadre prend en compte plusieurs personnes et services pour gouverner le cycle de vie de l’apprentissage automatique à grande échelle. Nous vous recommandons les étapes suivantes pour organiser vos équipes et services :

1. À l’aide de AWS Control Tower et d’outils d’automatisation, votre administrateur cloud configure les fondations à plusieurs comptes, telles que Organizations et AWS IAM Identity Center (successeur d’AWS Single Sign-On), ainsi que des services de sécurité et de gouvernance tels que AWS Key Management Service (AWS KMS) et Service Catalog. De plus, l’administrateur met en place diverses unités organisationnelles (OUs) et des comptes initiaux pour prendre en charge vos flux de travail ML et analytiques.
2. Les administrateurs du lac de données mettent en place votre lac de données et votre catalogue de données, et configurent le stockage central des fonctionnalités en collaboration avec l’administrateur de la plateforme ML.
3. L’administrateur de la plateforme ML provisionne des services partagés de ML tels que AWS CodeCommit, AWS CodePipeline, Amazon Elastic Container Registry (Amazon ECR), un registre de modèles central, les cartes de modèles SageMaker, le tableau de bord des modèles SageMaker, et des produits de Service Catalog pour les équipes ML.
4. Le responsable de l’équipe ML s’authentifie via IAM Identity Center, utilise les produits de Service Catalog et provisionne des ressources dans l’environnement de développement de l’équipe ML.
5. Les scientifiques des données des équipes ML des différentes unités commerciales s’authentifient dans leur environnement de développement d’équipe pour construire le pipeline de modèles.
6. Les scientifiques des données recherchent et extraient des fonctionnalités du catalogue de stockage central, construisent des modèles grâce à des expériences et sélectionnent le meilleur modèle à promouvoir.
7. Les scientifiques des données créent et partagent de nouvelles fonctionnalités dans le catalogue de stockage central pour une réutilisation ultérieure.
8. Un ingénieur ML déploie le pipeline de modèles dans l’environnement de test de l’équipe ML en utilisant un processus CI/CD avec des services partagés.
9. Après validation des parties prenantes, le modèle ML est déployé dans l’environnement de production de l’équipe.
10. Des contrôles de sécurité et de gouvernance sont incorporés à chaque couche de cette architecture à l’aide de services tels que AWS Security Hub, Amazon GuardDuty, Amazon Macie, et plus encore.
11. Les contrôles de sécurité sont gérés de manière centralisée depuis le compte d’outillage de sécurité en utilisant Security Hub.
12. Les fonctionnalités de gouvernance de la plateforme ML, telles que les cartes de modèles SageMaker et le tableau de bord des modèles SageMaker, sont gérées de manière centralisée depuis le compte de services de gouvernance.
13. Les journaux d’Amazon CloudWatch et d’AWS CloudTrail provenant de chaque compte membre sont rendus accessibles de manière centralisée depuis un compte d’observabilité à l’aide de services natifs AWS.

Ensuite, nous plongeons en profondeur dans les modules de l’architecture de référence pour ce framework.

Modules de l’architecture de référence

L’architecture de référence comprend huit modules, chacun conçu pour résoudre un ensemble spécifique de problèmes. Collectivement, ces modules traitent de la gouvernance à travers différentes dimensions, telles que l’infrastructure, les données, le modèle et les coûts. Chaque module offre un ensemble distinct de fonctions et interopère avec d’autres modules pour fournir une plateforme ML intégrée de bout en bout avec des contrôles de sécurité et de gouvernance intégrés. Dans cette section, nous présentons un bref résumé des capacités de chaque module.

Fondations multi-comptes

Ce module aide les administrateurs cloud à construire une zone d’atterrissage AWS Control Tower en tant que cadre fondamental. Cela inclut la construction d’une structure multi-comptes, l’authentification et l’autorisation via IAM Identity Center, une conception de réseau hub-et-spoke, des services de journalisation centralisés et de nouveaux comptes membres AWS avec des bases de sécurité et de gouvernance standardisées.

De plus, ce module donne des orientations sur les meilleures pratiques concernant les structures d’unité organisationnelle (OU) et de compte appropriées pour prendre en charge vos flux de travail ML et analytiques. Les administrateurs cloud comprendront l’objectif des comptes et des OUs requis, comment les déployer, ainsi que les principaux services de sécurité et de conformité qu’ils devraient utiliser pour gouverner de manière centralisée leurs charges de travail ML et analytiques.

Un framework pour fournir de nouveaux comptes est également couvert, utilisant l’automatisation pour établir des baselines pour les nouveaux comptes lorsqu’ils sont provisionnés. En mettant en place un processus automatisé de provisionnement de comptes, les administrateurs cloud peuvent fournir aux équipes ML et analytiques les comptes dont elles ont besoin pour effectuer leur travail plus rapidement, sans sacrifier une base solide pour la gouvernance.

Fondations du lac de données

Ce module aide les administrateurs de lac de données à configurer un lac de données pour ingérer des données, curer des jeux de données et utiliser le modèle de gouvernance AWS Lake Formation pour gérer l’accès aux données à finesse de grain sur les comptes et les utilisateurs en utilisant un catalogue de données centralisé, des politiques d’accès aux données et des contrôles d’accès basés sur des tags. Vous pouvez commencer petit avec un compte pour les fondations de votre plateforme de données, à des fins de preuve de concept ou pour quelques petites charges de travail. Pour une implémentation de charges de travail de production de VoAGI à grande échelle, nous recommandons d’adopter une stratégie multi-comptes. Dans un tel environnement, les LOB peuvent assumer le rôle de producteurs de données et de consommateurs de données en utilisant différents comptes AWS, et la gouvernance du lac de données est gérée à partir d’un compte AWS partagé central. Le producteur de données collecte, traite et stocke des données de son domaine de données, en plus de surveiller et de garantir la qualité de ses actifs de données. Les consommateurs de données consomment les données du producteur de données après que le catalogue centralisé les a partagées à l’aide de Lake Formation. Le catalogue centralisé stocke et gère le catalogue de données partagées pour les comptes producteurs de données.

Services de la plateforme ML

Ce module aide l’équipe d’ingénierie de la plateforme ML à mettre en place des services partagés utilisés par les équipes de science des données sur leurs comptes d’équipe. Les services comprennent un portfolio du Service Catalog avec des produits pour le déploiement du domaine SageMaker, le déploiement du profil utilisateur du domaine SageMaker, des modèles de science des données pour la construction et le déploiement de modèles. Ce module dispose de fonctionnalités pour un registre centralisé de modèles, des cartes de modèles, un tableau de bord de modèles et des pipelines CI/CD utilisés pour orchestrer et automatiser les flux de travail de développement et de déploiement de modèles.

De plus, ce module détaille comment mettre en place les contrôles et la gouvernance nécessaires pour permettre des capacités d’auto-service basées sur les personas, permettant aux équipes de science des données de déployer indépendamment leur infrastructure cloud requise et leurs modèles ML.

Développement de cas d’utilisation ML

Ce module aide les LOB et les data scientists à accéder au domaine SageMaker de leur équipe dans un environnement de développement et à instancier un modèle de construction pour développer leurs modèles. Dans ce module, les data scientists travaillent sur une instance de compte de développement du modèle pour interagir avec les données disponibles sur le lac de données centralisé, réutiliser et partager des fonctionnalités à partir d’un magasin de fonctionnalités central, créer et exécuter des expériences de ML, construire et tester leurs flux de travail de ML, et enregistrer leurs modèles dans un registre de modèles de compte de développement dans leurs environnements de développement.

Des fonctionnalités telles que le suivi des expériences, les rapports d’explicabilité des modèles, la surveillance des données et des biais du modèle, ainsi que le registre de modèles sont également implémentées dans les modèles, permettant une adaptation rapide des solutions aux modèles développés par les data scientists.

Opérations de ML

Ce module aide les responsables LOBs et les ingénieurs en machine learning à travailler sur leurs instances de développement du modèle de déploiement. Une fois que le modèle candidat est enregistré et approuvé, ils mettent en place des pipelines CI/CD et exécutent des workflows en machine learning dans l’environnement de test de l’équipe, ce qui enregistre le modèle dans le registre central des modèles qui s’exécute dans un compte de services partagés de la plateforme. Lorsqu’un modèle est approuvé dans le registre central des modèles, cela déclenche un pipeline CI/CD pour déployer le modèle dans l’environnement de production de l’équipe.

Magasin centralisé des caractéristiques

Après le déploiement des premiers modèles en production et lorsque plusieurs cas d’utilisation commencent à partager des caractéristiques créées à partir des mêmes données, un magasin de caractéristiques devient essentiel pour assurer la collaboration entre les cas d’utilisation et réduire les travaux en double. Ce module aide l’équipe d’ingénierie de plateforme en machine learning à mettre en place un magasin centralisé pour stocker et régir les caractéristiques de machine learning créées par les cas d’utilisation, permettant la réutilisation des caractéristiques entre les projets.

Journalisation et observabilité

Ce module aide les responsables LOBs et les praticiens en machine learning à avoir une visibilité sur l’état des charges de travail de machine learning à travers les environnements de machine learning grâce à la centralisation de l’activité de journalisation, telle que CloudTrail, CloudWatch, les journaux de flux VPC et les journaux de charges de travail en machine learning. Les équipes peuvent filtrer, interroger et visualiser les journaux pour l’analyse, ce qui peut également contribuer à renforcer la posture de sécurité.

Coûts et rapports

Ce module aide les différentes parties prenantes (administrateurs de cloud, administrateurs de plateforme, bureau d’affaires de cloud) à générer des rapports et des tableaux de bord pour décomposer les coûts au niveau de l’utilisateur en machine learning, de l’équipe en machine learning et du produit en machine learning, et suivre l’utilisation, telle que le nombre d’utilisateurs, les types d’instances et les points d’extrémité.

Les clients nous ont demandé de leur fournir des directives sur le nombre de comptes à créer et sur la manière de structurer ces comptes. Dans la prochaine section, nous fournirons des orientations sur cette structure de compte en tant que référence que vous pouvez modifier selon vos besoins en fonction des exigences de gouvernance de votre entreprise.

Structure de compte de référence

Dans cette section, nous discuterons de notre recommandation pour organiser votre structure de compte. Nous partagerons une structure de compte de référence de base ; cependant, nous recommandons aux administrateurs en machine learning et en données de travailler en étroite collaboration avec leur administrateur de cloud pour personnaliser cette structure de compte en fonction des contrôles de leur organisation.

Nous recommandons d’organiser les comptes par unité d’organisation (OU) pour la sécurité, l’infrastructure, les charges de travail et les déploiements. De plus, dans chaque OU, organisez les comptes par une OU non-production et une OU production, car les comptes et les charges de travail déployés sous eux disposent de contrôles différents. Ensuite, nous discuterons brièvement de ces OUs.

OU Sécurité

Les comptes dans cette OU sont gérés par l’administrateur de cloud de l’organisation ou l’équipe de sécurité pour surveiller, identifier, protéger, détecter et répondre aux événements de sécurité.

OU Infrastructure

Les comptes dans cette OU sont gérés par l’administrateur de cloud de l’organisation ou l’équipe réseau pour gérer les ressources et les réseaux partagés au niveau de l’entreprise.

Nous recommandons d’avoir les comptes suivants sous l’OU infrastructure :

• Réseau – Mettez en place une infrastructure de réseau centralisée telle que AWS Transit Gateway
• Services partagés – Mettez en place des services AD centralisés et des points de terminaison VPC

OU Charges de travail

Les comptes dans cette OU sont gérés par l’équipe d’administration de plateforme de l’organisation. Si vous avez besoin de mettre en œuvre différents contrôles pour chaque équipe de plateforme, vous pouvez imbriquer d’autres niveaux d’OU à cet effet, tels qu’une OU pour les charges de travail de machine learning, une OU pour les charges de travail de données, etc.

Nous recommandons d’avoir les comptes suivants sous l’OU charges de travail :

• Comptes de développement, de test et de production au niveau de l’équipe en machine learning – Mettez cela en place en fonction de vos besoins en matière d’isolation des charges de travail
• Comptes du lac de données – Partitionnez les comptes par domaine de données
• Compte central de gouvernance des données – Centralisez vos politiques d’accès aux données
• Compte central de magasin de caractéristiques – Centralisez les caractéristiques pour les partager entre les équipes

OU Déploiements

Les comptes dans cette OU sont gérés par l’équipe d’administration de plateforme de l’organisation pour déployer des charges de travail et assurer l’observabilité.

Nous recommandons les comptes suivants sous l’OU de déploiement car l’équipe de la plateforme ML peut configurer différents jeux de contrôles au niveau de cette OU pour gérer et contrôler les déploiements :

• Comptes de services partagés ML pour les tests et la production – Héberge les services partagés de la plateforme CI/CD et le registre des modèles
• Comptes d’observabilité ML pour les tests et la production – Héberge les journaux CloudWatch, les journaux CloudTrail et autres journaux selon les besoins

Ensuite, nous discutons brièvement des contrôles organisationnels qui doivent être pris en compte pour l’intégration dans les comptes membres afin de surveiller les ressources d’infrastructure.

Contrôles de l’environnement AWS

Un contrôle est une règle de haut niveau qui offre une gouvernance continue pour votre environnement AWS global. Il est exprimé en langage clair. Dans ce cadre, nous utilisons AWS Control Tower pour mettre en œuvre les contrôles suivants qui vous aident à gérer vos ressources et à surveiller la conformité dans des groupes de comptes AWS :

• Contrôles préventifs – Un contrôle préventif garantit que vos comptes restent conformes car il empêche les actions qui conduisent à des violations de politique et est mis en œuvre à l’aide d’une politique de contrôle de service (SCP). Par exemple, vous pouvez définir un contrôle préventif qui garantit que CloudTrail n’est pas supprimé ou arrêté dans les comptes ou régions AWS.
• Contrôles détecteurs – Un contrôle détecteur détecte les non-conformités des ressources dans vos comptes, telles que des violations de politique, fournit des alertes via le tableau de bord et est mis en œuvre à l’aide des règles AWS Config. Par exemple, vous pouvez créer un contrôle détecteur qui vérifie si l’accès en lecture publique est activé pour les compartiments de stockage Simple Storage Service (S3) d’Amazon dans le compte de dépôt d’archive de journaux.
• Contrôles proactifs – Un contrôle proactif analyse vos ressources avant leur provisionnement et s’assure que les ressources sont conformes à ce contrôle et sont mis en œuvre à l’aide des hooks AWS CloudFormation. Les ressources qui ne sont pas conformes ne seront pas provisionnées. Par exemple, vous pouvez définir un contrôle proactif qui vérifie que l’accès internet direct n’est pas autorisé pour une instance de bloc-notes SageMaker.

Interactions entre les services de plateforme ML, les cas d’utilisation de ML et les opérations ML

Différentes personnes, telles que le responsable de la science des données (chef de l’équipe de data science), le data scientist et l’ingénieur ML, utilisent les modules 2-6 comme indiqué dans le diagramme suivant pour les différentes étapes des services de plateforme ML, du développement des cas d’utilisation de ML et des opérations ML ainsi que des fondations du data lake et du référentiel central des fonctionnalités.

Le tableau suivant résume l’activité du flux d’opérations et les étapes de configuration pour différentes personnes. Une fois qu’une personne lance une activité ML dans le cadre du flux d’opérations, les services s’exécutent comme indiqué dans les étapes de configuration.

Personne	Activité du flux d’opérations – Numéro	Activité du flux d’opérations – Description	Étape de configuration – Numéro	Étape de configuration – Description
Responsable de la science des données ou chef d’équipe ML	1	Utilise le catalogue de services dans le compte des services de plateforme ML et déploie ce qui suit :	1-A	Configure les environnements de développement, de test et de production pour les lignes de produits bancaires en ligne
1-B	Configure SageMaker Studio avec la configuration requise
Data Scientist	2	Effectue et suit les expériences ML dans les notebooks SageMaker	2-A	Utilise des données du Data Lake
3	Automatise les expériences ML réussies avec les projets et les pipelines SageMaker	3-A	Initie les pipelines SageMaker (prétraitement, formation, évaluation) dans le compte de développement
3-B	Après l’exécution des pipelines SageMaker, enregistre le modèle dans le registre local (développement)
Responsable de la science des données ou chef d’équipe ML	4	Approuve le modèle dans le registre local (développement)	4-A	Les métadonnées du modèle et le package du modèle sont enregistrés du registre local (développement) vers le registre central du modèle
5	Approuve le modèle dans le registre central du modèle	5-A	Initie le processus de déploiement CI/CD pour créer des points de terminaison SageMaker dans l’environnement de test
5-B	Écrit les informations et les métadonnées du modèle dans le module de gouvernance ML (fiche de modèle, tableau de bord du modèle) dans le compte des services de plateforme ML depuis le compte local (développement)
Ingénieur ML	6	Teste et surveille le point de terminaison SageMaker dans l’environnement de test après le CI/CD	.
7	Approuve le déploiement des points de terminaison SageMaker dans l’environnement de production	7-A	Initie le processus de déploiement CI/CD pour créer des points de terminaison SageMaker dans l’environnement de production
8	Teste et surveille le point de terminaison SageMaker dans l’environnement de test après le CI/CD	.

Personas et interactions avec les différents modules de la plateforme ML

Chaque module s’adresse à des personas cibles spécifiques au sein de divisions particulières qui utilisent le module le plus souvent, leur accordant un accès principal. Un accès secondaire est ensuite autorisé aux autres divisions qui nécessitent une utilisation occasionnelle des modules. Les modules sont adaptés aux besoins de rôles ou de personas spécifiques afin d’optimiser leur fonctionnalité

Nous discutons des équipes suivantes :

• Central cloud engineering – Cette équipe opère au niveau de l’entreprise dans tous les charges de travail pour mettre en place des services d’infrastructure cloud communs, tels que la mise en place de la mise en réseau au niveau de l’entreprise, l’identité, les autorisations et la gestion des comptes.
• Data platform engineering – Cette équipe gère les lacs de données de l’entreprise, la collecte de données, la curation des données et la gouvernance des données.
• ML platform engineering – Cette équipe opère au niveau de la plateforme ML à travers les LOB pour fournir des services d’infrastructure ML partagée tels que la provision d’infrastructure ML, le suivi des expériences, la gouvernance des modèles, le déploiement et l’observabilité.

Le tableau suivant détaille les divisions qui ont un accès principal et secondaire pour chaque module selon les personas cibles du module.

Numéro du module	Modules	Accès principal	Accès secondaire	Personas cibles	Nombre de comptes
1	Fondations multi-comptes	Central cloud engineering	LOB individuels	Administrateur cloud Cloud ingénieurs	Quelques-uns
2	Fondations du lac de données	Central cloud ou data platform engineering	LOB individuels	Administrateur du lac de données Data ingénieurs	Plusieurs
3	Services de plateforme ML	Central cloud ou ML platform engineering	LOB individuels	ML Administrateur de la plateforme – Responsable d’équipe ML – Ingénieurs ML – Responsable de la gouvernance ML	Un
4	Développement de cas d’utilisation ML	LOB individuels	Central cloud ou ML platform engineering	Scientifiques de données Data ingénieurs – Responsable de l’équipe ML – Ingénieurs ML	Plusieurs
5	Opérations ML	Central cloud ou ML engineering	LOB individuels	ML Ingénieurs – Responsables d’équipe ML – Scientifiques de données	Plusieurs
6	Magasin centralisé de fonctionnalités	Central cloud ou data engineering	LOB individuels	Data ingénieur – Scientifiques de données	Un
7	Journalisation et observabilité	Central cloud engineering	LOB individuels	Administrateur cloud IT Vérificateurs	Un
8	Coût et reporting	LOB individuels	Central platform engineering	Cadres LOB ML Gestionnaires	Un

Conclusion

Dans cet article, nous avons présenté un cadre pour gouverner le cycle de vie de l’apprentissage automatique à grande échelle, qui vous aide à mettre en œuvre des charges de travail d’apprentissage automatique bien architecturées intégrant des contrôles de sécurité et de gouvernance. Nous avons discuté de la façon dont ce cadre adopte une approche holistique pour la construction d’une plate-forme d’apprentissage automatique en tenant compte de la gouvernance des données, de la gouvernance des modèles et des contrôles de niveau entreprise. Nous vous encourageons à expérimenter le cadre et les concepts présentés dans cet article et à partager vos commentaires.

We will continue to update IPGirl; if you have any questions or suggestions, please contact us!