Large reasoning model e paper Apple: tre regimi di performance, collasso e confronto con i modelli base

Il 20 aprile 2026 ho replicato nella mia sandbox di sperimentazione AI alcuni scenari del paper Apple "The Illusion of Thinking", provando Claude Sonnet 4.6 con adaptive thinking vs Sonnet 4.6 senza thinking su Torre di Hanoi in configurazioni da tre a dodici dischi. I risultati sono allineati al paper: con tre dischi entrambi i modelli risolvono al 100% con 7 mosse, ma il modello senza thinking termina in un secondo, con thinking ci mette 14 secondi e gira in tondo; con otto dischi il thinking comincia a guadagnare; con dieci dischi entrambi collassano a zero accuracy. È esattamente il pattern a tre regimi documentato dagli autori. Qui l'analisi ingegneristica del paper, la tabella comparativa dei risultati quantitativi, le critiche sensate e infondate, e cosa significa operativamente per chi integra LRM in una pipeline di produzione italiana.

Il paper Apple in 150 parole e perché è importante nonostante le critiche

The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity di Shojaee, Mirzadeh, Alizadeh, Horton, Bengio, Farajtabar (Apple Machine Learning Research, giugno 2025) valuta DeepSeek V3/R1 e Claude 3.7 Sonnet (thinking vs non-thinking) su quattro puzzle a complessità scalabile: Torre di Hanoi, River Crossing, Checkers Jumping, Blocks World. La scelta dei puzzle non è casuale: sono problemi con complessità parametrizzabile e soluzione verificabile, fuori dal training data. Il risultato centrale sono i tre regimi di performance.

Il paper ha generato una critica molto discussa, The Illusion of the Illusion of Thinking di Lawsen (ispirata da un esperimento con Claude), che fa alcuni punti validi e altri meno. Discuto entrambi più sotto.

I tre regimi in dettaglio: tabella comparativa operativa

Il regime basso è quello più controintuitivo: il LRM thinking, dovendo produrre ragionamento, considera soluzioni corrette come "possibili alternative" e a volte le scarta, finendo per dare risposte peggiori del modello base. È l'overthinking: più ragionamento, peggiore risultato.

Il regime medio è il sweet spot che giustifica l'esistenza dei LRM: task che richiedono passi di ragionamento strutturato, dove il thinking esplora opzioni che il modello base non pondera.

Il regime alto è il collasso: oltre una soglia di complessità specifica del modello, la probabilità di errore cumulativo sulla sequenza di output diventa 1. Non importa quanto budget di thinking dai, la sequenza non sta insieme.

Perché il collasso è strutturale, non risolvibile con più thinking

Il paper Apple fa un esperimento interessante: fornisce al modello l'algoritmo esplicito per risolvere Torre di Hanoi direttamente nel prompt. L'aspettativa naif sarebbe che l'accuracy salga al 100% perché il modello deve solo eseguire; nella realtà, l'accuracy collassa allo stesso numero di dischi con e senza algoritmo fornito. Il modello capisce l'algoritmo; non riesce a mantenere lo stato simbolico attraverso una sequenza lunga di mosse senza perdere il filo.

Questo è un punto strutturale: il Transformer è un predittore di token, non un esecutore di algoritmi. Può dirti come risolvere un problema (planning), non eseguire l'algoritmo su scala lunga (execution). La distinzione è la stessa del mio draft precedente su reasoning con tool: il LRM è creativo ma non preciso, il tool è preciso ma non creativo. La combinazione vince, non uno dei due da solo.

Se vuoi approfondire come calibro pipeline LLM in produzione sulla base dei tre regimi e del collasso strutturale, nel mio hub dedicato all'automazione AI trovo articoli tecnici con metodologia applicata e perimetro dichiarato.

Le critiche al paper Apple: cosa regge e cosa no

Lawsen ha pubblicato The Illusion of the Illusion of Thinking dieci giorni dopo il paper Apple, con tre critiche principali.

Critica 1: output token limit. Una soluzione a 10 dischi richiede 1023 mosse; se il tokenizer del modello consuma ~5 token per mossa, servono 5000+ token di output, sopra i limiti di molti modelli 2025. Il paper Apple non controlla per questo. Critica valida; Apple stessa ha ammesso il limite e aggiornato in versioni successive del paper.

Critica 2: River Crossing impossibile per N>5. Con 5 missionari e cannibali e una barca a capacità 2, non esiste soluzione matematica per N>5. Valutare il modello come "fallimento" su problema irrisolvibile è un errore metodologico. Critica valida anche questa.

Critica 3: chiedere all'LLM di generare una soluzione compressa (funzione Python) invece di una soluzione esplicita risolve il problema. Questa è la parte della critica più discussa. Tecnicamente vera ma operativamente irrilevante: se serve il tool use per risolvere Torre di Hanoi, il paper Apple è confermato, non smentito. Il punto non è "il modello non può risolvere Torre di Hanoi"; il punto è "il modello non può farlo con il suo ragionamento interno, senza tool". Lawsen ha ragione sul metodo, sbaglia l'interpretazione delle conclusioni.

Il paper Apple resta una misurazione rigorosa dei limiti strutturali dei LRM, con alcune debolezze metodologiche ma con un messaggio di fondo valido: i modelli di reasoning hanno un collasso alla complessità, non una curva morbida di degradazione.

Il caso parallelo: RLVR non aumenta le capacità, aumenta l'efficienza

Un secondo pilastro della letteratura 2025 sul reasoning è il paper Does Reinforcement Learning Really Incentivize Reasoning Capacity in LLMs Beyond the Base Model? di Yue et al. (Tsinghua, 2025). Finding centrale: RLVR (Reinforcement Learning with Verifiable Rewards), la tecnica usata per allenare DeepSeek R1 e simili, non espande le capacità di reasoning del modello base. Ne aumenta l'efficienza di campionamento.

Quantitativamente: un modello base a pass@256 (256 tentativi) risolve problemi che il suo corrispondente RLVR-tuned a pass@1 non risolve. La capacità esiste nel modello base, RLVR la concentra sui path più probabili. Il corollario: i guadagni sui benchmark dei modelli reasoning sono in buona parte "il modello base più veloce a trovare la risposta che avrebbe trovato comunque con più tentativi".

Questa lettura ridimensiona le aspettative: i modelli di reasoning non sono un salto di capacità, sono un'ottimizzazione di efficienza. Utile, ma non magico.

Implicazioni di progetto: cosa demandare davvero a un LRM

Quattro regole operative che applico nei progetti enterprise.

Regola 1: task sotto la soglia di collasso, con tolleranza agli errori. Task che richiedono ragionamento a 2-5 step (analisi di un documento, confronto fra opzioni, diagnosi di un errore). LRM thinking è appropriato.

Regola 2: task formali oltre una certa complessità, demanda a tool. Calcolo fiscale multi-regime, pianificazione logistica con vincoli, ottimizzazione combinatoriale. Il LRM scrive l'algoritmo, il tool lo esegue.

Regola 3: task semplici ripetitivi, usa modello base senza thinking. Estrazione, classificazione, traduzione, riassunto. Thinking qui è pura perdita di costo e latenza.

Regola 4: task in regime alto (oltre il collasso), NON usare LRM senza safety net. Un LRM che crolla a 0% accuracy non lo segnala; dà una risposta sbagliata con la stessa confidenza di una giusta. Serve validation esterna obbligatoria.

AlphaEvolve come risposta costruttiva al limite dei LRM

Se il paper Apple descrive il limite, AlphaEvolve di DeepMind (Novikov et al., giugno 2025) suggerisce una via d'uscita architetturale: non un LRM più grande, ma un ensemble evoluzionario che combina LLM creativo + verifier deterministico + loop di selezione. Su problemi matematici oltre il regime alto dei LRM classici (matrix multiplication 4x4 complex, kissing number in 11 dimensioni), AlphaEvolve trova soluzioni nuove o migliori delle esistenti. Non perché sia un LRM più capace; perché l'architettura cambia.

La lezione è coerente con il paper Apple: il ragionamento formale lungo non si ottiene rendendo l'LLM più bravo a "pensare". Si ottiene mettendo un verifier esterno che elimina le ipotesi sbagliate, lasciando all'LLM il ruolo di generatore di candidati. Per una pipeline enterprise italiana, questo significa costruire sistemi agentic dove il ruolo del modello è chiaro: creatività esplorativa + narrativa; il ruolo del codice tradizionale è precisione + esecuzione.

Il confronto quantitativo su moltiplicazione a più cifre

Un benchmark complementare alla Torre di Hanoi è la moltiplicazione a più cifre, usato nel paper Teaching Arithmetic to Small Transformers (Lee et al. 2023) e ripreso nel 2024 da Deng e colleghi. Quando aumenti il numero di cifre dei moltiplicandi, i LRM mostrano esattamente lo stesso pattern di collasso: performance accettabile fino a ~6 cifre, degradazione rapida oltre.

L'unico approccio che risolve la moltiplicazione a 20 cifre con accuracy 100% è training specialistico (stepwise internalization su GPT-2) oppure tool use con calcolatrice. Nessun LRM commerciale 2025-2026 risolve 20x20 senza tool. La dimostrazione è empirica, ripetibile, e allineata al finding Apple.

Corollario operativo: se il tuo task include calcolo numerico preciso (finanza, ingegneria, calcolo scientifico), non importa quale LRM usi senza tool, l'accuracy sarà sempre limitata dalla soglia di collasso. Il tool use con calcolatrice o solver formale non è optional, è architettura obbligatoria.

Pattern di fallimento nei progetti italiani 2026

Cinque anti-pattern che vedo ripetutamente nei progetti dove LRM sono stati adottati senza tener conto dei tre regimi.

• LRM usato come decision maker autonomo su task fuori regime medio. Il progetto funziona finché non arriva un input al limite del regime alto, e a quel punto il decision maker invisibilmente degrada.
• Nessun test su held-out a complessità scalabile. Il vendor ha mostrato il modello su task di regime basso-medio; nessuno ha testato su regime alto prima del deploy.
• Thinking budget non monitorato. Le run consumano thinking tokens variabili; il budget diventa non prevedibile e gli alert arrivano solo a bill fatta.
• Confidence score del modello presi come proxy di accuracy. Nel regime alto il modello è ugualmente confident e ugualmente sbagliato. I confidence score interni non sono calibrati al collasso.
• Nessun fallback. Quando il modello fallisce, non c'è un path alternativo (human-in-the-loop, algoritmo deterministico, escalation). La pipeline rimane bloccata su output sbagliato.

Quando un LRM è preferibile a un modello base e a un algoritmo formale

Riassumendo la tabella dei trade-off a livello di architettura:

La scelta non è "LRM vs non-LRM"; è "quale pezzo del problema richiede quale strumento". Le pipeline 2026 che reggono sono ibride: modello base dove basta, LRM dove serve ragionamento, algoritmo formale dove serve precisione, sempre con validation esterna e fallback definiti. Ogni componente è ingegneria nota; la composizione è l'arte del system design AI applicato al business reale e ai vincoli di budget delle PMI italiane, non alle demo da conferenza americana. Progettare una pipeline ibrida significa documentare in anticipo dove usi quale strumento, con quali metriche di fallback, con quale validation esterna e con quale kill switch centrale per tagliare run quando il regime alto emerge senza preavviso su un input che nessuno aveva previsto in fase di testing.

Il paper Apple non è un proclama anti-reasoning; è una carta dei confini operativi dei LRM. Ignorare i confini vuol dire costruire pipeline che funzionano nel regime medio e falliscono silenziosamente nel regime alto. Se hai un progetto in cui un LRM è il decision maker di qualcosa che conta, e vuoi capire se il tuo task cade nel regime medio (dove il LRM vince), nel basso (dove il modello base basta), o nell'alto (dove serve tool use obbligatorio), il modulo di preventivo gratuito ti risponde in due minuti se il caso rientra nel mio ambito. Gli LRM sono strumenti potenti; usarli come se fossero solutori universali è la via più rapida per finire nel 40% di progetti che Gartner prevede cancellati entro il 2027 per "inadequate risk controls". I tre regimi non sono un dettaglio accademico, sono la geografia operativa del 2026 per chi integra reasoning models in produzione, e la mappa va letta prima di partire, non dopo che il collasso si è già manifestato su richieste reali degli utenti.