No. 003Determinismo9 min di lettura

Il fatturato sbagliato con aria sicura: perché i modelli linguistici non sanno fare i conti

Il modello ti consegna un dato di fatturato con tono impeccabile e nessuna aritmetica dietro. 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 invenzioni non furono rilevate dalla revisione interna della società, né da quella del cliente. Furono scoperte da un accademico esterno che verificò i riferimenti. Il documento 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 il fatturato su duecento righe e ottieni una risposta con l'ordine di grandezza giusto, il simbolo di valuta corretto e una frase sicura intorno al numero. 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 vacilla 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 concorde 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 modelli linguistici sommano con un'euristica di 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 aritmetici 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 attuali modelli linguistici 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 problema 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 di attualità. Il 51% delle risposte presentava 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 era alterato o non era mai esistito (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 comunque 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 mai visti, e 0% a cinque cifre. Il limite è 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 solo 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 SQAI runtime 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 su una superficie di 4.574 capacità in sola lettura distribuite su 445 moduli — 4.564 delle quali completamente deterministiche — 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 provenga da TypeScript o Python, perché i risultati sono sottoposti a hash su un'unica forma JSON canonica. L'affermazione è onestamente delimitata: deterministico nell'ambito di esecuzione dichiarato, con un envelope che registra versione del runtime, piattaforma, modalità di precisione e numero di thread anziché promettere troppo. 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 identicamente, 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 riversa 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 allargare. Richiedere una capacità al di fuori della policy non produce un'alternativa creativa — 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 approssimative; 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 i conti?

La prossima volta che un sistema di intelligenza artificiale ti consegna un dato di fatturato, una domanda classifica ogni architettura sul mercato: chi ha fatto i conti?

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

Se la risposta è «un SQAI runtime, ed ecco l'hash», la verifica è una riproduzione: stesso intento, stesso runtime, 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 riassume in una frase: il modello scrive la domanda, mai la risposta.

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