Chain-of-thought: quando attivarlo e quando disattivarlo: checklist in sette criteri

Il 14 aprile 2026 ho migrato la parte di estrazione entità della mia pipeline personale da Claude Sonnet 4.6 con adaptive thinking a effort alto al Sonnet 4.6 senza thinking. Riduzione del costo per milione di chiamate da 87 a 22 euro, latenza mediana da 4,1 a 0,9 secondi, accuracy passata dal 94,2% al 93,6%. Lo 0,6% di accuracy persa non giustificava quattro volte il costo e più di quattro volte la latenza. Questo è il punto: il chain-of-thought non è un upgrade gratuito. Nel 2026, con adaptive thinking che sostituisce budget_tokens su Opus 4.7 (vedi Claude API extended thinking docs) e con output fino a 128k token, il costo del thinking è pagato ogni chiamata. Checklist operativa in sette criteri per decidere quando attivare, disattivare o vincolare il thinking mode nelle pipeline di produzione.

Perché chain-of-thought ha funzionato (e perché è rischioso usarlo in automatico)?

Chain-of-thought (CoT), reso popolare dal paper Chain-of-Thought Prompting Elicits Reasoning in Large Language Models di Wei et al. 2022, è la scoperta che aggiungere al prompt "think step-by-step" o mostrare esempi con ragionamento esplicito migliora drasticamente la performance su task matematici e logici. Il meccanismo è l'attention: obbligando il modello a produrre token intermedi di ragionamento, la predizione della risposta finale beneficia di un contesto più ricco e rilevante.

Dal 2024-2025 i modelli di reasoning (o1, o3, DeepSeek R1, Claude thinking, Gemini Flash thinking) espongono il CoT come modalità nativa, allenata via reinforcement learning su reasoning trace. Ottimo per task complessi; problema quando diventa default su task semplici: costa in token, in latenza, e in rumore di output.

Peggio: il paper Reasoning Models Don't Always Say What They Think di Chen et al. Anthropic, maggio 2025, ha dimostrato che il CoT non è sempre faithful. Claude 3.7 Sonnet menziona un hint ricevuto solo nel 25% dei casi (39% per DeepSeek R1). In scenari di "unauthorized access", Claude è faithful nel 41%, R1 nel 19%. Peggio ancora: CoT unfaithful tendono a essere più lunghi di CoT faithful, perché il modello costruisce giustificazioni elaborate per mascherare il ragionamento reale. La conseguenza: non puoi fidarti ciecamente del trace, anche quando sembra convincente.

Criterio 1: la difficoltà logica del task giustifica il costo del thinking?

Task con ragionamento strutturale multi-step (matematica, planning, debugging complesso, ottimizzazione combinatoriale): thinking attivo porta gain significativi. Task lineari (classificazione, extraction, riassunto, traduzione): il gain è minimo o zero, il costo è reale.

Il mio test pratico: prendi un batch di 500 esempi del tuo task, lancialo con thinking on e con thinking off, misura accuracy e costo. Se accuracy con thinking è sotto l'1% superiore a senza, thinking non serve.

Criterio 2: la latenza è un vincolo duro?

Thinking aggiunge 3-30 secondi di latenza a ogni chiamata, dipende dal task e dal budget. In pipeline user-facing interattive (chatbot, form in tempo reale) questa latenza è inaccettabile. In pipeline batch notturne è irrilevante.

Il thinking è una leva di precisione al costo della velocità. Se la pipeline deve rispondere in meno di 2 secondi, thinking è off di default e va attivato solo per subset specifici (esempio: only per prompts che matchano pattern "calcola/spiega/analizza").

Se vuoi approfondire come calibro governance costi e latenza su pipeline LLM di produzione, nel mio hub dedicato all'automazione AI trovo articoli tecnici con metodologia applicata e perimetro dichiarato.

Criterio 3: il vendor espone il reasoning trace nel response?

Nel 2026 la situazione è mista. OpenAI o-series nasconde il trace per default, restituendo solo la risposta finale (ma addebita comunque i reasoning tokens in fatturazione). Claude adaptive thinking espone i thinking blocks. DeepSeek R1 espone il full trace.

Se il vendor nasconde il trace, stai pagando per un contenuto che non vedi e che non puoi auditare. Per task high-stakes (decisioni legali, compliance, medical) questo è problematico: non puoi fare audit trail del ragionamento se il ragionamento è opaco. Per task di basso rischio, è un non-problema.

Criterio 4: la faithfulness del CoT impatta il tuo use case?

Se usi il CoT per diagnostica (capire perché il modello ha risposto in un certo modo), la faithfulness sotto il 40% è un problema grave. Il modello può aver usato informazioni che non menziona nel trace, e le tue conclusioni di diagnostica sono basate su narrativa post-hoc.

Se usi il CoT solo per migliorare l'accuracy e non ti interessa il contenuto del trace, faithfulness bassa è tollerabile. È comunque un punto di rischio in audit di compliance: il trace non è evidenza legale del ragionamento del modello.

Criterio 5: il task permette di sostituire thinking con un tool?

Come descritto nel mio articolo precedente su reasoning con tool, per molti problemi formali il tool use batte il thinking. Torre di Hanoi con 10 dischi: thinking = 0% accuracy, tool = 100%. Calcoli fiscali complessi: stesso pattern.

Regola pratica: se il task ha un algoritmo deterministico noto, il tool che esegue l'algoritmo batte sempre il thinking del modello. Thinking è utile per creatività esplorativa, non per calcolo.

Criterio 6: l'overthinking sta degradando l'output?

Il paper Apple The Illusion of Thinking ha documentato un fenomeno interessante: sui task semplici i modelli di reasoning considerano soluzioni corrette come possibili e poi si "ripensano" scegliendo soluzioni peggiori. È overthinking: più ragionamento che porta a peggiore risultato.

Sintomo pratico: CoT di 2000+ token su una domanda che richiede una risposta di 10 parole. Se osservi questo nei tuoi log, thinking off o effort abbassato è la via.

Criterio 7: il budget di produzione regge?

Reasoning tokens costano come output tokens (Claude e GPT-5 fatturano entrambi thinking al tier output). Un task con thinking tipico consuma 3-10x i token di un task senza thinking. Su volume di produzione, la differenza è sostanziale: un batch da 10.000 chiamate/giorno a 8k reasoning tokens in più costa ~15 euro/giorno extra su Claude Sonnet 4.6, ~45 euro/giorno su Opus 4.7.

Se il guadagno di accuracy non copre il costo marginale, thinking va spento. Il ROI del thinking va misurato sul task, non assunto come positivo di default.

Come misurare concretamente il ROI del thinking sulla tua pipeline

Quattro metriche da tenere in dashboard per decidere se il thinking vale il costo.

Accuracy delta con/senza thinking. Su un held-out set fisso, lancia 500 chiamate con thinking off e 500 con thinking on. Registra accuracy, latenza, costo per chiamata. Se accuracy con thinking è meno di 2 punti percentuali superiore, thinking off vince per quasi tutte le pipeline di produzione (la differenza sul costo totale è grande).

Thinking tokens distribution. Quanti token di thinking il modello usa per chiamata? Istogramma su 1000 chiamate. Se la distribuzione ha lunga coda (alcuni prompt consumano 10k+ thinking tokens), hai chiamate anomale che bruciano budget. Identifica i prompt responsabili e decidi se tagliarli o se tenerli.

Latency P95. Il P95 è più informativo del mediano per UX. Thinking alza significativamente il P95. Se il tuo SLA è "95% delle risposte sotto 3 secondi", thinking mode probabilmente violaza questo vincolo.

Cost-per-correct-answer. Invece di costo per chiamata, misura costo per chiamata corretta (costo diviso accuracy). Se thinking on costa 0,02 euro per chiamata con 95% accuracy, il cost-per-correct è 0,021. Se thinking off costa 0,005 per chiamata con 93%, il cost-per-correct è 0,0054. Thinking off è quattro volte più economico per risposta valida.

Queste quattro metriche vanno in dashboard con alert su deviazioni significative. Senza dashboard, thinking on di default è un costo invisibile che si accumula nella bolletta senza che nessuno sappia se vale la pena.

Case operativo: chatbot B2B con thinking controllato

Esempio reale dalla mia pipeline sandbox. Un chatbot per risposte tecniche su prodotti B2B, volume circa 3.000 chiamate/giorno, latenza richiesta sotto 3 secondi per l'85% delle risposte.

Versione 1, thinking sempre on su Claude Sonnet 4.6: costo giornaliero 42 euro, latenza mediana 5,8 secondi, P95 11 secondi. Accuracy su held-out 94,7%.

Versione 2, thinking off sempre: costo giornaliero 9 euro, latenza mediana 1,1 secondi, P95 2,3 secondi. Accuracy 91,3%. Sotto lo SLA di latenza, ma la accuracy del 3,4% in meno è stata giudicata inaccettabile su alcune categorie di domande.

Versione 3 (quella in produzione), hybrid routing: un classificatore leggero (modello piccolo, 50ms latenza aggiuntiva) decide se la domanda richiede thinking o no. Pattern "calcola/dimostra/spiega/confronta" attivano thinking; pattern "dimmi/mostra/lista/traduci" no. Costo giornaliero 17 euro, latenza mediana 1,4 secondi, P95 4,8 secondi (sopra SLA solo il 5% delle chiamate). Accuracy 94,2%.

La versione 3 è a metà strada fra 1 e 2: cattura la maggior parte dell'accuracy gain del thinking spendendo meno della metà del costo. Questo è il tipo di ingegneria micro-ottimizzata che separa pipeline progettate da pipeline buttate in produzione.

Come implementare la decisione: tre pattern operativi

Pattern 1: thinking off di default, on su match. La pipeline ha una classificazione leggera del prompt (regex o classificatore piccolo): se il prompt matcha pattern complex (es. contiene "spiega/analizza/calcola/pianifica"), thinking on; altrimenti off. Riduce costo medio mantenendo quality sui task che lo richiedono.

Pattern 2: thinking con budget limitato. Se il vendor lo permette (budget_tokens su modelli pre-Opus 4.7 o effort=low su adaptive thinking), limita il budget. Il modello ragiona meno ma risponde. Compromesso pratico.

Pattern 3: adaptive thinking su Opus 4.7. Lasci decidere al modello quando pensare. Il modello usa il thinking quando lo ritiene necessario. Ottima UX, ma il costo non è deterministico (varia per chiamata). Meno adatto a pipeline con budget fisso.

Edge case: thinking + tool use insieme (interleaved thinking)

Claude 4.x e successivi supportano interleaved thinking: il modello può pensare tra un tool call e l'altro, aggiustando la sua strategia iterativamente. Per task agentic di lungo orizzonte (es. risolvere un ticket GitHub con più step di debugging) interleaved thinking produce accuracy migliore rispetto a thinking one-shot iniziale.

Trade-off: il costo totale dei thinking tokens cresce linearmente con il numero di step, e la variance del costo è alta. Un task semplice consuma poco, un task complesso può bruciare 30k+ thinking tokens in una sola run.

Per task agentic il mio pattern è: interleaved thinking on, ma con un budget cap totale per run (es. max 20k thinking tokens cumulativi). Se il budget viene raggiunto, il modello fallisce "gracefully" restituendo "non sono riuscito a terminare entro il budget", così l'umano viene coinvolto. Fallimento controllato è sempre meglio di costo imprevisto.

Quando disattivare thinking non è una scelta ma un obbligo

Tre situazioni in cui thinking è strutturalmente incompatibile con il caso d'uso.

Audit di compliance con regolamento UE AI Act. Per sistemi ad alto rischio, la faithfulness del reasoning è rilevante. L'AI Act impone logging auditabile delle decisioni del modello; il CoT al 25% faithful non è affidabile come log decisionale. Per compliance seria, il ragionamento deve essere implementato fuori dal modello (rule engine esterno, validation layer).

Real-time streaming a utente. Lo streaming della risposta parte solo dopo il thinking. Per UX conversational, la latenza fra invio prompt e primo token di risposta è critica. Thinking lo fa saltare.

Budget fisso su pipeline di automazione. Se il budget è mensile, e thinking introduce variance del 3-10x nel costo per chiamata, il budget diventa non deterministico. Alcune pipeline non possono tollerare questa volatilità.

Errori comuni che vedo nei progetti 2026

Quattro pattern che vedo spesso nei code review di pipeline LLM aziendali.

Thinking attivato per tutto perché "migliora la qualità". Il costo aggregato esplode, la latenza P95 diventa inaccettabile, e accuracy sale di 0,5%. Decisione non basata su misurazione.

Faithfulness assunta come evidenza legale. "Il modello ha spiegato il suo ragionamento" scritto in un audit report di conformità. Il paper Anthropic smonta questa narrativa: il trace non è sempre veritiero.

Nessuna validation dei thinking tokens consumati. Budget blow su Opus 4.7 adaptive thinking perché nessuno tiene un alert su thinking tokens/chiamata. Avviene più spesso di quanto si pensi.

Confondere reasoning models con thinking mode. Claude Sonnet 4.6 senza adaptive thinking è diverso da senza thinking at all. OpenAI GPT-5.3 senza reasoning effort è diverso da GPT-5 base. Leggere le docs del vendor prima di scrivere il prompt risparmia settimane di bug.

Il chain-of-thought è una leva potente del prompt engineering 2026, ma è una leva, non un bottone "qualità più alta". Il costo aggregato su pipeline a volume può far lievitare la bolletta di 3-10x, la latenza ridurre il NPS di un prodotto user-facing, e la faithfulness sotto il 40% minare qualsiasi uso del trace per audit o diagnostica. Se hai una pipeline LLM in produzione e vuoi capire se thinking è davvero il livello giusto per il tuo task, o se l'accuracy che misuri vale il costo e la latenza che paghi, il modulo di preventivo gratuito ti risponde in due minuti se il caso rientra nel mio ambito. Misurare il ROI del thinking è la differenza tra una pipeline AI che scala economicamente e una che diventa un centro di costo opaco di cui nessuno riesce a giustificare il budget.