Foundation model per serie temporali: meno training custom

Ecco un'affermazione che cinque anni fa vi avrebbe fatto cacciare da qualsiasi team di forecasting: per la maggior parte dei problemi su serie temporali, addestrare un modello sui propri dati è ormai una perdita di tempo. Un time-series foundation model, addestrato su milioni di serie che non vedrete mai e in domini in cui non lavorate, batterà probabilmente la vostra pipeline accuratamente ottimizzata, in zero-shot, nel tempo necessario per un singolo forward pass su CPU. Timestral di Mistral, rilasciato questa settimana in versioni da 5M a 209M di parametri, è l'ultima e più forte conferma che il settore è arrivato a questo punto. E penso che molti practitioner opporranno resistenza a questa conclusione per ragioni comprensibilissime e per lo più sbagliate.

Cos'è davvero un time-series foundation model

L'analogia con gli LLM è utile, ma solo se si va oltre la superficie. Un large language model viene pre-addestrato su un enorme corpus di testo per generalizzare a compiti e formulazioni mai visti. Un time-series foundation model (TSFM) fa la stessa cosa con segnali continui: viene pre-addestrato su una raccolta massiccia e variegata di serie, reali e sintetiche, così da imparare la grammatica ricorrente dei dati temporali. Trend, stagionalità, cambi di regime, mean reversion, rumore di ogni tipo. Quando gli date in pasto il vostro flusso di sensori o la vostra storia delle vendite, non impara da zero: riconosce.

Quell'ultima parola è il trucco vero, e spiega ciò che mi ha confuso alla prima lettura: come fa un modello addestrato prevalentemente su dati sintetici a battere modelli addestrati su dati reali? Perché i generatori sintetici sono costruiti per produrre processi con dinamiche coerenti: combinazioni realistiche di trend, stagionalità e rumore, più dipendenze non lineari tra le serie. Il modello apprende una prior enorme su come può apparire un comportamento temporale. La vostra serie reale, per quanto la consideriate strana, è quasi certamente una ricombinazione di pattern che ha già visto un milione di volte.

La ricetta di addestramento di Timestral rende tutto questo concreto. Prima un pre-training su larga scala con soli dati sintetici, con un contesto di 8.192 time step. Poi un post-training su un mix di dati reali e sintetici, con il contesto esteso a 32.768 step. L'obiettivo è una pinball loss su 21 quantili, il che significa che il modello non restituisce una stima puntuale ma una distribuzione completa dell'incertezza: si ottiene una previsione con barre d'errore oneste invece di un singolo numero dall'aria sicurissima.

Un dettaglio architetturale che vale la pena di rubare per il vostro modello mentale: Timestral usa quello che Mistral chiama decoupled horizon forecasting. I decoder causali precedenti, come TimesFM, mascherano i valori da prevedere: è semplice, ma inefficiente, perché i valori mascherati diventano invisibili come contesto, quindi ogni previsione degrada l'input per quelle successive. Timestral mantiene l'intera storia nella sequenza e aggiunge forecast token appresi che leggono quella storia. Ogni valore osservato funge sia da target di addestramento sia da contesto. È il tipo di piccola correzione strutturale che non sembra drammatica e che su larga scala conta moltissimo.

Zero-shot forecasting: perché batte la vostra pipeline per singola serie

L'argomento più forte a favore dei TSFM non è la classifica dei benchmark, ma la forma del lavoro di forecasting reale. Quasi nessuno prevede una sola serie. Ne prevedete diecimila. Un retailer prevede la domanda per SKU e per punto vendita. Un team di piattaforma prevede la latenza per servizio e per regione. Un impianto industriale ha migliaia di sensori distribuiti su centinaia di asset. Le opzioni classiche sono tutte scadenti: adattare un ARIMA per ogni serie e vedere la maggior parte fallire perché ogni serie ha una storia scarsa, oppure addestrare un unico modello globale di gradient boosting e annegare nel feature engineering e nelle differenze di scala tra le serie.

Un TSFM aggira il dilemma. Un solo checkpoint, nessun fitting per serie, e la conoscenza trasversale tra le serie è già incorporata nel pre-training invece di dover essere scoperta dai soli dati. Per questo i practitioner che fanno forecasting su larga scala tendono a essere i meno scettici verso questi modelli: l'alternativa non è un elegante modello cesellato a mano, ma una pila di job AutoARIMA che richiedono ore e si rompono in silenzio sul 5% di serie strane che contano di più.

La parte sull'efficienza è quella che mi ha sorpreso di più. Il modello più grande di Timestral ha 209M di parametri, minuscolo per gli standard degli LLM, e non richiede una GPU in inferenza. Su un normale server CPU a 8 thread, prevedere un giorno in avanti a partire da tre settimane di dati a 15 minuti richiede 10 ms con il modello da 5M e 140 ms con quello da 209M. Il modello da 123M si colloca entro lo 0,2% dal punteggio del modello grande sui benchmark, con tre quarti della latenza. Questo rispecchia quanto è successo nei modelli linguistici, dove l'azione interessante si è spostata verso fasce piccole e veloci: la stessa dinamica di cui ho scritto nel nostro articolo sugli LLM di fascia flash: il modello di frontiera fa i titoli, quello piccolo ed efficiente manda avanti il business.

E l'economia si somma. Diecimila serie per una previsione giornaliera, a decine di millisecondi l'una, significano che l'intero carico di forecasting sta nella pausa pranzo su una macchina CPU qualunque. Nessun cluster GPU, nessun job di training distribuito, nessun eroismo da MLOps. Cinque anni fa costruire e rilasciare un modello di forecasting decente richiedeva mesi. Oggi richiede un pomeriggio, e gran parte di quel pomeriggio è plumbing dei dati, non modellazione.

Le covariate sono la vera feature, e la vera trappola

Qui devo concedere terreno agli scettici, perché la critica più acuta ai TSFM è corretta: per molti problemi, la storia della serie target è una minoranza dell'informazione. Se modellate la domanda elettrica, le previsioni meteo, il calendario delle festività e il listino prezzi non sono un condimento della previsione: sono la previsione. Un modello che tratta le vostre covariate accuratamente curate come un leggero miglioramento di qualità è un modello che vi metterà in imbarazzo proprio quando il regime cambia, cioè proprio quando ne avete più bisogno.

La risposta di Timestral è la covariate-aware attention, e il design è più rigoroso di quanto suoni. Ogni serie in input ha un ruolo: target, covariata solo passata o covariata futura nota. Le covariate future note (piani di produzione, fermi programmati, previsioni meteo) sono visibili lungo l'intera finestra, mentre i target restano causali, e l'informazione scorre solo dalle covariate verso i target. Quest'ultimo vincolo è quello importante: significa che il modello può condizionare sul previsto aumento di carico della settimana prossima senza far trapelare nella previsione il futuro del target stesso. La data leakage attraverso le covariate è uno dei classici fallimenti silenziosi nei sistemi di forecasting, e inserire la direzione del flusso informativo nella maschera di attention è un modo pulito per prevenirla.

Anche le covariate categoriche ricevono un trattamento adeguato: uno stato della macchina come «in funzione», «fermo» o «in manutenzione» viene passato come categoria, invece di essere schiacciato in un intero arbitrario che impone un ordinamento fasullo. Chiunque abbia visto un modello ad alberi imparare che «stato 3» è in qualche modo maggiore di «stato 2» apprezzerà.

Ma notate cosa significa in pratica: la qualità di un deployment TSFM è ormai limitata dalla qualità delle vostre pipeline di covariate, non dal modello. Se il feed meteo è vecchio, il calendario delle festività non include quelle regionali e nessuno ha codificato il piano di manutenzione in una forma leggibile dalle macchine, il modello non potrà salvarvi. La modellazione è diventata una commodity; l'ingegneria dei dati no. Pianificate lo sforzo di conseguenza.

Benchmark, e perché dovete testare sul vostro segnale

Sui tre principali benchmark pubblici (GIFT-Eval, TIME e fev-bench) il modello da 209M di Timestral si classifica primo tra i modelli pre-addestrati zero-shot, con un singolo checkpoint e senza ensembling. Il modello da 28M supererebbe Chronos-2, che è circa quattro volte più grande. Sono risultati davvero solidi, e il fatto che ogni dimensione della famiglia stia sulla frontiera di Pareto tra accuratezza e dimensione suggerisce che a fare il lavoro sia la ricetta, non solo la scala.

Ora i necessari distinguo. I benchmark di forecasting hanno un problema metodologico profondo: molte delle serie che contengono sono processi ad alto rumore e basso segnale, dove quasi ogni modello ragionevole si comporta allo stesso modo, perché c'è poco segnale da catturare. Se mediate i punteggi su centinaia di queste serie, comprimete le differenze reali in margini minuscoli, ed è così che si arriva ai grafici di marketing in cui un miglioramento di 0,03 viene disegnato come un divario cinque volte maggiore. È un caso specifico di una malattia generale di cui abbiamo già scritto: i benchmark mancano sistematicamente il lavoro che conta davvero, e i benchmark di forecasting lo mancano in modo particolarmente misurabile.

Il test migliore, e uno che potete eseguire voi stessi, è costruire serie di valutazione con un rapporto segnale/rumore noto e alto, dove un metodo semplice come le distribuzioni condizionali empiriche riesce a catturare gran parte del segnale, e verificare se il foundation model lo cattura altrettanto. Poi alzate progressivamente il livello di rumore e osservate dove il modello degrada. Un modello che sembra SOTA sui benchmark rumorosi ma lascia segnale evidente sul tavolo in regimi puliti vi sta dicendo qualcosa che la classifica non mostra.

Sui dati rumorosi, tutti i modelli sembrano uguali. Si separano solo quando c'è un segnale reale da catturare, quindi testate dove il segnale c'è.

Dove i metodi classici vincono ancora

La mia affermazione iniziale ha bisogno di limiti onesti, eccoli. Ci sono casi reali in cui non dovreste ricorrere a un foundation model.

• Vi servono le equazioni, non solo gli output. Se siete un operatore di rete elettrica o un ingegnere del controllo, spesso vi serve un modello dinamico interpretabile: parametri con un significato fisico su cui ragionare, sottoporre a stress test e consegnare a un regolatore. Un TSFM è una scatola nera: y = F(x, params) senza una struttura leggibile. Un modello state-space o di tipo SINDy stimato vi dà qualcosa che una rete neurale non darà mai.
• Avete una serie critica singola con una storia lunga e ricca e una forte struttura di dominio. Una singola serie ben compresa, per esempio un carico elettrico nazionale con decenni di dati, premia un modello su misura costruito con la conoscenza del dominio. La generalità zero-shot è sprecata quando avete un solo problema e una competenza profonda su di esso.
• Le covariate dominano e le relazioni sono stabili e note. Una regressione lineare sulle feature giuste è trasparente, facile da debuggare e, quando la fisica del problema è davvero lineare, imbattibile. Non pagate una tassa di complessità senza guadagno.
• Dovete possedere completamente la dipendenza. Timestral viene distribuito con una licenza MIT modificata con restrizioni, e se il vostro forecasting è infrastruttura portante, come i mercati dell'energia day-ahead, dovete ragionare a fondo sulla dipendenza da un server di un fornitore o da una licenza che non controllate del tutto. Esistono proprio per questo caso alternative open-weight e modelli interni.
• Avete requisiti rigorosi di igiene nel backtesting. Con un modello pre-addestrato non potete mai essere del tutto certi che il periodo del backtest non fosse nel corpus di addestramento, a meno che il fornitore non vi dia il controllo sul mix di training. Mistral lo offre tramite la sua pipeline Forge, ma verificatelo invece di darlo per scontato.

Notate lo schema: il foundation model vince su ampiezza, velocità e dati scarsi; perde su interpretabilità, profondità della singola serie e rischio di dipendenza. È una regola decisionale davvero utile, e più affilata del solito «dipende».

La domanda sull'architettura che tutti saltano

Una cosa che l'ondata dei TSFM ha chiarito e che merita più attenzione: i transformer funzionano bene sui segnali continui, e il problema della tokenizzazione si è rivelato meno spaventoso del previsto. Il trucco è il patching: invece di trattare ogni time step come un token (cosa che fa esplodere la lunghezza della sequenza) o incorporare i float grezzi in modo ingenuo, si suddivide la serie in patch e si incorporano quelle. La lunghezza delle patch diventa una manopola regolabile che bilancia risoluzione e contesto, esattamente come la dimensione del vocabolario in un LLM. Se avete seguito il dibattito su state-space model contro transformer, è notevole che i TSFM vincenti finora siano per lo più basati sull'attention: la struttura a lungo raggio dei dati temporali sembra adattarsi bene all'attention, una volta fissata la rappresentazione dell'input.

La strategia dei dati sintetici-first merita pari riconoscimento come contributo. Gran parte dei dati di addestramento di Timestral è stata generata, non raccolta: prima processi univariati con dinamiche coerenti, poi un sintetizzatore multivariato che stratifica dipendenze non lineari tra di essi. Questo aggira elegantemente il problema dei dati che ha perseguitato il machine learning sulle serie temporali: non esiste un Common Crawl di dati dai sensori, e ciò che c'è è frammentato, proprietario e formattato in modo incoerente. Se i dati sintetici con i bias induttivi giusti si trasferiscono così bene, cambia l'economia dell'intero sottocampo. Non dovete accumulare la telemetria del mondo; vi servono buoni generatori.

Dalla previsione al sistema

La conseguenza a lungo termine più interessante non è il modello, ma ciò che il modello rende possibile a valle. Un forecaster probabilistico, multivariato ed economico che gira in continuo sulle vostre metriche è un rilevatore di anomalie con un'incertezza onesta: invece di allertare quando un valore supera una soglia statica, allertate quando la realtà esce dai quantili previsti, il che significa allerte che rispettano la stagionalità e gli eventi pianificati. Un aumento di carico programmato è atteso, non segnalato come sorpresa. Questo da solo eliminerebbe una frazione deprimente del rumore delle reperibilità nella maggior parte delle organizzazioni.

Aggiungete sopra un agente LLM e ottenete il flusso di lavoro che Mistral abbozza: il modello numerico segnala un'anomalia su una pompa, un agente confronta i segnali con gli embedding dei guasti passati, avvia un'analisi delle cause su registri di manutenzione e note degli operatori, e consegna al responsabile di impianto una diagnosi con le prove invece di un semplice allarme. Che vi interessi o meno quella visione specifica, la direzione è sensata: è lo stesso schema che abbiamo visto con il constrained decoding per i modelli decisionali: tenete il modello veloce e specializzato nel loop per ciò in cui eccelle, e lasciate che il modello generalista orchestri intorno a lui.

Ecco dunque dove arrivo. Il forecasting cucito su misura non è morto: è stato retrocesso da default a strumento da specialisti. Se avete una sola serie, una profonda conoscenza del dominio e il bisogno di dinamiche interpretabili, continuate a stimare i vostri modelli state-space e dormite tranquilli. Ma se avete migliaia di serie, poca storia per ciascuna e un team di tre persone, l'onere della prova si è ribaltato: ora vi serve un motivo per non partire da un foundation model. Testatelo sui vostri dati ad alto segnale, collegate le covariate come si deve, verificate la licenza rispetto alla vostra tolleranza al rischio, e poi spendete i mesi risparmiati nel plumbing dei dati, cioè dove i progetti di forecasting sono sempre stati davvero vinti o persi.