Scenario illustrativo. Un cliente chiede due volte nella stessa mattina all'agente di assistenza se può rendere un ordine dopo 40 giorni. Alle 9:10 l'agente risponde: «Sì, hai 60 giorni». Alle 11:30, con le stesse parole, risponde: «Secondo il tuo ordine, il termine è di 30 giorni; contatta un consulente». Entrambe le risposte sembrano ragionevoli, le ha generate lo stesso sistema e una delle due sta per diventare un reclamo. Nessuno ha toccato nulla nel frattempo.
La tesi in una riga: la variabilità di un modello non è un difetto da riparare, è una proprietà da limitare. Decidi quali parti del processo non possono mai variare, quali tollerano variazione e come la misuri prima che la veda un cliente.
Perché l'IA risponde in modo diverso alla stessa domanda?
Perché un modello linguistico non recupera una risposta salvata: la calcola ogni volta. A ogni passo distribuisce probabilità tra le parole possibili e ne sceglie una, e quella scelta contiene per progetto una componente di casualità; il parametro che la regola si chiama temperatura. Per questo la stessa domanda può produrre formulazioni diverse e, quando la domanda lascia dei vuoti, conclusioni diverse.
Ci sono altre tre fonti di variazione che si dimenticano spesso. La prima è ciò che circonda la domanda: l'ordine in cui il sistema recupera i documenti, la data, la cronologia o la memoria cambiano il contesto e, con esso, la risposta. La seconda è il server: anche con temperatura zero, la maggior parte dei servizi di inferenza non garantisce risultati identici, perché il calcolo numerico dipende dal carico del server in quel momento (Thinking Machines, 2025). La terza è il fornitore: un cambio di versione del modello o delle sue impostazioni sposta il comportamento senza che tu tocchi nulla, lo stesso effetto che spieghiamo in perché un agente di IA peggiora nel tempo anche se nessuno ha cambiato niente.
Si può eliminare la variabilità abbassando la temperatura?
In parte, e del tutto non converrebbe. Abbassare la temperatura riduce la dispersione nella formulazione ma non la elimina (la fonte qui sopra spiega perché), e non cambia né ciò che il modello sa né ciò che gli arriva. Non corregge nemmeno l'errore: a bassa temperatura, un modello sbagliato sbaglia in modo più coerente. Ne parliamo in ridurre le allucinazioni dell'IA in produzione. E una certa variazione è proprio ciò che vuoi: permette a un riassunto o a una risposta di adattarsi al caso invece di suonare come un modulo.
La domanda utile non è «come faccio a farlo rispondere sempre uguale?», ma «in quali punti del processo non può rispondere in modo diverso?».
Quali parti di un processo devono essere deterministiche e quali tollerano variazione?
La regola: ciò che il cliente può citare, e ciò che muove denaro o impegni, non nasce dalla generazione libera. Nasce da una regola, da un dato o da un modello; il modello, al massimo, lo mette in parole.
| Parte del processo | Tollera variazione? | Dove deve vivere |
|---|---|---|
| Termini, importi, condizioni, date | No | In un dato del tuo sistema o in una regola di codice; il modello lo cita, non lo calcola |
| Decisione di instradamento o classificazione | Poca | Output chiuso (un elenco di categorie), soglia di confidenza e revisione dei casi dubbi |
| Redazione, tono, riassunto | Sì | Nelle istruzioni e negli esempi; il modello ha margine al loro interno |
| Azioni con effetto (inviare, addebitare, cancellare) | No | In una validazione deterministica prima dell'esecuzione e in permessi circoscritti |
Se quasi tutto il tuo processo ricade nelle righe del «No», forse non ti serve un agente: un flusso classico costa meno ed è più facile da verificare, come spieghiamo in come automatizzare processi con agenti, non con chatbot. E ciò che lasci al modello si definisce nelle sue istruzioni: cosa deve citare, cosa non può affermare e cosa fa quando non ha il dato.
Come si misura la variabilità di un agente prima di metterlo in produzione?
Con una prova noiosa e ripetibile. È un metodo, non un numero magico:
- Raccogli casi reali. Un insieme di input della tua operatività, compresi quelli ambigui e rari, non quelli della demo.
- Ripetili. Fai passare ogni input più volte nel sistema completo (con il suo recupero di documenti, non solo il modello) e conserva ogni output.
- Confronta ciò che conta. Sui campi di decisione (categoria, importo, sì o no), pretendi una corrispondenza esatta. Sul testo, confronta con una griglia: dice la stessa cosa nella sostanza?
- Fissa una soglia per campo. Un campo che muove denaro tollera zero discrepanze; un riassunto interno ne tollera di più. Decidi le soglie prima di guardare i risultati.
- Ripeti la prova a ogni cambiamento. Modello nuovo, istruzioni nuove, fonte di documenti nuova: si ripassa.
Quella prova è una eval, e progettarla e mantenerla fa parte di valutare la qualità degli agenti di IA. Una volta che l'agente è in funzione, il passo successivo è misurare le prestazioni delle tue automazioni, perché la variazione non si infiltri di notte.
Cosa fai se due risposte contraddittorie sono già arrivate a un cliente?
Prima ricostruisci cosa è successo: senza il registro di input, contesto recuperato, versione del modello e output, non puoi sapere quale delle due fosse quella giusta. Poi chiudi la falla:
- Porta il dato fuori dal testo libero. Se la contraddizione riguardava un termine o una condizione, smetti di generarlo: fallo leggere da una fonte unica.
- Fai in modo che il sistema si verifichi da solo. Per le risposte a rischio, genera due volte e, se non coincidono nella sostanza, non inviare: passa a una persona. Costa di più per risposta, quindi riservalo ai punti in cui l'errore costa caro.
- Adegua l'autonomia al rischio. Ciò che non può variare e non puoi validare automaticamente lo rivede un umano prima dell'invio. A questo servono i livelli di autonomia di un agente e l'umano nel ciclo.
Quando non vale la pena inseguire la coerenza?
Quando l'output è una bozza che una persona leggerà e ritoccherà, quando l'errore è economico e reversibile, o quando la variazione è il valore (idee, varianti di un testo). Pretendere variazione zero lì rende il sistema più caro senza proteggere nessuno. Spendi il rigore dove una risposta diversa costa denaro o fiducia, e lascia respirare il resto.
La riga da portare via: non chiedere al modello di essere sempre uguale; progetta il processo in modo che ciò che non può cambiare non dipenda da lui.
Fonti (consultate il 29 ottobre 2026): «Defeating Nondeterminism in LLM Inference», Thinking Machines Lab (10 settembre 2025), usata in modo qualitativo. Lo scenario di apertura è illustrativo.