Amazon MLA-C01: Surveillance et observabilité des modèles — Guide d'étude

By Laurynas Brazys · 3 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

Fait partie du AWS Machine Learning Engineer Associate MLA-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.

Concepts fondamentaux : dérive, bases de référence et observabilité

La surveillance de modèle (model monitoring) est la discipline opérationnelle qui convertit la télémétrie brute d’exécution en signaux exploitables : dérive des données, dérive de concept, régressions de la qualité du modèle et santé de l’infrastructure. La dérive des données (data drift) signifie que la distribution statistique des caractéristiques d’entrée en production diverge de la distribution de référence observée lors de l’entraînement ; la dérive de concept (concept drift) signifie que la relation statistique entre les entrées et les étiquettes change de telle sorte que le mappage prédictif du modèle se dégrade. Une observabilité efficace nécessite une base de référence du comportement attendu, un profilage continu des entrées et sorties en production, l’extraction de métriques (à la fois centrées sur le modèle comme F1/ROC AUC et centrées sur les données comme la distance KS, le PSI, les taux de valeurs manquantes, la cardinalité catégorielle), et un système d’alerte et de workflow fiable qui boucle la boucle vers la validation ou le réentraînement.

Les bases de référence sont généralement générées à partir d’un instantané représentatif des données d’entraînement (et de validation) à l’aide de statistiques descriptives et de fichiers de contraintes. Dans AWS SageMaker, l’utilitaire

undefined

ou une tâche de traitement (Processing job) peut calculer les statistiques de référence et un ensemble initial de contraintes (par ex., min/max, valeurs catégorielles autorisées, percentiles). La sortie est un fichier de contraintes JSON et un fichier de statistiques stockés dans S3 ; ces artefacts deviennent la base de référence canonique référencée par les tâches de surveillance en cours. La surveillance compare les statistiques par lot à ces bases de référence et signale les violations lorsque les seuils configurés sont dépassés. L’observabilité signifie également capturer les entrées du modèle, les sorties du modèle, la latence d’inférence et la métrique métier en aval (si disponible) et corréler ces signaux pour diagnostiquer rapidement une baisse des métriques au niveau du modèle comme le F1.

Services clés et configuration

SageMaker Model Monitor fournit la capacité gérée de planifier des tâches de traitement qui calculent et évaluent des statistiques par rapport à des bases de référence. Les API et objets de configuration principaux que vous utiliserez incluent

undefined

avec les paramètres

undefined

, où

undefined

contient un

undefined

avec une

undefined

de type cron et une

undefined

qui inclut

undefined

(

undefined

(emplacements d’entrée S3 et

undefined

), et

undefined

. Les artefacts de référence sont référencés via

undefined

. Pour la dérivation automatique de la base de référence, utilisez l’appel

undefined

(SDK Python SageMaker), qui exécute un

undefined

qui écrit les contraintes et les statistiques sur S3.

L’observabilité et les alertes sont mises en œuvre à l’aide des métriques et alarmes CloudWatch et d’EventBridge pour les workflows événementiels. Model Monitor publie des résultats d’exécution qui peuvent être convertis en métriques CloudWatch ; pour créer une alarme, vous utilisez l’API

undefined

avec

undefined

(ou

undefined

, et

undefined

. Liez les alarmes à des actions automatisées en spécifiant des

undefined

qui pointent vers un sujet SNS ou une cible EventBridge. Les règles EventBridge peuvent filtrer sur la source

undefined

et utiliser un modèle qui correspond aux échecs d’exécution de la planification de surveillance de Model Monitor ou aux violations de contraintes, puis acheminer vers une Lambda ou directement vers

undefined

pour un SageMaker Pipeline.

Pour un déploiement contrôlé et des approbations manuelles, le SageMaker Model Registry prend en charge les objets

undefined

. Lorsque vous appelez

undefined

, vous pouvez définir

undefined

sur

undefined

, et plus tard, un utilisateur autorisé appelle

undefined

avec

undefined

défini sur

undefined

. Les pipelines ou les tâches de CI/CD qui déploient des modèles ne promouvront que les versions de package de modèle avec

undefined

. Utilisez les politiques IAM pour contrôler qui peut appeler

undefined

Une pile de surveillance complète utilise généralement les services suivants en combinaison :

Amazon SageMaker Model Monitor
Amazon SageMaker Pipelines et Model Registry
Amazon S3 (pour les bases de référence, les données de vérité terrain et la capture d’inférence)
Amazon CloudWatch (métriques, journaux,

undefined

)

Amazon EventBridge (règles d’événements et routage)
AWS Lambda ou Step Functions (cibles d’automatisation)
Amazon SNS (notifications d’alarme)
AWS Glue / Athena / QuickSight pour l’exploration et la visualisation ad-hoc

Patrons de conception et compromis

Un patron courant et robuste consiste à séparer la détection à court terme de la remédiation à long terme. Utilisez une planification de surveillance à haute fréquence (par exemple,

undefined

horaire ou quotidien avec ScheduleExpression) pour calculer des statistiques par lot et détecter rapidement la dérive. Injectez les résultats de chaque exécution dans des métriques personnalisées CloudWatch à l’aide de PutMetricData, et créez des alarmes CloudWatch avec des seuils conservateurs pour des actions automatisées à faible confiance (par ex., envoyer des notifications) et des seuils plus stricts pour des actions automatisées à haute confiance (par ex., déclencher un pipeline de réentraînement). Les règles EventBridge font le lien entre la détection et la remédiation en mappant un événement de violation de Model Monitor ou un changement d’état d’une alarme CloudWatch à une fonction Lambda qui s’authentifie et appelle StartPipelineExecution pour un pipeline SageMaker ou invoque une tâche de réentraînement via CreateTrainingJob.

Pour décider s’il faut réentraîner automatiquement ou exiger une approbation manuelle, évaluez le risque métier et la conformité. Le réentraînement automatique convient aux modèles à faible risque disposant d’étapes de validation automatisées fiables dans le pipeline (validation des données, évaluation du modèle par rapport à des données de validation, tests de restauration). Pour les modèles réglementés ou à fort impact, utilisez le patron d’approbation manuelle de Model Registry : poussez un ModelPackage candidat avec un ModelApprovalStatus à "PendingManualApproval", déclenchez un flux de revue humaine (par ex., un ticket dans un tableau de bord MLOps ou une fonction Lambda d’approbation qui met à jour le ModelPackage via UpdateModelPackage), et seulement alors, autorisez le déploiement sur les points de terminaison de production.

La fréquence de surveillance et la taille de la capture d’inférence introduisent des compromis entre le coût et la sensibilité. Des fenêtres de lots plus petites augmentent la sensibilité au bruit transitoire et les coûts de traitement, tandis que des fenêtres plus grandes réduisent les coûts mais peuvent retarder la détection d’une dérive rapide. De même, la capture des charges utiles d’inférence complètes peut être coûteuse et soulever des problèmes de gouvernance des données ; envisagez d’échantillonner ou de ne stocker que les caractéristiques agrégées et les sorties du modèle, à moins que des relectures complètes ne soient nécessaires pour l’analyse des causes profondes.

Pour les déclencheurs de réentraînement, privilégiez l’automatisation événementielle qui encode la logique métier dans le pipeline : le déclenchement d’une alarme CloudWatch active une règle EventBridge qui transmet une charge utile minimale (les URI S3 pour les données capturées et les fichiers de différences de contraintes) à StartPipelineExecution avec des PipelineParameters tels que "TrainingDataS3Uri", "BaselineConstraintsS3Uri", et "RetrainTriggerReason". Cela maintient le déclencheur déterministe et auditable.

Pièges courants et critères de décision

Un piège fréquent est de considérer la dérive statistique comme nécessitant systématiquement une action. Toute dérive n’affecte pas les performances du modèle. Corrélez les changements de distribution des caractéristiques avec les métriques de qualité du modèle (F1, précision-rappel, calibration) avant de lancer un réentraînement coûteux. Une autre erreur est de ne pas sécuriser les données d’inférence capturées ; choisissez le chiffrement au repos (S3 SSE-KMS), les politiques de compartiment S3 et les points de terminaison VPC pour maintenir les données de production isolées. Lors de la configuration des tâches de surveillance, assurez-vous que l’IAM RoleArn dispose d’un accès selon le principe de moindre privilège : lecture des préfixes S3 de capture d’inférence, écriture sur le préfixe S3 de sortie de surveillance, et la permission de créer des journaux CloudWatch si vous émettez des journaux.

Pour sélectionner la cadence de réentraînement et la complexité du pipeline, basez vos décisions sur les rapports signal/bruit observés. Si Model Monitor montre des violations transitoires fréquentes, mettez en œuvre un lissage ou exigez plusieurs exécutions consécutives en violation avant de déclencher des pipelines. Pour les flux de travail d’approbation manuelle, imposez l’appel

undefined

sur le ModelPackage via un ensemble de permissions IAM restreint et enregistrez l’identité de l’approbateur dans les métadonnées d’exécution du pipeline à des fins de conformité.

Problème pratique : Scénario de cas d’usage

Nom de l’entreprise : FinSecure Analytics ; défi : un modèle XGBoost de détection de fraude en production présente des pics intermittents de faux positifs et une baisse constante du score F1 sur plusieurs mois ; les données proviennent des journaux de transactions S3 et d’un miroir de profils clients sur une base MySQL sur site ; le modèle doit être audité et réentraîné avec des approbations humaines.

Surveillance automatisée et ligne de base : exécutez

undefined

sur un instantané représentatif des données d’entraînement pour produire des statistiques et des contraintes de ligne de base stockées dans S3 (préfixe S3 de la ligne de base). Créez une

undefined

avec une

undefined

spécifiant une

undefined

pour des exécutions horaires, un

undefined

avec des droits de lecture/écriture S3, une

undefined

pointant vers le conteneur Model Monitor, une

undefined

avec

undefined

, des

undefined

qui pointent vers les préfixes S3 de capture d’inférence, et une

undefined

pour capturer les sorties d’exécution.

Alertes et triage : publiez les comptes de violations par exécution sur CloudWatch en utilisant

undefined

dans un Namespace personnalisé et créez une

undefined

avec un

undefined

qui se déclenche si

undefined

pendant trois périodes consécutives. Configurez les

undefined

vers un sujet SNS et une règle EventBridge qui filtre la source “aws.sagemaker” et le

undefined

“SageMaker Model Monitor” pour inclure les métadonnées de violation.

Pipeline de remédiation avec approbation manuelle : implémentez un SageMaker Pipeline qui effectue l’ingestion de données (une tâche Glue pour centraliser le miroir S3 + MySQL dans un jeu de données d’entraînement), l’ingénierie des caractéristiques automatisée, l’entraînement via

undefined

en utilisant le conteneur XGBoost, une étape d’évaluation produisant des rapports sur le F1 et le biais, et l’enregistrement dans le Model Registry via

undefined

avec

undefined

. Le pipeline écrit les métriques d’évaluation dans CloudWatch et dans les métadonnées du ModelPackage.

Humain dans la boucle et mise en application : utilisez une règle EventBridge déclenchée par l’alarme CloudWatch pour notifier l’équipe de science des données via SNS ; l’approbateur examine les artefacts d’évaluation accessibles dans S3/QuickSight puis appelle

undefined

avec

undefined

. L’étape de CICD/déploiement vérifie le

undefined

avant d’invoquer

undefined

(ou la mise à jour de l’endpoint SageMaker). Pour le réentraînement automatisé où les métriques tombent en dessous des seuils automatiques et que l’entreprise accepte le réentraînement automatique, attachez une cible Lambda à la règle EventBridge qui appelle

undefined

avec les

undefined

, permettant un chemin entièrement automatisé protégé par des seuils plus stricts.

Justification AWS : SageMaker Model Monitor centralise la détection de dérive et la comparaison avec la ligne de base avec un travail opérationnel minimal ; CloudWatch et EventBridge fournissent un système d’alerte et de routage robuste vers SNS/Lambda ; SageMaker Pipelines automatise le réentraînement et la validation des modèles ; le

undefined

du Model Registry impose un portail d’approbation manuelle pour les déploiements en production, et S3/Glue/Athena fournissent une agrégation de données centralisée et sécurisée pour l’entraînement et la visualisation. Ensemble, ces services permettent des lignes de base reproductibles, des approbations auditables et un réentraînement automatisé configurable avec une séparation claire entre la détection et la remédiation.

← MLOps et gestion du cycle de vie des modèles · Tous les domaines · Sécurité →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →