Il 31 agosto 2026, Google Research ha presentato TimesFM-3, un foundation model zero-shot destinato alle serie temporali multivariate. L’editore annuncia 330 milioni di parametri, un preaddestramento su oltre mille miliardi di punti temporali e il supporto nativo di più target, oltre a variabili storiche o note per il futuro. Queste capacità rendono il modello interessante per accelerare i progetti di previsione. Non eliminano però la necessità di un confronto locale, di un’analisi dei dati e di un sistema di governance.
Da ricordare: TimesFM-3 deve essere considerato un candidato aggiuntivo, non una verità universale. Un pilota serio lo confronta con una baseline ingenua, un modello statistico e l’approccio attualmente utilizzato, su finestre temporali riproducibili e metriche legate alle decisioni aziendali.
1. Che cosa offre realmente TimesFM-3
Le prime versioni di TimesFM si concentravano sulle previsioni univariate: il modello osservava lo storico di una serie e ne prevedeva il seguito. TimesFM-3 aggiunge una rappresentazione multivariata. Può prevedere più serie correlate e utilizzare variabili che influenzano il fenomeno.
Google distingue tre famiglie di input. I target sono le serie da prevedere, ad esempio le vendite di più prodotti. Le covariate passate sono note solo nello storico, come il traffico osservato. Le covariate dinamiche sono note sull’orizzonte futuro, per esempio un calendario di promozioni, i giorni festivi o una previsione meteo disponibile al momento della decisione.
L’architettura alterna attenzione temporale causale e attenzione tra variabili. Il modello produce l’intero orizzonte in un unico passaggio non autoregressivo e fornisce nove quantili tra il 10° e il 90° percentile. Questa uscita probabilistica permette di rappresentare più scenari invece di una sola linea.
Google annuncia il primo posto medio in diversi benchmark pubblici rispetto ad altri modelli preaddestrati. Si tratta di risultati comunicati dal team che lo ha progettato, su dataset e protocolli definiti. Indicano un potenziale, ma non anticipano le prestazioni sulle vostre serie, sulle vostre discontinuità, sulle vostre granularità e sui vostri vincoli operativi.
2. Perché lo zero-shot cambia l’avvio di un progetto
Un modello zero-shot può essere applicato senza un addestramento specifico per ogni serie. Questa caratteristica riduce il tempo necessario per ottenere un primo riferimento. Un team può caricare lo storico, definire l’orizzonte e confrontare rapidamente il risultato con i metodi esistenti.
Questo vantaggio è particolarmente utile quando un’organizzazione possiede molte serie brevi o eterogenee: vendite per punto distributivo, volumi di ticket per categoria, consumo dell’infrastruttura per servizio o fabbisogni di scorte per articolo. Addestrare e mantenere un modello distinto per ogni serie diventa costoso.
Zero-shot non significa «senza lavoro sui dati». Occorre comunque definire la frequenza, gestire i buchi, distinguere gli zeri reali dai valori mancanti, trattare i cambiamenti di perimetro e scegliere il periodo storico pertinente. Un modello potente non può capire da solo che un negozio ha chiuso, che un sensore è cambiato o che una regola contabile ha spostato i volumi.
Inventario, qualità, autorizzazioni e tracciabilità devono quindi precedere la scelta del modello, come nella nostra guida per preparare i dati a un progetto di IA generativa. Per la previsione, aggiungete a questa base la data di effettiva disponibilità di ogni variabile.
Occorre inoltre confrontare il tempo totale. Il modello può evitare una fase di addestramento, ma richiedere più calcolo in inferenza o un’infrastruttura specifica. Il costo rilevante è quello di una previsione prodotta, supervisionata e utilizzata, non soltanto quello del notebook iniziale.
3. I casi in cui il multivariato può creare valore
Il multivariato è utile quando le serie condividono davvero una dinamica. Le vendite di prodotti complementari, i carichi di diversi servizi di una piattaforma o i volumi di filiali soggette allo stesso calendario possono informarsi a vicenda.
Le variabili note per il futuro sono spesso ancora più importanti. Un calendario di promozioni, una chiusura pianificata, un lancio, un giorno festivo o una prenotazione già registrata possono modificare l’orizzonte. Un approccio univariato vede l’effetto passato ma ignora l’evento in arrivo; un modello che accetta queste covariate può integrarlo.
La qualità dipende tuttavia dalla stabilità del legame. Una promozione non ha sempre lo stesso effetto a seconda del prezzo, del canale, della disponibilità o della stagione. Anche una previsione meteorologica contiene incertezza. Introdurre più variabili non garantisce una generalizzazione migliore e può creare una dipendenza da dati non disponibili in produzione.
Prima del pilota, costruite una matrice semplice: variabile, disponibilità al momento della previsione, frequenza di aggiornamento, qualità storica, responsabile e motivazione aziendale. Qualsiasi variabile sconosciuta al momento reale della decisione deve essere esclusa dal dataset futuro, anche se è presente nel data warehouse a posteriori.
4. Evitare le fughe di informazioni tra passato e futuro
La fuga temporale è l’errore più pericoloso di un progetto di previsione. Si verifica quando un’informazione futura viene utilizzata, direttamente o indirettamente, per produrre una previsione che dovrebbe essere stata effettuata nel passato.
Un esempio classico è un dato promozionale registrato dopo la campagna ma associato alla sua data di inizio. Un backtest eseguito oggi considera quindi che l’informazione fosse disponibile, anche se non lo era al momento della decisione. Lo stesso problema riguarda le correzioni dei dati, gli aggregati calcolati su un periodo completo e le variabili aggiornate retroattivamente.
Ogni colonna deve avere due date: la data dell’evento e la data di disponibilità. La suddivisione utilizza la seconda. Per una previsione effettuata il 1° giugno, il modello riceve soltanto ciò che era realmente noto il 1° giugno.
Anche la normalizzazione può causare una fuga se le statistiche vengono calcolate sull’intero dataset. Anche quando il modello dispone di una propria normalizzazione, le trasformazioni aziendali, l’imputazione e la selezione delle serie devono essere adattate solo al passato di ciascuna finestra.
Infine, conservate un set di test finale intatto. Le numerose prove sullo stesso orizzonte trasformano progressivamente questo set in dati di addestramento impliciti per il team.
5. Costruire un backtesting affidabile
Un’unica suddivisione passato/futuro offre una visione fragile. Utilizzate una validazione a origine mobile: scegliete diverse date storiche di previsione, addestrate o configurate i metodi con i dati disponibili a ciascuna data e misurate poi l’orizzonte successivo.
Le finestre devono rappresentare le situazioni importanti: alta stagione, periodo calmo, lancio, interruzione della fornitura e cambiamento di tendenza. Un modello efficace in media può fallire proprio nei periodi in cui la decisione è più costosa.
Confrontate almeno quattro livelli:
- una baseline ingenua, come l’ultimo valore o lo stesso periodo precedente;
- un metodo statistico adatto alla stagionalità;
- la soluzione attualmente utilizzata dall’azienda;
- TimesFM-3 nelle modalità univariata e multivariata quando i dati lo consentono.
La baseline ingenua è indispensabile. In molti contesti stabili rimane difficile da battere. Un modello che migliora leggermente un benchmark ma non supera «lo stesso giorno della settimana precedente» non offre un valore operativo sufficiente.
Documentate le versioni dei dati, del codice, del modello e delle dipendenze. Il risultato deve poter essere riprodotto diversi mesi dopo, soprattutto se una nuova versione del modello modifica le previsioni.
6. Misurare l’incertezza, non solo l’errore medio
Le metriche devono corrispondere alla decisione. La MAE misura l’errore assoluto medio e rimane leggibile nell’unità aziendale. La WAPE rapporta l’errore al volume complessivo, ma può essere dominata dalle serie più grandi. La MASE confronta il modello con una previsione ingenua e facilita i confronti tra serie.
Per i quantili, utilizzate una loss quantile e verificate la calibrazione. Se l’intervallo annunciato all’80% contiene il valore reale solo il 50% delle volte, l’incertezza è sottostimata. Al contrario, un intervallo molto ampio copre quasi tutto ma aiuta poco la decisione.
Aggiungete metriche aziendali. Una sottostima delle scorte può costare più di una sovrastima. Un errore del 10% su un articolo piccolo non ha lo stesso impatto che su un prodotto strategico. Calcolate le rotture di stock evitate, le scorte immobilizzate, le ore pianificate o il budget cloud riservato.
Valutate anche la stabilità. Una previsione che cambia molto per una piccola modifica dell’input può essere difficile da utilizzare. Confrontate le versioni successive man mano che arrivano nuovi dati e misurate la revisione dell’orizzonte.
L’output probabilistico di TimesFM-3 rappresenta un potenziale vantaggio, a condizione che i quantili siano calibrati sul contesto locale e utilizzati realmente nelle regole decisionali.
7. Scegliere tra foundation model, modello specializzato e approccio ibrido
Un foundation model è adatto quando il numero di serie è elevato, il tempo di avvio è breve e l’organizzazione desidera una base comune. Può anche fungere da challenger permanente o da soluzione di riserva quando un modello specializzato non dispone di uno storico sufficiente.
Un modello locale resta pertinente quando il fenomeno è fortemente specifico, le variabili sono ben controllate e pochi punti di performance hanno un valore elevato. Può integrare vincoli aziendali, funzioni di costo asimmetriche o una struttura causale non rappresentata nel modello generalista.
L’approccio ibrido è spesso il più robusto. TimesFM-3 fornisce una previsione di base e i quantili; un livello aziendale applica vincoli, combina informazioni locali o corregge un bias osservato. Per alcune famiglie di serie è possibile selezionare un altro modello.
La decisione deve includere performance, costo, latenza, licenza, riservatezza, spiegabilità e facilità operativa. Verificate anche la disponibilità delle integrazioni annunciate: al 31 agosto 2026, Google indicava TimesFM-3 come disponibile su GitHub e Hugging Face, mentre l’integrazione con BigQuery era annunciata per le settimane successive.
8. Un pilota in sei fasi
Iniziate da un perimetro in cui decisione e valore siano chiari: da venti a cento serie, un orizzonte definito e una baseline esistente. Evitate di selezionare soltanto le serie più pulite.
Secondo, costruite la tabella di disponibilità delle variabili ed eliminate le fughe. Terzo, preparate da cinque a dieci origini di backtest che coprano diverse situazioni aziendali. Quarto, eseguite tutti i metodi con lo stesso protocollo e gli stessi dati.
Quinto, organizzate una revisione con gli utenti. Presentate errori, intervalli e alcuni casi concreti senza rivelare subito il nome del modello, per ridurre il bias di novità. Chiedete quale decisione sarebbe cambiata e con quale impatto.
Sesto, implementate in modalità osservazione. Il sistema genera le previsioni, ma il metodo attuale resta il decisore per diversi cicli. Misurate qualità, costo, stabilità e disponibilità prima di qualsiasi passaggio.
Stabilite i criteri di successo prima del test: miglioramento minimo rispetto alla baseline, calibrazione accettabile, costo massimo, tempo di esecuzione e percentuale di serie per le quali il modello non peggiora il risultato. Senza una soglia definita in anticipo, il team troverà sempre un modo per giustificare il modello più recente.
Conclusione
TimesFM-3 segna un’evoluzione interessante dei foundation model per le serie temporali: previsione multivariata zero-shot, variabili note per il futuro e output probabilistico in un unico passaggio. Queste caratteristiche possono ridurre il costo di ingresso e ampliare il numero di serie coperte.
Il valore sarà tuttavia dimostrato soltanto da un protocollo locale, senza fughe temporali, a confronto con baseline solide e con metriche legate all’attività. Partitech accompagna la preparazione dei dati, la costruzione del backtesting, l’industrializzazione MLOps e la trasformazione delle previsioni in decisioni misurabili.
Riferimenti
- Google Research — «TimesFM-3: A zero-shot foundation model for multivariate forecasting», 31 agosto 2026: https://research.google/blog/timesfm-3-a-zero-shot-foundation-model-for-multivariate-forecasting/
- Google Research — repository TimesFM: https://github.com/google-research/timesfm
- Hugging Face — modello TimesFM-3: https://huggingface.co/google/timesfm-3.0-pytorch