Amazon MLA-C01: Vision par ordinateur, NLP et ML spécialisé — 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.

Concept de base

Les solutions de vision par ordinateur et de NLP sur AWS reposent sur trois niveaux de préoccupations : l’ingestion et la sécurité des données, la préparation des caractéristiques (features) et des étiquettes, et le cycle de vie du modèle (entraînement, registre, déploiement, surveillance). Pour la classification d’images et la détection d’objets, les flux de travail d’entraînement sont centrés sur le stockage de ressources étiquetées dans Amazon S3 avec un chiffrement et des contrôles réseau stricts, des formats d’annotation tels que Pascal VOC / COCO pour la détection d’objets et RecordIO ou TFRecord pour l’entraînement à haut débit. Pour la classification de texte et la reconnaissance d’entités nommées (NER), les entrées sont généralement des séquences tokenisées (WordPiece/BPE pour les modèles de type transformer) ou du JSON délimité par des sauts de ligne avec des étiquettes ; le prétraitement doit préserver les décalages (offsets) des tokens par rapport aux caractères lors de l’utilisation des sorties de Rekognition Textract ou des plages étiquetées manuellement, afin que l’alignement des étiquettes NER soit cohérent. L’ingénierie des caractéristiques (feature engineering) pour les modèles de détection de fraude sur données tabulaires se concentre sur l’agrégation sur des fenêtres temporelles, la réduction de la cardinalité des catégories et un encodage cohérent entre l’entraînement et la mise en service ; l’utilisation d’une transformation centralisée (flux Feature Store ou Data Wrangler) prévient la dérive (skew) entre l’entraînement hors ligne et l’inférence en ligne.

Les choix de construction de modèles correspondent à des services AWS spécialisés : Amazon SageMaker propose des algorithmes intégrés (XGBoost, Linear Learner, Random Cut Forest) et des conteneurs gérés pour des frameworks (MXNet, TensorFlow, PyTorch), ainsi que SageMaker Clarify pour le biais et l’explicabilité. Amazon Rekognition couvre les API d’image pré-entraînées pour l’étiquetage, la détection de visages/célébrités, et l’entraînement d’étiquettes personnalisées via Rekognition Custom Labels lorsqu’une faible surcharge opérationnelle est requise. Pour l’extraction de texte et de données structurées à partir de documents, Amazon Textract fournit l’OCR et l’extraction de formulaires/tableaux ; pour les tâches au niveau du langage comme le sentiment, la reconnaissance d’entités ou la modélisation de sujets, Amazon Comprehend fournit des API gérées et Comprehend Medical pour la NER clinique. Il est essentiel pour la production de lier ces éléments dans un pipeline cohérent afin que le prétraitement, les entrées du modèle et la surveillance soient reproductibles et auditables.

Services clés et configuration

Les services AWS principaux et les paramètres d’API/configuration pertinents à connaître sont Amazon SageMaker (TrainingJob, ModelPackage, ModelPackageGroup, ModelRegistry), SageMaker Pipelines (RegisterModel, CallbackStep, ConditionStep), SageMaker Model Monitor et Clarify (BaselineConfig, DataConfig, ModelConfig, bias_config), Amazon Rekognition, Amazon Comprehend, Amazon Textract, AWS Glue et Lake Formation. Pour un stockage isolé et sécurisé, configurez S3 avec un chiffrement côté serveur en utilisant SSE-KMS (S3.PutBucketEncryption avec SSEKMSKeyId), attachez des stratégies de compartiment (bucket policies) limitant l’accès au rôle d’exécution de SageMaker, et activez un point de terminaison d’un VPC de type passerelle pour S3 pour les transferts sur le réseau privé. Lors du lancement des tâches d’entraînement, définissez le paramètre VpcConfig (SecurityGroupIds et Subnets) dans CreateTrainingJob pour que les instances s’exécutent dans le VPC du client, et activez NetworkIsolation et InstanceMetadataServiceConfiguration pour limiter l’accès.

Pour gérer les modèles de manière centralisée avec une surcharge opérationnelle minimale, utilisez le SageMaker Model Registry en créant un ModelPackageGroup et en ajoutant des versions de ModelPackage avec le ModelApprovalStatus défini sur ‘PendingManualApproval’ via CreateModelPackage. Automatisez une porte d’approbation manuelle en ajoutant un CallbackStep ou une étape “ManualApproval” dédiée dans SageMaker Pipelines ; le pipeline attend un signal externe, puis vous appelez UpdateModelPackage pour définir le ModelApprovalStatus sur ‘Approved’ en vue du déploiement. Pour des évaluations à la demande du biais ou de la dérive des points de terminaison en temps réel déployés, utilisez SageMaker Clarify pour les métriques de biais et SageMaker Model Monitor pour la dérive des données et des prédictions : capturez les charges utiles (payloads) d’inférence en activant DataCaptureConfig dans CreateEndpoint (EnableCapture, CaptureOptions, DestinationS3Uri), puis lancez une tâche de traitement Clarify via CreateProcessingJob avec les paramètres du SDK Clarify DataConfig, ModelConfig et bias_config pour calculer immédiatement les métriques de dérive.

Les services pertinents incluent :

Amazon SageMaker (TrainingJob, CreateModelPackage, UpdateModelPackage, CreateProcessingJob, CreateMonitoringSchedule)
SageMaker Pipelines (RegisterModel, CallbackStep, ConditionStep)
SageMaker Clarify (DataConfig, ModelConfig, bias_config, explainability_config)
Amazon Rekognition (StartProjectVersion, DetectLabels, CreateProjectVersion)
Amazon Comprehend (DetectEntities, StartEntitiesDetectionJob)
Amazon Textract (StartDocumentTextDetection, AnalyzeDocument)
AWS Glue et AWS Lake Formation (Crawlers, Jobs, Data Catalog)
Amazon Lookout for Metrics et Amazon QuickSight pour la visualisation des anomalies

Patrons de conception et compromis

Pour la classification tabulaire comme la détection de fraude, le patron de conception pratique consiste à centraliser les sources brutes dans un lac de données S3 sécurisé en utilisant AWS Glue ou DMS pour les tables relationnelles, à les cataloguer dans Glue Data Catalog et à appliquer l’accès via Lake Formation. Les transformations sont exprimées une seule fois dans des flux SageMaker Data Wrangler ou en tant que tâches Glue ETL et sont persistées dans SageMaker Feature Store afin que les mêmes transformations s’exécutent à l’entraînement et à l’inférence. Le choix de Feature Store ajoute des étapes opérationnelles initiales mais réduit le décalage (skew) et le temps de débogage ; les transformations directes au sein de la tâche ont une charge initiale plus faible mais rendent la reproductibilité et le calcul de caractéristiques en ligne plus difficiles. Pour les algorithmes d’entraînement, XGBoost (conteneur fourni par SageMaker) est un excellent choix par défaut pour la détection de fraude en raison de ses performances sur les données tabulaires et de sa prise en charge des colonnes de poids ; configurez les hyperparamètres en utilisant HyperParameters dans CreateTrainingJob et passez une colonne de poids ou définissez scale_pos_weight pour contrer le déséquilibre des classes, ce qui évite des pipelines de rééchantillonnage plus complexes.

Pour la vision par ordinateur, si vous avez besoin d’itérations rapides et que les données étiquetées sont limitées, Rekognition Custom Labels offre le chemin le plus rapide avec un minimum d’opérations ; pour un contrôle maximal et des architectures personnalisées, utilisez l’entraînement SageMaker avec MXNet/PyTorch, et stockez les jeux de données au format RecordIO ou ImageFolder sur S3. Pour la détection d’objets, préférez l’entraînement avec des frameworks qui génèrent le format COCO et tirez parti de l’entraînement distribué de SageMaker en spécifiant InstanceType=ml.p3.2xlarge ou supérieur et en définissant la configuration MPI ou horovod dans l’AlgorithmSpecification et le TrainingInputMode du TrainingJob. Les compromis incluent le débit par rapport au coût : les tâches par lots (batch) utilisant des instances Spot gérées réduisent les coûts mais ajoutent de la latence et un risque de terminaison ; la mise en cache dans SageMaker Pipelines réduit le redémarrage des étapes répétées lorsque les entrées sont inchangées, ce qui minimise le temps de démarrage de calcul inutile.

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

Un piège fréquent est de ne pas centraliser les artefacts de prétraitement. Si la tokenisation, le mappage d’étiquettes pour la NER ou les encodeurs catégoriels sont appliqués différemment lors de l’entraînement et de l’inférence, vous introduisez des erreurs de prédiction difficiles à tracer. Utilisez Feature Store ou persistez l’artefact de prétraitement (tokeniseur, vocab.json, label_map) avec le package de modèle dans le Model Registry afin que le conteneur déployé récupère et applique les transformations exactes. Une autre défaillance courante est une capture insuffisante pour la surveillance : sans activer DataCaptureConfig sur le point de terminaison et sans un workflow approprié d’étiquetage des données de référence (ground-truth), Model Monitor ne peut pas calculer les métriques de dérive ou de qualité, et clarifier les baisses du score F1 devient une pure conjecture. Pour le déséquilibre des classes, la solution la moins intensive sur le plan opérationnel consiste à utiliser une pondération prise en charge par l’algorithme (par exemple, l’hyperparamètre scale_pos_weight de XGBoost ou la fourniture d’une colonne de poids dans les données d’entraînement) plutôt qu’un sur-échantillonnage/sous-échantillonnage aveugle, qui peut introduire un biais d’échantillonnage.

Problème pratique : Scénario d’utilisation

Nom de l’entreprise : MeridianPay. MeridianPay doit construire un pipeline de détection de fraude en temps réel combinant des journaux de transactions dans S3 et des profils clients dans une base de données MySQL sur site (on-prem). Les exigences incluent un stockage sécurisé et isolé, un registre de modèles centralisé avec approbation manuelle, une latence de démarrage minimale entre les exécutions d’entraînement consécutives, une détection d’anomalies et une visualisation automatisées après agrégation, la prise en charge de caractéristiques mixtes (catégorielles et numériques) avec un minimum d’opérations, la gestion du déséquilibre des classes, et un modèle de production qui peut être surveillé pour la dérive et le biais à la demande.

Agréger et sécuriser les données : utiliser AWS DMS pour répliquer en continu les tables MySQL sur site dans une zone d’atterrissage (landing zone) S3 chiffrée, exécuter des crawlers AWS Glue et enregistrer les tables résultantes dans AWS Glue Data Catalog. Appliquer l’accès via AWS Lake Formation et les politiques de compartiment S3 ; activer un point de terminaison d’un VPC de type passerelle (Gateway) pour S3 et configurer le rôle d’exécution SageMaker avec les privilèges IAM les plus faibles (least-privilege). Utiliser SSE-KMS sur S3 avec une clé KMS gérée par le client et définir BucketEncryption avec le KmsMasterKeyId.
Transformer et stocker les caractéristiques : créer des transformations dans SageMaker Data Wrangler ou une tâche ETL Glue, persister les caractéristiques dérivées dans le magasin en ligne (online store) d’Amazon SageMaker Feature Store pour une recherche à faible latence lors de l’inférence et dans le magasin hors ligne (offline store) pour l’entraînement. Stocker les artefacts de tokeniseur/encodeur à côté des artefacts du modèle. Utiliser les API FeatureGroup pour créer des groupes de caractéristiques et configurer RecordIdentifierFeatureName et EventTimeFeatureName pour permettre l’exactitude à un instant T (point-in-time).
Entraîner avec une surcharge opérationnelle minimale : utiliser le conteneur intégré XGBoost de SageMaker en créant un CreateTrainingJob avec AlgorithmSpecification pointant vers l’URI du conteneur XGBoost, spécifier VpcConfig pour s’exécuter dans le VPC, passer des HyperParameters incluant “objective”:“binary:logistic” et définir “scale_pos_weight” sur le ratio d’exemples négatifs par rapport aux exemples positifs pour gérer le déséquilibre des classes. Pour réduire la latence de démarrage répétée, implémenter SageMaker Pipelines et activer la mise en cache pour les étapes de préparation des données afin que les exécutions consécutives du pipeline ignorent les étapes inchangées ; utiliser des recherches dans le feature store persistant plutôt que de recourir au retraitement chaque fois que possible.
Registre de modèles et approbation manuelle : enregistrer les modèles entraînés dans un ModelPackageGroup via CreateModelPackage avec ModelApprovalStatus=‘PendingManualApproval’. Intégrer une CallbackStep de SageMaker Pipelines qui se met en pause après RegisterModel ; les réviseurs appellent ensuite UpdateModelPackage pour définir ModelApprovalStatus=‘Approved’. Utiliser ce package approuvé pour les configurations CreateModel et CreateEndpoint.
Détection d’anomalies et visualisation : après l’agrégation, utiliser Amazon Lookout for Metrics pour effectuer une détection automatique d’anomalies sur les agrégats de transactions en séries temporelles et configurer les intégrations avec S3/Glue. Pour la visualisation, connecter les résultats de Lookout et les données dans des tableaux de bord QuickSight ou utiliser des notebooks SageMaker Studio pour visualiser la dérive des caractéristiques. Pour l’évaluation à la demande du biais/de la dérive du modèle pour les points de terminaison déployés, activer DataCaptureConfig dans CreateEndpoint et exécuter une tâche de traitement SageMaker Clarify à la demande (CreateProcessingJob) avec DataConfig et ModelConfig pointant vers les données capturées ; utiliser Model Monitor/CreateMonitoringSchedule pour planifier des vérifications récurrentes et pour déclencher une exécution unique avec StartMonitoringSchedule.

Justification : cette approche centralise les données et les transformations, utilise des services gérés là où ils réduisent la charge opérationnelle (Glue/DMS/Lookout/Comprehend/Textract pour leurs domaines respectifs), tire parti de SageMaker Model Registry et Pipelines pour le versionnage et l’approbation manuelle avec une infrastructure personnalisée minimale, résout le déséquilibre des classes via les paramètres de l’algorithme pour éviter un rééchantillonnage lourd, et fournit des évaluations de biais/dérive à la fois planifiées et à la demande via Model Monitor et Clarify, tout en gardant les données chiffrées et isolées du réseau.

← Optimisation des coûts pour les charges de travail ML · Tous les domaines

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