I modelli di ragionamento si addestrano, non si promptano

Ecco un'opinione che l'anno scorso ho difeso male a un pranzo di squadra e che da allora mi convince sempre di più: se il tuo modello mentale di un modello di ragionamento è «un LLM normale a cui è stato detto di pensare passo dopo passo», non capisci affatto i modelli di ragionamento, e questo equivoco ti sta silenziosamente costando denaro e accuratezza in produzione. I modelli di ragionamento non sono una tecnica di prompting. Sono un artefatto dell'addestramento. Il comportamento di chain-of-thought che li rende bravi in matematica e nel codice emerge dal reinforcement learning con ricompense verificabili, non da nulla che scrivi in un system prompt. Ho finalmente capito questo punto a fondo lavorando sullo stesso terreno che Sebastian Raschka copre nel suo nuovo corso di 11 ore su come costruire un modello di ragionamento: caricare un piccolo modello base Qwen3, costruire un verificatore, lanciare GRPO e guardare le tracce di ragionamento allungarsi mentre l'accuratezza sale. Una volta che l'hai visto succedere nel tuo training loop, non puoi più farne a meno di vederlo.

Lascia che difenda questa affermazione come si deve, e poi che la ridimensioni dove serve, perché c'è un punto in cui il prompting conta davvero, e fingere il contrario sarebbe un'altra forma di hype.

Perché il modello mentale del «basta fare prompt» non regge

La storia più diffusa va più o meno così: nel 2022 i ricercatori hanno scoperto che aggiungere «Ragioniamo passo dopo passo» a un prompt migliorava parecchio l'accuratezza aritmetica, e così è nata la chain-of-thought prompting. È vero, per quanto arriva. Quello che la storia omette è cosa è successo dopo: i laboratori hanno preso quel comportamento e l'hanno impresso nei pesi con il reinforcement learning. Un modello di ragionamento moderno non ha bisogno della tua formula magica passo dopo passo. Genera tracce di ragionamento estese per default perché è stato addestrato a farlo, premiato per produrre tracce che terminano con risposte corrette.

Puoi verificarlo da solo con un esperimento che richiede un pomeriggio. Prendi un modello base (Qwen3 0.6B funziona bene e gira su una singola GPU consumer) e valutalo su MATH-500 con e senza chain-of-thought prompting. Ottieni un miglioramento modesto. Ora prendi la variante addestrata con RLVR della stessa famiglia di modelli. La differenza tra le due condizioni non è un miglioramento modesto: è un precipizio. Nessun system prompt mai scritto la colma. Ecco il nucleo empirico della mia tesi: la capacità vive nei pesi, e i pesi ci sono arrivati grazie all'addestramento, non grazie a sofisticate disposizioni di token in fase di inferenza.

La confusione persiste perché, dall'esterno, i due casi sembrano identici: il modello emette un lungo flusso di ragionamento intermedio prima di rispondere. Ma questa somiglianza superficiale nasconde una differenza causale. Chiedere a un modello base di pensare passo dopo passo è come chiedere a qualcuno di raccontare ad alta voce il proprio processo mentale mentre fa un calcolo a mente: il racconto segue la capacità. Il training RL, invece, cambia la capacità stessa, perché il modello viene ottimizzato end-to-end per la correttezza della risposta, e il ragionamento esteso si rivela una strategia utile per ottenere risposte corrette sui problemi difficili.

Il verificatore è tutto il trucco

Quando facevo l'ML engineer, la parte del RLHF che mi sembrava sempre un po' maledetta era il reward model. Addestri una rete neurale separata a imitare le preferenze umane, poi ottimizzi la tua policy contro di essa, e poi passi il resto del progetto a combattere il reward hacking: la policy trova qualche output degenere che ottiene un punteggio alto dal reward model pur essendo inutile per gli esseri umani veri. È una relazione conflittuale incorporata nell'architettura.

Il reinforcement learning con ricompense verificabili, cioè RLVR, aggira del tutto questo problema, e costruire un verificatore da zero ti fa apprezzare quanto sia elegante la mossa. Per la matematica, il verificatore è un programma noioso e deterministico: estrae la risposta finale dall'output del modello, la normalizza (gestendo frazioni, decimali e forme equivalenti come 1/2 e 0.5) e verifica l'equivalenza matematica. Risposta giusta, ricompensa uno. Risposta sbagliata, zero. Non c'è nessun reward model appreso da ingannare. Il segnale di ricompensa è la verità di base.

È per questo che i modelli di ragionamento sono diventati bravi prima in matematica e nel codice. Entrambi i domini offrono verificatori economici e affidabili: controllori di equivalenza simbolica per la matematica, unit test per il codice. Non servono annotatori umani che classifichino gli output; serve una funzione Python che restituisca un booleano. La conseguenza pratica per chi costruisce un ragionamento specifico di dominio è netta: se sai scrivere un verificatore per il tuo dominio, probabilmente puoi addestrare un reasoner per quel dominio. Se non puoi, perché la correttezza nel tuo dominio è questione di gusto, come nel copy di marketing, resti bloccato con l'RLHF e con i suoi grattacapi di reward hacking.

Il collo di bottiglia del ragionamento in un nuovo dominio non è il calcolo né i dati. È se riesci a scrivere in forma di programma che cosa significa «corretto».

Un dettaglio che apprezzo molto di costruire prima il verificatore, prima di qualsiasi training, è che svolge un doppio ruolo. Lo stesso grader che valuta il tuo modello base su MATH-500 diventa la funzione di ricompensa durante la RL. Quando lo implementi da solo ti accorgi di quanto lavoro sottile svolge: l'estrazione della risposta è davvero ostica, perché i modelli esprimono le risposte finali in decine di formati, e un estrattore fragile corrompe in silenzio il segnale di ricompensa. Un modello che scrive «quindi x = 7» potrebbe risultare sbagliato se la tua regex cerca solo le risposte nel box. Verificatori sciatti insegnano policy sciatte. È il tipo di lezione che non impari mai leggendo articoli.

Cosa fa davvero GRPO ai pesi

Il training loop vero e proprio, nella sua forma semplificata da zero, è sorprendentemente compatto. Group Relative Policy Optimization, l'algoritmo reso popolare da DeepSeek, elimina la rete critic che rendeva PPO così esoso in memoria. Invece di apprendere una funzione valore, generi un gruppo di risposte allo stesso prompt, le valuti tutte con il verificatore e calcoli il vantaggio di ciascuna rispetto alla media del gruppo. Le risposte migliori della media vedono aumentare la probabilità dei loro token; quelle peggiori la vedono diminuire.

def grpo_advantages(rewards: torch.Tensor) -> torch.Tensor:
# rewards: [group_size], one per sampled response to the same prompt
mean = rewards.mean()
std = rewards.std().clamp_min(1e-4)
return (rewards - mean) / std  # relative advantage per response
# Training step: maximize advantage-weighted log-probability
def grpo_loss(logprobs: torch.Tensor, advantages: torch.Tensor) -> torch.Tensor:
# logprobs: summed sequence log-prob under the current policy
return -(advantages.detach() * logprobs).mean()

Le implementazioni reali aggiungono una penalità KL per evitare che la policy si allontani troppo dal modello di riferimento, più il clipping preso in prestito da PPO, ma lo scheletro qui sopra è onestamente l'idea centrale. E ciò che la rende magica da osservare è che non dici al modello nulla sullo stile di ragionamento. Premi solo le risposte finali corrette. Eppure, nel corso del training, la lunghezza delle risposte cresce. Il modello inizia a produrre autocorrezioni a metà traccia («aspetta, controllo») perché le tracce con comportamenti di verifica hanno più probabilità di concludersi con risposte corrette, e le risposte corrette sono l'unica cosa che fa guadagnare ricompensa. Lo stile di chain-of-thought è una soluzione emergente al problema di ottimizzazione, non un comportamento che qualcuno ha progettato. Ecco perché dico che è addestrato, non promptato: la versione dell'era del prompting di questo comportamento era l'essere umano che imitava ciò che la RL avrebbe poi scoperto da sola.

C'è una nota ingegneristica pragmatica nascosta qui, che il ciclo dell'hype salta: un modello da 0.6B con una GPU decente basta per vedere questa dinamica in modo concreto. Otterrai un miglioramento misurabile su MATH-500 con GRPO su hardware che puoi noleggiare per pochi dollari l'ora. Non otterrai un modello di frontiera. Va bene così: non è questo lo scopo dell'esercizio.

Inference-time scaling: dove il calcolo sostituisce (in parte) l'addestramento

Prima di qualsiasi RL esiste una famiglia di tecniche che migliorano le risposte con i pesi congelati: campioni più candidati con temperatura e top-p, poi li combini. La self-consistency è il cavallo di battaglia: generi k risposte e prendi la maggioranza tra le risposte finali. Funziona in modo sorprendentemente efficace e funziona anche sui modelli base, ed è la prima crepa nella mia affermazione iniziale che concedo volentieri: il calcolo in fase di inferenza è un asse di miglioramento reale e indipendente.

Ma guarda cosa richiedono davvero queste tecniche. Il voto a maggioranza aiuta solo se il modello ha già una probabilità non banale di produrre risposte corrette: il voto amplifica un segnale che esiste, non ne crea uno dal nulla. La selezione basata su punteggi (ordinare i candidati per log-probabilità della sequenza) ha la stessa proprietà. E i cicli di auto-raffinamento, in cui il modello critica e rivede la propria risposta, si rivelano deludentemente deboli sui modelli base, perché l'autocritica onesta è essa stessa una capacità che la RL installa. Ogni trucco in fase di inferenza si combina con l'addestramento; nessuno lo sostituisce. Il motivo per cui i sistemi di frontiera combinano modelli addestrati con RL e scaling in inferenza è che i due effetti si moltiplicano invece di sommarsi.

Il lato dei costi conta per chi lavora sul campo. La self-consistency con k=16 costa sedici volte l'inferenza. Se sia un buon compromesso dipende interamente dalla tua curva accuratezza-per-dollaro, e l'unico modo onesto per rispondere è tracciare tu stesso l'accuratezza su MATH-500 in funzione del numero di candidati. Abbiamo già affrontato una questione simile sul posizionamento del calcolo nel nostro articolo sui modelli flash e l'efficienza in inferenza: il filo conduttore è che «spendere più calcolo» ha almeno tre significati diversi, e non sono intercambiabili.

Distillazione, e l'unico punto in cui sopravvive il prompting

La fase finale della pipeline da zero è la distillazione: prendi le lunghe tracce di ragionamento di un reasoner forte (di solito grande) e fai il fine-tuning di un modello più piccolo direttamente su di esse, con un normale apprendimento supervisionato. Niente RL, nessun verificatore nel loop. È così che sono nati molti dei piccoli modelli di ragionamento economici che finirai per distribuire. E questo rafforza la tesi invece di indebolirla: il comportamento di ragionamento arriva comunque da dati di training prodotti da un modello addestrato con RL, solo trasferiti tramite discesa del gradiente invece che tramite ricompensa. La capacità non viene mai iniettata al momento del prompt; viene sempre impressa dall'ottimizzazione.

Allora dove si rompe la mia tesi controcorrente? Qui, onestamente: il prompting conta ancora ai margini, e i margini non sono zero. I controlli dello sforzo di ragionamento, cioè le impostazioni di budget di pensiero basso/medio/alto che i modelli di ultima generazione espongono, sono leve di inferenza che scambiano in modo significativo accuratezza con latenza e costo. I vincoli sull'output strutturato, le pipeline con verificatore nel loop e il constrained decoding sono tecniche a livello di prompt e harness con un valore reale, come abbiamo sostenuto nel nostro articolo sul constrained decoding. E se sei bloccato con un modello base e non puoi addestrare nulla, il chain-of-thought prompting vale ancora punti reali sugli eval. «Addestrati, non promptati» è un'affermazione sull'origine della capacità, non sostiene che le scelte in fase di inferenza non contino.

Perché costruirlo batte il leggerne

Un'obiezione ragionevole è emersa nei soliti posti: un tutorial per costruire il proprio modello di ragionamento non è come una guida per costruire la propria CPU, affascinante ma inutile, visto che i veri training richiedono cluster e dati proprietari? Penso che questo fraintenda lo scopo dell'esercizio, e direi lo stesso del classico tutorial per costruire una shell, che abbiamo apprezzato in Cosa insegna costruire una shell sulla riga di comando Unix proprio per questo motivo. Nessuno scrive una shell per sostituire bash. La scrivi perché fork, exec, pipe e gestione dei segnali smettono di essere astrazioni memorizzate e diventano meccanismi che hai tenuto tra le mani.

Lo stesso vale qui. Le cose che hanno cambiato in modo permanente il mio modo di lavorare con i modelli di ragionamento sono venute da dettagli implementativi, non dagli articoli:

• Scrivere il verificatore mi ha insegnato che la qualità della ricompensa è un problema di ingegneria del software: i casi limite della normalizzazione distorcono il training in silenzio, e «la ricompensa è la verità di base» è vera solo quanto il tuo estrattore di risposte.
• Implementare il punteggio tramite log-probabilità della sequenza (con tutte le acrobazie di stabilità numerica che comporta) ha demistificato metà delle funzioni di loss della letteratura di post-training. Si riducono tutte a confrontare quanto sono probabili le risposte sotto policy diverse.
• Vedere crescere la lunghezza delle risposte durante GRPO, senza alcun prompt, ha eliminato la mia ultima convinzione residua che lo stile di ragionamento fosse un comportamento superficiale. È ciò che l'ottimizzazione trova quando l'unico obiettivo è la correttezza.
• Tracciare l'accuratezza in funzione del numero di candidati per la self-consistency mi ha dato un'intuizione concreta del compromesso accuratezza-per-dollaro che nessuna tabella di benchmark mi aveva mai dato.

Anche l'ansia per il calcolo è esagerata per il caso d'uso didattico. Le parti iniziali (caricare un modello base, generare in streaming con KV caching, costruire il verificatore, eseguire MATH-500) rientrano nel territorio di CPU e laptop, o quasi. Il training GRPO richiede una GPU, ma una sola, e noleggiata all'ora costa meno della maggior parte dei manuali. Ciò che non puoi replicare a casa è la scala, e la scala è davvero una disciplina diversa: è uno dei miti sul motore di inferenza di DeepSeek che abbiamo verificato. Lo stack di serving di un laboratorio di frontiera risolve problemi che semplicemente non esistono alla scala dei tutorial, e viceversa.

La conclusione pratica

Se porti via una sola cosa da tutto questo, porta con te la visione centrata sul verificatore. Lo stack moderno del ragionamento è questo: un modello base, un programma che decide cosa significa «corretto», un algoritmo di RL che ottimizza rispetto a quel criterio e tecniche in fase di inferenza che moltiplicano il risultato. Il prompting sta ai margini di questo sistema, a guidare una capacità che l'addestramento ha creato. I team che lo capiscono concentrano lo sforzo dove si compone: verificatori migliori, design delle ricompense migliore, cicli di valutazione migliori, come quelli che sosteniamo manchino in gran parte dei benchmark sull'IA che non misurano il lavoro reale. I team che non lo capiscono continuano a ritoccare i system prompt chiedendosi perché l'accuratezza si stabilizzi.

La mia affermazione del pranzo di squadra regge con un asterisco: i modelli di ragionamento si addestrano, non si promptano, ma l'harness che costruisci attorno a loro, prompt inclusi, decide quanta di quella capacità addestrata riesci davvero a sfruttare. Costruisci tu stesso la versione piccola, prima o poi. Undici ore di codice seguendo il corso sono un prezzo basso per non confondersi mai più su questo punto.