Amazon AIF-C01: MLOps et déploiement — Guide d'étude
Fait partie du AWS AI Practitioner AIF-C01 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.
Modèles de déploiement et d’inférence : temps réel, par lots, sans serveur et en périphérie (edge)
Le choix d’un modèle d’inférence commence par l’analyse des compromis au niveau du service en matière de latence, de débit, de coût et de complexité opérationnelle. Pour les besoins de faible latence et de débit élevé, les points de terminaison en temps réel provisionnés d’Amazon SageMaker (points de terminaison à modèle unique ou multi-modèles) ou SageMaker Real-Time Inference avec mise à l’échelle automatique (autoscaling) et instances GPU sont des solutions classiques ; utilisez les variantes de point de terminaison pour implémenter des déploiements canary ou bleu/vert. Pour les tâches hors ligne volumineuses où la latence n’est pas critique, SageMaker Batch Transform ou le traitement distribué sur AWS Glue/EMR sont des options rentables et simples à mettre à l’échelle. Pour les charges de travail imprévisibles ou à faible QPS (requêtes par seconde), SageMaker Serverless Inference ou l’invocation de modèles depuis AWS Lambda (avec la simultanéité provisionnée si nécessaire) réduit la charge de gestion et les coûts. Les déploiements en périphérie (edge) nécessitent d’empaqueter les modèles avec SageMaker Edge Manager et de les distribuer via AWS IoT Greengrass pour les appareils ayant une connectivité intermittente et des exigences strictes en matière de latence ou de confidentialité. Les pièges courants pour les praticiens incluent le choix de points de terminaison en temps réel pour un trafic clairsemé (ce qui entraîne des coûts élevés), l’oubli de tester les démarrages à froid (cold starts) pour les déploiements sans serveur, et la sous-estimation des besoins en mémoire/GPU pour les points de terminaison multi-modèles. Les décisions doivent être guidées par les SLO (latence p99, débit), la taille du modèle, les schémas de simultanéité et la fréquence attendue des mises à jour ; le profilage avec un trafic représentatif est essentiel avant de choisir un modèle d’hébergement.
Registre de modèles, pipelines et CI/CD pour une livraison reproductible
Un flux de travail de production robuste utilise SageMaker Model Registry pour versionner les artefacts, capturer la lignée du modèle et gérer les flux d’approbation, et SageMaker Pipelines pour composer des étapes reproductibles d’entraînement, de validation et de déploiement. L’intégration d’un contrôle de source basé sur Git avec AWS CodePipeline et CodeBuild permet la CI (intégration continue) du code du modèle : tests unitaires, vérifications du schéma de données et évaluation automatisée du modèle qui conditionne la promotion dans le registre. L’automatisation du déploiement doit mettre en œuvre des environnements étagés (dev → staging → prod) et prendre en charge les restaurations (rollbacks) automatiques ou le basculement de trafic via des variantes de point de terminaison, des déploiements bleu/vert ou un routage basé sur Lambda. Les magasins de caractéristiques (feature stores), comme SageMaker Feature Store, assurent la cohérence entre l’entraînement et l’inférence en stockant les définitions des caractéristiques et leurs horodatages. Les pièges courants incluent l’oubli d’enregistrer les hyperparamètres et les versions de l’environnement, la non-automatisation des tests de validation (schéma de données, seuils de performance) et l’absence d’artefacts immuables (stockez les artefacts de modèle dans S3 ou ECR). Utilisez l’infrastructure en tant que code (IaC) (CloudFormation ou CDK) pour la configuration des points de terminaison, assurez la reproductibilité en figeant les versions des bibliothèques et les graines aléatoires (seeds), et planifiez des déclencheurs de réentraînement (dérive de données, planifications périodiques) intégrés au même pipeline.
Surveillance, Model Monitor et contrôles opérationnels
La surveillance opérationnelle doit couvrir la dérive des données (data drift), la dérive des concepts (concept drift), la dégradation des performances, la latence et l’utilisation des ressources. Amazon SageMaker Model Monitor peut établir une référence (baseline) des distributions de l’entraînement et profiler en continu le trafic d’inférence pour détecter la dérive des caractéristiques, les valeurs manquantes et les changements de schéma ; lorsque les données de référence (ground truth) sont disponibles, Model Monitor peut également suivre la qualité des prédictions et la dérive de la cible. Instrumentez la journalisation des inférences vers Amazon S3 et CloudWatch, et diffusez les journaux (logs) vers Amazon Kinesis ou Amazon EventBridge pour des alertes en temps réel et des déclencheurs de pipeline automatisés. Évitez les erreurs courantes comme traiter chaque alerte de dérive comme un signal de réentraînement — les changements transitoires et la saisonnalité peuvent provoquer de faux positifs — ou définir des seuils sans comprendre la variance naturelle. Pour les classes déséquilibrées, privilégiez la précision, le rappel et le score F1 à l’exactitude (accuracy) pour détecter une dégradation significative. Mettez en œuvre le RBAC et le chiffrement (KMS) pour les artefacts de modèle, utilisez des points de terminaison VPC et AWS PrivateLink pour un accès sécurisé aux services, et capturez les pistes d’audit via AWS CloudTrail. Maintenez des guides opérationnels (playbooks) pour la remédiation : validez les pipelines de données, comparez les performances des cohortes récentes, et choisissez de réentraîner, de restaurer (roll back) ou d’appliquer des corrections de calibration et de caractéristiques.
- Principales métriques d’évaluation et quand les utiliser
- Exactitude (Accuracy) : correction globale ; trompeuse sur des données déséquilibrées
- Précision : exactitude des prédictions positives ; à utiliser lorsque les faux positifs sont coûteux
- Rappel (Sensibilité) : capacité à trouver les cas positifs ; à utiliser lorsque les faux négatifs sont coûteux
- Score F1 : moyenne harmonique de la précision et du rappel ; choix équilibré pour les classes déséquilibrées
- AUC-ROC : qualité du classement à travers différents seuils ; utile pour les classifieurs binaires, indépendamment du seuil
Explicabilité, fiches de modèle et contrôles prêts pour la conformité
L’explicabilité doit être opérationnelle, auditable et adaptée aux besoins des parties prenantes. Amazon SageMaker Clarify fournit des vérifications de biais avant l’entraînement, des métriques de biais après l’entraînement et des attributions de caractéristiques par prédiction via SHAP qui peuvent être produites au moment de l’inférence ou en lots hors ligne. Les explications d’exécution doivent être journalisées avec les prédictions et les empreintes des entrées pour assurer la traçabilité ; stockez les explications dans S3 et indexez-les pour la récupération. Les fiches de modèle (Model Cards) documentent l’utilisation prévue, la provenance des données, les métriques d’évaluation sur des segments pertinents, les limitations connues et les avertissements de performance ; maintenez les versions des fiches de modèle dans le Model Registry pour répondre aux exigences de gouvernance. Les cas d’utilisation financiers et réglementés exigent des pistes d’audit déterministes : conservez les artefacts du modèle, les hyperparamètres, les données d’évaluation et les journaux d’explication ; mettez en œuvre des portes d’approbation avec intervention humaine (human-in-the-loop) pour les décisions à fort impact et maintenez des explications contrefactuelles pour les cas difficiles. Pour une intégration sécurisée avec les modèles de fondation gérés, utilisez des points de terminaison d’interface AWS PrivateLink pour appeler Amazon Bedrock depuis un VPC, chiffrez les charges utiles avec KMS et appliquez des contrôles IAM et réseau granulaires. Les choix de services pour le stockage des embeddings et la recherche vectorielle dépendent des besoins de récupération ; comparez les options en fonction de leurs performances et de leur coût opérationnel :
- Amazon OpenSearch Service (k-NN) : recherche vectorielle évolutive avec des analyses intégrées
- Amazon Kendra : recherche sémantique gérée avec des connecteurs intégrés et des fonctionnalités d’entreprise
- Amazon RDS (Postgres + pgvector) : stockage vectoriel transactionnel, plus simple pour les jeux de données relationnels
- ANN personnalisé sur Amazon EKS ou ECS : flexibilité maximale pour NMSLIB/FAISS, mais charge opérationnelle plus importante
Problème pratique : Scénario d’utilisation
Scénario : FinSight exploite un pipeline de décision de crédit sur AWS en utilisant SageMaker pour l’entraînement des modèles, Bedrock pour les explications génératives auxiliaires et Amazon S3 pour les données. Les modèles sont déployés en tant que points de terminaison en temps réel SageMaker dans un VPC, et Model Monitor est activé pour profiler les caractéristiques entrantes.
Défi : Model Monitor a signalé une dérive des caractéristiques au-delà des seuils et les réglementations métier exigent des décisions auditables et explicables pour toute modification automatisée des limites de crédit.
Approche recommandée :
- Utilisez les alertes de SageMaker Model Monitor pour déclencher une règle EventBridge qui envoie les données de dérive à un workflow de réentraînement SageMaker Pipelines, et créez un instantané des données d’inférence actuelles et des données d’entrée récentes dans un compartiment S3 de quarantaine.
- Exécutez une tâche de validation automatisée dans SageMaker Pipelines qui compare les distributions de données récentes à la référence, calcule les métriques d’évaluation (précision/rappel/F1) et produit des explications SHAP par échantillon avec SageMaker Clarify pour une cohorte représentative.
- Si les vérifications automatisées réussissent, enregistrez le nouveau modèle dans SageMaker Model Registry avec une fiche de modèle (Model Card) mise à jour capturant les segments de performance et les explications ; utilisez une variante de point de terminaison et le décalage de trafic (traffic shifting) pour un déploiement progressif. Si les vérifications échouent, créez un incident dans la file d’attente des opérations et lancez une étape de révision humaine avant tout déploiement.
- Pour les appels Bedrock sécurisés qui génèrent des explications lisibles par l’homme, acheminez le trafic Bedrock via AWS PrivateLink et chiffrez les charges utiles avec KMS ; journalisez toutes les sorties d’explication dans S3 et liez-les aux enregistrements d’inférence pour l’auditabilité.
Justification : Cette approche combine la détection automatisée, la validation reproductible et le déploiement contrôlé avec des pistes d’audit et des explications par décision, alignant ainsi les contrôles opérationnels sur la transparence réglementaire et minimisant les actions de réentraînement/restauration erronées.
← Entraînement · Tous les domaines · Optimisation des coûts et tarification pour l’IA →
Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Réussissez votre examen →