Lo strawberry problem e l'aritmetica degli LLM: diagnosi di quando NON usare un modello linguistico

Il 14 marzo 2026, nove giorni dopo il rilascio di GPT-5.4 Thinking, ho rifatto sulla mia sandbox lo stesso esperimento che gira ormai da due anni nei video divulgativi: ho chiesto al modello "quante R ci sono nella parola strawberry?". GPT-5.4 Thinking, a temperatura zero su API, mi ha risposto "due". Glielo ho rifatto cinque volte ricaricando una sessione pulita: tre volte "due", due volte "tre". Una settimana dopo ho replicato il test su Claude Opus 4.7 e Gemini 3.1 Pro Thinking, sullo stesso Hetzner CCX33 (8 vCPU AMD EPYC 9454P, 32 GB RAM DDR5) della mia pipeline personale di automazione AI: Opus risponde "tre" stabilmente, Gemini oscilla tra "due" e "tre" a seconda del seed di campionamento. Tre frontier model nel 2026, una parola di dieci lettere: nessuno dei tre risponde correttamente in modo deterministico.

Il punto non è che gli LLM siano "stupidi". Il punto è che hanno una forma molto specifica di intelligenza statistica del linguaggio, e contare lettere non è un problema linguistico: è un problema di accesso al carattere atomico del testo, accesso che gli LLM strutturalmente non hanno. Lo stesso vale per l'aritmetica esatta su numeri lunghi, per i vincoli numerici precisi sull'output ("scrivi esattamente 150 parole"), per il ragionamento simbolico oltre una certa profondità, per la citazione bibliografica precisa. Sono cinque famiglie di compiti diverse con una causa comune: l'LLM è ottimizzato per produrre il prossimo token probabile dato il contesto, non per eseguire algoritmi formali. E nel 2026 questo è ancora il singolo più grande motivo per cui le pipeline LLM aziendali falliscono in produzione, dietro il 40% di progetti agentic AI che Gartner stima cancellati entro il 2027 per "inadequate risk controls" (press release del 25 giugno 2025).

Perché GPT-5.4 sbaglia a contare le R in strawberry?

Per lo stesso motivo che ho raccontato nell'articolo sulla tassa nascosta della tokenizzazione italiana: la tokenizzazione. Quando GPT-5.4 riceve "strawberry" non vede una sequenza di dieci caratteri ma una manciata di token sub-parola estratti dal suo vocabolario o200k_base. Sull'inglese il tokenizer è efficiente: spesso "strawberry" diventa due o tre token, qualcosa come [straw][berry] oppure [str][aw][berry]. L'LLM lavora su quei token, non sui caratteri. Il modello non ha mai visto la lettera "R" come unità di calcolo: ha visto solo le sequenze in cui "R" era frammento interno di un token più grande. Chiedergli quante R ci sono in strawberry equivale a chiedere a un cieco di contare le ondulazioni di un suono.

C'è un esperimento facile da fare per convincersi: chiedi allo stesso modello quante R ci sono in s-t-r-a-w-b-e-r-r-y separato con trattini. La risposta migliora drasticamente, perché la separazione forza una tokenizzazione carattere-per-carattere. Il modello "sa" contare quando i caratteri sono token espliciti. Non sa farlo quando i caratteri sono nascosti dentro token più grossi. Da qui derivano una serie di errori che sembrano stupidi ma hanno radice strutturale: contare lettere in una parola, contare parole in una frase, identificare la posizione di una sub-stringa, manipolare anagrammi, fare giochi di palindromo. Tutti compiti carattere-level. Tutti fuori dal dominio nativo del modello.

Se gestisci una pipeline LLM aziendale e vuoi sapere dove va a sbattere

Nel mio hub dedicato all'AI per aziende raccolgo gli articoli tecnici sulla governance dei costi, la diagnosi dei pattern di failure, l'audit del codice AI-generated. Se stai progettando o gestendo un'integrazione LLM per una PMI italiana, è il punto da cui partire prima di firmare il primo contratto col fornitore.

Apple ha provato a misurare il pavimento del ragionamento LLM

A giugno 2025, prima del rilascio dei reasoning model di seconda generazione, Apple ha pubblicato il paper The Illusion of Thinking che ha sollevato la prima discussione tecnica seria sul tema (ho dedicato all'analisi dei tre regimi di collasso un pezzo verticale qualche settimana fa). I ricercatori hanno preso i Large Reasoning Models del momento (o1, Claude Sonnet con thinking, Gemini Pro thinking) e li hanno testati non sui benchmark di matematica standard, dove il rischio di contaminazione con il training set è enorme, ma su quattro puzzle a complessità controllabile: Torre di Hanoi, River Crossing, Checker Jumping, Blocks World. Risultato: tre regimi netti. Sui task semplici i modelli base senza reasoning vanno meglio dei reasoning model. Sui task medio-complessi i reasoning model dimostrano vantaggio. Sui task ad alta complessità entrambi collassano completamente, con un comportamento controintuitivo: lo sforzo di ragionamento (token usati per pensare) cresce con la complessità fino a un certo punto e poi cala drasticamente, anche con budget di token disponibile. Come se il modello si arrendesse implicitamente.

Il paper ha generato un rebuttal interessante di Lawsen e colleghi, The Illusion of the Illusion of Thinking, che ha mostrato come parte dei collassi fosse imputabile a limiti pratici di output-token (Hanoi a 15 dischi richiede di stampare migliaia di mosse) e a benchmark River Crossing matematicamente impossibili per N≥6. Quando hai chiesto al modello di scrivere un programma Lua ricorsivo invece dell'enumerazione, Claude e o3 producevano soluzioni corrette per 15 dischi. Il follow-up Rethinking the Illusion of Thinking ha ricalibrato il dibattito: il limite cognitivo c'è, ma scatta più tardi di quanto Apple sosteneva, e si attiva a 8 dischi nelle condizioni revised. Per chi progetta pipeline aziendali la lezione operativa è la stessa: oltre una certa profondità di ricorsione formale gli LLM smettono di funzionare in modo affidabile, e il pattern corretto è offload del calcolo a un sistema esterno (Lean, SymPy, un solver Z3, persino Python).

Le cinque famiglie di compiti che NON vanno date a un LLM diretto

Nella mia pipeline personale ho costruito nel corso degli ultimi 18 mesi una checklist operativa dei pattern di failure che si ripresentano sistematicamente. La uso prima di promettere a un cliente che "l'LLM può farlo": se il task ricade in una di queste famiglie, l'architettura cambia. Non è un'opinione, è una mappa di rischio.

Famiglia 1: Conteggio a livello di carattere o sub-token. Conta lettere, conta sillabe, identifica posizione di sub-stringhe, gestisci palindromi e anagrammi, valida lunghezze minime/massime di un campo. Riconoscibile dal pattern "quante X ci sono in Y" o "verifica che la stringa sia di esattamente N caratteri". Mitigazione: passa la stringa a una funzione Python (len(s), s.count('r')) e chiama l'LLM solo per generare la risposta finale al cliente.

Famiglia 2: Aritmetica esatta su numeri di più di otto-dieci cifre. Moltiplicazione, divisione, modulo, calcolo di interesse composto, quadrature contabili. Riconoscibile dal pattern "calcola N moltiplicato per M" con N e M fuori dal range che l'LLM ha digerito di frequente nel training. Per addizioni semplici e numeri piccoli i modelli reasoning più recenti se la cavano, ma su numeri grandi collassano in modo silenzioso, restituendo risultati plausibili ma sbagliati di poche unità (errore peggiore del crash). Mitigazione: tool use obbligatorio. Il modello deve emettere una chiamata a eval di un'espressione che un servizio esterno calcola, non rispondere direttamente.

Famiglia 3: Vincoli numerici esatti sull'output. "Scrivi esattamente 150 parole", "produci una bozza di 280 caratteri per Twitter", "genera una lista di 17 elementi". Il modello tende sistematicamente a produrre 145-155 parole su un target di 150, e non c'è prompt che possa correggerlo del tutto perché viola la natura del campionamento autoregressivo: quando arriva al 145esimo token deve decidere se chiudere o no, non sa contare quanti ne ha già emessi. Mitigazione: post-process. L'LLM produce una bozza, una funzione esterna conta e tronca/rifila, e (se serve) richiede al modello una versione più corta di N parole.

Famiglia 4: Ragionamento simbolico oltre la soglia di Apple. Tower of Hanoi a 12+ dischi, sistemi di equazioni Diofantee, dimostrazioni geometriche complesse, ricerca di percorso ottimale su grafi grandi, soddisfacibilità di vincoli formali. Il pattern Lawsen lo ha confermato: oltre una certa profondità di ricorsione formale, anche i reasoning model collassano. DeepMind con Gemini Deep Think ha vinto la medaglia d'oro IMO 2025 lavorando end-to-end in linguaggio naturale, ma è un sistema con compute orders of magnitude maggiore di una API call standard, ed è ancora un'eccezione di laboratorio non un componente da pipeline aziendale. Mitigazione: per dimostrazioni serie usa Lean o Coq con formalizzazione manuale; per problemi NP usa solver dedicati (Z3, OR-Tools); per matematica simbolica chiama SymPy o Mathematica.

Famiglia 5: Citazione precisa di fonti, sentenze, articoli di legge. "Citami il comma dell'art. 7 GDPR", "qual era il dispositivo della sentenza Cassazione N°...". L'LLM allucina con eleganza titoli di sentenze inesistenti, articoli di legge errati, anni di pubblicazione plausibili ma sbagliati. È il pattern che produce le "fake citations" che hanno fatto sanzionare avvocati negli Stati Uniti dal 2023 in poi. Mitigazione: RAG sopra un corpus normativo verificato (per il diritto italiano: NormAttiva, Pluris, Cassazione Italgiure) e blocco hard sull'output: se la pipeline non trova match testuale del riferimento citato dal modello dentro il corpus, abort della risposta.

Il pattern architetturale corretto: routing a tool

La conseguenza pratica di queste cinque famiglie è che un sistema LLM aziendale serio nel 2026 non è "un'API call al modello con un buon prompt". È un sistema di routing: il modello, esposto a un task, deve riconoscere se rientra in una delle famiglie sopra e delegare al tool appropriato (Python sandbox, solver formale, RAG verificato, calcolatrice esatta) prima di formulare la risposta finale al cliente. Questo è il senso architetturale del Tool Use Anthropic, dei tool MCP esposti via Model Context Protocol e del Programmatic Tool Calling che Anthropic ha rilasciato a fine Q1 2026 per ridurre il token overhead di pipeline con molti tool, di cui ho parlato in dettaglio nell'analisi dei pattern di reasoning con tool use su problemi formali. La mia regola interna è semplice: se tra il prompt utente e l'output finale c'è anche solo un compito di una delle cinque famiglie, quel compito non viene risolto dall'LLM da solo, ma dall'LLM che chiama uno strumento. Concretamente, nel mio orchestrator interno il system prompt dichiara "for any character counting, exact arithmetic, exact length constraint, formal proof or normative citation: route to the dedicated tool, do not answer directly". Il modello impara a emettere la chiamata tool invece di tentare la risposta diretta. È la differenza fra una pipeline che misura come fallisce e una pipeline che si limita a fallire silenziosamente fino al primo incident.

Il problema è che sul mercato italiano questa architettura non è il default. I dati dell'Osservatorio Politecnico Milano 2026 raccontano che il 71% delle grandi imprese italiane ha avviato almeno un progetto AI, ma solo il 9% ha una governance strutturata. Tradotto: la maggior parte delle integrazioni produzione lavora con prompt diretti al modello, senza routing a tool, senza fail-safe sul conteggio, senza verifica delle citazioni. Funziona finché funziona. Poi un giorno un agent classifica un cliente come "5 fatture aperte" quando ne aveva 7, perché ha contato basandosi su una rappresentazione testuale e non su una query SQL. Il bug non è nel modello: è nell'architettura che ha promesso al cliente che il modello potesse fare quel conteggio.

C'è un trade-off culturale che il consulente serio deve mettere in chiaro fin dal kick-off. Costruire la pipeline con tool augmented routing costa il 30-50% in più di engineering iniziale rispetto al "chiama l'LLM e fidati". Ma elimina alla radice tre delle cinque famiglie di failure (conteggi, aritmetica, citazioni) e mitiga le altre due (vincoli output, ragionamento simbolico). Il TCO a 18 mesi è inferiore perché non paghi le fix in emergenza dopo gli incident. Il revisore tecnico interno può audit-are il sistema perché ogni decisione critica passa da uno strumento deterministico tracciabile, non da un'inferenza probabilistica. E il cliente può dichiarare al Garante o al revisore esterno quale pezzo della pipeline è "guidato dall'AI" e quale no, distinzione che diventa rilevante con l'AI Act in vigore dal 2 agosto 2026 sul perimetro PMI.

L'esperimento delle R in strawberry è banale ma è il canarino in miniera, ed è banale a fare in trenta secondi prima di firmare qualunque preventivo. Se il tuo fornitore AI ti dice che "il modello sa contare le lettere", oppure ti propone un demo che gestisce conteggi numerici senza tool esterni, oppure si rifiuta di mostrarti come la pipeline tratta il caso limite di un input fuori distribuzione, hai tre informazioni convergenti: non hanno fatto due ore di test seri sui pattern di failure, non hanno costruito un sistema di routing, e non hanno l'attrezzatura mentale per progettare governance in produzione. Stai per assumere il rischio di una pipeline che funziona finché il task del giorno è abbastanza simile a quelli che l'LLM ha digerito nel training, e che fallisce silenziosamente fuori da quella distribuzione. È esattamente il pattern che il 40% dei progetti agentic AI cancellati che Gartner attribuisce a "inadequate risk controls" segue, e che il modulo di preventivo gratuito ti aiuta a inquadrare in due minuti, sette domande, prima che la prima emergenza tecnica arrivi.