Amazon MLS-C01: Serie temporali e previsione — 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.

Selezione dell’algoritmo e quando utilizzare ciascun approccio

La scelta del modello di previsione corretto inizia dalla forma dei dati e dall’obiettivo. Gli approcci univariati classici come ARIMA/SARIMA rimangono la scelta giusta quando si ha una singola serie ben definita con uno storico lungo e termini stagionali interpretabili; è possibile implementarli in uno script di training di SageMaker utilizzando statsmodels o eseguire esperimenti in modo interattivo in SageMaker Studio. I modelli scomponibili in stile Prophet sono preziosi quando gli effetti delle festività legati al business e le molteplici stagionalità (giornaliera/settimanale/annuale) devono essere modellati e interpretati esplicitamente; questi vengono spesso prototipati in notebook e possono essere messi in produzione in SageMaker. Per la previsione probabilistica multi-serie su larga scala, utilizzare DeepAR (algoritmo integrato di SageMaker o DeepAR+ di Amazon Forecast) che apprende da serie storiche correlate e produce previsioni quantiliche. Le scelte di configurazione importanti includono l’impostazione di time_freq, prediction_length e context_length (tipicamente, context_length dovrebbe essere >= prediction_length), la scelta di una likelihood appropriata (studentT per le code pesanti, negative-binomial per i conteggi/domanda intermittente) e l’abilitazione di use_feat_dynamic_real o use_feat_static_cat per le covariate. Utilizzare i modelli classici quando sono richieste interpretabilità e diagnostica su singole serie; preferire DeepAR/Amazon Forecast quando si hanno molte serie correlate e si necessita di output probabilistici calibrati e di scalabilità integrata.

Preparazione dei dati: stagionalità, covariate e valori mancanti

Previsioni accurate richiedono un attento allineamento di timestamp, frequenza e covariate. Normalizzare sempre i timestamp a un fuso orario e a una frequenza coerenti (impostare time_freq per i modelli). Catturare la stagionalità nota e gli eventi di business aggiungendo indicatori di festività e feature per eventi speciali come covariate statiche o dinamiche; includere promozioni sui prezzi, aperture di negozi o flag di campagne come feature dinamiche. I valori mancanti devono essere gestiti con attenzione: per brevi interruzioni utilizzare l’interpolazione o il riempimento forward/backward; per interruzioni più lunghe utilizzare l’imputazione con approcci basati su modelli o mascherarli quando l’algoritmo supporta i valori mancanti (DeepAR accetta feature dinamiche mascherate). Per la domanda intermittente con molti zeri o conteggi sovradispersi, utilizzare la likelihood negative-binomial, sperimentare con l’aggregazione (ad es. settimanale) per ridurre la sparsità, o applicare un pre-processing basato sul metodo di Croston quando i metodi classici sono appropriati. Evitare di “trapelare” (leak) informazioni future nelle covariate: le feature dinamiche devono essere note o prevedibili per l’orizzonte di previsione. Memorizzare i metadati (item_id, category, store_id) come feature categoriche statiche per consentire ai modelli multi-serie di condividere le informazioni tra gli articoli.

Valutazione: metriche probabilistiche, backtesting e calibrazione

La previsione probabilistica richiede criteri di valutazione diversi rispetto alle previsioni puntuali. Utilizzare la quantile loss (pinball loss) e il continuous ranked probability score (CRPS) per valutare la qualità della distribuzione e riportare la copertura per i quantili chiave (ad es. P50, P90) per verificare la calibrazione degli intervalli. Evitare di fare affidamento esclusivamente sul MAPE per serie con zeri o domanda intermittente; utilizzare il Mean Absolute Scaled Error (MASE) per un confronto invariante alla scala o le weighted quantile loss per dare priorità agli SKU ad alto fatturato. Implementare la cross-validation di tipo rolling-origin (serie storiche) con finestre di backtest multiple per catturare l’instabilità temporale e la stagionalità, assicurandosi che ogni finestra rispetti i cicli stagionali in modo che i set di holdout contengano periodi stagionali completi. Verificare la calibrazione con i tassi di successo degli intervalli di previsione (prediction interval hit rates) e istogrammi di tipo PIT; se gli intervalli sono troppo stretti, considerare di aumentare num_eval_samples in DeepAR o di modificare le assunzioni sulla likelihood. Le trappole comuni includono l’utilizzo di covariate note nel futuro che non saranno disponibili al momento dell’inferenza, l’aggregazione che elimina la stagionalità critica e la valutazione su un singolo set di holdout statico che non cattura i cambiamenti di regime. Aggregare le metriche per serie in base all’importanza per il business piuttosto che con semplici medie, per riflettere l’impatto decisionale.

Scalabilità, pattern di deployment e criteri decisionali

La scalabilità delle previsioni a migliaia o milioni di serie e il loro deployment in produzione comportano dei compromessi a livello architetturale. Per una soluzione gestita e orientata alla scalabilità, Amazon Forecast gestisce gruppi di set di dati (serie temporali target, serie temporali correlate, metadati degli articoli), feature engineering automatizzato, backtesting integrato e predittori ospitati elastici per previsioni batch o esportabili; è la soluzione ideale quando si desidera un servizio che gestisca molte serie senza un training di modelli personalizzato. Per esigenze di modellazione personalizzata, si utilizza SageMaker con DeepAR (o modelli PyTorch/TF personalizzati) dove si ha il controllo su iperparametri, scelte di verosimiglianza (likelihood) e feature engineering; si esegue il training su istanze GPU per la velocità e si utilizza SageMaker Batch Transform per l’inferenza massiva (bulk) o endpoint in tempo reale per l’erogazione a bassa latenza. Per l’efficienza dei costi con molte versioni di modelli, si possono considerare endpoint multi-modello o pipeline batch asincrone attivate da eventi S3 o da Step Functions. I criteri decisionali includono la necessità di architetture personalizzate (scegliere SageMaker), la necessità di apprendimento cross-serie con operazioni minime (scegliere Forecast) e la richiesta di previsioni a bassa latenza per singole serie (privilegiare gli endpoint in tempo reale di SageMaker). Trappole comuni: sotto-provisioning di context_length, configurazione errata degli output dei quantili e mancata ponderazione della valutazione in base all’impatto sul business.

Problema Pratico: Scenario d’Uso

Scenario: Acme Retail gestisce 5.000 negozi e mantiene log giornalieri di vendite e promozioni in Amazon S3. Utilizzano SageMaker Studio per la data science e necessitano di previsioni di produzione scalabili per guidare l’inventario e le promozioni.

Sfida: Produrre previsioni probabilistiche della domanda a 30 giorni, calibrate per ogni coppia SKU-negozio, che tengano conto di festività e promozioni, gestiscano vendite nulle intermittenti per molti SKU e scalino per la produzione batch notturna.

Approccio Raccomandato:

Configurare le pipeline di dati: ingerire vendite e promozioni giornaliere in S3, catalogarle con AWS Glue ed esporle tramite Athena; creare file di dataset con timestamp, item_id, store_id, target_value e feature dinamiche.
Prototipare i modelli in SageMaker Studio: provare una scomposizione in stile Prophet per alcuni SKU rappresentativi, quindi addestrare SageMaker DeepAR (impostare time_freq='D', prediction_length=30, context_length=30–90, likelihood='negative-binomial' per i conteggi, num_eval_samples=100).
Per la scalabilità e la produzione: pianificare il training batch notturno o il retraining incrementale in SageMaker (o, in opzione, usare Amazon Forecast con gruppi di set di dati e predittori se si preferiscono previsioni gestite), e usare SageMaker Batch Transform o l’esportazione batch di Forecast per l’inferenza massiva notturna.
Valutare con backtest a origine mobile (rolling-origin) utilizzando la quantile loss e le metriche di copertura (P50/P90), e monitorare la calibrazione in tempo reale; se gli intervalli non coprono a sufficienza (under-cover), ottimizzare la likelihood o aumentare num_eval_samples.

Logica: L’uso di Glue/Athena e S3 standardizza l’accesso ai dati, DeepAR (o Forecast) modella nativamente molte serie correlate e produce i quantili necessari per le decisioni di inventario, la distribuzione binomiale negativa (negative-binomial) gestisce i conteggi intermittenti e la trasformazione batch (batch transform) consente una scalabilità notturna efficiente in termini di costi.

← Elaborazione del linguaggio naturale e del parlato · Tutti i domini · Addestramento →

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