Amazon MLS-C01: Deep Learning e Computer Vision — Guida allo studio

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

Fa parte della AWS Machine Learning Specialty MLS-C01 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Architetture, transfer learning e selezione del modello

Le backbone convoluzionali come le famiglie ResNet e Inception rimangono i cavalli di battaglia per la computer vision: ResNet (50/101) offre un apprendimento residuo stabile per gerarchie di feature profonde, mentre i moduli Inception forniscono un’aggregazione di feature multi-scala che aiuta con oggetti di dimensioni variabili. Per i moderni compromessi, EfficientNet e MobileNet danno priorità al rapporto FLOPs-accuratezza, rendendoli scelte eccellenti per applicazioni mobile/edge. In pratica su AWS, si parte da pesi pre-addestrati su ImageNet (disponibili in TorchVision, TensorFlow Hub o tramite i container di training di SageMaker) e si applica il transfer learning sostituendo la testa di classificazione (classification head), utilizzando un learning rate molto più basso per i layer della backbone e uno più alto per le teste appena inizializzate. Congelare i primi layer per dataset di piccole dimensioni e scongelarli progressivamente per fasi per evitare il catastrophic forgetting (dimenticanza catastrofica). Criteri decisionali: scegliere backbone più pesanti (ResNet101, Inception-ResNet) per dataset di grandi dimensioni ed endpoint tolleranti alla latenza (istanze ml.p3 o ml.p4), e backbone leggere (MobileNetV3, EfficientNet-lite) per il deployment su dispositivi con risorse limitate tramite SageMaker Neo o AWS IoT Greengrass. Una trappola comune è eseguire il fine-tuning con lo stesso learning rate elevato usato per l’addestramento da zero; adottare invece learning rate discriminativi, usare il weight decay e validare la trasferibilità monitorando le attivazioni dei layer nello spazio delle feature e la validation loss per individuare segnali di overfitting.

Pratiche di addestramento, augmentation e considerazioni su dataset/labeling

Dati etichettati di alta qualità sono il fondamento per modelli di vision affidabili. Utilizzare Amazon SageMaker Ground Truth per creare flussi di lavoro di etichettatura (labeling) con bounding box, poligoni o maschere semantiche, e applicare controlli di accesso ai dati tramite workforces private, restrizioni IAM e crittografia S3 con KMS. Mitigare il rumore nelle etichette (label noise) con meccanismi di consenso e cicli di revisione, e usare l’active learning per dare priorità a esempi ambigui o rari. Per dataset piccoli o sbilanciati, impiegare un’augmentation aggressiva e appropriata al task: trasformazioni fotometriche, ritagli casuali (random crops), rotazioni, cutout, mixup o mosaic augmentation per la detection; utilizzare campionamento bilanciato per classe (class-balanced sampling), focal loss o cross-entropy pesata per classe per gestire un grave sbilanciamento delle classi. Suddividere i dati per evitare il data leakage: per dipendenze a livello di utente o di negozio, eseguire suddivisioni raggruppate (grouped split) o basate sul tempo (time-based split) invece di suddivisioni casuali ingenue; una trappola frequente è la fuoriuscita (leakage) di timestamp futuri o di immagini multiple dello stesso oggetto tra i set di train/val/test. Per dati medici o regolamentati, abilitare l’isolamento di rete per i job di training di SageMaker, crittografare S3 con KMS, limitare l’accesso ai notebook tramite endpoint VPC e ruotare le credenziali usando Secrets Manager. Tracciare esperimenti e metriche con SageMaker Experiments per correlare le scelte di augmentation, learning rate e regolarizzazione.

Object detection e segmentazione: architetture, metriche e insidie

Le scelte per l’object detection includono detector a uno stadio (one-stage) come YOLO e RetinaNet per un throughput in tempo reale, e detector a due stadi (two-stage) come Faster R-CNN per una maggiore accuratezza e per la localizzazione di oggetti piccoli. Aggiungere Feature Pyramid Networks (FPN) per migliorare la detection multi-scala; usare Mask R-CNN o DeepLabv3+ per compiti di instance segmentation e semantic segmentation. Gli anchor, le soglie di IoU e la Non-Max Suppression (NMS) influenzano pesantemente i risultati: ottimizzare le dimensioni/aspect ratio degli anchor in base alle scale degli oggetti nel dataset e scegliere una IoU appropriata per l’assegnazione positivo/negativo. La valutazione deve usare la mAP su diversi livelli di IoU (AP50, AP75) oltre a curve di recall/precision per classe; affidarsi unicamente all’accuracy maschera i fallimenti di localizzazione. Nei flussi di lavoro AWS, usare il training di SageMaker con i container PyTorch/TensorFlow per architetture personalizzate, archiviare i dataset in S3 con file manifest per Ground Truth e validare con i job di SageMaker Processing. Trappole comuni sono l’uso di dimensioni di input eccessivamente grandi per l’inferenza (aumenta la latenza) o l’ignorare lo sbilanciamento delle classi nel conteggio degli oggetti; ottimizzare applicando un’augmentation specifica per classe, usando loss pesate o un addestramento a due stadi in cui un detector generico è seguito da “refiner” specifici per classe. Per la produzione, esportare i modelli in formato ONNX o TorchScript e validare gli output esportati confrontandoli con quelli di training per evitare discrepanze negli operatori (operator mismatch).

Ottimizzazione dell’inferenza, deployment e monitoraggio per GPU e edge

L’ottimizzazione dell’inferenza richiede il profiling dell’intera pipeline, non solo del calcolo su GPU. Una bassa utilizzazione della GPU è spesso causata da pre-elaborazione CPU-bound, batch di piccole dimensioni, latenza degli endpoint sincroni o attese di I/O. Esegui il profiling con SageMaker Debugger e le metriche di CloudWatch per identificare i colli di bottiglia, quindi applica le soluzioni: aumenta la dimensione del batch o usa l’inferenza asincrona; converti i modelli in TorchScript/ONNX e abilita le ottimizzazioni TensorRT su istanze basate su NVIDIA; usa la precisione mista (AMP/bfloat16) su istanze p4/p3; compila con SageMaker Neo per l’hardware di destinazione o implementa Elastic Inference per aggiungere accelerazione frazionata a istanze CPU per un throughput moderato. Per il deployment su edge, usa SageMaker Edge Manager o AWS IoT Greengrass con modelli compilati da Neo, applica la quantizzazione e il pruning per ridurre le dimensioni del modello ed esegui il batching on-device dove possibile. Configura endpoint multi-modello di SageMaker o la provisioned concurrency per gestire i cold start e usa policy di scaling automatico basate sull’utilizzo della memoria GPU e sulla latenza delle richieste. Abilita anche Model Monitor per rilevare il drift dell’input e SageMaker Model Registry per una promozione controllata dei modelli; trappole comuni includono la compilazione di modelli con operazioni non supportate da Neo o la dimenticanza di configurare ruoli IAM ed endpoint VPC per l’accesso privato a S3, il che causa fallimenti nel deployment.

Problema Pratico: Scenario d’Uso

Scenario: QuickServe Corp gestisce un sistema point-of-sale on-premise e utilizza SageMaker per l’addestramento e l’inferenza dei modelli; le immagini dalle telecamere dei negozi sono archiviate in un bucket S3 privato con crittografia KMS. Vogliono una pipeline di produzione per rilevare la lunghezza delle code alle casse e distribuire un modello leggero su dispositivi edge per avvisi in tempo reale.

Sfida: Costruire e distribuire un modello per il conteggio delle code che sia accurato, a bassa latenza, che rispetti la sicurezza dei dati (S3 privato, KMS) e che funzioni su hardware edge con risorse limitate, consentendo al contempo un riaddestramento sicuro con nuovi dati etichettati.

Approccio Raccomandato:

Addestrare un rilevatore utilizzando un backbone MobileNetV3 pre-addestrato (in un container SageMaker PyTorch) affinato su bounding box etichettate con Ground Truth e archiviate in S3 con crittografia KMS; utilizzare suddivisioni raggruppate per negozio per evitare il data leakage.
Usare l’augmentation (ritaglio casuale, capovolgimento orizzontale, variazione di luminosità) e la focal loss per gestire lo sbilanciamento delle classi tra frame con coda e senza coda; validare con AP50 e recall per classe.
Esportare il modello in TorchScript/ONNX, compilarlo con SageMaker Neo per il dispositivo edge di destinazione e distribuirlo tramite AWS IoT Greengrass o SageMaker Edge Manager con firma del modello e un ruolo IAM che consenta l’accesso solo agli artefatti S3 necessari.
Monitorare le prestazioni con caricamenti batch periodici su S3, eseguire job di SageMaker Processing per il rilevamento del drift e riaddestrare in SageMaker utilizzando dataset versionati in S3 e Model Registry con un rollout controllato verso l’edge.

Logica: Questo approccio utilizza un transfer learning efficiente e una compilazione specifica per il dispositivo per soddisfare i vincoli di latenza e dimensione, garantisce la sicurezza tramite KMS e IAM e implementa un ciclo di riaddestramento monitorato per mantenere l’accuratezza prevenendo il data leakage.

← Modellazione — Supervisionata e non supervisionata (ML classico) · Tutti i domini · Elaborazione del linguaggio naturale e del parlato →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →