Amazon MLA-C01: Visione artificiale, NLP e ML specializzato — Guida allo studio

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

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

Concetto fondamentale

Le soluzioni di computer vision e NLP in AWS ruotano attorno a tre aree di interesse stratificate: ingestion e sicurezza dei dati, preparazione delle feature e delle etichette, e ciclo di vita del modello (addestramento, registro, deployment, monitoraggio). Per la classificazione di immagini e il rilevamento di oggetti, i flussi di lavoro di addestramento si concentrano sull’archiviazione di asset etichettati in Amazon S3 con crittografia robusta e controlli di rete rigorosi, formati di annotazione come Pascal VOC / COCO per il rilevamento di oggetti e RecordIO o TFRecord per l’addestramento ad alto throughput. Per la classificazione del testo e il riconoscimento di entità nominate (NER), gli input sono comunemente sequenze tokenizzate (WordPiece/BPE per i modelli transformer) o JSON delimitato da righe con etichette; la pre-elaborazione deve preservare gli offset da token a carattere quando si utilizzano output di Rekognition Textract o intervalli etichettati manualmente, in modo che l’allineamento delle etichette NER sia coerente. La feature engineering per modelli tabulari antifrode si concentra sull’aggregazione su finestre temporali, sulla riduzione della cardinalità categorica e su una codifica coerente tra addestramento e inferenza (serving); l’utilizzo di una trasformazione centralizzata (un flusso di Feature Store o Data Wrangler) previene lo skew tra l’addestramento offline e l’inferenza online.

Le scelte per la creazione di modelli corrispondono a servizi AWS specializzati: Amazon SageMaker offre algoritmi integrati (XGBoost, Linear Learner, Random Cut Forest) e container gestiti per framework (MXNet, TensorFlow, PyTorch), oltre a SageMaker Clarify per l’analisi di bias e spiegabilità. Amazon Rekognition copre API di immagine pre-addestrate per l’etichettatura, il rilevamento di volti/celebrità e l’addestramento di etichette personalizzate tramite Rekognition Custom Labels quando è richiesto un basso carico operativo. Per l’estrazione di testo e dati strutturati da documenti, Amazon Textract fornisce OCR ed estrazione di moduli/tabelle; per attività a livello di linguaggio come sentiment analysis, riconoscimento di entità o topic modeling, Amazon Comprehend fornisce API gestite e Comprehend Medical per il NER clinico. È fondamentale per la produzione collegare questi componenti in una pipeline coerente, in modo che la pre-elaborazione, gli input del modello e il monitoraggio siano riproducibili e auditabili.

Servizi e configurazioni chiave

I servizi AWS principali e i relativi parametri API/di configurazione da conoscere sono Amazon SageMaker (TrainingJob, ModelPackage, ModelPackageGroup, ModelRegistry), SageMaker Pipelines (RegisterModel, CallbackStep, ConditionStep), SageMaker Model Monitor e Clarify (BaselineConfig, DataConfig, ModelConfig, bias_config), Amazon Rekognition, Amazon Comprehend, Amazon Textract, AWS Glue e Lake Formation. Per uno storage sicuro e isolato, configurare S3 con crittografia lato server utilizzando SSE-KMS (S3.PutBucketEncryption con SSEKMSKeyId), associare policy del bucket che limitano l’accesso al ruolo di esecuzione di SageMaker e abilitare un endpoint VPC di tipo Gateway per S3 per i trasferimenti su rete privata. Quando si avviano i processi di addestramento, impostare il parametro VpcConfig (SecurityGroupIds e Subnets) in CreateTrainingJob in modo che le istanze vengano eseguite nel VPC del cliente, e abilitare NetworkIsolation e InstanceMetadataServiceConfiguration per limitare l’accesso.

Per gestire centralmente i modelli con un carico operativo minimo, utilizzare il SageMaker Model Registry creando un ModelPackageGroup e aggiungendo versioni di ModelPackage con ModelApprovalStatus impostato su ‘PendingManualApproval’ tramite CreateModelPackage. Automatizzare un gate di approvazione manuale aggiungendo un CallbackStep o uno step dedicato “ManualApproval” in SageMaker Pipelines; la pipeline attende un segnale esterno, dopodiché si chiama UpdateModelPackage per impostare ModelApprovalStatus=‘Approved’ per il deployment. Per valutazioni on-demand di bias o drift degli endpoint in tempo reale distribuiti, usare SageMaker Clarify per le metriche di bias e SageMaker Model Monitor per il drift dei dati e delle previsioni: catturare i payload di inferenza abilitando DataCaptureConfig in CreateEndpoint (EnableCapture, CaptureOptions, DestinationS3Uri), e quindi avviare un processo di elaborazione Clarify tramite CreateProcessingJob con i parametri SDK di Clarify DataConfig, ModelConfig e bias_config per calcolare immediatamente le metriche di drift.

I servizi rilevanti includono:

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 e AWS Lake Formation (Crawlers, Jobs, Data Catalog)
Amazon Lookout for Metrics e Amazon QuickSight per la visualizzazione delle anomalie

Pattern di progettazione e compromessi

Per la classificazione tabellare come il rilevamento delle frodi, il pattern di progettazione pratico consiste nel centralizzare le fonti grezze in un data lake S3 sicuro utilizzando AWS Glue o DMS per le tabelle relazionali, catalogarle in Glue Data Catalog e imporre l’accesso tramite Lake Formation. Le trasformazioni vengono espresse una sola volta nei flussi di SageMaker Data Wrangler o come processi ETL di Glue e rese persistenti in SageMaker Feature Store, in modo che le stesse trasformazioni vengano eseguite sia in fase di training che di inferenza. La scelta del Feature Store aggiunge passaggi operativi iniziali ma riduce lo skew e i tempi di debug; le trasformazioni dirette all’interno del processo hanno un overhead iniziale inferiore ma rendono più difficili la riproducibilità e il calcolo delle feature online. Per gli algoritmi di training, XGBoost (container fornito da SageMaker) è un’ottima scelta predefinita per il rilevamento delle frodi grazie alle sue prestazioni su dati tabellari e al supporto per le colonne di peso; configurare gli iperparametri usando HyperParameters in CreateTrainingJob e passare una colonna di peso o impostare scale_pos_weight per contrastare lo sbilanciamento delle classi, il che evita pipeline di ricampionamento più complesse.

Per la computer vision, se è necessaria un’iterazione rapida e i dati etichettati sono limitati, Rekognition Custom Labels offre il percorso più veloce con operazioni minime; per il massimo controllo e architetture personalizzate, utilizzare il training di SageMaker con MXNet/PyTorch e archiviare i set di dati in formato RecordIO o ImageFolder su S3. Per l’object detection, preferire il training con framework che producono l’output in formato COCO e sfruttare il training distribuito di SageMaker specificando InstanceType=ml.p3.2xlarge o superiore e impostando la configurazione MPI o horovod in AlgorithmSpecification e TrainingInputMode del TrainingJob. I compromessi includono il throughput rispetto al costo: i processi batch che utilizzano istanze spot gestite riducono i costi ma aggiungono latenza/rischio di terminazione; il caching delle pipeline in SageMaker Pipelines riduce l’avvio ripetuto di passaggi quando gli input non cambiano, il che minimizza i tempi di avvio non necessari delle risorse di calcolo.

Errori comuni e criteri decisionali

Un errore frequente è la mancata centralizzazione degli artefatti di pre-elaborazione. Se la tokenizzazione, la mappatura delle etichette per il NER o gli encoder categoriali vengono applicati in modo diverso durante l’addestramento e l’inferenza, si introducono errori di previsione difficili da tracciare. Utilizzare Feature Store o persistere l’artefatto di pre-elaborazione (tokenizer, vocab.json, label_map) con il pacchetto del modello nel Model Registry, in modo che il container distribuito recuperi e applichi le trasformazioni esatte. Un altro errore comune è l’acquisizione insufficiente di dati per il monitoraggio: senza abilitare DataCaptureConfig sull’endpoint e un flusso di lavoro adeguato per l’etichettatura ground-truth, Model Monitor non può calcolare le metriche di drift o di qualità, e chiarire i cali nel punteggio F1 diventa un’ipotesi. Per lo sbilanciamento delle classi, la soluzione meno intensiva dal punto di vista operativo è utilizzare la ponderazione supportata dall’algoritmo (ad esempio l’iperparametro scale_pos_weight di XGBoost o fornire una colonna di pesi nei dati di addestramento) piuttosto che un upsampling/downsampling indiscriminato, che può introdurre bias di campionamento.

Problema Pratico: Scenario d’Uso

Azienda: MeridianPay. MeridianPay deve costruire una pipeline di rilevamento frodi in tempo reale che combini i log delle transazioni in S3 e i profili dei clienti in un database MySQL on-premise. I requisiti includono uno storage sicuro e isolato, un registro centrale dei modelli con approvazione manuale, latenza di avvio minima tra esecuzioni di addestramento consecutive, rilevamento automatico delle anomalie e visualizzazione dopo l’aggregazione, supporto per feature miste (categoriali e numeriche) con operazioni minime, gestione dello sbilanciamento delle classi e un modello di produzione che possa essere monitorato on-demand per drift e bias.

Aggregare e proteggere i dati: utilizzare AWS DMS per replicare continuamente le tabelle del database MySQL on-premise in una landing zone S3 crittografata, eseguire i crawler di AWS Glue e registrare le tabelle risultanti in AWS Glue Data Catalog. Applicare l’accesso tramite AWS Lake Formation e le policy dei bucket S3; abilitare un Gateway VPC Endpoint per S3 e configurare il ruolo di esecuzione di SageMaker con i privilegi minimi (least-privilege) IAM. Utilizzare SSE-KMS su S3 con una chiave KMS gestita dal cliente (customer-managed) e impostare BucketEncryption con il KmsMasterKeyId.
Trasformare e archiviare le feature: creare le trasformazioni in SageMaker Data Wrangler o in un job ETL di Glue, persistere le feature derivate nell’online store di Amazon SageMaker Feature Store per ricerche a bassa latenza durante l’inferenza e nell’offline store per l’addestramento. Archivia gli artefatti del tokenizzatore/encoder insieme agli artefatti del modello. Utilizzare le API FeatureGroup per creare i gruppi di feature e configurare RecordIdentifierFeatureName e EventTimeFeatureName per garantire la correttezza point-in-time.
Addestrare con un sovraccarico operativo minimo: utilizzare il container predefinito di SageMaker XGBoost creando un CreateTrainingJob con AlgorithmSpecification che punta all’URI del container XGBoost, specificare VpcConfig per l’esecuzione nel VPC, passare gli HyperParameters includendo "objective":"binary:logistic" e impostare "scale_pos_weight" sul rapporto tra esempi negativi e positivi per gestire lo sbilanciamento delle classi. Per ridurre la latenza di avvio ripetuta, implementare SageMaker Pipelines e abilitare la cache per gli step di preparazione dei dati, in modo che le esecuzioni consecutive della pipeline saltino gli step non modificati; utilizzare ricerche persistenti nel feature store anziché rielaborare i dati quando possibile.
Registro dei modelli e approvazione manuale: registrare i modelli addestrati in un ModelPackageGroup tramite CreateModelPackage con ModelApprovalStatus='PendingManualApproval'. Integrare un CallbackStep di SageMaker Pipelines che mette in pausa la pipeline dopo RegisterModel; i revisori chiamano quindi UpdateModelPackage per impostare ModelApprovalStatus='Approved'. Utilizzare questo pacchetto approvato per le configurazioni di CreateModel e CreateEndpoint.
Rilevamento anomalie e visualizzazione: dopo l’aggregazione, utilizzare Amazon Lookout for Metrics per eseguire il rilevamento automatico delle anomalie sugli aggregati di transazioni time-series e configurare le integrazioni con S3/Glue. Per la visualizzazione, collegare i risultati di Lookout e i dati in dashboard QuickSight o utilizzare i notebook di SageMaker Studio per visualizzare il drift delle feature. Per la valutazione on-demand di bias/drift degli endpoint distribuiti, abilitare DataCaptureConfig in CreateEndpoint ed eseguire un job di elaborazione on-demand di SageMaker Clarify (CreateProcessingJob) con DataConfig e ModelConfig che puntano ai dati acquisiti; utilizzare Model Monitor/CreateMonitoringSchedule per pianificare controlli ricorrenti e per attivare un’esecuzione una tantum con StartMonitoringSchedule.

Logica: questo approccio centralizza dati e trasformazioni, utilizza servizi gestiti dove riducono l’onere operativo (Glue/DMS/Lookout/Comprehend/Textract per i loro domini), sfrutta SageMaker Model Registry e Pipelines per il versioning e l’approvazione manuale con un’infrastruttura personalizzata minima, risolve lo sbilanciamento delle classi tramite i parametri dell’algoritmo per evitare un pesante ricampionamento, e fornisce valutazioni di bias/drift sia pianificate che on-demand tramite Model Monitor e Clarify, mantenendo i dati crittografati e isolati a livello di rete.

← Ottimizzazione dei costi per carichi di lavoro ML · Tutti i domini

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