Una previsione meteorologica, vista dall’esterno, sembra qualcosa di molto semplice: un’icona, una temperatura, una probabilità di pioggia, il vento previsto e qualche informazione aggiuntiva.

Dietro quel risultato, però, può esserci un processo molto più articolato.

È quello che è successo anche a Meteo Gesualdo.

Nel tempo il sistema previsionale è cresciuto, è stato riscritto più volte e soprattutto ha iniziato a separare compiti che nelle prime generazioni erano concentrati nello stesso motore. La nuova pipeline nasce proprio da questa evoluzione: invece di affidare l’intera previsione a un unico algoritmo, diversi componenti specializzati collaborano, ciascuno con una responsabilità precisa.

Oggi il cuore della pipeline è formato da quattro componenti principali:

• Vertumno 10, il motore della previsione locale;
• Lira 4, il motore che interpreta le informazioni provenienti dai modelli meteorologici esterni;
• Efesto 9, il componente Forecast che fonde le sorgenti, dialoga con Metis e prepara il risultato finale per la pubblicazione;
• Metis 7, il motore KNN che utilizza la memoria delle previsioni validate per valutare conferme, rifiniture e correzioni.

Il risultato che arriva sul sito e nell’app non appartiene quindi a un solo algoritmo. È il punto di arrivo di un percorso nel quale osservazioni locali, modelli esterni, fusione, memoria storica e controlli di coerenza vengono fatti lavorare insieme.

Due modi diversi di guardare lo stesso futuro

Il primo principio della nuova pipeline è semplice: per prevedere il tempo a Gesualdo è utile osservare contemporaneamente ciò che sta accadendo realmente sul territorio e ciò che i modelli meteorologici descrivono su una scala più ampia.

Da una parte c’è la stazione meteorologica locale.

Temperatura, umidità, punto di rugiada, pressione, vento, raffiche, precipitazioni, radiazione solare e altre grandezze costruiscono continuamente una fotografia delle condizioni presenti.

A queste osservazioni si aggiunge lo storico locale, che permette di inserire ciò che sta accadendo all’interno del comportamento meteorologico e climatico già osservato a Gesualdo.

Dall’altra parte ci sono i modelli meteorologici esterni, capaci di descrivere l’evoluzione dell’atmosfera su territori molto più vasti e di osservare fenomeni che una singola stazione, per sua natura, non può vedere direttamente.

Le due prospettive sono entrambe importanti, ma non è detto che raccontino esattamente la stessa storia nello stesso momento.

Per questo la nuova pipeline non chiede a una sorgente di sostituire l’altra.

Le fa lavorare in parallelo e poi le mette a confronto.

Vertumno 10: partire dal territorio

Vertumno è il componente che costruisce la previsione locale.

Lavora esclusivamente sui dati della stazione di Gesualdo e sullo storico locale, senza utilizzare il KNN e senza interrogare direttamente servizi meteorologici esterni.

Il suo compito non consiste semplicemente nel prendere l’ultimo valore registrato da un sensore e proiettarlo nelle ore successive.

Deve interpretare quello che sta accadendo.

Un aumento dell’umidità può avere significati differenti durante la notte, nelle prime ore del mattino oppure nel pomeriggio. Una diminuzione della radiazione solare può essere legata a un passaggio nuvoloso, ma deve essere valutata rispetto all’ora, al periodo dell’anno e alle altre variabili disponibili. Una variazione improvvisa del vento o della temperatura può descrivere un cambiamento significativo oppure un fenomeno rapido destinato a esaurirsi.

Vertumno utilizza quindi il dettaglio recente della stazione, lo storico orario, la climatologia locale e la ricerca di situazioni analoghe per costruire una traiettoria previsionale autonoma.

Una parte importante del suo lavoro consiste proprio nel distinguere i segnali più lenti e persistenti da quelli rapidi, come passaggi nuvolosi, outflow o variazioni locali che non devono essere proiettate automaticamente per molte ore.

Il risultato è un punto di vista fortemente legato al territorio.

In termini semplici, Vertumno cerca di rispondere a una domanda:

“Partendo da ciò che Gesualdo sta realmente osservando e dal suo comportamento storico, quale evoluzione locale è plausibile?”

Lira 4: guardare oltre la stazione

Una stazione meteorologica può descrivere molto bene ciò che accade nel punto in cui è installata, ma non può vedere da sola tutto ciò che si sta formando o spostando nell’atmosfera circostante.

Per questo esiste Lira.

Lira rappresenta il secondo punto di vista della pipeline e parte dai dati dei modelli meteorologici esterni.

Il suo lavoro, però, non consiste nel prendere un’icona già pronta da un altro servizio e passarla direttamente a Meteo Gesualdo.

Riceve numerose variabili meteorologiche e le interpreta secondo lo stesso contratto utilizzato dal resto della pipeline.

Temperatura, umidità, pressione, vento, raffiche, precipitazioni, copertura nuvolosa e altre informazioni vengono trasformate in valori, probabilità, famiglie meteorologiche, fenomeni principali e fenomeni secondari coerenti con il linguaggio utilizzato anche da Vertumno.

Lira utilizza inoltre informazioni provenienti dagli ensemble per rappresentare meglio l’incertezza della previsione e, in alcuni casi, osserva anche le ore adiacenti per evitare che un singolo picco isolato del modello produca un cambiamento artificiale nella classificazione.

Il punto fondamentale è che, alla fine del processo, Vertumno e Lira parlano lo stesso linguaggio.

Non abbiamo quindi “la previsione locale” contrapposta a “un simbolo preso da internet”.

Abbiamo due previsioni strutturate dello stesso futuro, costruite da informazioni differenti ma rese direttamente confrontabili.

Efesto 9: un solo componente, due momenti fondamentali

Quando Vertumno e Lira hanno prodotto le rispettive traiettorie entra in gioco Efesto 9, il componente Forecast della nuova pipeline.

Il suo ruolo è particolare perché interviene sia prima sia dopo Metis.

Questi due momenti sono gestiti da due parti separate dello stesso componente.

La prima è il Merge: riceve Vertumno e Lira, li allinea e li fonde.

La seconda è il Forecast: dopo il lavoro di Metis riceve la previsione canonica definitiva e la prepara per la pubblicazione, per lo Snapshot e per gli altri servizi interni.

Efesto, quindi, non è semplicemente “il Merge” e non è semplicemente “l’endpoint finale”.

È il componente che accompagna la previsione dalla fusione delle sorgenti fino alla sua distribuzione finale, passando attraverso Metis.

La prima fase di Efesto: fondere Vertumno e Lira

Vertumno e Lira possono essere perfettamente d’accordo.

Ma possono anche descrivere scenari differenti.

La prima parte di Efesto ha il compito di gestire proprio questo confronto.

Il Merge non funziona come un interruttore che decide semplicemente “uso Vertumno” oppure “uso Lira”.

Le due traiettorie vengono prima allineate sulla stessa fascia temporale e successivamente combinate considerando diversi elementi, tra cui il tempo che manca alla previsione, la qualità delle sorgenti, la loro freschezza e il loro grado di accordo.

Il lead temporale ha un ruolo importante.

Nel breve periodo il dato locale può avere una forte capacità descrittiva perché racconta ciò che sta realmente avvenendo a Gesualdo. Spostandosi più avanti nel futuro, invece, le informazioni provenienti dai modelli esterni acquistano naturalmente maggiore importanza.

Questo passaggio non viene gestito con uno stacco improvviso tra una sorgente e l’altra, ma attraverso una fusione progressiva.

Efesto confronta inoltre i diversi aspetti della previsione: non soltanto il fenomeno meteorologico vincente, ma anche valori fisici, distribuzioni probabilistiche, fenomeni secondari e livello di accordo complessivo.

Il risultato del Merge contiene quindi una nuova traiettoria e conserva anche il contesto che descrive come quella traiettoria è nata.

Ma c’è una distinzione fondamentale:

il risultato del Merge non viene ancora pubblicato.

Efesto lo passa prima a Metis.

Metis 7: confrontare la previsione con l’esperienza

Metis è il componente KNN della pipeline.

Il principio di base può essere descritto con una domanda molto semplice:

“Ci siamo già trovati in una situazione simile?”

Ma il sistema va oltre la semplice ricerca di casi meteorologici somiglianti.

La domanda realmente interessante diventa:

“Quando avevamo prodotto una previsione in un contesto simile, come era andata rispetto a ciò che è realmente successo?”

Lo storico utilizzato da Metis contiene infatti previsioni che sono state successivamente confrontate con la realtà.

Questo permette al motore di studiare non soltanto la somiglianza tra il presente e il passato, ma anche gli errori che il sistema aveva commesso nei casi precedenti.

La ricerca considera molte caratteristiche contemporaneamente: valori fisici, distribuzioni meteorologiche, contesto temporale, distanza del lead e informazioni provenienti dalla fusione tra Vertumno e Lira.

Anche lo storico, però, non viene trattato come se fosse tutto ugualmente valido.

La qualità delle vecchie osservazioni, la compatibilità con l’architettura attuale, la distanza dal caso corrente e la quantità di informazione effettivamente confrontabile contribuiscono a stabilire quanto un vecchio esempio possa essere realmente utile.

Correggere quando serve, non perché si può

Metis non ha il compito di modificare obbligatoriamente ogni previsione.

Anzi, una parte fondamentale del suo comportamento consiste nel capire quando non deve intervenire.

Se i casi storici disponibili sono troppo lontani, se la memoria è insufficiente oppure se l’evidenza non è abbastanza forte, la previsione può essere semplicemente confermata.

Quando invece lo storico offre un segnale sufficientemente rappresentativo, Metis può applicare una rifinitura o una correzione.

Inoltre, non tutte le parti della previsione devono necessariamente cambiare insieme.

Temperatura, umidità, pressione, vento, classificazione meteorologica, fenomeni secondari e altri canali possono avere una quantità di memoria e una qualità dell’evidenza differenti.

Può quindi esistere abbastanza esperienza per rifinire un valore fisico senza avere motivi sufficienti per cambiare il fenomeno principale.

Oppure lo storico può mostrare un errore ricorrente nella classificazione meteorologica lasciando sostanzialmente corretti gli altri valori.

Dopo gli eventuali interventi, Metis ricompone il risultato mantenendo la coerenza tra i diversi elementi e applica controlli di continuità tra fasce consecutive per limitare transizioni meteorologiche poco plausibili.

Alla fine produce la previsione canonica: il risultato meteorologico di riferimento della nuova pipeline.

La seconda fase di Efesto: dal risultato di Metis alla pubblicazione

A questo punto Efesto torna nuovamente protagonista.

Il file Forecast non ripete il Merge, non ricalcola Vertumno e Lira e non applica un secondo KNN.

Riceve invece la cache canonica prodotta da Metis e la considera la propria sorgente meteorologica finale.

Da quel momento il problema non è più stabilire quale sarà il tempo.

Il problema è trasformare quel risultato nei diversi formati necessari all’ecosistema Meteo Gesualdo.

Efesto prepara quindi più viste dello stesso risultato.

La vista PUBLIC è pensata per sito e app e rende la previsione direttamente utilizzabile dall’utente.

La vista SNAPSHOT mantiene invece il contratto tecnico necessario allo storico e alla successiva validazione.

La vista MOTIVATION permette di separare e consultare le motivazioni legate al comportamento di Metis.

La meteorologia non viene ricostruita tre volte.

La previsione canonica è una sola; Efesto la elabora in modi differenti a seconda di chi dovrà utilizzarla.

In questa fase possono inoltre essere integrate informazioni complementari, come la qualità dell’aria, che arricchiscono l’output pubblico ma rimangono separate dalla decisione meteorologica presa dalla pipeline.

Trend: raccontare una previsione già decisa

Una previsione oraria molto dettagliata è utile per il sistema, ma non è sempre il modo più immediato per raccontare l’evoluzione di una giornata.

Per questo esiste Trend.

Trend lavora a valle della vista PUBLIC di Efesto.

Non decide il meteo, non ricalcola probabilità e non corregge il risultato di Metis.

Prende invece le ore già previste e le comprime in fasce, riepiloghi e descrizioni più facilmente leggibili.

È quindi importante distinguere i due compiti:

la pipeline decide la previsione; Trend la racconta.

Warm: preparare la catena prima che serva

Accanto ai componenti che prendono decisioni meteorologiche esistono processi con un ruolo prevalentemente operativo.

Uno dei più importanti è il Warm.

Il Warm coordina in anticipo l’esecuzione della catena previsionale, richiamando i diversi passaggi nell’ordine necessario.

Ogni endpoint continua però a essere proprietario della propria cache e della propria scadenza.

Il Warm non sostituisce Vertumno, Lira, Efesto o Metis e non prende decisioni meteorologiche al loro posto.

Il suo compito è fare in modo che le informazioni possano essere già pronte quando sito, app o altri servizi ne avranno bisogno.

La catena operativa segue così la costruzione delle sorgenti, il Merge, la generazione canonica di Metis e infine le viste Forecast e i servizi che dipendono da esse.

In altre parole:

il Warm non decide che tempo farà; cerca di fare in modo che chi deve deciderlo abbia già lavorato al momento giusto.

La previsione non è la fine del processo

Una delle caratteristiche più interessanti della nuova architettura è che il processo non termina quando una previsione viene pubblicata.

Perché Metis possa utilizzare davvero l’esperienza del sistema, bisogna prima costruire quella memoria.

Qui entra in gioco lo Snapshot.

Una selezione delle previsioni prodotte viene conservata insieme alle informazioni tecniche necessarie a ricordare esattamente ciò che il sistema aveva previsto prima di conoscere il risultato reale.

Questo passaggio è fondamentale.

Se vogliamo capire quanto una previsione fosse corretta, dobbiamo conservare ciò che era stato realmente previsto in quel momento, senza poterlo modificare dopo aver visto cosa è successo.

Quando arriva la realtà

Dopo che la fascia prevista è trascorsa, entrano in gioco le osservazioni reali della stazione.

Il sistema raccoglie i campioni registrati durante quell’ora e ricostruisce automaticamente valori come temperatura media, umidità, punto di rugiada, pressione, vento, raffiche, precipitazioni, radiazione solare e indice UV.

La parte meteorologica viene invece validata manualmente.

Una stazione può misurare con precisione una temperatura o una raffica, ma stabilire se il cielo fosse realmente sereno, con nubi sparse, parzialmente nuvoloso oppure coperto richiede anche un’osservazione della situazione meteorologica effettivamente verificatasi.

La validazione combina quindi due fonti:

• le misure reali raccolte automaticamente dalla stazione;
• l’osservazione meteorologica utilizzata per indicare il fenomeno principale e gli eventuali fenomeni secondari realmente presenti.

Una volta effettuata la validazione, il server confronta automaticamente ciò che era stato previsto con ciò che è realmente successo.

Una stessa ora può verificare molte vecchie previsioni

Una singola fascia reale può essere stata prevista molte volte.

La stessa ora può essere comparsa in una previsione quando mancava soltanto un’ora, ma anche in una previsione generata molte ore o giorni prima.

Quando quella fascia viene validata, tutte queste vecchie previsioni possono essere confrontate con la stessa realtà.

Questo permette al sistema di imparare anche una cosa molto importante: come cambia l’errore al variare della distanza temporale della previsione.

Una previsione a breve termine e una previsione molto più lontana possono quindi diventare due esperienze differenti anche se si riferiscono esattamente alla stessa ora reale.

Anche la qualità della memoria conta

Accumulare esempi non basta.

Bisogna anche sapere quanto siano affidabili.

Il sistema controlla quindi la quantità e la disponibilità dei campioni osservati dalla stazione prima di permettere la validazione ordinaria.

Quando i dati sono più scarsi può essere utilizzata una validazione forzata, ma quella memoria viene automaticamente declassata in funzione della quantità di osservazioni disponibili.

Se invece non esistono campioni sufficienti a descrivere la fascia, il dato non viene trasformato artificialmente in un esempio valido.

Questo principio è importante perché Metis non deve semplicemente possedere uno storico molto grande.

Deve possedere uno storico il più possibile rappresentativo e affidabile.

Osservare anche il comportamento di Metis

La pipeline non registra soltanto gli errori delle previsioni.

Esiste anche un livello di analisi dedicato al comportamento stesso di Metis.

Il sistema può conservare informazioni sulla qualità della memoria utilizzata, sul numero di vicini realmente disponibili, sui campi che sono stati rifiniti, sui cambiamenti applicati e sulle variazioni della confidenza.

Questi dati possono essere aggregati e studiati nel tempo per capire quanto spesso Metis interviene, in quali lead trova una memoria più utile e quali parti della previsione tende maggiormente a confermare o correggere.

È un aspetto importante perché un sistema che apprende dallo storico deve essere anche osservabile.

Non basta sapere che ha prodotto un risultato.

Bisogna poter studiare come ci è arrivato.

Da linea a ciclo

A questo punto la struttura completa della nuova pipeline diventa più chiara.

Vertumno costruisce la previsione locale.

Lira costruisce la previsione basata sui modelli esterni.

Efesto, attraverso il Merge, fonde le due sorgenti e consegna il risultato a Metis.

Metis confronta quella situazione con la memoria storica e produce la previsione canonica.

Efesto riceve nuovamente il risultato, lo elabora e genera le viste destinate alla pubblicazione e agli utilizzi tecnici.

Una parte delle previsioni viene conservata attraverso Snapshot.

Quando arriva il momento previsto, la realtà viene osservata e validata.

Gli errori entrano nello storico.

E quello storico torna a essere disponibile per Metis nelle previsioni successive.

La pipeline, quindi, non è realmente una linea con un punto di partenza e uno di arrivo.

È un ciclo continuo:

osservare → prevedere → fondere → confrontare → pubblicare → verificare → imparare → prevedere di nuovo.

Perché dividere tutto in componenti?

Un’architettura composta da più elementi è inevitabilmente più complessa rispetto a un unico grande algoritmo.

Ma questa separazione permette a ogni parte di concentrarsi sul proprio compito.

Vertumno può specializzarsi nell’interpretazione del territorio e dello storico locale.

Lira può concentrarsi sui modelli meteorologici e sulla loro traduzione nel contratto Meteo Gesualdo.

Efesto può occuparsi della fusione, dell’orchestrazione con Metis e della trasformazione del risultato finale nelle viste necessarie al sistema.

Metis può concentrarsi sulla memoria, sui vicini storici e sugli errori già osservati.

Questa separazione rende anche più leggibile ciò che succede quando una previsione non va come previsto.

È possibile capire cosa vedeva Vertumno.

È possibile confrontarlo con ciò che proponeva Lira.

È possibile osservare come Efesto abbia fuso le sorgenti.

È possibile verificare se Metis abbia confermato o modificato il risultato.

Ed è infine possibile confrontare tutto questo con ciò che è realmente accaduto.

La complessità aumenta, ma aumenta anche la possibilità di controllare, misurare e migliorare il sistema.

Quattro componenti, un unico obiettivo

Alla fine, per chi apre Meteo Gesualdo, il risultato continua a essere molto semplice: sapere che tempo farà.

Dietro quella schermata, però, oggi lavorano quattro componenti con responsabilità differenti.

Vertumno 10 osserva e interpreta il territorio.

Lira 4 guarda ai modelli meteorologici esterni.

Efesto 9 fonde le due prospettive, dialoga con Metis e trasforma il risultato canonico nella previsione utilizzabile dal sistema.

Metis 7 confronta la previsione con l’esperienza accumulata e decide quando quella memoria può realmente essere utile.

Intorno a loro altri processi mantengono pronta la catena, sintetizzano il risultato, conservano le vecchie previsioni, misurano gli errori e trasformano ciò che è successo in nuova memoria.

Questo primo articolo è soltanto la mappa generale.

Nei prossimi approfondimenti entreremo uno alla volta nei diversi componenti della pipeline per capire più da vicino come lavorano, quali problemi cercano di risolvere e perché sono stati separati.

Perché una previsione meteo può essere riassunta in pochi simboli.

Ma la parte più interessante, spesso, è tutto ciò che succede prima e dopo quei simboli.