Perché l'RL batte le euristiche in produzione
Una retrospettiva sulla sostituzione di uno scheduler basato su regole in Dekali con una policy RL — e sulle regole tacite che nessuno aveva mai scritto.
Quando sono entrato nel team di pianificazione di Dekali, giravano con uno scheduler euristico cresciuto in quattro anni. Ogni settimana qualcuno aggiungeva una regola per una specifica escalation cliente. Nessuno ne toglieva una da diciotto mesi. Il risultato era una catena di if/else da 1.400 righe che funzionava in media e falliva in modo catastrofico due volte a trimestre.
Il passaggio al Reinforcement Learning veniva presentato in azienda come una scommessa di ricerca. Col senno di poi era un cambiamento organizzativo travestito da intervento tecnico. Sostituire 1.400 righe di condizionali con una policy appresa ci ha costretti per la prima volta ad articolare cosa stessimo effettivamente ottimizzando. La risposta onesta era: non lo sapevamo.
Abbiamo costruito prima un simulatore discreto a eventi dell'impianto. Era quello il vero artefatto. Una volta che ci fidavamo, abbiamo addestrato una policy PPO con tre componenti di reward: makespan, compatibilità skill operatore, costo di setup macchina. La prima reward era sbagliata e la policy "barava" sul makespan congelando i job a bassa priorità. La seconda era più vicina ma preferiva gli operatori visti spesso in training.
Il deployment è stata la parte difficile. Niente switch: sei settimane di shadow run, loggando ogni disaccordo tra la policy e il supervisore. L'ottanta per cento dei disaccordi erano la policy che aveva ragione. Il restante venti per cento erano cose che il supervisore sapeva e la policy no — sono diventate feature la settimana dopo.
Due lezioni: cattura le regole tacite, perché l'RL non le apprende guardando i dati; e l'explainability batte l'accuratezza, perché in una PMI la fiducia è l'unica valuta che hai.