Chain of Thought, RLVR e Test-Time Compute, misurati

La tentazione è dire che la seconda versione “ci ha pensato”. Resistiamo, perché il meccanismo è insieme più semplice e più utile da conoscere.

Un transformer esegue una quantità fissa di calcolo per ogni token generato. Un forward pass: gli stessi layer, le stesse matrici, lo stesso numero di operazioni, indipendentemente dal fatto che la domanda sia quanto fa 2+2 o dimostra questo teorema. Dentro il model non c’è una manopola per “impegnati di più su questo”.

Quindi, quando a un model viene chiesto di dare subito una risposta, tutto il calcolo a sua disposizione è un singolo forward pass. Ogni quantità intermedia deve stare nelle attivazioni di quel singolo passaggio, e qualsiasi cosa non riesca a calcolare lì, non la può calcolare.

Emettere token cambia la situazione, e la cambia in due modi distinti che vale la pena separare:

• Più calcolo. Ogni token generato è un altro forward pass completo. Centoquarantacinque token di lavoro equivalgono a centoquarantacinque volte l’aritmetica necessaria per rispondere direttamente.
• Memoria esternalizzata. I token vengono scritti nel context, quindi il passaggio successivo può leggerli. 5 × 13 = 65 diventa un fatto nell’input, non un valore che il model deve tenere in un’attivazione e portare avanti. Il model usa il proprio output come blocco per gli appunti.

Questo secondo punto è quello che molti si perdono, e spiega perché il lavoro deve essere scritto per aiutare. Un model a cui si chiede di “pensarci in silenzio e poi rispondere” non ha un posto dove mettere il pensiero.

Niente di tutto questo richiede qualcosa di mistico, e porta a una previsione chiara: la chain of thought dovrebbe aiutare soprattutto nei problemi con struttura seriale — dove il secondo passaggio ha bisogno del risultato del primo — e meno nei problemi che sono una singola consultazione. È esattamente ciò che trova la letteratura, ed è il motivo per cui “pensa passo dopo passo” non fa nulla per qual è la capitale della Francia.

La tecnica è arrivata nel 2022 in due parti. Wei et al. hanno mostrato che includere esempi svolti nel prompt — dimostrazioni in cui la risposta è preceduta dal ragionamento — produceva grandi miglioramenti su benchmark aritmetici e di commonsense.¹ Kojima et al. hanno poi mostrato qualcosa di più strano: non servono gli esempi. Aggiungere “Let's think step by step” a un prompt zero-shot cattura gran parte dello stesso guadagno.²

Il secondo risultato è quello che rivela cosa sta succedendo. Se una frase magica sblocca il comportamento, quel comportamento era già nel model: il pretraining è pieno di soluzioni svolte, e la frase è un puntatore a quella regione della distribuzione. La chain of thought non ha insegnato nulla al model. Ha selezionato qualcosa che il model aveva già.

Questo inquadramento prevede anche la futura obsolescenza della tecnica, a cui torniamo alla fine del capitolo.

La mossa successiva ovvia: se una catena di ragionamento può essere sbagliata, campionane diverse e prendi la risposta di maggioranza. Questa è la self-consistency.³ È una spesa strettamente maggiore — $n$ generazioni complete invece di una — e l’intuizione è che le risposte sbagliate si disperdono mentre quelle giuste concordano.

Misurata su 16 degli stessi problemi, campionando a temperature 0,8, con voto di maggioranza su $n$ catene:

Sedici problemi sono un denominatore piccolo, e la regola del Capitolo 4 si applica a questa tabella tanto quanto a qualunque altra. 13 su 16 è 81% con un intervallo di Wilson al 95% di [57, 93]; 16 su 16 è 100% con [81, 100]. Si sovrappongono. Leggi la forma della curva, che è il risultato; non leggere il gradino esatto in cui si appiattisce, cosa che sedici problemi non possono localizzare.

Due cose in quella tabella, e la seconda non è ciò che mi aspettavo.

La curva si appiattisce a $n = 3$. Già al terzo campione l’accuratezza è al suo tetto e i due campioni restanti non comprano nulla, pur costando 172 token ciascuno, 345 in totale. È la forma di ogni curva di self-consistency riportata in letteratura, ed è molto prima di quanto suggerisca l’idea “più campioni è più meglio”.

E il greedy decoding era già al 100%. Torna all’inizio del capitolo: una catena, niente campionamento, 145 token, 24/24. Campionare a temperature 0,8 ha abbassato l’accuratezza all’81%, e la self-consistency ha avuto bisogno di tre generazioni per risalire dove un singolo passaggio greedy era già arrivato — a 3,6 volte i token, o sei volte se esegui lo sweep fino a cinque senza sapere dove si appiattisce.

Questo non è un argomento contro la self-consistency. È una dichiarazione precisa di ciò che fa: la temperature compra diversità iniettando errori, e il voto rimuove gli errori che ha appena iniettato. Nei problemi in cui il greedy decoding fallisce — dove la singola catena più probabile porta da qualche parte di sbagliato e una meno probabile è giusta — quello scambio paga, ed è il motivo per cui la tecnica esiste. Nei problemi in cui il greedy riesce già, è un modo per spendere sei volte il budget e andare in pari.

Nessuno pubblica il secondo caso, ed è per questo che vale la pena misurarlo sul tuo task prima di adottare la tecnica. Questi sono problemi facili in due passaggi per un model piccolo; è il regime in cui la risposta esce così.

Tutto fin qui accade al momento del prompt su un model che non è mai stato addestrato specificamente per questo. Il cambiamento che ha prodotto l’attuale generazione di reasoning models è stato spostarlo nell’addestramento — e la chiave che lo ha reso possibile è più stretta di quanto sembri.

Il post-training del Capitolo 11 aveva bisogno di preferenze umane, perché “questa era una buona risposta?” non ha una risposta programmatica. Ma per alcune domande ce l’ha. Una risposta matematica o è uguale al valore corretto o non lo è. Il codice o supera i test o non li supera. Una dimostrazione o verifica o non verifica.

Per quei domini puoi sostituire il reward model con un verifier, e tutto ciò che viene dopo migliora in un colpo solo: niente annotatori, niente fitting Bradley–Terry, niente reward hacking del tipo misurato nel Capitolo 11 — perché non puoi lusingare uno unit test. Questo è reinforcement learning from verifiable rewards, ed è il contesto per cui è stato costruito GRPO: campionare un gruppo di tentativi di soluzione allo stesso problema, controllare ciascuno e usare il punteggio medio del gruppo come baseline. Nessun critic, nessun annotatore, nessun reward model. Solo un programma che dice giusto o sbagliato.

Il risultato che ha riformulato il campo è arrivato da DeepSeek all’inizio del 2025.⁶ Hanno preso un base model e applicato reinforcement learning with verifiable rewards direttamente, senza prima una fase di supervised fine-tuning — la fase che il Capitolo 11 presenta come fondamento di tutto. Lunghe catene di ragionamento sono emerse comunque. Così anche comportamenti che nessuno aveva addestrato: il model ha iniziato a ricontrollare i propri passaggi e, nel passaggio più citato del paper, a riconsiderare spontaneamente un approccio a metà soluzione.

La lettura onesta non è che il ragionamento sia magia. È che quando l’unica cosa premiata è avere ragione, e avere ragione su un problema difficile richiede di lavorarci attraverso, allora lavorarci attraverso è ciò che l’ottimizzatore trova — incluse le parti del lavorarci attraverso che anche gli umani fanno, perché sono ciò che il problema richiede e non ciò che qualcuno ha insegnato.

La conseguenza pratica di tutto questo è che un reasoning model produce token che hai chiesto e token che non hai chiesto, e paghi per entrambi.

I provider gestiscono la cosa in modo diverso, e la differenza conta:

• La maggior parte delle API conta i reasoning token dentro il conteggio degli output token. La tua fattura e il tuo limite max_tokens includono entrambi il pensiero che non vedi mai.
• Gemini di Google riporta i thinking token come campo separato, fuori dal conteggio standard dell’output.

È una vera incompatibilità tra due modi di contare la stessa cosa, e qualsiasi codice che calcoli i costi o faccia rispettare un budget tra provider deve normalizzarla. Il Capitolo 16 è dove questo diventa denaro, e il Capitolo 23 dove diventa un budget che puoi applicare.

L’altra conseguenza è una questione di latency che sorprende le persone la prima volta. Il tempo al primo token visibile di un reasoning model include tutto il suo thinking, quindi una richiesta che non streamma nulla per otto secondi e poi risponde in uno non è una connessione bloccata: è il model che lavora. Qualsiasi interfaccia che mostri uno spinner senza spiegazione per otto secondi ha un problema di design, non di networking.

Un avvertimento finale, perché è il modo più comune in cui il materiale di questo capitolo viene applicato male.

Tutto nella prima metà è una tecnica per far sì che un model che non è stato addestrato a ragionare produca comunque ragionamento. I model addestrati con RLVR lo fanno già: emettono il proprio lavoro, alla propria lunghezza, prima di rispondere. Dire a un model del genere di pensare passo dopo passo è nel migliore dei casi ridondante e nel peggiore dannoso: può produrre una catena breve, a forma di prompt, al posto di quella più lunga che il model avrebbe generato da solo, e alcuni provider documentano esattamente questo.

Lo stesso vale per elaborate impalcature di ragionamento costruite nel codice applicativo. Un prompt che guida un model attraverso un albero decisionale che già percorre internamente sta spendendo i tuoi token per vincolare un comportamento che è stato addestrato dentro il model. Questa è la prima apparizione di un tema che attraversa il resto del corso: tecniche che erano essenziali nel 2022 sono diventate superstizione nel 2025, e l’unico modo per capire quali siano quali per il tuo model, oggi, è misurare entrambe.

Il Capitolo 15 è dove quella misurazione diventa una disciplina invece che un’opinione.

Il ragionamento ha una proprietà scomoda: è l’unica capacità il cui costo scala con la difficoltà della domanda. Un model che pensa per novecento token esegue novecento forward pass, mantiene in memoria una cache crescente per tutti loro e occupa una GPU per tutta la durata.

Questo rende l’economia del servire un reasoning model nettamente peggiore rispetto al servire un chat model, e trasforma una serie di dettagli implementativi nella differenza tra un prodotto sostenibile e uno insostenibile: come viene memorizzata e riutilizzata la cache delle keys e dei values passati, quante richieste possono condividere un forward pass e di quanta precisione hanno davvero bisogno i weights.

Il Capitolo 13 è l’ultimo in cui il model è un oggetto nella tua memoria invece che un servizio dietro una porta, e riguarda il rendere quell’oggetto abbastanza economico da servire. Incassa anche una promessa di questo capitolo: speculative decoding, che produce diversi token a circa il prezzo di uno facendo indovinare a un model piccolo e controllare a uno grande — un trucco che ha senso solo dopo aver visto quanta parte di un forward pass viene spesa ad aspettare la memoria invece che a fare aritmetica.

Tutte le misurazioni in questo capitolo provengono da Qwen/Qwen2.5-0.5B-Instruct su 24 problemi testuali generati in due passaggi, greedy decoding tranne dove è indicato il campionamento, con zero generazioni troncate ai cap di token usati. Sono riproducibili, e sono un model piccolo su problemi facili: leggi il risultato sulla self-consistency come dimostrazione del meccanismo, non come benchmark. Il Capitolo 18 degli appunti delle lezioni CS229 e il Capitolo 12 dell’Hugging Face LLM Course trattano entrambi questo materiale con model più grandi e benchmark veri.