AutoML for classification, regression, and forecasting

Nel binario dei sistemi LLM e AI applicati ai dati, l’AutoML è tra gli strumenti più promettenti e più fraintesi. La promessa è allettante: carichi una tabella, dichiari il target, ottieni in qualche ora una leaderboard di modelli già ottimizzati, comprimendo settimane di modellazione. Ma la promessa è vera solo a metà. Quello che AutoML automatizza bene è la ricerca meccanica — preprocessing candidati, famiglie di modelli, iperparametri — mentre lascia a te le due parti che decidono se il progetto regge: formulare il problema in modo che il target esista davvero al momento della predizione, e verificare che la metrica ottimizzata corrisponda alla decisione di business. Chi salta questi due passaggi ottiene un punteggio alto in laboratorio e un modello inutile in produzione.

Il cuore della questione

Questa lezione decide quando la ricerca automatica basta, quando serve modellazione su misura e quando il problema non è modellabile, con il vincolo che lo split replica sempre l’uso reale e la metrica segue il costo dell’errore.

La sequenza di lavoro

Ecco come si procede per usare AutoML senza farsi ingannare.

1. Verifica che il target esista al momento della predizione e che le etichette siano pulite e numerose.
2. Imponi lo split corretto prima del primo run: temporale con avanzamento per serie storiche, per gruppi quando la stessa entità genera più righe.
3. Lancia la baseline onesta e prosegui solo se la ricerca automatica la batte di un margine che copre costi e complessità.
4. Valuta per segmento e per passo di orizzonte, verifica la calibrazione e tara la soglia sul costo atteso.
5. Esegui i controlli anti-leakage su colonne sospette, disgiunzione delle entità e trasformazioni stimate sul solo training.
6. Esporta l’intera pipeline versionata, logga input e predizioni dal giorno uno e definisci soglie di allarme con rollback pronto.

Quando AutoML è la scelta giusta e quando no

La domanda utile non è “AutoML o custom”, ma “quanta struttura specifica del problema devo iniettare perché il modello generalizzi”. AutoML eccelle quando il segnale sta nelle interazioni standard tra colonne tabulari, il dataset ha almeno qualche migliaio di righe etichettate in modo pulito, e la funzione di perdita del tool è allineata alla decisione. Classificazione binaria su churn, propensione, scoring lead, regressione su prezzi o tempi di consegna con feature statiche: qui la ricerca automatica su gradient boosting, foreste ed ensembling copre quasi tutto lo spazio sensato, e il tuo tempo rende di più su definizione del target e qualità delle label che su tuning manuale.

Il custom modeling diventa necessario quando il problema ha struttura che la pipeline standard non vede. I casi tipici sono serie storiche con gerarchie (SKU per negozio per settimana), effetti causali da promozioni e prezzi, censura e troncamento (domanda osservata solo fino a esaurimento scorte) e vincoli di business duri (quantità non negative, somme che devono quadrare tra livelli). In questi casi un AutoML tabellare tratta ogni riga come indipendente e perde la dipendenza temporale o gerarchica. Serve almeno feature engineering temporale esplicito; spesso un modello gerarchico o un forecast reconciliation; a volte niente machine learning, ma un modello statistico classico. La terza opzione — problema non modellabile — scatta quando manca il segnale (label rumorose, target definito dopo che la decisione è già stata presa), quando la distribuzione in produzione sarà diversa da quella di training senza possibilità di correzione, o quando il costo dell’errore su un segmento supera qualsiasi guadagno medio.

Una tabella di triage aiuta a decidere in mezz’ora invece che in due sprint:

Situation	Signal	Decision
Target osservabile al momento della predizione, righe indipendenti, migliaia di label	Baseline AutoML batte la regola euristica entro il primo run	AutoML, investi in deploy e monitoraggio
Dipendenze temporali, gerarchie, censura, vincoli di coerenza	AutoML produce metriche buone in media ma errori sistematici per segmento	Custom: feature temporali, validazione walk-forward, riconciliazione
Label ambigue, leakage inevitabile, distribuzione futura ignota	La metrica balla a ogni split, nessun pattern stabile	Fermarsi: ridefinire target o raccogliere dati migliori

Il criterio di stop merita enfasi. Se dopo due iterazioni di pulizia target e split corretto la baseline banale — media storica, maggioranza, naive stagionale — resta competitiva con AutoML, il messaggio non è “serve più tuning”. Il messaggio è che il dataset non contiene il segnale che cerchi, e aggiungere complessità aumenta solo la varianza.

Come funziona davvero una pipeline AutoML

Sotto il cofano, un sistema AutoML tabellare esegue tre ricerche annidate: quali trasformazioni applicare alle colonne, quale famiglia di modelli usare, quali iperparametri assegnare. Il preprocessing prova encoding per categoriche ad alta cardinalità, imputazione, scaling dove serve, selezione feature. Il livello modelli confronta tipicamente regressione regolarizzata, foreste, gradient boosting (LightGBM, XGBoost, CatBoost) e talvolta reti tabellari; il livello tuning esplora iperparametri con ottimizzazione bayesiana o bandit, sotto un budget di tempo. L’output è una leaderboard ordinata per metrica di validazione interna, più un ensemble pesato dei migliori. Il punto che molti saltano è che la validazione interna del tool vale solo se il protocollo di split riflette l’uso reale. Con righe indipendenti, una k-fold stratificata basta. Con dati temporali o raggruppati per cliente, la k-fold casuale è ottimista perché mette il futuro nel training e lo stesso cliente da entrambe le parti. Prima di lanciare qualsiasi run, decidi lo split a mano — temporale, per gruppo, o entrambi — e imponilo al tool se lo permette. Se non lo permette, diffida della leaderboard e ricostruisci la validazione fuori dal tool. Il tempo di calcolo risparmiato non compensa una stima d’errore distorta del 10-20%.

Il secondo equivoco riguarda l’ensembling finale. L’ensemble pesato in cima alla leaderboard riduce quasi sempre l’errore medio di qualche punto, ma aumenta latenza, costo di inferenza e opacità. In produzione conta il trade-off: se il secondo modello da solo perde una frazione di punto ma dimezza il tempo di scoring e si spiega con un grafico di importanza feature stabile, spesso è la scelta migliore. Chiedi sempre al tool l’artefatto singolo oltre all’ensemble, con tempi di inferenza misurati, non stimati.

# Confronto onesto: split per gruppo temporale, non k-fold casuale
# I commenti spiegano ogni scelta di validazione
import pandas as pd
from sklearn.model_selection import GroupKFold

# df: una riga per cliente-mese; target: churn nei 30 giorni successivi
# groups: customer_id, così lo stesso cliente non sta in train e validazione
gkf = GroupKFold(n_splits=5)
for train_idx, val_idx in gkf.split(df, df["target"], groups=df["customer_id"]):
    train = df.iloc[train_idx]
    valid = df.iloc[val_idx]
    # Qui va il fit del candidato AutoML o del baseline;
    # la metrica si media sulle 5 fold raggruppate
    pass

Classificazione senza farsi ingannare dalla leaderboard

In classificazione il pericolo è ottimizzare la metrica sbagliata. Accuracy su classi sbilanciate (2% di frodi, 5% di churn) è quasi decorativa: un modello che predice sempre la classe maggioritaria ottiene il 98% e non serve a nulla. La coppia operativa è precisione e richiamo al variare della soglia: i veri positivi diviso i predetti positivi da un lato, i veri positivi diviso i positivi reali dall’altro. Alzare la soglia aumenta la precisione e abbassa il richiamo; il punto operativo non è quello che massimizza una statistica, ma quello dove il costo atteso è minimo. Se un falso negativo (cliente a rischio non contattato, frode non bloccata) costa dieci volte un falso positivo (contatto inutile, controllo manuale), la soglia va tarata di conseguenza, con una curva di costo esplicita, non a 0,5 di default.

La calibrazione è il secondo tema ignorato. Molti booster ordinano bene ma producono probabilità schiacciate verso gli estremi: dicono 0,97 quando la frequenza reale è 0,80. Se la probabilità alimenta una decisione con soglia di costo o un’allocazione di budget, serve una curva di calibrazione su dati di validazione mai visti nel tuning, ed eventualmente una ricalibrazione isotonica o di Platt. Verifica con bin di probabilità: raggruppa le predizioni in decili e confronta media predetta contro frequenza osservata. Scostamenti sistematici sopra il terzo decile indicano sovraconfidenza da correggere prima del deploy.

Terzo controllo: stabilità per segmento. Una metrica globale alta può nascondere un segmento dominante ottimo e uno nuovo o minoritario pessimo — esattamente dove il business vuole espandersi. Pretendi dal report AutoML la metrica disaggregata per i segmenti che contano (canale, area, fascia di anzianità cliente) e diffida di tool che mostrano solo il numero aggregato. Se un segmento critico ha poche centinaia di righe, la sua stima avrà intervalli larghi: meglio dichiararlo che scoprire il degrado a campagna avviata.

Regressione: errore, scala e costo reale

In regressione la metrica definisce il comportamento del modello più di quanto sembri. L’errore quadratico penalizza gli errori grandi più che proporzionalmente, l’errore assoluto li tratta in modo lineare, l’errore percentuale li relativizza al valore vero ma esplode quando il denominatore si avvicina a zero. Se prevedi tempi di consegna e un ritardo di 10 giorni costa molto più di dieci ritardi di un giorno, l’errore quadratico è la scelta coerente. Se prevedi ticket medi e vuoi robustezza agli outlier, l’errore assoluto è più onesto. L’errore percentuale va evitato su target intermittenti o con zeri (domanda sporadica, vendite di coda lunga): in quei casi meglio metriche scalate sulla media. La regola pratica è partire dalla funzione di costo di business — quanto perdi per ogni unità di errore, e se l’errore positivo costa come quello negativo — e poi scegliere la metrica surrogata, non il contrario.

La scala del target merita un controllo esplicito. Molti AutoML applicano log o standardizzazione automatica; utile per la convergenza, pericoloso per l’interpretazione se la metrica viene calcolata nello spazio trasformato e poi riportata come se fosse nello spazio originale. Pretendi sempre la metrica nello spazio decisionale — euro, giorni, pezzi — calcolata dopo l’inversa della trasformazione, e confrontala con la baseline banale della mediana o media per segmento.

Terzo punto: eteroschedasticità e intervalli. In quasi tutti i casi reali l’errore cresce con il valore (prevedere una casa da 200 mila euro è più preciso in assoluto che prevederne una da 2 milioni). Un singolo numero medio nasconde questo fatto. Strumenti seri di AutoML offrono regressione quantilica o intervalli di predizione: usali per consegnare al business non un punto ma una forchetta, ad esempio il quantile 0,1 e 0,9. Una stima puntuale di 1.200 pezzi con intervallo 400-2.500 dice allo stock manager qualcosa di diverso da 1.200 con intervallo 1.050-1.350, e la decisione di scorta cambia di conseguenza.

Forecasting: il tempo non è una colonna qualsiasi

Il forecasting rompe quasi tutte le assunzioni del tabellare. Le righe non sono indipendenti, il futuro non è disponibile al momento della predizione, e l’errore si propaga lungo l’orizzonte. Il primo errore operativo è usare feature che al momento del forecast non esisteranno: promozioni future non ancora decise, giacenze aggiornate in tempo reale quando lo scoring gira con due giorni di ritardo, medie mobili che includono il giorno da prevedere. Ogni feature va etichettata con il suo ritardo di disponibilità reale, e la pipeline di training deve replicare esattamente quel ritardo. Un backtest che ignora questo dettaglio sovrastima la precisione in modo spettacolare e sistematico.

Il protocollo corretto è il walk-forward con finestra mobile o expanding, mai la k-fold casuale. Si addestra fino al tempo t, si prevede l’orizzonte t+1 … t+H, si avanza di un passo e si ripete, mediando l’errore su molte origini. Solo così la stima riflette stagionalità, cambi di regime e degrado con l’orizzonte. Riporta sempre l’errore per passo dell’orizzonte, non solo la media: un modello ottimo a una settimana e pessimo a otto settimane va usato solo per il breve termine, e va dichiarato.

Scelta	Quando regge	Quando tradisce
Naive stagionale (stessa settimana anno scorso)	Domanda stabile, forte stagionalità	Promozioni, discontinuità, nuovi prodotti
Modelli statistici (ETS, ARIMA)	Serie singole lunghe, poco rumore esogeno	Gerarchie con migliaia di serie, regressori forti
ML tabellare con lag e calendario	Molte serie corte, regressori utili	Orizzonti lunghi, relazioni temporali complesse
Modelli globali / deep (TFT, DeepAR via AutoML)	Migliaia di serie correlate, pattern condivisi	Poche serie, overfitting, costo di tuning alto

La riconciliazione gerarchica chiude il cerchio: la somma delle previsioni per SKU deve quadrare con la previsione per categoria e canale. Senza vincolo di coerenza, magazzino e finanza lavorano su numeri diversi. Se il tool non la supporta, riconcilia a valle con approcci top-down o middle-out e misura l’errore a ogni livello, perché l’aggregazione nasconde errori che si compensano solo in apparenza.

Leakage, drift e validazione che regge in produzione

Il leakage è il modo più costoso di farsi ingannare. Entra in tre forme: target leakage (una colonna che contiene il futuro, come data_chiusura_contratto in un modello di propensione che deve decidere prima della chiusura), split leakage (stessa entità in train e test, normalizzazione o encoding calcolati su tutto il dataset prima dello split), e pipeline leakage (imputazione, selezione feature o tuning che vedono il test). Il sintomo classico è una metrica troppo bella per essere vera — punteggio stellare al primo tentativo su un problema notoriamente rumoroso — seguita da un crollo in produzione. La difesa è procedurale: congela il test prima di qualsiasi esplorazione, calcola ogni trasformazione solo sul train e applicala al test, e mantieni una blacklist di colonne sospette revisionata con chi conosce il gestionale sorgente.

Il drift è il leakage al contrario: il modello era onesto, ma il mondo si è mosso. Cambiano le covariate (nuovi canali di acquisizione, mix clienti diverso), cambia la relazione con il target (concorrenza, prezzi, normative), cambiano le definizioni a monte (un evento tracking rinominato dimezza un tasso senza che nessuno tocchi il modello). Distingui covariate shift da concept drift perché le contromisure differiscono: nel primo caso basta monitorare le distribuzioni degli input con test statistici e soglie, nel secondo serve rietichettatura e retraining perché la frontiera decisionale si è spostata. Strumenti come population stability index o semplici confronti di decili per feature bastano per un monitoraggio settimanale efficace, a patto di loggare le predizioni con le feature di input e non solo l’output.

# Controllo anti-leakage minimale prima di ogni run AutoML
# Ogni controllo fallito blocca il training finché non è risolto
import pandas as pd

# 1. Nessuna feature con timestamp successivo all'istante di scoring
# scoring_time: momento in cui la predizione sarebbe disponibile davvero
sospette = [c for c in df.columns if "close" in c or "esito" in c or "post" in c]
assert not sospette, f"Colonne sospette di target leakage: {sospette}"

# 2. Split temporale: tutto il test viene dopo tutto il train
cutoff = df["scoring_time"].quantile(0.8)
assert df.loc[df["scoring_time"] > cutoff, "target"].notna().all()

# 3. Entità disgiunte tra train e test (niente stesso cliente da due parti)
train_ids = set(df.loc[df["scoring_time"] <= cutoff, "customer_id"])
test_ids = set(df.loc[df["scoring_time"] > cutoff, "customer_id"])
assert train_ids.isdisjoint(test_ids), "Overlap di entità tra train e test"
print("Controlli anti-leakage superati: si può lanciare il run")

La validazione che regge combina tre strati: split corretto per struttura (temporale o per gruppo), baseline competitive (euristica di business, modello precedente, naive stagionale per il forecast) e slice analysis per segmento. Un AutoML che batte la media globale ma perde contro la regola euristica sul segmento ad alto margine non è pronto. Documenta per ogni run lo split esatto, il seed, il budget di ricerca e la metrica per slice: senza questi metadati il risultato non è riproducibile e la leaderboard è aneddotica.

Portare un modello AutoML in produzione senza rimpianti

Il passaggio da notebook a servizio è dove molti progetti AutoML si arenano, non per il modello ma per il contratto con il resto del sistema. Il primo requisito è la parità train-serve: le trasformazioni applicate in training (encoding, imputazione, lag temporali con i loro ritardi) devono essere lo stesso codice — stesso artefatto serializzato — eseguito in inferenza. Rieseguire la logica “a mano” nel servizio introduce derive silenziose: una categorica con livello mai visto, un null trattato diversamente, un fuso orario interpretato male. Esporta la pipeline intera dal tool, versionala con dati e codice, e testa lo scoring su un campione storico confrontando predizioni batch e online fino al bit. Il secondo requisito è l’osservabilità dal giorno uno: logga input, versione del modello, predizione e, appena disponibile, l’esito reale. Senza questo join tra predizione ed esito non puoi misurare il degrado, e il retraining diventa superstizione. Definisci prima del deploy le soglie che fanno scattare un allarme — calo di metrica sotto una banda, errore per orizzonte sopra il contratto, quota di input fuori distribuzione oltre una percentuale — e il playbook associato: chi investiga, se si rollbacka alla baseline, quando si rilancia la ricerca AutoML. Un modello senza owner e senza rollback è un prototipo con pretese.

Il terzo requisito è la spiegabilità proporzionata al rischio. Per uno scoring interno a basso impatto bastano importanza feature globale e qualche esempio locale. Per decisioni che toccano clienti, credito o accesso a servizi servono motivazioni stabili nel tempo, testate contro piccole perturbazioni degli input, più una model card che dichiari dati di training, limiti noti, segmenti deboli e casi d’uso esclusi. Se le spiegazioni cambiano a ogni retraining senza che la metrica cambi, il segnale è fragile: meglio un modello leggermente peggiore ma con ragioni stabili.

Quanto costa e come governarlo

AutoML sposta il costo dal tempo del data scientist al conto cloud, e il conto va letto prima di firmare. Un run con decine di candidati su milioni di righe può costare da pochi euro a diverse centinaia a seconda di istanze, parallelismo e budget di tuning; il retraining settimanale su serie gerarchiche moltiplica la cifra. Fissa un budget per run, parti da un sottoinsieme stratificato per scremare le famiglie, e allarga al dataset pieno solo per i finalisti. Misura anche il costo di inferenza: un ensemble enorme che gira ogni ora su uno stream costa più del punto di metrica che guadagna rispetto al singolo booster. Nella scelta tra cloud gestito (Vertex AI, Azure AutoML, SageMaker Autopilot, Databricks AutoML) e librerie open (Auto-Sklearn, FLAML, AutoGluon) pesa la portabilità: il servizio gestito accelera, ma l’artefatto deve restare esportabile e rieseguibile fuori dal vendor.

La governance chiude il cerchio con quattro artefatti leggeri ma non negoziabili: scheda del problema (decisione, owner, metrica di business, soglia di stop), datasheet dei dati (sorgenti, definizioni, ritardi di disponibilità, licenze e vincoli privacy), model card del vincitore (split, seed, budget, metriche globali e per segmento, limitazioni), runbook operativo (monitoraggio, soglie, rollback, cadenza di retraining). Con questi documenti un revisore esterno ricostruisce le scelte senza inseguire conversazioni; senza, anche il miglior modello resta un’opinione ben formattata.

Strumenti e riferimenti da usare con criterio

La documentazione ufficiale resta il punto di verifica per limiti e terminologia, perché le capacità dei tool cambiano ogni trimestre e i tutorial invecchiano in fretta. Per il forecasting tabellare, il riferimento operativo è la guida di Vertex AI su modelli tabulari e orizzonti; per la classificazione e regressione generalista, la panoramica concettuale di Azure AutoML e la guida di SageMaker Autopilot descrivono bene search space e artefatti esportati; Databricks AutoML documenta l’integrazione con MLflow per tracking e lineage. Sul fronte agentico e orchestrazione, la guida agli agenti di OpenAI serve quando la pipeline include tool e handoff, non per il tuning in sé. Usali per verificare un dettaglio implementativo prima di progettare il workflow reale, non come ricette da copiare: ogni dataset con leakage, drift o vincoli gerarchici richiede comunque le verifiche descritte sopra.

Verdetto: ricerca automatica sui tabulari puliti, modellazione su misura su tempo e gerarchie, stop onesto quando la baseline resta competitiva.

Il premio Netflix e la leaderboard che non vinse

Nel 2009 Netflix assegnò il premio da un milione di dollari al team che migliorò del 10 percento il suo sistema di raccomandazione con un ensemble da oltre cento modelli. Quel modello non entrò mai in produzione: il guadagno non giustificava il costo ingegneristico di esercizio e manutenzione. È la lezione di questa pagina: la leaderboard misura l’errore, non il valore, e l’ultimo punto di metrica è quasi sempre il più caro.

Domande per chiudere la lezione

1. Quale segnale dopo due iterazioni oneste ti dice che il problema non è modellabile?
2. Perché la validazione casuale mente su dati temporali e quale protocollo la sostituisce?
3. Come scegli tra errore quadratico ed errore assoluto partendo dal costo di business?
4. Cosa deve contenere il pacchetto di deploy perché training e serving non divergano?