Vertumno osserva Gesualdo dal punto di vista della stazione e dello storico locale.

Lira guarda invece all’evoluzione descritta dai modelli meteorologici esterni.

Alla fine dei loro calcoli la pipeline possiede quindi due previsioni autonome dello stesso futuro.

A volte saranno molto simili.

Altre volte racconteranno scenari differenti.

Qualcuno deve quindi metterle in relazione, capire quanto siano concordi, costruire una traiettoria comune e accompagnare il risultato fino alla forma utilizzata dal sito, dall’app e dagli altri servizi.

Questo è il compito di Efesto 9.

Efesto non è soltanto la fusione

Per comprendere correttamente Efesto bisogna fare subito una distinzione importante.

All’interno del componente Forecast esistono due momenti separati.

Nel primo, il Merge riceve le previsioni di Vertumno e Lira e le fonde.

Il risultato viene quindi consegnato a Metis, che può confrontarlo con la memoria delle previsioni validate.

Dopo il lavoro di Metis entra in gioco la seconda parte di Efesto: il Forecast riceve il risultato canonico e lo elabora per la pubblicazione e per gli altri utilizzi interni.

Il percorso può quindi essere riassunto così:

Vertumno + Lira → Merge → Metis → Forecast → pubblicazione.

Merge e Forecast sono due parti differenti dello stesso componente Efesto.

Ed è proprio questa posizione, prima e dopo Metis, a rendere Efesto uno dei nodi centrali dell’intera pipeline.

Il primo problema: far combaciare due traiettorie

Prima ancora di decidere come fondere Vertumno e Lira, bisogna essere sicuri che stiano parlando dello stesso momento.

Entrambi producono una sequenza di fasce previsionali, ma Efesto deve allinearle correttamente lungo la stessa linea temporale.

Solo dopo questo passaggio può confrontare ciò che Vertumno prevede per una determinata ora con ciò che Lira prevede esattamente per quella stessa ora.

Può sembrare un dettaglio tecnico, ma è un requisito fondamentale.

Una fusione meteorologica ha senso soltanto se le informazioni confrontate descrivono realmente lo stesso istante futuro.

Due sorgenti, nessun vincitore fisso

Una volta allineate le previsioni, potrebbe sembrare naturale scegliere quale delle due sia più affidabile e utilizzare sempre quella.

La pipeline non funziona così.

Vertumno e Lira hanno caratteristiche differenti e il loro valore cambia anche in funzione della distanza temporale della previsione.

Vertumno possiede un vantaggio importante nel breve periodo: parte da ciò che la stazione sta realmente osservando a Gesualdo.

Lira possiede invece una visione atmosferica molto più ampia e diventa particolarmente importante quando bisogna guardare più lontano nel futuro.

Efesto non stabilisce quindi che una sorgente sia universalmente migliore dell’altra.

Decide quanto ascoltarle in quella particolare fascia previsionale.

Il lead cambia il valore delle informazioni

Il tempo che separa il momento presente dall’ora prevista viene normalmente indicato come lead.

Una previsione per fra poche ore e una previsione per diversi giorni dopo non rappresentano lo stesso problema meteorologico.

Molto vicino al presente, una variazione realmente osservata dalla stazione può contenere informazioni che un modello non ha ancora rappresentato perfettamente.

Andando avanti nel tempo, però, diventa sempre meno plausibile proiettare il comportamento locale senza considerare l’evoluzione atmosferica più ampia descritta dai modelli.

Efesto tiene conto di questa differenza in maniera progressiva.

Non esiste un istante nel quale Vertumno viene improvvisamente spento e Lira prende il suo posto.

La relazione tra le sorgenti cambia gradualmente lungo l’orizzonte della previsione.

Non basta sapere da dove arriva il dato

La distanza temporale non è l’unico elemento che conta.

Efesto riceve anche informazioni sulla qualità e sulla confidenza delle sorgenti.

Questo significa che due previsioni possono avere lo stesso ruolo teorico nella pipeline ma presentarsi con livelli differenti di solidità.

Una sorgente può disporre di informazioni complete e coerenti.

Un’altra può trovarsi in una situazione più incerta oppure avere dati meno rappresentativi.

Efesto considera quindi diversi aspetti contemporaneamente:

• la distanza temporale della previsione;
• la disponibilità delle informazioni;
• la loro freschezza;
• la qualità delle sorgenti;
• la confidenza associata ai risultati;
• il grado di accordo tra Vertumno e Lira.

La fusione diventa così un processo dinamico, non una semplice regola fissa.

Fondere non significa fare una media

Questo è probabilmente uno dei punti più importanti per capire Efesto.

Se Vertumno prevede una temperatura e Lira ne prevede un’altra, la soluzione non consiste necessariamente nel prendere i due valori, sommarli e dividerli per due.

E questo vale ancora di più quando si parla di fenomeni meteorologici.

Non avrebbe senso fare la “media” tra sereno e pioggia.

Efesto deve quindi lavorare in maniera differente a seconda del tipo di informazione.

I valori fisici vengono combinati secondo la logica prevista per quel canale.

Le probabilità meteorologiche vengono fuse mantenendo la loro natura probabilistica.

I fenomeni secondari vengono trattati separatamente.

Anche quantità particolari, come la direzione del vento, richiedono un trattamento coerente con la loro natura.

La fusione non produce un valore intermedio generico: costruisce una nuova previsione meteorologicamente coerente.

Le probabilità contano quanto il fenomeno vincente

Vertumno e Lira non consegnano soltanto un’etichetta finale.

Conservano anche distribuzioni che descrivono quanto siano sostenuti diversi scenari meteorologici.

Questo permette a Efesto di capire molto meglio quanto le due sorgenti siano realmente vicine.

Immaginiamo che Vertumno consideri più probabile un cielo nuvoloso ma attribuisca una possibilità significativa anche al coperto.

Lira potrebbe scegliere coperto come fenomeno principale ma mantenere una probabilità importante sul nuvoloso.

Guardando soltanto le due etichette sembrerebbe esserci un disaccordo.

Guardando le distribuzioni complete, invece, le due previsioni potrebbero essere in realtà molto vicine.

Il caso opposto è altrettanto importante.

Due sorgenti potrebbero scegliere la stessa classificazione principale ma avere distribuzioni molto differenti nelle alternative.

Per questo Efesto non confronta soltanto “chi ha vinto”.

Confronta anche quanto il resto della previsione sostiene quel risultato.

Misurare il disaccordo

Il disaccordo tra Vertumno e Lira non viene considerato semplicemente un problema da eliminare.

È esso stesso un’informazione.

Se due sorgenti indipendenti descrivono praticamente lo stesso scenario, la pipeline possiede un segnale diverso rispetto a una situazione nella quale le due previsioni divergono nettamente.

Efesto conserva quindi informazioni sul loro grado di accordo.

Questo permette di distinguere la qualità interna di una singola sorgente dal rapporto tra le sorgenti.

Una previsione può infatti essere prodotta con buona confidenza da Vertumno e buona confidenza da Lira, ma le due potrebbero comunque non essere d’accordo tra loro.

Queste sono due informazioni differenti e la pipeline cerca di conservarle entrambe.

Un esempio: cielo locale contro segnale modellistico

Immaginiamo una situazione nella quale la stazione osservi condizioni abbastanza stabili e Vertumno continui a sostenere cielo poco nuvoloso nelle ore successive.

Lira, però, potrebbe iniziare a vedere l’avvicinamento di una struttura nuvolosa prevista dai modelli.

Nel brevissimo periodo il segnale locale potrebbe ancora avere grande importanza.

Più avanti, però, ignorare completamente l’evoluzione modellistica significherebbe rischiare di proiettare troppo a lungo una situazione che appartiene soltanto al presente.

Efesto deve quindi costruire una transizione nella quale l’informazione locale e quella esterna vengono entrambe considerate.

Non deve scegliere quale delle due “ha ragione” in senso assoluto.

Deve stabilire come cambia il loro valore lungo il tempo.

Valori fisici e meteorologia devono rimanere coerenti

Una previsione non può essere considerata soltanto come una serie di classificazioni del cielo.

Temperatura, umidità, pressione, vento e precipitazioni devono raccontare una storia compatibile con il fenomeno meteorologico previsto.

Per questo Efesto lavora contemporaneamente su più livelli.

La fusione dei valori fisici alimenta la struttura della previsione.

La fusione delle probabilità descrive le possibili condizioni meteorologiche.

I fenomeni secondari aggiungono informazioni che non devono essere perse durante il processo.

Alla fine questi elementi devono formare un insieme sufficientemente coerente da poter essere consegnato al passaggio successivo.

Anche la continuità temporale conta

Ogni fascia previsionale viene calcolata su un proprio insieme di informazioni, ma una previsione deve essere leggibile anche come evoluzione nel tempo.

Una sequenza che cambiasse continuamente da sereno a coperto, poi di nuovo sereno e immediatamente dopo nuvoloso senza un supporto reale sarebbe difficilmente credibile.

Efesto applica quindi già durante la fusione un primo controllo della continuità temporale.

L’obiettivo non è impedire i cambiamenti rapidi.

Un temporale può modificare realmente il tempo in poco tempo.

Il punto è distinguere un cambiamento sostenuto dalle informazioni disponibili da una semplice frammentazione prodotta dal calcolo.

Il Merge non è la previsione finale

Dopo tutti questi passaggi Efesto possiede una previsione fusa.

Ma questa previsione non viene ancora mostrata all’utente.

Il Merge rappresenta il miglior punto di incontro costruito in quel momento tra Vertumno e Lira.

Manca però ancora una domanda fondamentale:

come si è comportata in passato la pipeline quando si trovava in situazioni simili?

Per rispondere serve Metis.

Efesto consegna quindi il risultato del Merge al componente KNN insieme alle informazioni necessarie a comprenderne il contesto.

Metis riceve più di una semplice previsione

Perché Metis possa confrontare il caso corrente con la memoria storica non basta passargli il fenomeno meteorologico finale.

Il contesto della fusione contiene molte informazioni utili.

Vertumno era disponibile?

Lira era disponibile?

Quanto erano affidabili le due sorgenti?

Quanto erano d’accordo?

Quali valori avevano prodotto?

Come erano distribuite le probabilità?

Qual era la distanza temporale della previsione?

Questi elementi contribuiscono a descrivere il caso che Metis dovrà confrontare con lo storico.

In questo senso Efesto non consegna soltanto una previsione.

Consegna anche la storia di come quella previsione è stata costruita.

Efesto si ferma e lascia lavorare Metis

Una volta consegnato il risultato, Efesto non cerca di anticipare il comportamento del KNN.

Metis dispone di una responsabilità precisa: confrontare la situazione corrente con la memoria delle previsioni validate e decidere se esistono elementi sufficienti per confermare, rifinire o correggere alcuni aspetti della previsione.

Questo passaggio è separato dalla fusione.

È una distinzione importante perché evita di mescolare due problemi diversi.

Efesto cerca di costruire la migliore sintesi possibile delle sorgenti disponibili.

Metis cerca invece di capire se l’esperienza accumulata suggerisca che quella sintesi possa essere migliorata.

Il ritorno da Metis

Quando Metis termina il proprio lavoro viene prodotta la previsione canonica.

A quel punto Efesto entra nella seconda parte del proprio compito.

Il Forecast riceve il risultato canonico e lo utilizza come propria sorgente meteorologica finale.

Non torna a chiedere nuovamente una previsione a Vertumno.

Non esegue una seconda fusione con Lira.

Non ripete il KNN.

La decisione meteorologica è già stata presa.

Da questo momento il problema cambia completamente.

Bisogna preparare quella previsione per i diversi servizi che dovranno utilizzarla.

Una previsione, più rappresentazioni

Non tutti i componenti dell’ecosistema hanno bisogno delle stesse informazioni.

L’utente che apre il sito o l’app ha bisogno di una previsione comprensibile.

Il sistema di apprendimento ha invece bisogno di conservare dettagli tecnici che permettano in futuro di confrontare previsione e realtà.

Gli strumenti diagnostici devono poter capire perché Metis abbia effettuato o meno determinate modifiche.

Per questo Efesto prepara diverse rappresentazioni dello stesso risultato canonico.

PUBLIC: ciò che serve agli utenti

La vista PUBLIC rappresenta la previsione destinata alla distribuzione.

È quella che può essere utilizzata dal sito, dall’app e dagli altri servizi che devono mostrare il tempo previsto.

Qui il risultato viene organizzato nella forma necessaria alla presentazione: fenomeni, valori meteorologici, confidenza e informazioni utili all’interfaccia.

La vista pubblica non deve ricostruire nuovamente la previsione.

Parte dalla decisione canonica già prodotta da Metis e la rende utilizzabile.

SNAPSHOT: ricordare ciò che avevamo previsto

La vista SNAPSHOT ha uno scopo completamente diverso.

Serve a conservare una rappresentazione tecnica della previsione che possa entrare nel ciclo di apprendimento.

Quando alcune fasce vengono selezionate per lo storico, il sistema deve sapere esattamente cosa era stato previsto e con quali informazioni era stato costruito il risultato.

Per questo lo Snapshot conserva molti dettagli che non avrebbe senso mostrare direttamente all’utente.

Sono queste informazioni che, una volta arrivata la realtà, permetteranno di confrontare correttamente la vecchia previsione con ciò che è realmente accaduto.

MOTIVATION: capire perché Metis è intervenuto

Esiste poi una rappresentazione dedicata alle motivazioni.

Metis può confermare una previsione, applicare una rifinitura oppure modificare uno o più aspetti del risultato.

Per rendere osservabile il comportamento del sistema è utile conservare anche le informazioni che spiegano questo intervento.

La vista MOTIVATION serve proprio a separare questa parte diagnostica dalla previsione destinata normalmente all’utente.

In questo modo Meteo Gesualdo può non soltanto produrre una previsione, ma anche analizzare successivamente il comportamento del motore che l’ha modificata.

Una sola meteorologia, non tre previsioni diverse

PUBLIC, SNAPSHOT e MOTIVATION non rappresentano tre motori differenti.

E non rappresentano tre tentativi separati di prevedere il tempo.

La previsione meteorologica canonica è già stata decisa.

Efesto crea semplicemente rappresentazioni differenti perché gli utilizzatori a valle hanno necessità diverse.

È una distinzione importante per l’architettura:

una sola decisione meteorologica, più modi di utilizzarla.

La qualità dell’aria rimane separata dalla decisione meteo

Nella fase finale possono essere integrate anche informazioni che arricchiscono l’esperienza dell’utente.

Un esempio è la qualità dell’aria.

Questa informazione può comparire accanto alla previsione e diventare parte del servizio offerto da Meteo Gesualdo.

Ma non viene utilizzata da Metis per decidere se domani sarà sereno, nuvoloso o piovoso.

È quindi importante distinguere tra:

• informazioni che partecipano alla decisione meteorologica;
• informazioni complementari aggiunte successivamente alla rappresentazione finale.

Trend lavora soltanto dopo Efesto

Un altro elemento collegato al Forecast è Trend.

Trend non parte da Vertumno.

Non interroga Lira.

Non esegue il Merge.

E non modifica il risultato di Metis.

Legge la previsione PUBLIC già prodotta da Efesto e la organizza in una forma più sintetica.

Le numerose ore previste possono così essere trasformate in fasce temporali, andamenti, valori minimi e massimi e descrizioni dell’evoluzione della giornata.

La distinzione è quindi semplice:

Efesto costruisce e prepara la previsione. Trend la riassume.

Il Warm mantiene il percorso pronto

L’intera sequenza dipende anche da un livello operativo che cerca di mantenere aggiornate le diverse cache della pipeline.

Il Warm richiama i componenti nell’ordine necessario:

Local → API → Merge → KNN canonico → servizi complementari → viste Forecast.

Questo non significa che Warm possieda la logica meteorologica di Efesto.

Ogni componente rimane responsabile del proprio calcolo e della propria cache.

Warm coordina semplicemente l’esecuzione affinché il risultato possa essere già disponibile quando viene richiesto dal sito o dall’app.

Cosa succede se una sorgente manca?

Una pipeline reale deve anche gestire condizioni non ideali.

Una sorgente può non essere disponibile.

Può arrivare con informazioni incomplete.

Può avere una qualità inferiore rispetto alla situazione normale.

Efesto deve quindi conoscere non soltanto il valore prodotto da Vertumno e Lira, ma anche se quel valore esista e con quale qualità sia stato ottenuto.

La presenza o l’assenza di una sorgente diventa parte del contesto della fusione.

Questo permette al sistema di evitare di trattare un dato mancante come se fosse una normale previsione meteorologica.

Perché conservare così tanto contesto?

A prima vista potrebbe sembrare sufficiente salvare il risultato finale.

Se la previsione dice “nuvoloso”, perché ricordare anche quanto Vertumno e Lira fossero d’accordo, quali valori avessero prodotto e quale fosse il lead?

La risposta arriva dal ciclo di apprendimento.

Quando Metis cercherà nel passato situazioni simili, sapere soltanto che il risultato finale era “nuvoloso” non sarà sufficiente.

Due previsioni con la stessa classificazione finale potrebbero essere nate da contesti completamente differenti.

In un caso Vertumno e Lira potevano essere quasi perfettamente concordi.

In un altro potevano essere fortemente in disaccordo e il Merge aver prodotto un compromesso.

Per un sistema che vuole imparare dagli errori, questa differenza è estremamente importante.

Efesto è il punto d’incontro della pipeline

Vertumno è specializzato nel territorio.

Lira è specializzata nei modelli meteorologici.

Metis è specializzato nella memoria delle previsioni validate.

Efesto si trova esattamente nel punto nel quale questi mondi devono comunicare.

Prima prende due previsioni indipendenti e costruisce una sintesi.

Poi consegna quella sintesi a Metis.

Infine riceve il risultato canonico e lo trasforma nelle viste necessarie al resto del sistema.

Il suo ruolo può quindi essere riassunto in tre verbi:

fondere → consegnare → pubblicare.

La previsione finale nasce dal confronto

Efesto 9 rappresenta uno dei cambiamenti concettuali più importanti della pipeline di Meteo Gesualdo.

La previsione non nasce più dalla scelta preventiva di una singola sorgente.

Nasce dal confronto.

Vertumno porta ciò che il territorio sta raccontando.

Lira porta ciò che i modelli stanno descrivendo.

Efesto misura quanto queste due prospettive siano compatibili e costruisce una fusione coerente.

Metis confronta quella fusione con l’esperienza accumulata.

Efesto riceve infine il risultato e lo prepara affinché possa diventare la previsione che gli utenti vedranno realmente.

Non sceglie semplicemente quale sorgente ascoltare.

Costruisce il punto nel quale tutte le informazioni della pipeline possono finalmente diventare una sola previsione.