Un'azienda riceve diecimila eventi al giorno. Ordini, foto del controllo qualità, ticket dei clienti, letture dei sensori. Qualcuno deve decidere quali richiedono intervento, entro quanto tempo, e quanto costa sbagliare. Il problema è questo. Non se un modello sappia descrivere quegli eventi con una bella prosa.
Eppure molte delle offerte che vedo partono dallo stesso punto: si attacca un LLM a un'interfaccia e lo si chiama AI. In demo funziona benissimo. Risponde anche a una domanda che in produzione nessuno aveva fatto.
La tentazione del modello universale
Capisco perché l'LLM sia la scelta predefinita. La demo si fa in un pomeriggio, l'input può essere disordinato, il risultato si mostra facilmente a un consiglio di amministrazione. E gli LLM di oggi non si limitano a chiacchierare: possono restituire JSON che rispetta uno schema rigido. La documentazione di OpenAI sugli Structured Outputs è però onesta sul punto debole. Lo schema può essere valido e i valori dentro possono essere sbagliati lo stesso.
Un formato valido non è una decisione corretta. È un'ipotesi vestita bene.
Due domande, non una
Gran parte della confusione nasce dal mettere tutti i termini sullo stesso asse. Le domande sono due. Che cosa fa il sistema: stima, classifica, rileva anomalie, genera, ottimizza? E come elabora i dati: modello statistico, alberi, rete convoluzionale, encoder di testo, modello a stati, transformer generativo, rete su grafi?
"Machine learning contro AI" è una lite finta (il ML è il contenitore, gli LLM ci stanno dentro). Il confronto vero è tra metodi scelti per il compito e un LLM usato come punto di partenza per qualsiasi cosa.
Prendiamo i dati tabellari: abbandono dei clienti, priorità, rischio di errore amministrativo. Si parte da una regressione logistica o da una regola semplice come baseline, poi alberi e boosting, poi reti neurali se le prove lo giustificano. Grinsztajn, Oyallon e Varoquaux hanno trovato modelli ad albero molto competitivi su dataset tabellari di medie dimensioni. Uno studio più ampio presentato a NeurIPS 2023 da McElfresh e colleghi mostra che non esiste un vincitore universale. La lezione non è "vincono gli alberi". La lezione è: fate il confronto.
Le immagini chiedono modelli visivi che leggano pattern locali. I flussi di eventi chiedono modelli che rispettino l'ordine: baseline statistiche, modelli ricorrenti, modelli a stati come Mamba, che elabora sequenze con costo lineare rispetto alla lunghezza. Proprietà dell'architettura, attenzione, non un risultato garantito sui dati del vostro impianto. Un encoder di testo può smistare un ticket senza scriverci sopra un paragrafo.
Dove il generativo è di casa
Niente di tutto questo è contro gli LLM. Spiegazioni, richieste aperte, sintesi di materiale eterogeneo, una persona che esplora un caso segnalato: lì il modello generativo gioca in casa. A volte l'LLM è anche lo strumento migliore per un compito circoscritto. Decide la verifica, non la tassonomia.
Quello che entra in azienda raramente è un modello solo. È una catena: dati, valutazione, regole e soglie, revisione o azione, monitoraggio. Modelli diversi a ogni anello. Codice che stabilisce cosa succede se manca un campo, se una probabilità è incerta, se l'errore costa caro. Il mercato ha già un nome per questo, Decision Intelligence, e non ho alcuna intenzione di rivendicarne l'invenzione. La differenza sta nel modo in cui si progetta e si verifica il sistema decisionale concreto.
Perché conta per la vostra azienda
Prima di scegliere un modello, fissate una baseline, umana o software. Misurate per segmento: precision, recall, falsi positivi, falsi negativi, calibrazione se usate probabilità, costo per caso e carico di revisione. Concordate con il business quale errore fa più male. Poi test offline, pilot dentro il flusso reale, monitoraggio dopo. Una probabilità serve solo se è calibrata sui casi in cui verrà usata, e i classificatori profondi sono noti per sbagliare con grande sicurezza fuori dai dati che hanno visto.
Gli eventi continuano ad arrivare, qualunque sia il modello di moda questo trimestre. La domanda da fare a un fornitore, a qualsiasi fornitore, è semplice: quale decisione migliora, rispetto a quale baseline, con quali errori residui, e chi ne risponde? L'architettura segue la risposta.
Pan