Amazon MLS-C01: Apprentissage profond et vision par ordinateur — Guide d'étude

By Laurynas Brazys · 26 July 2026 · #amazon #mls-c01 #certification #exam-prep #study-guide

Fait partie du AWS Machine Learning Specialty MLS-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.

Architectures, apprentissage par transfert et sélection de modèles

Les backbones convolutionnels comme les familles ResNet et Inception restent des piliers pour la vision par ordinateur : ResNet (50/101) offre un apprentissage résiduel stable pour des hiérarchies de caractéristiques profondes, tandis que les modules Inception fournissent une agrégation de caractéristiques multi-échelles qui aide à gérer des objets de tailles variées. Pour les compromis modernes, EfficientNet et MobileNet privilégient le rapport FLOPs/précision, ce qui en fait des choix solides pour le mobile/edge. En pratique sur AWS, partez de poids pré-entraînés sur ImageNet (disponibles dans TorchVision, TensorFlow Hub ou via les conteneurs d’entraînement SageMaker) et appliquez l’apprentissage par transfert en remplaçant la tête de classification, en utilisant un taux d’apprentissage beaucoup plus faible pour les couches du backbone et un taux plus élevé pour les têtes nouvellement initialisées. Gelez les premières couches pour les petits jeux de données et dégelez-les progressivement par étapes pour éviter l’oubli catastrophique. Critères de décision : choisissez des backbones plus lourds (ResNet101, Inception-ResNet) pour les grands jeux de données et les points de terminaison tolérants à la latence (instances ml.p3 ou ml.p4), et des backbones légers (MobileNetV3, EfficientNet-lite) lors du déploiement via SageMaker Neo ou AWS IoT Greengrass sur des appareils aux ressources limitées. Un piège courant est d’effectuer le fine-tuning avec le même taux d’apprentissage élevé que pour l’entraînement à partir de zéro ; adoptez plutôt des taux d’apprentissage discriminatifs, utilisez la décroissance de poids (weight decay), et validez la transférabilité en surveillant les activations des couches dans l’espace des caractéristiques et la perte de validation pour détecter les signaux de surapprentissage.

Pratiques d’entraînement, augmentation et considérations sur les jeux de données/l’étiquetage

Des données étiquetées de haute qualité sont le fondement de modèles de vision fiables. Utilisez Amazon SageMaker Ground Truth pour construire des flux de travail d’étiquetage avec des boîtes englobantes, des polygones ou des masques sémantiques, et appliquez des équipes de travail privées, des restrictions IAM et le chiffrement S3 KMS pour respecter les contrôles d’accès aux données. Atténuez le bruit dans les étiquettes avec des tours de consensus et de révision, et utilisez l’apprentissage actif pour prioriser les exemples ambigus ou rares. Pour les jeux de données petits ou déséquilibrés, employez une augmentation agressive et adaptée à la tâche : transformations photométriques, recadrages aléatoires, rotations, cutout, augmentations mixup ou mosaic pour la détection ; utilisez l’échantillonnage équilibré par classe, la perte focale (focal loss) ou l’entropie croisée pondérée par classe pour gérer un déséquilibre de classe sévère. Répartissez les données pour éviter les fuites : pour les dépendances au niveau de l’utilisateur ou du magasin, effectuez des répartitions groupées ou temporelles plutôt que des répartitions aléatoires naïves ; un piège fréquent est la fuite d’horodatages futurs ou de plusieurs images du même objet entre les ensembles d’entraînement/validation/test. Pour les données médicales ou réglementées, activez l’isolation réseau pour les tâches d’entraînement SageMaker, chiffrez S3 avec KMS, restreignez l’accès aux notebooks via des points de terminaison VPC, et effectuez la rotation des informations d’identification avec Secrets Manager. Suivez les expériences et les métriques avec SageMaker Experiments pour corréler les choix d’augmentation, de taux d’apprentissage et de régularisation.

Détection et segmentation d’objets : architectures, métriques et pièges

Les choix pour la détection d’objets incluent des détecteurs à un étage comme YOLO et RetinaNet pour un débit en temps réel, et des détecteurs à deux étages comme Faster R-CNN pour une plus grande précision et la localisation de petits objets. Ajoutez des Feature Pyramid Networks (FPN) pour améliorer la détection multi-échelles ; utilisez Mask R-CNN ou DeepLabv3+ pour les tâches de segmentation d’instance et sémantique. Les ancres (anchors), les seuils d’IoU et la suppression des non-maximaux (NMS) affectent fortement les résultats : ajustez les tailles/ratios d’aspect des ancres aux échelles des objets du jeu de données et choisissez un IoU approprié pour l’assignation positive/négative. L’évaluation doit utiliser le mAP à différents niveaux d’IoU (AP50, AP75) ainsi que les courbes de rappel/précision par classe — se fier uniquement à la précision masque les échecs de localisation. Dans les flux de travail AWS, utilisez l’entraînement SageMaker avec les conteneurs PyTorch/TensorFlow pour les architectures personnalisées, stockez les jeux de données dans S3 avec des fichiers manifestes pour Ground Truth, et validez avec des tâches de traitement SageMaker Processing. Les pièges courants sont l’utilisation de tailles d’entrée trop grandes pour l’inférence (ce qui augmente la latence) ou l’ignorance du déséquilibre des classes dans le nombre d’objets ; optimisez en appliquant une augmentation spécifique à la classe, en utilisant des pertes pondérées, ou un entraînement en deux étapes où un détecteur générique est suivi de raffineurs par classe. Pour la production, exportez les modèles vers ONNX ou TorchScript et validez les sorties exportées par rapport aux sorties d’entraînement pour éviter les discordances d’opérateurs.

Optimisation de l’inférence, déploiement et surveillance pour les GPU et l’edge

L’optimisation de l’inférence nécessite de profiler l’ensemble du pipeline, pas seulement le calcul GPU. Une faible utilisation du GPU provient souvent d’un prétraitement limité par le CPU, de petites tailles de lot (batch), de la latence des points de terminaison synchrones ou d’attentes d’E/S (I/O). Profilez avec SageMaker Debugger et les métriques CloudWatch pour identifier les goulots d’étranglement, puis appliquez des solutions : augmentez la taille du lot ou utilisez l’inférence asynchrone ; convertissez les modèles en TorchScript/ONNX et activez les optimisations TensorRT sur les instances basées sur NVIDIA ; utilisez la précision mixte (AMP/bfloat16) sur les instances p4/p3 ; compilez avec SageMaker Neo pour le matériel cible ou déployez Elastic Inference pour attacher une accélération fractionnée aux instances CPU pour un débit modéré. Pour le déploiement en périphérie (edge), utilisez SageMaker Edge Manager ou AWS IoT Greengrass avec des modèles compilés par Neo, appliquez la quantification et l’élagage (pruning) pour réduire la taille du modèle, et exécutez le traitement par lots sur l’appareil lorsque c’est possible. Configurez des points de terminaison multi-modèles SageMaker ou la simultanéité provisionnée (provisioned concurrency) pour gérer les démarrages à froid (cold starts) et utilisez des politiques de mise à l’échelle automatique basées sur l’utilisation de la mémoire GPU et la latence des requêtes. Activez également Model Monitor pour détecter la dérive des données d’entrée (input drift) et SageMaker Model Registry pour une promotion contrôlée des modèles ; les pièges courants incluent la compilation de modèles avec des opérations non prises en charge par Neo ou l’oubli de provisionner des rôles IAM et des points de terminaison VPC pour l’accès privé à S3, ce qui provoque des échecs de déploiement.

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

Scénario : QuickServe Corp exploite un système de point de vente sur site (on-prem) et utilise SageMaker pour l’entraînement et l’inférence de modèles ; les images des caméras des magasins sont stockées dans un compartiment S3 privé avec chiffrement KMS. Ils souhaitent un pipeline de production pour détecter la longueur des files d’attente aux caisses et déployer un modèle léger sur des appareils en périphérie (edge) pour des alertes en temps réel.

Défi : Construire et déployer un modèle de comptage de file d’attente précis et à faible latence qui respecte la sécurité des données (S3 privé, KMS) et fonctionne sur du matériel de périphérie aux ressources limitées, tout en permettant un réentraînement sécurisé avec de nouvelles données étiquetées.

Approche recommandée :

Entraîner un détecteur en utilisant un backbone MobileNetV3 pré-entraîné (dans le conteneur SageMaker PyTorch) affiné (fine-tuned) sur des boîtes englobantes (bounding boxes) étiquetées avec Ground Truth et stockées dans S3 chiffré avec KMS ; utiliser des divisions groupées par magasin pour éviter la fuite de données (leakage).
Utiliser l’augmentation de données (recadrage aléatoire, retournement horizontal, variation de la luminosité) et la perte focale (focal loss) pour gérer le déséquilibre des classes entre les images avec et sans file d’attente ; valider avec l’AP50 et le rappel (recall) par classe.
Exporter le modèle en TorchScript/ONNX, le compiler avec SageMaker Neo en ciblant l’appareil de périphérie, et le déployer via AWS IoT Greengrass ou SageMaker Edge Manager avec signature du modèle et un rôle IAM n’autorisant que les artefacts S3 nécessaires.
Surveiller les performances avec des téléversements périodiques par lots vers S3, exécuter des tâches SageMaker Processing pour la détection de dérive, et réentraîner dans SageMaker en utilisant des jeux de données versionnés dans S3 et Model Registry avec un déploiement contrôlé vers la périphérie.

Justification : Cette approche utilise l’apprentissage par transfert (transfer learning) efficace et la compilation spécifique à l’appareil pour respecter les contraintes de latence et de taille, renforce la sécurité via KMS et IAM, et met en œuvre une boucle de réentraînement surveillée pour maintenir la précision tout en empêchant la fuite de données.

← Modélisation — Supervisée et non supervisée (ML classique) · Tous les domaines · Traitement du langage naturel et parole →

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