Amazon MLS-C01: Analisi esplorativa dei dati e visualizzazione — 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.

Distribuzioni, trasformazioni e scaling delle feature

La comprensione delle distribuzioni delle feature grezze è il fondamento dell’EDA. Iniziate profilando ogni variabile con istogrammi, stime di densità kernel e sommari dei quantili in un notebook SageMaker Studio o in un job di SageMaker Processing (ml.m5.xlarge con scikit-learn/pandas). Le trasformazioni logaritmiche, Box-Cox, Yeo-Johnson e quelle basate sul rango (quantile transformer) sono appropriate per dati con asimmetria a destra (right-skewed), ma la Box-Cox richiede valori strettamente positivi e fallisce con gli zeri. Tra le trappole comuni vi sono l’applicazione di trasformazioni logaritmiche/Box-Cox senza compensare gli zeri e il dimenticare di invertire le trasformazioni quando si interpretano gli output del modello. La standardizzazione (media zero, varianza unitaria) è essenziale prima di metodi basati sulla distanza (k-means, PCA, SVM) e prima di modelli lineari regolarizzati; lo scaling Min-Max è utile per le reti neurali con attivazioni limitate. In fase di deployment, persistete i trasformatori in SageMaker Feature Store o come artefatti del modello, in modo che l’inferenza online e batch utilizzi una pre-elaborazione identica. Utilizzate AWS Glue o Glue DataBrew per profilare dataset S3 molto grandi e generare statistiche di riepilogo; usate Athena per interrogare campioni stratificati. I criteri decisionali dipendono dalla sensibilità dell’algoritmo: gli ensemble di alberi tollerano feature non scalate, mentre i metodi lineari e quelli basati sulla distanza no. Infine, verificate la presenza di outlier e code pesanti con statistiche robuste (mediana, IQR) e valutate se effettuare il clipping, il winsorizing o modellare separatamente (segmentazione) piuttosto che rimuovere ciecamente i punti.

Analisi dei residui, curve di apprendimento e test diagnostici

I residui rivelano una errata specificazione del modello (misspecification): media non nulla, eteroschedasticità, autocorrelazione o non linearità devono essere diagnosticate. Tracciate i grafici dei residui rispetto ai valori predetti e rispetto alle feature chiave in SageMaker Studio; calcolate il test di Durbin-Watson per l’autocorrelazione e usate il test di Ljung-Box per la correlazione dei residui nelle serie storiche. Per la regressione, cercate forme a imbuto che indicano eteroschedasticità; applicate trasformazioni per stabilizzare la varianza o modelli eteroschedastici (ad es., XGBoost con una funzione obiettivo modificata o forecasting probabilistico). Le curve di apprendimento — grafici dell’errore di training e di validazione rispetto alla dimensione del set di training — identificano un’alta varianza (overfitting) o un alto bias (underfitting). Utilizzate SageMaker Debugger per catturare i tensori per ogni epoca e le metriche di CloudWatch, e aggiungete un allarme CloudWatch che si attivi se la loss di validazione diverge mentre la loss di training diminuisce. Tra le trappole comuni vi sono l’uso della cross-validation casuale per dati temporali (usate suddivisioni basate sul tempo) e la valutazione con l’accuracy su set sbilanciati (preferite la precision-recall o l’AUC-PR). Per il tuning degli iperparametri, basate le decisioni su questa diagnostica: se il divario di validazione persiste, aumentate la regolarizzazione, aggiungete dati o riducete la complessità del modello; se entrambi gli errori sono alti, aumentate la capacità o aggiungete feature. Persistete i grafici diagnostici e le metriche tramite SageMaker Experiments per la riproducibilità.

Riduzione della dimensionalità, PCA, autoanalisi e clustering

La riduzione della dimensionalità riduce il rumore e migliora l’interpretabilità. Applicate la PCA o la SVD randomizzata (scikit-learn o Spark MLlib su EMR/Glue) dopo lo scaling; ispezionate il rapporto della varianza spiegata (explained variance ratio) per scegliere il numero di componenti ed esaminate i loadings per mappare le componenti alle feature originali. I segni degli autovettori (eigenvector) sono arbitrari: interpretate i loadings in valore assoluto e raggruppate le feature per magnitudine. Per strutture altamente non lineari, usate t-SNE o UMAP solo per la visualizzazione, non come pre-elaborazione per i modelli senza un’attenta cross-validation. Per il clustering, scegliete k-means per cluster sferici (richiede lo scaling), Gaussian Mixture Models per assegnazioni soft e DBSCAN per forme basate sulla densità; eseguite il calcolo dei silhouette score e dell’indice di Davies-Bouldin per confrontarli. Su dataset di grandi dimensioni, utilizzate l’algoritmo k-means integrato di SageMaker (istanze GPU/CPU) o eseguite il mini-batch k-means in SageMaker Processing. Attenzione alla trappola di applicare la PCA a feature categoriche codificate con one-hot encoding: considerate il feature hashing o i layer di embedding. Utilizzate i grafici a gomito (elbow plot), i grafici della varianza spiegata e la stabilità dei cluster tra sottocampioni per decidere il valore di k. Persistete i centroidi dei cluster e i trasformatori PCA in SageMaker Feature Store in modo che lo scoring in tempo reale e i modelli basati su segmenti a valle utilizzino trasformazioni coerenti.

Visualizzazione, monitoraggio e integrazione AWS per drift e performance

La visualizzazione è sia esplorativa che operativa: utilizzare matplotlib/seaborn in SageMaker Studio per grafici ad-hoc e Amazon QuickSight per dashboard che tracciano le metriche di performance in tempo reale. Per il drift del modello e la qualità dei dati, stabilire delle baseline con un campione di training rappresentativo tramite SageMaker Model Monitor e SageMaker Clarify per rilevare scostamenti distribuzionali (distributional shifts), cambiamenti nell’importanza delle feature e bias. Configurare Model Monitor con una baseline derivata da un artefatto di un Processing job e abilitare il monitoraggio continuo sugli endpoint distribuiti con controlli orari/giornalieri; gli eventi CloudWatch e SNS possono attivare allarmi. Per l’ingestion e l’analisi in streaming, utilizzare Kinesis Data Firehose per salvare i dati JSON su S3 con conversione di formato in Parquet (abilitare la conversione del formato dei record e l’integrazione con il Glue Catalog) o collegare una funzione Lambda per trasformazioni personalizzate. Per query SQL near-real-time su file compressi, partizionare e registrare i dati nel Glue Data Catalog ed eseguire query con Athena, aggiornando le partizioni tramite una Lambda all’arrivo di nuovi oggetti S3. Le trappole comuni includono la mancata versionatura delle baseline, l’ignorare l’evoluzione dello schema (utilizzare Glue Schema Registry) e l’affidarsi esclusivamente a metriche aggregate — includere sempre il drift per singola feature e le performance per segmento per rilevare un degrado localizzato. Utilizzare SageMaker Experiments e Model Monitor insieme per correlare le modifiche degli iperparametri con gli eventi di drift e mantenere la lineage.

Problema pratico: scenario d’uso

Scenario: Acme Retailer utilizza lo stack ML di AWS con SageMaker Studio, un data lake su S3, ingestion tramite Kinesis Firehose, Glue Data Catalog e QuickSight per la visualizzazione. Il team archivia i dati demografici dei clienti, i log di sessione e gli acquisti in S3 come JSON e Parquet.

Sfida: Identificare i segmenti di clienti con la più alta probabilità di abbandono (churn) nei prossimi sei mesi e implementare un monitoraggio per rilevare se le distribuzioni delle feature o le performance del modello subiscono un drift dopo la distribuzione (deployment).

Approccio raccomandato:

1. Creare un SageMaker Processing job (ml.m5.xlarge) per campionare e profilare i dati usando pandas/sklearn, applicare trasformazioni logaritmiche/Box-Cox dove appropriato, e registrare gli artefatti di pre-elaborazione in SageMaker Feature Store.
2. Calcolare la PCA (scikit-learn o Spark ML su Glue/EMR) dopo lo scaling per ridurre la dimensionalità, esaminare la varianza spiegata e i loadings, ed eseguire il clustering con SageMaker xgboost o il k-means integrato per derivare i segmenti.
3. Addestrare un modello di classificazione (XGBoost in SageMaker o una piccola rete neurale in TensorFlow) usando suddivisioni train/validation basate sul tempo (time-aware), registrare le metriche su SageMaker Experiments, e impostare l’early stopping e il class-weighting per gestire lo sbilanciamento delle classi.
4. Eseguire il deployment con un SageMaker Endpoint, abilitare Model Monitor usando una baseline generata dal Processing job, configurare controlli di drift orari e allarmi CloudWatch per le notifiche via SNS; visualizzare le performance a livello di segmento e il drift in QuickSight.

Logica: Questo approccio combina una pre-elaborazione robusta, una riduzione della dimensionalità interpretabile e un clustering scalabile per la segmentazione, mentre SageMaker Model Monitor e QuickSight forniscono il rilevamento operativo del drift dei dati e delle performance, garantendo una pre-elaborazione riproducibile tramite Feature Store e esperimenti tracciati per l’analisi delle cause alla radice (root-cause analysis).

← Ingegneria dei dati e ingegneria delle feature · Tutti i domini · Modellazione — Supervisionata e non supervisionata (ML classico) →

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

Sfoglia Amazon →