Davanti a un processo industriale, un modello generico può scrivere equazioni che tornano sulla carta e dimenticare ciò che il tecnico dà per scontato. Gli autori di un paper uscito a settembre fanno l'esempio del serbatoio che non può traboccare: nessuno lo scrive nella descrizione del problema, perché in reparto lo sanno tutti.
Il paper è stato pubblicato su arXiv il 15 settembre 2026 da cinque ricercatori del dipartimento di Data Science della City University di Hong Kong e, secondo la pagina del codice, è destinato ai Findings della conferenza EMNLP 2026. Descrive little m, un agente che aiuta a tradurre un processo industriale in un modello di ottimizzazione. È un lavoro accademico, provato su 50 esercizi presi da manuali universitari, non un'installazione in fabbrica.
Per chi in una PMI manifatturiera deve decidere come portare dentro un agente quello che sanno i suoi tecnici, i numeri più utili del paper stanno in due prove secondarie. Da lì si ricavano due cose pratiche: di che cosa è fatta una scheda di conoscenza, e in quali punti l'agente deve fermarsi a chiedere.
Cosa fa little m
Si parte da una descrizione a parole di un impianto — un evaporatore, una colonna di distillazione, un serbatoio di miscelazione — quasi sempre accompagnata dallo schema dell'impianto. Si arriva a un modello matematico: quali grandezze si possono regolare, che cosa si vuole minimizzare o massimizzare, quali vincoli vanno rispettati. Quel modello poi lo userà un ingegnere, dopo averlo controllato.
Invece di chiedere tutto al modello linguistico in un colpo solo, little m lavora in tre fasi, che secondo gli autori ricalcano il modo di lavorare di un ingegnere di processo:
- Raccolta delle informazioni. L'agente riordina quello che ha ricevuto e segna cosa manca.
- Strategia. Sceglie che tipo di problema è e come affrontarlo.
- Modello. Scrive le equazioni, e per ogni simbolo indica da quale dato viene.
A ogni fase attinge a una base di conoscenza di 55 schede: 45 valide per l'industria di processo in generale e 10 specifiche per la produzione della birra. Il modello linguistico è Gemini 2.5 Pro di Google, il recupero delle schede è un normale sistema RAG. Le schede, gli esercizi e una versione del flusso senza le domande all'utente sono pubblici su GitHub.
Gli autori non vendono il sistema. Il lavoro è finanziato dalla City University e da un centro di ricerca congiunto con Baosteel, un grande produttore cinese di acciaio.
Il vincolo che nessuno scrive
Il passaggio da cui parte tutto è nella descrizione dell'architettura. I problemi industriali, scrivono gli autori, spesso si appoggiano su una conoscenza non dichiarata, e l'esempio che fanno è questo:
«tacit knowledge» that is not explicitly stated in the prompt, e.g., assuming a tank cannot overflow.
Un modello che traduce direttamente il testo in equazioni, proseguono, spesso inventa vincoli sbagliati o dimentica proprio questi limiti di sicurezza impliciti.
Conoscenza tacita è un'espressione resa nota dal filosofo Michael Polanyi con The Tacit Dimension, nel 1966: la parte di quello che sappiamo che non riusciamo a dire del tutto. Nel linguaggio delle aziende indica anche, più semplicemente, quello che un tecnico sa e non ha mai scritto, spesso perché non gli viene in mente che vada detto. In un reparto ha forme molto concrete. La temperatura oltre la quale il prodotto si rovina anche se la scheda tecnica dice un'altra cosa. La valvola che va aperta prima dell'altra. Il sensore che legge in ritardo e a cui nessuno crede più.
Un modello generico queste cose non le può indovinare, perché non stanno nel testo che riceve. Rischia di scrivere un modello pulito, coerente, e sbagliato nel punto che per il capoturno era ovvio.
I numeri, letti per quello che dicono
Nell'abstract gli autori scrivono che little m «substantially outperforms», cioè supera nettamente, i modelli di punta con cui l'hanno confrontato: Qwen3-Next, la versione da 80 miliardi di parametri del modello di Alibaba, e DeepSeek-V3.2. Le tabelle raccontano una storia più misurata.
C'è anche un confronto che il paper non fa. little m usa Gemini 2.5 Pro, gli altri due sono modelli diversi, usati da soli. Nessuna prova mette Gemini senza le tre fasi davanti agli stessi esercizi: una parte del vantaggio può venire dal modello di base, non dal metodo.
La valutazione umana. Otto valutatori, dottorandi e ricercatori post-dottorato (tre di informatica, due di scienza dei dati, tre di ingegneria del controllo), hanno confrontato alla cieca le risposte dei tre sistemi su 20 dei 50 casi, da due a quattro persone per caso. Hanno preferito little m nel 58% dei voti sulla funzione da ottimizzare, nel 60% sulle variabili, nel 52% sui vincoli e nel 66% sulla qualità complessiva. Scegliendo a caso fra tre, ci si aspetterebbe il 33%. Il risultato è netto, ma su un campione piccolo e con valutatori accademici, non con tecnici di impianto: sulla familiarità con il controllo di processo, solo due degli otto si danno 4 su 5, nessuno 5.
La valutazione automatica, su tutti i 50 casi, misura quanto il modello prodotto somiglia alla soluzione di riferimento, con un punteggio da 0 a 1. Sulle variabili little m ottiene 0,733 contro lo 0,699 di DeepSeek. Sui vincoli 0,418 contro 0,395. Sulla funzione da ottimizzare è sotto: 0,518 contro 0,553. Gli autori lo riconoscono: questi numeri, scrivono, non sostengono l'idea che il sistema a fasi migliori ogni parte del modello.
Due limiti vanno tenuti presenti leggendo tutto il resto. Il primo: i casi vengono da manuali universitari, e gli autori stessi scrivono che non si può escludere che i modelli li abbiano già visti durante l'addestramento. Il secondo: la prova confronta i modelli scritti dagli agenti con una soluzione di riferimento, ma non li fa girare. Nessuno ha verificato che funzionino su un impianto vero.
Sui vincoli, poi, nel confronto principale nessuno dei tre sistemi supera 0,42. È la parte più difficile per tutti.
Il dato mancante pesa più della scheda generica
I numeri utili per una PMI sono in due prove più piccole, alla fine della sezione sperimentale.
Senza la base di conoscenza. Gli autori hanno rifatto la prova togliendo le 55 schede. Le variabili passano da 0,733 a 0,720, la funzione da ottimizzare da 0,518 a 0,510, i vincoli da 0,418 a 0,381. È l'effetto più visibile, ed è sui vincoli, ma resta piccolo. Togliere lo schema dell'impianto pesa di più sulla funzione da ottimizzare, che scende a 0,468.
Con le informazioni incomplete. Poi hanno tolto dalla descrizione dei problemi alcune informazioni: la struttura del processo, i limiti di funzionamento o i dati sul controllo. Senza quelle informazioni, e senza possibilità di fare domande, i vincoli scendono a 0,314. Lasciando che l'agente faccia domande prima di scrivere il modello, tornano a 0,423: appena sopra lo 0,418 della descrizione completa. Le variabili salgono a 0,802, più che con la descrizione completa. La funzione da ottimizzare, invece, recupera poco: da 0,431 a 0,443.
Messe insieme: sui vincoli, togliere le schede costa meno di quattro centesimi di punteggio; far domandare l'agente ne recupera undici.
Il confronto va preso con cautela, per tre ragioni. Gli undici punti misurano quanto valevano informazioni tolte apposta, e a restituirle non era una persona ma un simulatore, che le rivelava solo se la domanda le riguardava: gli autori scrivono che non riproduce il comportamento di un utente reale. Le schede sono conoscenza generica da manuale, provata su esercizi da manuale che il modello forse aveva già visto: che togliendole cambi poco non dice quanto varrebbero schede scritte con i tecnici di un'azienda. E il paper non prova mai le schede con e senza le domande, né misura il peso delle tre fasi da sole.
Quello che ne ricaviamo è quindi una lettura nostra, più che un risultato del paper: su questi esercizi, accorgersi di cosa manca e chiederlo ha pesato più di una base di conoscenza generica. Per chi costruisce un agente, vuol dire progettare le domande con la stessa cura delle schede.
Di che cosa è fatta una scheda di conoscenza
Le schede di little m sono il pezzo più riutilizzabile del lavoro, perché mostrano una forma. Ognuna parte da un problema che si vede in reparto e arriva a quello che serve per affrontarlo. I campi sono sei:
- Il sintomo osservabile. Quello che succede e che qualcuno nota: la concentrazione del prodotto cambia dopo ogni variazione dell'alimentazione, e poiché la misura arriva in ritardo il vapore viene corretto di continuo, oltre il necessario. Il sintomo serve a ritrovare la scheda; la diagnosi viene dopo.
- L'obiettivo. Che cosa migliorare, e che cosa non va peggiorato nel farlo: stabilizzare la concentrazione senza uscire dai limiti di qualità e senza sprecare vapore.
- I metodi possibili, con le loro condizioni. Ogni metodo accompagnato dalla condizione che lo giustifica: uno se il disturbo si misura in modo affidabile, un altro se esiste un modello dinamico validato.
- Le informazioni che servono. L'elenco dei dati senza i quali la scheda non si applica. È il campo che dice all'agente cosa chiedere.
- Gli schemi di vincoli ricorrenti. Bilanci di massa ed energia, limiti degli attuatori, ritardi di misura.
- I limiti di applicabilità. Dove la scheda smette di valere, e cosa resta da confermare con chi conosce l'impianto.
Nei progetti che vediamo, quando un'azienda raccoglie la conoscenza dei suoi tecnici, mancano spesso le informazioni che servono e i limiti di applicabilità. Si scrive come si fa una cosa; raramente cosa bisogna sapere prima, e quando non la si deve fare.
Nel file pubblico delle schede, in apertura, c'è una frase che vale per qualunque base di conoscenza aziendale: le soglie di temperatura, tempo, pressione, concentrazione, portata e qualità che contiene «must not be used directly as plant setpoints», non vanno usate direttamente come valori di impianto. I limiti veri devono venire dai documenti del singolo stabilimento.
Per un'azienda, tradurre questa forma significa sedersi con un tecnico e partire dai sintomi, non dai procedimenti. «Quando vedi questo, cosa guardi prima? Cosa ti serve sapere per decidere? Quando la tua regola non vale più?» Le risposte alla terza domanda sono i vincoli che nessuno ha mai scritto. Le domande fanno emergere quello che il tecnico sa dire ma non ha mai messo per iscritto; la parte che non sa dire si recupera solo guardandolo lavorare.
Fra i limiti, il paper lo scrive chiaramente: estendere la base di conoscenza a un nuovo settore «requires expert curation for each target domain», richiede che qualcuno del mestiere la curi, settore per settore. Le schede non si generano. Si scrivono con chi lavora in reparto.
Quando l'agente deve fermarsi e chiedere
Il secondo pezzo riutilizzabile è dove little m si ferma. I punti di controllo sono tre, uno per fase, e in ognuno l'agente mostra quello che ha fatto e aspetta.
Dopo la raccolta delle informazioni. L'agente produce un riepilogo in cui ogni voce ha un segno: informazione sufficiente, parzialmente mancante, gravemente mancante. Poi chiede se il riepilogo descrive davvero la situazione e se c'è da aggiungere qualcosa. È il punto in cui un tecnico vede scritto «capacità del serbatoio: non indicata» e se ne accorge.
Dopo la strategia. L'agente propone un solo approccio, motivato, e chiede conferma prima di scrivere una sola equazione. Il controllo arriva prima dei dettagli, quando correggere costa poco.
Dopo il modello. Ogni simbolo del modello deve avere accanto il dato da cui viene, oppure essere segnato come non risolto. I parametri che nessuno ha fornito restano parametri, invece di diventare numeri inventati. Poi una lista di controlli: ogni collegamento dello schema è rappresentato? Le unità di misura tornano? Ci sono i limiti di funzionamento?
Gli autori scrivono anche cosa questi punti non fanno. Un punto di controllo, scrivono, è un'occasione per correggere, non una garanzia che l'errore non ci sia. E il sistema è pensato come «a formulation assistant, not an autonomous decision-maker»: un assistente che prepara il modello, non uno che decide. Ogni modello va rivisto da una persona prima di essere usato su un processo in cui la sicurezza conta.
Da noi è la quarta delle fasi con cui costruiamo un flusso: coinvolgere le persone quando serve una scelta, con tutto il contesto davanti. La lezione pratica, per come la leggiamo noi: poche fermate, in punti fissi, e a ogni fermata l'agente arriva con una domanda precisa.
Prima di dare all'agente il primo manuale
Il riflesso, quando si porta un agente su un processo che conoscono in pochi, è raccogliere manuali, procedure e schede tecniche e caricarli tutti. Il paper su little m suggerisce di spostare l'attenzione. Nei suoi numeri le schede generiche, provate su esercizi da manuale, pesano poco. Pesa di più che l'agente sappia distinguere quello che sa da quello che gli manca, e che si fermi a chiederlo nei punti giusti.
Le due cose si preparano insieme. Una scheda scritta partendo dal sintomo, con le informazioni necessarie e i limiti di applicabilità, dice all'agente cosa chiedere. Tre fermate fisse dicono quando. Il resto lo fanno i tecnici, rispondendo.
Qual è il vincolo che nel tuo reparto tutti sanno e nessuno ha mai scritto?