Un world model per una valvola vera: guasti rilevati in cinque secondi senza averne mai visto uno
Nella parte precedente il banco era una mini-centrale termica simulata: comoda, controllabile, ma pur sempre un modello del mondo e non il mondo. La domanda vera restava aperta: la ricetta regge su dati veri? In questa nota la risposta. Abbiamo preso uno dei benchmark classici del fault detection industriale — la telemetria di una valvola pneumatica di uno zuccherificio polacco, registrata nel 2001 — e applicato la stessa procedura, quasi senza ritocchi. Il verdetto in anticipo: sui guasti che il cruscotto rende visibili, il modello li rileva entro cinque secondi dall'inizio, senza averne mai visto uno in training.
Il banco: una valvola vera
Il benchmark si chiama DAMADICS ed è nato per confrontare i metodi di diagnosi su attuatori industriali. I dati sono telemetria vera: tre valvole pneumatiche dello zuccherificio di Lublino, osservate per 25 giorni nel novembre 2001, un campione al secondo per grandezza. Per la valvola di portata che abbiamo scelto (sigla FC57_03) fanno oltre due milioni di campioni per ciascuna delle sei grandezze: comando del regolatore, posizione dello stelo, portata, pressione a monte e a valle, temperatura.
Nel mezzo della conduzione normale, il benchmark documenta 19 episodi di guasto di quattro tipi: caduta dell'alimentazione d'aria, salto di pressione a monte, bypass aperto, sensore di portata guasto. Sono guasti brevi — da quattordici secondi a qualche minuto — iniettati di proposito dagli autori, con inizio e fine certificati al secondo. Per noi sono oro: una verità terreno su cui misurare rilevazioni e ritardi, che nella simulazione dovevamo costruirci a mano.
Dalla telemetria al cruscotto
LeWorldModel parla per immagini; una valvola parla in serie temporali. Il ponte è rendere la telemetria un'immagine: ogni blocco di cinque secondi diventa un quadro strumenti 224×224 — due strumenti a lancetta per la posizione dello stelo e la portata, barre orizzontali per il comando del regolatore e le due pressioni, un indicatore sottile per la temperatura. L'azione che il modello riceve a ogni passo sono i cinque valori del comando del regolatore nel blocco. Vincolo d'onestà: nel cruscotto entrano solo grandezze che i sensori misurano davvero; le etichette di guasto restano fuori, nei metadati usati solo in valutazione.
Il training: solo il funzionamento normale
Dai 25 giorni abbiamo tenuto solo i periodi sani: 81 episodi di conduzione normale, 423.567 blocchi da cinque secondi. Training da zero con la ricetta immutata, otto epoche su una GPU a noleggio, fermato quando la loss si è assestata. Di guasti, ancora una volta, il modello non ha visto l'ombra: ha imparato soltanto a prevedere il prossimo blocco di telemetria data la storia recente e ciò che il regolatore sta facendo.
I numeri
La valutazione mette di fronte le sei finestre registrate attorno ai guasti della valvola — cinque minuti prima e cinque dopo l'inizio certificato — e trenta finestre di controllo pescate nei periodi sani. La soglia d'allarme è la regola di sempre: media più tre deviazioni standard degli errori su funzionamento normale.
Sul guasto al sensore di portata la risposta è netta: AUC 1,000, tre finestre su tre rilevate, e la sorpresa supera la soglia già al primo blocco dopo l'inizio — cinque secondi. L'errore schizza a cento volte la baseline e rientra in una ventina di blocchi, seguendo la durata reale del guasto. Sul salto di pressione, il guasto più corto (quattordici-ventidue secondi), due finestre su tre: quella mancata è la più breve di tutte e sul cruscotto lascia una firma troppo debole — l'errore resta sotto metà della soglia. Va detto con onestà: la letteratura ventennale su questo benchmark lavora con metodi dedicati, supervisionati o statistici, allenati anche sugli esempi di guasto; il nostro modello ne ha visti zero, e cinque finestre su sei le riconosce subito.
La demo: il nodo sensore in diretta
Il modo migliore per giudicare è guardarlo lavorare. La demo interattiva riproduce due ore vere del 17 novembre 2001 — quelle con cinque guasti — come un flusso live: il cruscotto che il modello vede (i frame originali, non una ricostruzione), la curva dello stupore con la soglia, l'allarme che scatta. A velocità reale dura due ore come la realtà; a 240× si guarda in trenta secondi. È la prova generale di ciò che farebbe un nodo sensore attaccato alla valvola: niente cloud, niente etichette, solo il modello che si stupisce.
Cosa manca
Tre limiti dichiarati. Primo: un solo attuatore su tre e due tipi di guasto su quattro in valutazione — le altre valvole e gli altri guasti aspettano il loro training. Secondo: il salto di pressione breve resta il punto debole; la strada per rafforzarlo passa da una grana temporale più fine o da strumenti più sensibili alla pressione. Terzo: il conto che decide tutto, cioè quanto hardware serve per far girare il modello attaccato alla valvola, è per ora un conto di massima — tre millisecondi a blocco su GPU, una cinquantina su CPU da laptop, contro i cinque secondi del blocco — e va misurato su hardware vincolato vero. È il prossimo esperimento del filone.
La direzione però è quella giusta: la stessa ricetta che funzionava nella centrale simulata regge sulla telemetria vera, con numeri che un manutentore può usare. Un world model piccolo, allenato solo sul funzionamento normale, può stare attaccato a un componente e fare la guardia. Resta da misurare quanto piccolo può diventare l'hardware che lo ospita.
Note e riferimenti
Questa è la quarta parte di una serie: la teoria, la verifica del modello altrui, l'impianto simulato nelle parti precedenti. Il modello è LeWorldModel (Maes et al., 2026), fondato su LeJEPA (Balestriero & LeCun, 2025); training con il codice pubblico le-wm su stable-worldmodel. I dati sono il benchmark DAMADICS (Bartyś & Syfert, «DAMADICS Benchmark Definition», 2002), registrati allo zuccherificio di Lublino.
Note di metodo: blocco da 5 secondi (5 campioni a 1 Hz); il frame è il cruscotto delle medie di blocco; azione = i 5 valori del comando del regolatore, standardizzati sul training set; sorpresa = errore quadratico tra il latente predetto (storia di 3 blocchi + azioni) e il latente del frame reale successivo; soglia = media + 3σ su 30 finestre di controllo fault-free, stimata sui blocchi a regime; latenza = primo blocco dopo l'inizio del guasto con errore sopra soglia, in blocchi da 5 secondi; loss di validazione a fine training 0,024, in plateau da tre epoche.