Amazon MLA-C01: Valutazione e selezione del modello — 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.

Una valutazione accurata del modello inizia con la selezione di metriche che corrispondono all’obiettivo di business e alle caratteristiche delle classi/etichette. Per la classificazione binaria, la matrice di confusione — veri positivi, falsi positivi, falsi negativi, veri negativi — è la primitiva canonica da cui derivano la precision (TP / (TP+FP)), il recall o sensitività (TP / (TP+FN)), la specificità (TN / (TN+FP)) e l’accuratezza ((TP+TN) / totale). Precision e recall costituiscono un trade-off che viene catturato nel punteggio F1 (2 * precision * recall / (precision + recall)), che è la media armonica ed enfatizza l’equilibrio tra falsi positivi e falsi negativi. Quando lo squilibrio tra le classi è grave, l’accuratezza può essere fuorviante; l’area sotto la curva ROC (AUC) misura la separabilità tra le soglie ed è robusta allo squilibrio in molti casi, mentre l’AUC precision-recall (AUPRC) è più informativa quando la prevalenza della classe positiva è bassa. Per la regressione, l’errore quadratico medio (RMSE) penalizza quadraticamente gli errori più grandi ed è sensibile agli outlier; utilizzare l’errore assoluto medio (MAE) quando si preferisce la robustezza agli outlier.

La selezione della soglia è una decisione operativa: molti algoritmi producono un punteggio di probabilità e richiedono una soglia per convertirlo in etichette di classe. Utilizzare le curve ROC e precision-recall per individuare le soglie che massimizzano un obiettivo scelto, come l’F1 o una funzione di costo ponderata in base al business. Una metodologia pratica consiste nel calcolare precision, recall e F1 per ogni soglia dalla matrice di confusione e quindi scegliere la soglia che soddisfa un vincolo target di precision o recall. La cross-validation integra questo approccio riducendo la varianza nelle stime delle metriche: utilizzare la K-fold stratificata per la classificazione sbilanciata per preservare le proporzioni delle classi tra i fold. Nel codice, StratifiedKFold di scikit-learn con n_splits e shuffle=True più un random_state fisso fornisce fold riproducibili; registrare le metriche per fold e aggregare medie e deviazioni standard per quantificare la varianza attesa. Quando si utilizza SageMaker, è possibile orchestrare le esecuzioni di CV come job di addestramento separati e tracciarle con le API di SageMaker Experiments: CreateExperiment, CreateTrial, CreateTrialComponent, e poi LogMetric e LogHyperParameter per ogni fold.

Il trade-off bias-varianza guida la complessità del modello e le scelte di regolarizzazione. I modelli ad alto bias soffrono di underfitting e producono un errore elevato sia sul set di addestramento che su quello di validazione, mentre i modelli ad alta varianza soffrono di overfitting e hanno un basso errore di addestramento ma un alto errore di validazione. Per rimediare al bias, aumentare la capacità del modello, aggiungere feature informative o ridurre l’intensità della regolarizzazione; per rimediare alla varianza, aggiungere regolarizzazione (L1/L2), ridurre la complessità, usare il dropout o aumentare i dati di addestramento. Utilizzare le stime della cross-validation per rilevare la varianza: un’ampia dispersione delle metriche tra i fold implica un’alta varianza. Per l’addestramento iterativo su SageMaker, incorporare l’early stopping (per XGBoost impostare l’iperparametro early_stopping_rounds e eval_metric=‘auc’ o ’error’) e utilizzare SageMaker Automatic Model Tuning con una strategia bayesiana per esplorare l’hyperparameter_space; configurare HyperparameterTuner con objective_metric_name, objective_type=‘Maximize’ o ‘Minimize’, hyperparameter_ranges, max_jobs e max_parallel_jobs.

Servizi e configurazioni chiave

I servizi AWS formano una toolchain strettamente integrata per tracciare esperimenti, registrare modelli, rilevare il drift e applicare guardrail di implementazione. Utilizzare Amazon SageMaker Experiments per organizzare le esecuzioni; chiamare sagemaker.create_experiment, sagemaker.create_trial e sagemaker.log_metric per persistere iperparametri e metriche. Per la gestione centralizzata del ciclo di vita del modello, utilizzare SageMaker Model Registry (ModelPackageGroup e ModelPackage) e controllare il flusso di deployment attraverso l’attributo del pacchetto modello ModelPackageApprovalStatus che supporta valori come “PendingManualApproval”, “Approved” e “Rejected”. Integrare le approvazioni manuali in un flusso CI/CD invocando UpdateModelPackage per cambiare l’approval_status da una AWS Lambda o da un’azione di approvazione umana di Step Functions.

Per il monitoraggio post-deployment e il rilevamento di bias/drift, utilizzare SageMaker Model Monitor e SageMaker Clarify. Abilitare l’acquisizione di dati in tempo reale su un endpoint impostando DataCaptureConfig nella chiamata CreateEndpointConfig o UpdateEndpointConfig; specificare CaptureOptions: [{“CaptureMode”:“Input”}, {“CaptureMode”:“Output”}], DestinationS3Uri e SamplingPercentage per raccogliere payload rappresentativi. Utilizzare Model Monitor DefaultModelMonitor per generare una baseline (GenerateBaseline) (JSON baseline_statistics e baseline_constraints) da un dataset di riferimento e poi creare una pianificazione di monitoraggio con create_monitoring_schedule, fornendo una MonitoringScheduleConfig, una schedule_expression (cron o rate) e MonitoringInputs come EndpointInput con local_path e S3InputMode. Per l’equità (fairness) e il bias, utilizzare SageMaker Clarify come ProcessingJob con i parametri clarify_config compute_bias e compute_data_drift, oppure utilizzare il builtin SageMaker Clarify in un job di Processing e salvare i risultati su S3 per le dashboard.

Diverse funzionalità AWS sono comunemente utilizzate insieme per l’aggregazione dei dati, la preparazione delle feature e il rilevamento delle anomalie:

Amazon S3 per lo storage e l’isolamento sicuro (policy dei bucket, S3 Block Public Access e crittografia KMS tramite SSE-KMS).
AWS Glue e AWS Glue Data Catalog per scoprire, unificare e catalogare set di dati da sorgenti S3 e JDBC.
Amazon SageMaker Data Wrangler per trasformazioni drag-and-drop e visualizzazione automatica di distribuzioni, valori mancanti e asimmetria.
Amazon SageMaker Feature Store per il serving di feature online e offline con le API PutRecord e GetRecord e per la coerenza delle feature tra addestramento e inferenza (serving).
SageMaker Model Monitor e SageMaker Clarify per il drift, il bias e il monitoraggio.
Amazon Lookout for Metrics per il rilevamento automatico di anomalie nelle serie temporali, dove appropriato.

Pattern di progettazione e trade-off

Quando l’overhead operativo deve essere ridotto al minimo, è preferibile utilizzare servizi gestiti e funzionalità degli algoritmi integrati piuttosto che creare pipeline ETL o di monitoraggio personalizzate. Ad esempio, per l’addestramento di un classificatore binario per il rilevamento di frodi, XGBoost è una scelta integrata ed efficiente in SageMaker che offre un addestramento a bassa latenza e iperparametri specifici per lo sbilanciamento, come scale_pos_weight, che dovrebbe essere impostato su (num_negative / num_positive). Configura gli iperparametri di XGBoost nell’Estimator o nel container di addestramento: objective='binary:logistic', eval_metric='aucpr' o 'auc', e early_stopping_rounds per terminare le esecuzioni anomale. Questo evita di dover creare pipeline di oversampling personalizzate (SMOTE), a meno che non sia richiesto un campionamento sintetico specifico del dominio.

Per la feature engineering, utilizza SageMaker Data Wrangler per applicare trasformazioni di codifica (one-hot per le feature categoriche a bassa cardinalità, codifica ordinale/label o target encoding per le feature ad alta cardinalità) e poi materializzare le feature pulite in SageMaker Feature Store o S3. Data Wrangler elimina gran parte del carico operativo e produce script o processi di elaborazione (processing jobs) che puoi riutilizzare. Se hai bisogno di una selezione automatizzata del modello con il minimo sforzo, SageMaker Autopilot può pre-elaborare automaticamente feature categoriche e numeriche miste e generare modelli candidati; tuttavia, Autopilot astrae le trasformazioni e potrebbe non essere ottimale per regimi di feature personalizzati.

Il confronto e la promozione dei modelli sono più robusti quando metriche, artefatti e lineage vengono registrati. Usa SageMaker Experiments per confrontare le esecuzioni (runs), quindi crea un ModelPackage in un ModelPackageGroup. Promuovi il modello impostando ModelPackageApprovalStatus su “Approved” e produci un EndpointConfig che faccia riferimento all’ARN del pacchetto del modello. Laddove è richiesto un controllo umano, lascia il modello in stato “PendingManualApproval” e orchestra un flusso di lavoro di approvazione umana utilizzando Step Functions o AWS CodePipeline con un’azione di approvazione che chiami UpdateModelPackage per spostarlo in “Approved”.

Errori comuni e criteri decisionali

Un errore comune è confondere un calo del punteggio F1 in produzione con un difetto del modello, quando il problema di fondo è il data drift. La causa più probabile di un calo prolungato del punteggio F1 mesi dopo il deployment è una deriva nella distribuzione degli input o una deriva delle etichette (concept drift), piuttosto che un bug improvviso. Per diagnosticare il problema, abilita DataCaptureConfig sull’endpoint per catturare i payload di richiesta e risposta su S3, esegui le pianificazioni di monitoraggio di Model Monitor rispetto ai vincoli di baseline e calcola le statistiche di distribuzione delle feature e il PSI (population stability index). Esegui anche i controlli di data drift e bias di Clarify per rilevare cambiamenti che influenzano le metriche di equità (fairness).

Un altro errore frequente è la gestione errata dello sbilanciamento delle classi, ricampionando ingenuamente senza tenere conto del leakage temporale o dei costi di business. È preferibile utilizzare prima i controlli a livello di algoritmo — per XGBoost, imposta scale_pos_weight e ottimizza eval_metric su aucpr o un obiettivo personalizzato — prima di passare a strategie di campionamento che possono introdurre esempi duplicati. Per la riproducibilità e il tracciamento degli esperimenti, utilizza sempre le API di SageMaker Experiments per registrare iperparametri e metriche, e registra i pacchetti di modelli con gli URI degli artefatti e i metadati di provenienza, in modo che le promozioni siano verificabili.

Problema pratico: scenario d’uso

Azienda: FinSight Inc. — rilevamento di frodi per transazioni online con dati in Amazon S3 e MySQL on-premise. Requisiti: isolamento sicuro dei dati, rilevamento e visualizzazione automatizzati delle anomalie, approvazione manuale prima del deployment in produzione, bassa latenza di avvio per l’addestramento iterativo e versioning centralizzato dei modelli con un overhead operativo minimo.

Aggregazione e sicurezza dei dati: Utilizzare AWS Glue per eseguire il crawling dei log delle transazioni in S3 e creare tabelle nel Glue Catalog, impostare la crittografia del bucket con SSE-KMS e limitare l’accesso tramite policy IAM e VPC endpoint. Per il MySQL on-premise, utilizzare una connessione JDBC di AWS Glue all’interno di un VPC con una VPN sicura o AWS Direct Connect, oppure usare AWS DMS per replicare le tabelle necessarie in una landing zone su S3. Registrare i set di dati nel Glue Data Catalog e concedere ai ruoli di esecuzione di SageMaker l’accesso con il principio del privilegio minimo (least-privilege).
Preparazione delle feature e rilevamento delle anomalie: Utilizzare Amazon SageMaker Data Wrangler per connettersi al Glue Catalog e alla landing zone S3, applicare trasformazioni (imputazione di valori mancanti, label encoding per variabili categoriche, scaling per quelle numeriche) ed eseguire il profiling integrato di Data Wrangler per visualizzare le distribuzioni e segnalare le anomalie. Esportare le feature elaborate nell’offline store di SageMaker Feature Store per l’addestramento e nell’online store per ricerche a bassa latenza durante l’inferenza.
Addestramento del modello e minimizzazione della latenza di avvio: Utilizzare SageMaker Estimator per XGBoost con objective='binary:logistic', eval_metric='aucpr' e impostare scale_pos_weight=(neg_count/pos_count). Per ridurre la latenza di avvio tra i job di addestramento iterativi, memorizzare nella cache gli output di Data Wrangler in S3 e riutilizzare la stessa immagine del container di addestramento e lo stesso tipo di istanza, invece di ricostruire ogni volta l’ingestion dei dati; utilizzare SageMaker Pipelines con cache_config abilitato in modo che i passaggi ripetuti con input/iperparametri invariati saltino l’avvio dell’infrastruttura.
Tracciamento degli esperimenti e selezione del modello: Strumentare ogni esecuzione di addestramento con SageMaker Experiments (CreateExperiment, CreateTrial, LogMetric). Utilizzare HyperparameterTuner configurato con objective_metric_name='validation:aucpr', objective_type='Maximize', strategy='Bayesian', max_jobs e max_parallel_jobs per trovare i migliori iperparametri. Confrontare i modelli in Experiments e registrare i candidati scelti nel SageMaker Model Registry creando un ModelPackage in un ModelPackageGroup.
Approvazione manuale e controllo del deployment: Lasciare i pacchetti di modelli appena creati nello stato ModelPackageApprovalStatus='PendingManualApproval'. Utilizzare un flusso di lavoro di AWS Step Functions con un task di approvazione umana o un’azione di approvazione di AWS CodePipeline; una volta approvato, eseguire UpdateModelPackage per impostare l’approvazione su ‘Approved’ e attivare la creazione automatica di un EndpointConfig e l’esecuzione di UpdateEndpoint per effettuare il deployment.
Monitoraggio, bias e drift: Abilitare DataCaptureConfig sull’endpoint in tempo reale con CaptureOptions per Input e Output, DestinationS3Uri e SamplingPercentage. Generare statistiche di baseline con GenerateBaseline di Model Monitor a partire dal set di dati di addestramento e pianificare il monitoraggio continuo con create_monitoring_schedule. Eseguire regolarmente SageMaker Clarify come processing job per calcolare le metriche di bias e data drift. Se il punteggio F1 scende al di sotto dei vincoli di baseline, utilizzare gli allarmi di Model Monitor per attivare una pipeline di riaddestramento automatizzata (SageMaker Pipeline) che registra le nuove esecuzioni in Experiments e produce nuovi pacchetti di modelli per la revisione umana.

Logica della scelta di AWS: Questo approccio utilizza le funzionalità gestite di SageMaker: Data Wrangler e Feature Store per minimizzare l’overhead di pre-elaborazione, XGBoost con scale_pos_weight per gestire lo sbilanciamento senza complessi ricampionamenti, SageMaker Experiments e Model Registry per una gestione verificabile del ciclo di vita degli esperimenti e dei modelli, DataCaptureConfig insieme a Model Monitor e Clarify per il rilevamento automatizzato di drift ed equità (fairness), e Step Functions/CodePipeline integrati con Model Registry per fornire il gate di approvazione manuale richiesto. Questi servizi, insieme, minimizzano l’onere operativo preservando al contempo la sicurezza, la tracciabilità e la capacità di rispondere al degrado del modello.

← Addestramento del modello e ottimizzazione degli iperparametri · Tutti i domini · Deployment del modello e inferenza →

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