No. 003Determinismo9 min di lettura

Il numero di fatturato sbagliato con aria sicura: perché i LLM non sanno fare i conti

Il modello ti consegna un dato di fatturato con postura impeccabile e nessuna aritmetica alle spalle. La ricerca dice che il fallimento è strutturale — e lo è anche la soluzione.

Nell'ottobre 2025, Deloitte ha restituito denaro al governo australiano. La società aveva consegnato una revisione da 440.000 dollari australiani al Department of Employment and Workplace Relations; il rapporto pubblicato conteneva una citazione inventata da una sentenza di un tribunale federale e riferimenti a articoli accademici inesistenti (The Guardian, 2025). Una versione rivista ha dichiarato che GPT-4o era stato utilizzato nella redazione. Reportage successivi hanno quantificato il rimborso in circa 97.000 dollari australiani — l'ultima rata del contratto.

Un dettaglio conta più del denaro. Le falsificazioni non furono rilevate dalla revisione interna della società, né da quella del cliente. Le scoprì un accademico esterno che verificò i riferimenti. Il deliverable aveva superato ogni livello di controllo per cui era stato progettato, perché nulla in esso sembrava sbagliato.

Questa è la categoria: non il modello che fallisce, ma il modello che risponde. Chiedi a un modello linguistico di sommare i ricavi su duecento righe e ottieni una risposta con la giusta grandezza, il giusto simbolo di valuta e una frase sicura intorno ad essa. Quello che non ottieni in modo affidabile è la somma. Una risposta mancante viene notata. Una risposta sbagliata con buona postura viene inoltrata al consiglio di amministrazione.

E la postura non si incrina mai, perché anche la sicurezza è testo generato. Il modello non sa di sbagliare; non c'è nessun allarme interno da sopprimere. La frase che afferma il numero e il numero stesso provengono dallo stesso posto — il token successivo più probabile.

Plausibile non è calcolato

L'istinto è di archiviare i numeri sbagliati sotto la voce maturità del modello: sicuramente la prossima versione somma correttamente. La ricerca dice che il fallimento è strutturale, ed è insolitamente coerente sul perché.

GPT-4, a cui è stato chiesto di moltiplicare due numeri a tre cifre, ha ottenuto il 59% di risposte corrette zero-shot; ChatGPT, il 55% (arXiv, 2023). A quattro cifre, GPT-4 è sceso al 3%. A cinque, 0%. Gli autori di Faith and Fate hanno tracciato il meccanismo: i transformer affrontano i problemi composizionali abbinando frammenti linearizzati di ciò che hanno visto — ricerca di pattern, non procedura. Il precipizio si trova esattamente dove i pattern si esauriscono.

L'addizione non è più sicura. Un'analisi del 2025 ha rilevato che i LLM addizionano con un'euristica lookahead a una cifra anziché con un algoritmo: l'accuratezza crolla esattamente dove i riporti si propagano oltre una cifra, indipendentemente dal prompting o dalla tokenizzazione, e i fallimenti sono prevedibili dalla sola struttura dei riporti (arXiv, 2025). Sistematico, non casuale. Il modello non sta quasi calcolando. Sta facendo qualcos'altro che spesso coincide con il calcolo.

GSM-Symbolic di Apple ha chiuso l'ultima scappatoia — che forse questo riguarda solo l'aritmetica difficile (Apple, 2024). Prendi problemi a parole da scuola elementare e cambia solo i numeri: ogni modello all'avanguardia testato ha peggiorato. Aggiungi una clausola plausibile ma irrilevante: l'accuratezza è calata fino al 65%. E l'accuratezza variava notevolmente tra istanziazioni diverse dello stesso template di domanda — lo stesso problema, riformulato, restituisce una distribuzione diversa di risposte. Quest'ultima scoperta spiega il problema della demo. Una demo è un singolo campione dalla distribuzione. Un audit è la distribuzione.

Il verdetto degli autori — «gli LLM attuali non sono capaci di ragionamento logico genuino» — è insolitamente diretto per un articolo di ricerca. Nessuno lo ha ancora smentito.

100 50 0 accuracy, % zero-shot scratchpad 59 92 3×3-digit 4 4×4-digit 0 5×5-digit
Accuratezza di GPT-4 nella moltiplicazione n×n cifre, zero-shot vs scratchpad passo per passo. Faith and Fate, NeurIPS 2023.

Le soluzioni ovvie, misurate

Ogni team che incontra questo fallimento ricorre alle stesse quattro soluzioni. Ognuna è stata misurata.

Recupero. FinanceBench ha posto a GPT-4-Turbo 150 domande su documenti finanziari pubblici, con un sistema di recupero che forniva i documenti. Ha risposto in modo errato o si è rifiutato di rispondere all'81% di esse (Patronus AI, 2023). Sedici configurazioni — GPT-4-Turbo, Llama 2, Claude 2, vector store, contesto lungo — hanno mostrato debolezze su 2.400 risposte revisionate manualmente, e i modelli hanno allucinato cifre ogni volta che le pagine di evidenza non erano fornite perfettamente. Il recupero recupera il documento. Il modello sbaglia comunque il numero.

Grounding. La BBC ha dato a ChatGPT, Copilot, Gemini e Perplexity accesso diretto ai propri articoli e ha chiesto loro notizie. Il 51% delle risposte aveva problemi significativi; il 91% ne aveva almeno qualcuno. Il 19% delle risposte che citavano contenuti BBC introduceva errori fattuali — affermazioni errate, numeri sbagliati, date errate — e il 13% delle citazioni attribuite ad articoli BBC erano alterate o non erano mai esistite (BBC, 2025). La fonte era a portata di mano. I numeri si sono comunque distorti.

Un modello più sofisticato. La system card di OpenAI riporta che o3 allucinava nel 33% dei prompt PersonQA e o4-mini nel 48% — contro il 16% del precedente o1 (OpenAI, 2025). Secondo la misurazione del fornitore stesso, i nuovi modelli di ragionamento allucinano da due a tre volte di più del predecessore. o3 semplicemente fa più affermazioni — più corrette e più inventate, consegnate alla stessa temperatura di certezza.

Prompting migliore. Il prompting con scratchpad passo per passo porta la moltiplicazione a tre cifre di GPT-4 dal 59% al 92% (arXiv, 2023). Meglio — e ancora un prodotto sbagliato su dodici. Anche il fine-tuning esaustivo di GPT-3 sulla moltiplicazione a quattro cifre ha prodotto circa il 40% su problemi a quattro cifre non visti, e 0% a cinque cifre. Il soffitto è il meccanismo, non il prompt.

Ogni soluzione sposta le probabilità. Nessuna cambia chi fa l'aritmetica. La risposta è ancora campionata da una distribuzione di numeri plausibili, e esattamente uno di essi è la somma.

0 50 100 % RETRIEVAL · FINANCEBENCH 2023 wrong or refused 81% GROUNDING · BBC 2025 significant issues 51% factual errors introduced 19% REASONING · PERSONQA, OPENAI 2025 o1 (predecessor) 16% o3 33% o4-mini 48%
Tassi di fallimento dopo la soluzione. FinanceBench 2023 · BBC 2025 · OpenAI o3 / o4-mini system card 2025.

Cambia chi fa l'aritmetica

La risposta strutturale è una divisione del lavoro tracciata esattamente lungo la linea di competenza. I modelli linguistici eccellono nel linguaggio e sono inaffidabili con i registri contabili, quindi il modello non dovrebbe mai essere quello che calcola.

SQAI è costruito su questa separazione. Il modello redige un intento tipizzato — sum amount where region = "east" — e un motore deterministico lo esegue come codice compilato: validato rispetto a un contratto con hash fisso, verificato rispetto alla policy, calcolato in float64 su un singolo thread, restituito con provenienza.

{
  "status": "ok",
  "value": 2130.5,
  "rows_matched": 5
}

Quel 2130.5 non è un token probabile. È la somma, prodotta da un kernel deterministico da una superficie di 4.574 capacità in sola lettura su 445 moduli — 4.564 dei quali completamente deterministici — con risposta in 0,83–0,93 ms a caldo.

Deterministico significa verificabile. finance.npv(0.1, [-1000, 300, 420, 560, 680]) restituisce 505.020148896933 con hash di computazione b74f67d0… — lo stesso valore e lo stesso hash sia che la chiamata venga effettuata da TypeScript o Python, perché i risultati sono sottoposti a hash su un'unica forma JSON canonica. L'affermazione è delimitata onestamente: deterministico nell'ambito di esecuzione dichiarato, con un envelope che registra versione del runtime, piattaforma, modalità di precisione e numero di thread anziché fare promesse eccessive. La risposta di un modello allo stesso prompt non può garantire di corrispondere a se stessa alla prossima esecuzione. Questa si riproduce byte per byte identica, mesi dopo, in entrambi i linguaggi.

C'è una seconda falla, e la maggior parte degli stack la lascia aperta. Collega un motore di calcolo, poi versa le righe grezze della query nel contesto «per la sintesi» — e il modello rideriva silenziosamente, e reinventa, numeri dalle righe. SQAI tratta il contesto come un confine governato: al massimo 25 righe, 250 celle e 32.000 byte raggiungono mai il modello, dietro un limite predefinito di 100 righe e un tetto di esecuzione rigido di 1.000. Il troncamento è sempre dichiarato, così il modello non può onestamente affermare di aver totalizzato ciò che ha visto. Le righe parziali non vengono mai mostrate, così nessun mezzo record lo tenta a completare dall'immaginazione. Gli aggregati sono calcolati prima del confine. Il modello riceve la risposta, non i compiti.

E la policy non è un prompt. Le sorgenti, i campi e le funzioni consentiti sono fissati nel codice al momento di createSQAI() e verificati in-process prima dell'esecuzione; l'input dello strumento del modello non contiene alcun campo di policy, quindi non c'è nulla che possa ampliare. Richiedere una capacità al di fuori della policy non produce un workaround creativo — produce policy_denied_function. L'argomento è lo stesso che sta dietro al non lasciare che gli agenti scrivano SQL: non governare il testo generato con istruzioni best-effort; governare l'esecuzione con allow-list che il testo non può toccare.

GOVERNED BOUNDARY MODEL language in, language out sum(amount) · region = "east" typed intent — never a SQL string ENGINE contract → policy → execute float64 · 1 thread · sub-ms warm value 2130.5 · rows 5 plan_hash f87610d8afeb… byte-identical replay · TS ≡ PY answer, not rows ≤ 25 rows · ≤ 250 cells · ≤ 32,000 B truncation always declared
La divisione del lavoro: il modello redige un intento tipizzato; un kernel float64 calcola; i limiti sulle righe tengono i dati grezzi fuori dal contesto.

Chi ha fatto l'aritmetica?

La prossima volta che un sistema AI ti consegna un dato di fatturato, una domanda classifica ogni architettura sul mercato: chi ha fatto l'aritmetica?

Se la risposta è «il modello», hai in mano un numero con postura eccellente e provenienza sconosciuta, e l'unico percorso di verifica è che un essere umano rifaccia il lavoro — la cosa che stavi cercando di automatizzare. Le falsificazioni di Deloitte furono scoperte perché un accademico esterno al processo decise di verificare. Non è un controllo. È fortuna.

Se la risposta è «un motore deterministico, ed ecco l'hash», la verifica è un replay: stesso intento, stesso motore, stessi byte. Il fallimento diventa più sottile — e più silenzioso — quando il numero sbagliato proviene da un join ramificato anziché da un'addizione errata, il che è un'altra storia. Ma la disciplina si condensa in una frase: il modello scrive la domanda, mai la risposta.

Il numero di fatturato sbagliato non si annuncia. Arriva formattato, citato e sicuro — e a cinque cifre di moltiplicazione, non è mai corretto. Costruisci la pipeline in modo che non possa entrare.