20 maggio 2026 | 2 min lettura | Saggio
Il non determinismo non è un bug
Questo non vuol dire abbandonare il controllo, ma capire dove il controllo è utile e dove invece diventa un vincolo.
Nel mondo dell’AI, non determinismo è un termine che viene usato spesso in senso negativo. Significa che dato lo stesso input, un large language model non produce lo stesso output: cambia qualcosa, anche di poco, ogni volta. La risposta più frequente è cercare di tenerlo sotto controllo con guardrail, prompt rigidi, temperatura azzerata. E capisco l’idea di fondo, perché quando costruisci un sistema che deve essere affidabile, la variabilità sembra il nemico naturale dell’affidabilità.
Nei primi test che stiamo conducendo con i dati dei nostri clienti, io, Leo e Da abbiamo provato a far girare il framework in due modalità diverse. Nella prima, il modello riceveva un insieme di dati di contesto e istruzioni precise su dove guardare e come valutare ciò che trovava. Nella seconda, le istruzioni erano quasi assenti e il modello era libero di muoversi. Il sistema costruisce un albero di percorsi possibili, li valuta con un algoritmo di scoring che copre l’intero universo dei dati disponibili, e sceglie la strada che porta al segnale più interessante.
Il contesto e le istruzioni aiutano: danno struttura, riducono gli errori ovvi e tengono il sistema concentrato su ciò che conta. Ma la versione libera ha trovato cose che la versione guidata non avrebbe mai cercato. Relazioni tra variabili che nessuno aveva collegato. Segnali deboli che vivono nell’incrocio tra dati che normalmente non si guardano insieme. Anomalie che non avevano un nome, e che proprio per questo non erano mai finite in nessuna dashboard.
Se la nostra proposta di valore è andare oltre il perimetro delle dashboard, trovare ciò che nessuno sapeva di cercare, allora un sistema solamente deterministico è in qualche modo una contraddizione interna: esplora sempre gli stessi percorsi, con la stessa logica, e restituisce sempre la stessa risposta. È affidabile nel senso in cui lo è una dashboard, ovvero ti dice bene quello che ti aspettavi di sapere, ma non è attrezzato per sorprenderti.
Questo non vuol dire abbandonare il controllo, ma capire dove il controllo è utile e dove invece diventa un vincolo. Le metriche che un CFO porta in board devono essere riproducibili, e per quel lavoro il determinismo è la scelta giusta. Un sistema che esplora i dati alla ricerca di segnali che nessuno ha ancora pensato di cercare ha bisogno di qualcosa di diverso: deve potersi muovere in modo che non puoi prevedere del tutto, altrimenti non farà mai nulla che un team di data science non avrebbe già fatto. Quello che stiamo cercando di costruire in Southwind tiene entrambe le cose separate e le fa lavorare insieme, perché sono due lavori diversi e confonderli è probabilmente l’errore più comune quando si costruisce su questi modelli.
Ci tengo ad essere chiaro su questo punto: non so ancora fino a dove si può spingere questa idea, e i test che stiamo facendo sono ancora pochi. Ma quello che abbiamo visto finora mi ha convinto che trattare il non determinismo come un problema da risolvere sia la direzione sbagliata, almeno per quello che stiamo cercando di fare.