AutoML: quando lasciar scegliere il modello alla macchina

Facciamo un esperimento mentale. Ti do un dataset tabellare e ti chiedo il modello migliore entro stasera. Cosa fai? Provi una regressione logistica come baseline, poi un random forest, poi XGBoost. Per ognuno una ricerca di iperparametri, ognuna con la sua cross-validation. Verso le sette di sera hai una tabella di punteggi, gli occhi stanchi e il sospetto di aver dimenticato di provare LightGBM. Ora la domanda scomoda: in quel pomeriggio, quante decisioni hai preso che richiedevano davvero te? Quasi nessuna. Hai eseguito un ciclo meccanico — prova, valuta, confronta — che una macchina esegue meglio, più in fretta e senza dimenticarsi nulla. Questo ciclo meccanico automatizzato ha un nome: AutoML.

Cosa automatizza davvero l’AutoML

Due richiami veloci, poi partiamo. Gli iperparametri sono le manopole che regoli prima dell’addestramento (profondità di un albero, learning rate); la cross-validation è il metodo che stima onestamente quanto un modello generalizza, addestrando su K fette del training set a turno. L’AutoML mette insieme questi ingredienti e automatizza tre scelte in un colpo solo:

• Quale famiglia di modelli: random forest? gradient boosting? modello lineare?
• Quali iperparametri per ciascuna famiglia, cercati con strategie più furbe della grid search;
• Come spendere il budget: quanti secondi dedicare ai candidati promettenti e quanto in fretta abbandonare quelli scarsi.

L’analogia che uso sempre è il navigatore in macchina. Prima calcolavi il percorso sulla cartina: sceglievi tu le strade, e ci mettevi mezz’ora. Il navigatore esplora migliaia di percorsi in un secondo e ti propone il migliore. Ma nota cosa non fa: non decide dove vuoi andare, non sa che preferisci evitare l’autostrada, e ogni tanto propone una scorciatoia assurda che tu, conoscendo la zona, scarti al volo. Con l’AutoML è identico: automatizza la ricerca, non il giudizio.

FLAML in pratica: un budget di tempo, non di pazienza

Il corso originale di PAIthon usava TPOT, un pioniere basato su algoritmi genetici che oggi mostra gli anni. Nel 2026 il mio strumento preferito per iniziare è FLAML (Microsoft Research): leggero, open source, e con un’idea centrale elegante — gli dai un budget in secondi e lui organizza la ricerca per estrarre il massimo da quel tempo, iniziando da modelli economici e salendo di costo solo quando ne vale la pena.

# ambiente 2026: Python 3.12 + uv, editor VS Code o PyCharm
# uv venv .venv && source .venv/bin/activate
# uv pip install "flaml[automl]" scikit-learn

from sklearn.datasets import load_breast_cancer
from sklearn.model_selection import train_test_split
from flaml import AutoML

X, y = load_breast_cancer(return_X_y=True)  # incluso in sklearn
X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, random_state=42, stratify=y
)

automl = AutoML()
automl.fit(
    X_train, y_train,
    task="classification",   # o "regression"
    time_budget=60,          # secondi TOTALI di ricerca: decidi tu
    metric="accuracy",
    seed=42,
    verbose=1,
)

# il verdetto della ricerca
print("Modello scelto:", automl.best_estimator)       # es. "lgbm"
print("Iperparametri:", automl.best_config)
print(f"Accuratezza sul test: {automl.score(X_test, y_test):.3f}")

Tre dettagli da apprezzare. Primo: time_budget=60 significa che dopo un minuto, qualunque cosa succeda, hai un modello — l’AutoML come strumento diventa prevedibile, e in un contesto MLOps la prevedibilità dei tempi vale oro. Secondo: l’oggetto restituito rispetta l’interfaccia scikit-learn (predict, predict_proba), quindi si infila in qualsiasi pipeline esistente. Terzo: seed=42 rende la ricerca riproducibile, che per il debugging è metà della battaglia.

Regola pratica che ti evita una delusione: confronta sempre il risultato con una baseline addestrata da te in trenta secondi.

from sklearn.ensemble import RandomForestClassifier

baseline = RandomForestClassifier(random_state=42).fit(X_train, y_train)
print(f"Baseline (RF default): {baseline.score(X_test, y_test):.3f}")
print(f"AutoML (60 secondi):   {automl.score(X_test, y_test):.3f}")
# se la differenza e' sotto l'1%, chiediti se la complessita' in piu' vale

Dentro la scatola: la pipeline automatizzata

Cosa succede in quei 60 secondi? FLAML esegue un loop che assomiglia moltissimo al tuo pomeriggio di prove manuali, ma con una disciplina che tu non avresti: sceglie un candidato (modello + configurazione), lo valuta in validazione, aggiorna le sue stime su cosa è promettente, e riparte — tenendo conto del costo di ogni tentativo, così i modelli lenti vengono provati solo quando i veloci hanno esaurito il loro potenziale.

Il loop di ricerca (tratteggio teal) gira da solo finché c’è budget; la freccia terracotta è l’iterazione. Ma il modello «migliore» passa comunque dal tuo giudizio prima di andare in produzione.

L’AutoML non sostituisce il machine learning engineer: sostituisce il suo pomeriggio più noioso.

Quando l’AutoML NON serve (ed è spesso)

Qui tocca essere onesti, perché il marketing intorno all’AutoML promette molto di più di quello che mantiene. I casi in cui lo sconsiglio:

• Dati sporchi o feature deboli. L’AutoML ottimizza il modello, non i dati. Se le tue feature non contengono il segnale, nessuna ricerca lo troverà: un’ora spesa a costruire una feature sensata batte dieci ore di ricerca automatica. È il classico «garbage in, garbage out» con un motore più veloce.
• Quando serve interpretabilità. Se il modello va spiegato a un medico, a un revisore o a un giudice, un ensemble di gradient boosting scelto da una macchina è un pessimo punto di partenza rispetto a una regressione logistica che capisci riga per riga.
• Dataset minuscoli. Con 200 righe, la varianza della cross-validation è tale che la «classifica» dei modelli è in gran parte rumore: l’AutoML ti restituirà un vincitore, ma la vittoria non significa nulla.
• Deep learning e dati non tabellari. Per immagini, audio e testo, nel 2026 la risposta è quasi sempre il fine-tuning di un modello pre-addestrato, non una ricerca di architetture da zero.

Il punto di vista MLOps aggiunge un’ultima cautela: il modello che vince la ricerca è spesso un ensemble grosso, e in produzione paghi latenza, memoria e costi di serving a ogni singola predizione. Un modello dell’1% peggiore ma tre volte più veloce è quasi sempre l’affare migliore — e questa valutazione, di nuovo, la macchina non la fa per te (anche se FLAML permette di limitare i modelli candidati proprio per questo, con l’argomento estimator_list).

Prova tu

Prendi il dataset fetch_california_housing di scikit-learn (regressione). Addestra prima una baseline con RandomForestRegressor di default, poi lancia FLAML con task="regression", metric="r2" e tre budget diversi: 30, 120 e 300 secondi. Riporta in una tabellina R² sul test e modello scelto per ciascun budget. Domande a cui rispondere: il guadagno tra 120 e 300 secondi giustifica il tempo extra? Il modello scelto cambia con il budget? E quanto dista la baseline dal vincitore?

Per approfondire: la documentazione ufficiale di FLAML (microsoft.github.io/FLAML) è ben scritta e piena di esempi; se invece vuoi capire la teoria dietro tutto il campo, il libro Automated Machine Learning: Methods, Systems, Challenges di Hutter, Kotthoff e Vanschoren (Springer) è disponibile gratuitamente online ed è il riferimento standard.