Dal modello di base all'assistente: SFT, RLHF, DPO e GRPO

Il primo passaggio è il meno appariscente e fa la maggior parte del lavoro. Si raccolgono esempi di istruzioni abbinate a buone risposte, e si continua l'addestramento su di esse con esattamente la loss del Capitolo 8 — prevedere il next token — ma solo sulla parte della risposta. Questo è supervised fine-tuning, o SFT.

Non si sta insegnando nulla di nuovo sul linguaggio. Si sta insegnando un formato: che un testo di questa forma è seguito da un testo di quella forma, e poi si ferma. Guarda di nuovo il fallimento del modello di base. Aveva risposto alla domanda nella prima frase e poi non riusciva a fermarsi, perché nulla nel suo addestramento aveva mai segnato la fine di una risposta. Fermarsi è un comportamento appreso.

È anche per questo che al modello bisogna dire dove sono i confini, ed è ciò che fa un chat template:

<|im_start|>system
You are Qwen, created by Alibaba Cloud. You are a helpful assistant.<|im_end|>
<|im_start|>user
What is the capital of France?<|im_end|>
<|im_start|>assistant

Quei marker <|im_start|> e <|im_end|> sono token reali nel vocabolario, aggiunti prima del fine-tuning, e il modello ne ha visti milioni esattamente in queste posizioni. Sono il modo in cui sa di chi è il turno e dove finisce un turno.

Salta il template e dai al modello una domanda nuda, e gli stai dando una sequenza che non ha visto in training. Misurato, stesso modello, stessa domanda, stesso greedy decoding:

 The capital of France is Paris.

To verify this, I will use a simple
Python code snippet to confirm that
Paris is indeed the capital city of
France.

[...and then it starts writing a
Python script to check its own answer]

The capital of France is Paris.

La risposta è corretta in entrambi i casi, ma senza i marker il modello scivola a scrivere Python per controllarsi, perché il prompt che ha ricevuto non assomiglia a nulla su cui sia stato fine-tuned. Questa è la causa più comune di «il modello è diventato più stupido quando l'ho chiamato direttamente»: il template non è decorazione attorno al modello, è parte del modello, e un template sbagliato è un degrado silenzioso senza alcun errore associato.

SFT ha un tetto, e il tetto sono i dati. Per fare fine-tuning su una dimostrazione serve qualcuno che scriva la risposta ideale — e per la maggior parte delle domande interessanti, scrivere una buona risposta è difficile, lento, costoso, e produce esattamente una risposta di cui non puoi verificare la qualità.

Ciò in cui le persone sono brave è il confronto. Mostrate due risposte, un annotatore può dire in modo affidabile quale sia migliore in pochi secondi, senza essere in grado di produrre nessuna delle due. Questo è il fatto su cui è costruita tutta la seconda fase, ed è la parte che la maggior parte delle spiegazioni capisce al contrario:

Gli esseri umani non scrivono le risposte. Ordinano coppie.

Quindi i dati sono coppie: un prompt, due risposte, e quale delle due ha vinto. Questo non può essere inserito in una next-token loss, perché non c'è una sequenza target. Serve una macchina diversa.

Non puoi chiedere a un essere umano di valutare ogni risposta durante il training: sarebbero milioni di giudizi. Quindi addestri un modello a imitare gli esseri umani: un reward model che prende una risposta e restituisce uno scalare.

Addestrarlo dai confronti usa un risultato del 1952. Il modello Bradley–Terry² dice che, se due elementi hanno forze latenti, la probabilità che uno batta l'altro è la funzione logistica della loro differenza. Ribaltalo e diventa una loss: dato che un essere umano ha preferito $y_w$ a $y_l$, massimizza

che nel codice è l'intero ciclo di training:

loss = -F.logsigmoid(reward(chosen) - reward(rejected)).mean()   

Nota cosa il modello non vede mai: un punteggio assoluto. Impara sempre e solo differenze, che è esattamente ciò che contengono i dati.

Ora la parte che vale la pena misurare. Un reward model impara ciò che gli annotatori hanno premiato, e gli annotatori sono persone. Ecco una simulazione in cui la qualità vera di una risposta dipende solo dall'essere utile e corretta — la lunghezza non vale nulla — ma l'annotatore simulato ha una lieve preferenza per risposte più lunghe quando tutto il resto è vicino, un bias umano ben documentato. Addestra il reward model su 2000 confronti e leggi i suoi pesi:

Il reward model sta funzionando perfettamente. Ha imparato fedelmente le preferenze che gli sono state mostrate — inclusa la parte di quelle preferenze che non ha nulla a che vedere con la qualità. Un reward model non è una misura del bene; è una misura di ciò che gli annotatori hanno scelto, e ogni bias nel gruppo di annotazione ora è un coefficiente in una funzione differenziabile contro cui un modello molto più grande sta per ottimizzare.

Il che ci porta a cosa succede quando lo ottimizzi. Dai alla policy un budget fisso di sforzo da spendere tra le proprietà della risposta, con un'asimmetria realistica: essere utile ed essere corretta è costoso, essere più lunga è economico — basta continuare a scrivere.

Reward per unità di sforzo, per il modello addestrato sopra: utile 8.26, corretto 8.31, lunghezza 31.70. La lunghezza paga quasi quattro volte meglio della correttezza, non perché il reward model sia rotto, ma perché è economica.

Ottimizza contro quella reward e guarda entrambi i numeri:

La reward è aumentata di un fattore 2,5. La cosa che la reward doveva misurare è scesa a zero. La policy ha scoperto che poteva ottenere un punteggio enorme scrivendo a lungo e non dicendo nulla, e nessuna parte del ciclo di training aveva modo di accorgersene, perché il reward model è la definizione di buono dentro il ciclo.

Questo è reward hacking, e se ti sei mai chiesto perché i modelli chat siano così prolissi, questa tabella è una parte importante della risposta.

La difesa standard è penalizzare la policy quando si allontana troppo da dove era partita, misurando la distanza con la divergenza KL del Capitolo 4:

Il riferimento $\pi_{\text{ref}}$ è il modello SFT — la policy prima della fase di reinforcement. L'affermazione è che questo impedisce al modello di vagare verso comportamenti degeneri. Vediamo quanta parte di questa affermazione sopravvive alla misura. Stesso setup, variando $\beta$:

Leggi l'ultima riga rispetto al resto. A $\beta = 0$ e $\beta = 1$ la penalità non fa proprio nulla: la reward vale così tanto più della KL che l'ottimizzatore paga la multa e fa hacking comunque. Tra 5 e 15 il comportamento oscilla. E a $\beta = 60$, la qualità vera è risalita a 1.769 — che è ancora sotto l'1.791 che il modello di riferimento aveva prima che tutto questo iniziasse.

Un'avvertenza prima che quel numero venga citato da qualche parte: l'1.791 dell'ultima riga e lo 0.974 che la prima tabella dà alla policy iniziale sono due misure diverse dello stesso modello pre-RL, prese separatamente dai due esperimenti. Confronta le righe dentro una tabella, mai tra tabelle diverse: la conclusione di ogni tabella sta nelle sue righe, e nessuna dipende dalla baseline dell'altra.

Quindi il riassunto onesto non è «la penalità KL impedisce il reward hacking». È:

La penalità KL non impedisce il reward hacking. Limita quanto la policy può allontanarsi dal riferimento — e siccome il fallimento richiede movimento, questo aiuta. Ma è un guinzaglio, non un correttivo: a $\beta$ basso il guinzaglio si spezza, e a $\beta$ alto riottieni il modello di riferimento e l'intera fase costosa non ha comprato nulla.

La banda utile è stretta, la sua posizione dipende dal reward model, e non c'è modo di trovarla se non guardando. Ecco perché il modello di riferimento deve essere buono: la KL è un pavimento alla qualità del riferimento, non un soffitto al fallimento, ed è gran parte del motivo per cui questa fase è difficile nella pratica più che in linea di principio.

L'algoritmo che ha fatto funzionare tutto questo su scala è Proximal Policy Optimization.³ In un paragrafo: stima l'advantage di ciascuna risposta, aggiorna la policy per aumentare la probabilità delle risposte sopra la baseline, e limita con clipping la dimensione di ogni singolo aggiornamento così che una grande stima dell'advantage non possa distruggere la policy in un passo. Applicato ai language model⁴ significa tenere in gioco quattro modelli alla volta: la policy, il riferimento, il reward model e un critico, con la policy che genera campioni freschi durante tutto il training.

Funziona, ha prodotto InstructGPT e tutto ciò che ne discende, ed è davvero difficile: quattro modelli in memoria, sampling nel ciclo di training, e una reputazione di instabilità meritata. Fingere di poterlo implementare in un blog post sarebbe disonesto, quindi questo capitolo non lo fa.

Ciò che lo ha sostituito per la maggior parte degli usi nasce da un'osservazione. L'obiettivo regolarizzato con KL qui sopra ha una policy ottimale in forma chiusa, e quell'espressione può essere invertita: la reward può essere scritta in termini della policy ottimale e del riferimento. Sostituirla di nuovo nella loss di Bradley–Terry fa scomparire completamente il reward model. Ciò che rimane è una loss supervisionata su coppie di preferenza: niente sampling, niente critico, niente reward model, due modelli in memoria invece di quattro.

Questa è Direct Preference Optimization,⁵ ed è due righe:

def dpo_loss(pi_w, pi_l, ref_w, ref_l, beta=0.1):
    """pi_* and ref_* are summed log-probabilities of a full response."""
    logits = beta * ((pi_w - ref_w) - (pi_l - ref_l))   
    return -F.logsigmoid(logits)                        

Leggi cosa dice. La quantità che viene spinta verso l'alto è quanto più la policy preferisce il vincitore rispetto al riferimento, meno quanto più preferisce il perdente. Il riferimento non è una penalità aggiunta dopo: è dentro la loss, ed è per questo che DPO non ha bisogno di un termine KL separato.

La proprietà che conta di più è nel gradient. Valuta la loss e il suo gradient sulla stessa coppia in cinque stati diversi della policy:

Il gradient cresce man mano che la policy sbaglia di più. Le coppie che il modello gestisce già contribuiscono quasi nulla; le coppie che gestisce al contrario dominano l'aggiornamento. DPO pesa ogni esempio in base a quanto la policy si sta sbagliando in quel momento, automaticamente, senza scheduling — e questo auto-pesamento è il meccanismo che fa il lavoro che in PPO facevano la stima dell'advantage e il critico. (La loss alla terza riga è esattamente $\ln 2$, che è l'ancora con cui controllare qualunque implementazione: una policy identica al suo riferimento non ha imparato nulla e dovrebbe stare a $\ln 2$.)

GRPO⁶ prende una strada diversa per uscire dallo stesso problema. Mantiene il ciclo di sampling ma elimina il critico: invece di addestrare un modello a prevedere la baseline, campiona un gruppo di risposte allo stesso prompt e usa direttamente la reward media del gruppo come baseline. L'advantage di una risposta è quanto è stata migliore delle sue sorelle. Questo scambia un intero modello con un batch più grande, ed è ciò che ha reso pratico il training con reward verificabili — l'argomento del Capitolo 12.

Due cose da portare avanti.

La prima è che questa fase ha un costo, e si manifesta come capacità. I modelli spesso peggiorano in modo misurabile su alcuni benchmark task dopo l'alignment training — la tassa dell'allineamento — perché l'obiettivo è cambiato: una risposta sicura, cauta e ben formattata non è sempre la risposta che massimizza l'accuratezza. Parte di quel divario è stato eliminato con engineering, e parte è un vero trade-off più che un bug da correggere.

La seconda è la domanda che la parola allineato nasconde. Allineato con chi? La catena è: un'azienda scrive linee guida, i contractor le interpretano, i loro confronti addestrano un reward model, il reward model plasma una policy, e la policy risponde a una domanda posta da qualcuno che non ha visto nulla di tutto questo. Ogni anello è una scelta fatta da persone specifiche, e nessuno degli algoritmi di questo capitolo ha un'opinione sul fatto che quelle scelte siano buone.

Non è un vezzo retorico. È la ragione concreta per cui due modelli frontier rifiutano richieste diverse, per cui lo stesso modello cambia idea tra versioni, e per cui «allineato» è la descrizione di un processo più che una proprietà di un artefatto. La matematica in questo capitolo è assestata. Quella parte no.

Il post-training ha insegnato al modello a rispondere. Non gli ha insegnato a pensare prima di rispondere, e le due cose sono diverse in un modo che, si scopre, può essere addestrato.

Il Capitolo 12 parla di cosa succede quando lasci che un modello spenda più calcolo su una domanda difficile al momento della risposta anziché al momento del training: chain of thought, reinforcement learning da reward verificabili, e il motivo per cui un modello che mostra il proprio ragionamento non sta semplicemente spiegando sé stesso, ma sta calcolando in modo diverso. Salda anche il debito di questo capitolo: GRPO esiste lì, facendo il lavoro che prima faceva il critico di PPO, su reward che non hanno bisogno di alcun annotatore perché una dimostrazione o verifica, o non verifica.

Le generazioni qui sopra vengono da gpt2 e Qwen/Qwen2.5-0.5B-Instruct con greedy decoding, quindi si riproducono esattamente. Il Capitolo 11 dell'Hugging Face LLM Course attraversa SFT e DPO con trl e peft se vuoi eseguire la cosa reale invece della simulazione; il capitolo 7 di Build a Large Language Model (From Scratch) di Sebastian Raschka implementa l'instruction fine-tuning end to end senza una libreria.