Una RNN che ha imparato il ritmo di una fabbrica italiana

Un ordine di produzione in Dekali attraversa da sei a dodici fasi nominate — taglio, piegatura, saldatura, finitura, ispezione — a seconda del prodotto. La fabbrica aveva un sistema che registrava ufficialmente inizio e fine di ogni fase, ma nessuno lo usava in modo consistente. Gli operatori loggavano quando se ne ricordavano. Il "dato" era una poltiglia di timestamp con il venti per cento mancante e un altro venti percento ovviamente sbagliato.

La richiesta del management era semplice: dimmi, per un ordine in lavorazione, in quale fase si trova davvero e quanti euro avrà consumato alla consegna. Due domande, un modello. Una RNN — una piccola GRU bidirezionale — perché l'input è naturalmente una sequenza: ogni evento registrato, in ordine temporale, con operatore e ID macchina. Due teste in output: softmax sulle fasi, regressione sui costi residui.

Il training era sul log sporco, ma un passo di preprocessing ha fatto tutto. Per ogni ordine costruivamo due sequenze parallele: il "loggato" ufficiale e l'"inferito reale", usando l'invariante che non si può saldare prima di tagliare. I disaccordi diventavano una terza feature: una confidence per evento. Il modello imparava a pesare gli eventi sicuri e ignorare i contradditori, senza che nessuno curasse a mano il dataset.

L'head di fase ha raggiunto il 92% su un mese di holdout. L'head di costo era a ±6% in media. Numeri non impressionanti in classifica. Numeri rivoluzionari in fabbrica, perché il tool precedente — uno spreadsheet della responsabile ufficio — non aveva alcun concetto di incertezza.

Lezione: in ambito industriale, il gap tra "dati che abbiamo" e "dati che ci servono" si colma con priors di dominio, non con modelli più grandi. Una GRU bidirezionale a tre layer ha battuto un transformer molto più grosso, perché i priors erano cotti nel feature engineering. Vincono i priors.