De la model de bază la asistent: SFT, RLHF, DPO și GRPO

Primul pas este cel mai puțin spectaculos și face cea mai mare parte a muncii. Colectezi exemple de instrucțiuni împerecheate cu răspunsuri bune și continui antrenarea pe ele cu exact loss-ul din Capitolul 8 — prezice următorul token — dar numai pe partea de răspuns. Acesta este supervised fine-tuning, sau SFT.

Nu se predă nimic nou despre limbaj. Ce se predă este un format: că textul de această formă este urmat de textul de acea formă, iar apoi se oprește. Uită-te din nou la eșecul modelului de bază. A răspuns la întrebare în prima propoziție și apoi nu s-a putut opri, pentru că nimic din antrenarea lui nu a marcat vreodată sfârșitul unui răspuns. Oprirea este un comportament învățat.

De aceea modelului trebuie să i se spună și unde sunt limitele, iar asta este 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

Acele marcaje <|im_start|> și <|im_end|> sunt tokens reali în vocabular, adăugați înainte de fine-tuning, iar modelul a văzut milioane dintre ei exact în aceste poziții. Așa știe al cui este rândul și unde se termină un rând.

Sari peste template și dă-i modelului o întrebare brută, iar tu îi dai o secvență pe care nu a văzut-o în antrenare. Măsurat, același model, aceeași întrebare, aceeași decodare greedy:

 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.

Răspunsul este corect în ambele cazuri, dar fără marcaje modelul deviază spre a scrie Python ca să se verifice singur, pentru că prompt-ul primit nu seamănă cu nimic din ce a fost fine-tuned. Aceasta este cea mai frecventă cauză pentru „modelul a devenit mai prost când l-am apelat direct”: template-ul nu este decor în jurul modelului, este parte din model, iar un template greșit este o degradare tăcută, fără eroare atașată.

SFT are un plafon, iar plafonul sunt datele. Ca să faci fine-tuning pe o demonstrație, ai nevoie ca cineva să scrie răspunsul ideal — iar pentru cele mai multe întrebări interesante, să scrii un răspuns bun este greu, lent, scump și produce exact un răspuns a cărui calitate nu o poți verifica.

La ce se pricep oamenii este comparația. Dacă i se arată două răspunsuri, un adnotator poate spune fiabil, în câteva secunde, care este mai bun, fără să poată produce niciunul dintre ele. Acesta este faptul pe care este construită întreaga a doua etapă și este partea pe care cele mai multe explicații o prezintă invers:

Oamenii nu scriu răspunsurile. Ei ordonează perechi.

Așadar datele sunt perechi — un prompt, două răspunsuri și care dintre ele a câștigat. Asta nu poate fi introdus într-un loss next-token, pentru că nu există o secvență țintă. Are nevoie de o mașină diferită.

Nu poți cere unui om să puncteze fiecare răspuns în timpul antrenării — asta ar însemna milioane de judecăți. Așa că antrenezi un model să imite oamenii: un model de recompensă care ia un răspuns și returnează un scalar.

Antrenarea lui din comparații folosește un rezultat din 1952. Modelul Bradley–Terry² spune că, dacă două elemente au forțe latente, probabilitatea ca unul să îl bată pe celălalt este funcția logistică a diferenței lor. Întoarce asta pe dos și devine un loss: dat fiind că un om a preferat $y_w$ în locul lui $y_l$, maximizează

ceea ce în cod este întreaga buclă de antrenare:

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

Observă ce nu vede niciodată modelul: un scor absolut. Învață doar diferențe, ceea ce este exact ce conțin datele.

Acum partea care merită măsurată. Un model de recompensă învață ce au recompensat adnotatorii, iar adnotatorii sunt oameni. Iată o simulare în care calitatea adevărată a unui răspuns depinde doar de a fi util și corect — lungimea nu valorează nimic — dar adnotatorul simulat are o preferință ușoară pentru răspunsuri mai lungi când tot restul este apropiat, un bias uman bine documentat. Antrenează modelul de recompensă pe 2000 de comparații și citește-i ponderile:

Modelul de recompensă funcționează perfect. A învățat fidel preferințele care i-au fost arătate — inclusiv partea acelor preferințe care nu are nicio legătură cu calitatea. Un model de recompensă nu este o măsură a binelui; este o măsură a ceea ce au ales adnotatorii, iar fiecare bias din grupul de adnotare este acum un coeficient într-o funcție diferențiabilă față de care un model mult mai mare urmează să optimizeze.

Asta ne aduce la ce se întâmplă când optimizezi pentru el. Dă-i policy-ului un buget fix de efort de cheltuit între proprietățile răspunsului, cu o asimetrie realistă: a fi util și a fi corect sunt scumpe, iar a fi mai lung este ieftin — continui pur și simplu să scrii.

Reward per unitate de efort, pentru modelul antrenat mai sus: util 8,26, corect 8,31, lungime 31,70. Lungimea plătește de aproape patru ori mai bine decât corectitudinea, nu pentru că modelul de recompensă este stricat, ci pentru că este ieftină.

Optimizează față de acel reward și urmărește ambele numere:

Reward-ul a crescut cu un factor de 2,5. Lucrul pe care reward-ul trebuia să îl măsoare a ajuns la zero. Policy-ul a descoperit că poate obține scoruri enorm de bune scriind pe larg și nespunând nimic, iar nicio parte a buclei de antrenare nu avea vreo modalitate să observe, pentru că modelul de recompensă este definiția binelui în interiorul buclei.

Acesta este reward hacking, iar dacă te-ai întrebat vreodată de ce modelele de chat sunt atât de verbose, acest tabel este o mare parte din răspuns.

Apărarea standard este să penalizezi policy-ul pentru că se îndepărtează prea mult de unde a pornit, măsurând distanța cu divergența KL din Capitolul 4:

Referința $\pi_{\text{ref}}$ este modelul SFT — policy-ul înainte de etapa de reinforcement. Afirmația este că asta împiedică modelul să rătăcească în comportamente degenerate. Să vedem cât din această afirmație supraviețuiește măsurării. Aceeași configurație, variind $\beta$:

Citește ultimul rând în raport cu restul. La $\beta = 0$ și $\beta = 1$ penalizarea nu face nimic: reward-ul valorează mult mai mult decât KL, așa că optimizatorul plătește amenda și face hacking oricum. Între 5 și 15 comportamentul se schimbă brusc. Iar la $\beta = 60$, calitatea adevărată a urcat înapoi la 1,769 — ceea ce este tot sub 1,791, cât avea modelul de referință înainte ca toate acestea să înceapă.

O avertizare înainte ca acel număr să fie citat undeva: 1,791 din ultimul rând și 0,974 pe care primul tabel îl dă policy-ului inițial sunt două măsurători diferite ale aceluiași model pre-RL, luate separat de cele două experimente. Compară rânduri în interiorul unui tabel, niciodată între tabele — concluzia fiecărui tabel stă pe propriile rânduri și niciuna nu depinde de baseline-ul celuilalt.

Așadar rezumatul onest nu este „penalizarea KL previne reward hacking”. Este:

Penalizarea KL nu previne reward hacking. Limitează cât de departe se poate mișca policy-ul față de referință — și, fiindcă eșecul necesită mișcare, asta ajută. Dar este o lesă, nu o corecție: la $\beta$ mic, lesa se rupe, iar la $\beta$ mare primești înapoi modelul de referință și întreaga etapă scumpă nu a cumpărat nimic.

Banda utilă este îngustă, poziția ei depinde de modelul de recompensă și nu există nicio modalitate de a o găsi decât uitându-te. De aceea modelul de referință trebuie să fie bun — KL este o podea la calitatea referinței, nu un plafon asupra eșecului — și aceasta este o mare parte din motivul pentru care etapa este dificilă în practică, nu în principiu.

Algoritmul care a făcut ca asta să funcționeze la scară este Proximal Policy Optimization.³ Într-un paragraf: estimează advantage-ul fiecărui răspuns, actualizează policy-ul ca să crească probabilitatea răspunsurilor peste baseline și limitează dimensiunea oricărei actualizări individuale, astfel încât o estimare mare de advantage să nu distrugă policy-ul dintr-un singur pas. Aplicat modelelor lingvistice⁴, asta înseamnă să ții în joc patru modele deodată — policy-ul, referința, modelul de recompensă și un critic — cu policy-ul generând mostre proaspete pe tot parcursul antrenării.

Funcționează, a produs InstructGPT și tot ce a coborât din el, și este cu adevărat dificil: patru modele în memorie, sampling în bucla de antrenare și o reputație de instabilitate pe deplin meritată. Să pretinzi că îl poți implementa într-un articol de blog ar fi necinstit, așa că acest capitol nu o face.

Ce l-a înlocuit pentru cele mai multe scopuri a venit din observarea unui lucru. Obiectivul regularizat cu KL de mai sus are o policy optimă în formă închisă, iar acea expresie poate fi inversată: reward-ul poate fi scris în funcție de policy-ul optim și de referință. Înlocuind asta în loss-ul Bradley–Terry, modelul de recompensă dispare complet. Ce rămâne este un loss supravegheat pe perechi de preferințe — fără sampling, fără critic, fără model de recompensă, două modele în memorie în loc de patru.

Acesta este Direct Preference Optimization,⁵ și are două linii:

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)                        

Citește ce spune. Cantitatea împinsă în sus este cât de mult mai mult preferă policy-ul câștigătorul decât o făcea referința, minus cât de mult mai mult preferă învinsul. Referința nu este o penalizare atașată ulterior — este în interiorul loss-ului, motiv pentru care DPO nu are nevoie de un termen KL separat.

Proprietatea care contează cel mai mult este în gradient. Evaluează loss-ul și gradient-ul lui pe aceeași pereche în cinci stări diferite ale policy-ului:

Gradient-ul crește pe măsură ce policy-ul greșește mai mult. Perechile pe care modelul le gestionează deja contribuie aproape deloc; perechile pe care le inversează domină actualizarea. DPO ponderează fiecare exemplu după cât de greșit este policy-ul în acel moment, automat, fără programare — iar această auto-ponderare este mecanismul care face munca pe care estimarea de advantage și criticul din PPO o făceau. (Loss-ul de pe al treilea rând este exact $\ln 2$, ancora față de care poți verifica orice implementare: o policy identică cu referința ei nu a învățat nimic și ar trebui să stea la $\ln 2$.)

GRPO⁶ ia o rută diferită pentru a ieși din aceeași problemă. Păstrează bucla de sampling, dar șterge criticul: în loc să antreneze un model să prezică baseline-ul, eșantionează un grup de răspunsuri la același prompt și folosește direct reward-ul mediu al grupului ca baseline. Advantage-ul unui răspuns este cât de mult mai bun a fost decât frații lui. Asta schimbă un model întreg pe un batch mai mare și este ce a făcut practică antrenarea cu reward verificabil — subiectul Capitolului 12.

Două lucruri de dus mai departe.

Primul este că această etapă are un cost, iar el apare ca abilitate. Modelele devin adesea măsurabil mai slabe la unele sarcini de benchmark după antrenarea de alignment — taxa de alignment — fiindcă obiectivul s-a schimbat: un răspuns sigur, prudent și bine formatat nu este întotdeauna răspunsul care maximizează acuratețea. O parte din acel decalaj a fost eliminată prin inginerie, iar o parte este un compromis real, nu un bug de reparat.

Al doilea este întrebarea pe care cuvântul aligned o ascunde. Aliniat cu cine? Lanțul este: o companie scrie ghiduri, contractori le interpretează, comparațiile lor antrenează un model de recompensă, modelul de recompensă modelează o policy, iar policy-ul răspunde la o întrebare de la cineva care nu a văzut nimic din toate acestea. Fiecare verigă este o alegere făcută de oameni anume, iar niciunul dintre algoritmii din acest capitol nu are vreo opinie despre dacă acele alegeri sunt bune.

Aceasta nu este o înfloritură retorică. Este motivul concret pentru care două modele frontier refuză cereri diferite, de ce același model se răzgândește între versiuni și de ce „aligned” este o descriere a unui proces, nu o proprietate a unui artefact. Matematica din acest capitol este stabilită. Acea parte nu este.

Post-training a învățat modelul să răspundă. Nu l-a învățat să gândească înainte să răspundă, iar cele două sunt diferite într-un fel care se dovedește a fi antrenabil.

Capitolul 12 este despre ce se întâmplă când lași un model să cheltuiască mai multă computație pe o întrebare grea la momentul răspunsului, nu la momentul antrenării — chain of thought, reinforcement learning din recompense verificabile și motivul pentru care un model care își arată lucrul nu doar se explică, ci calculează diferit. Achită și datoria din acest capitol: GRPO există în el, făcând treaba pe care o făcea înainte criticul PPO, pe rewards care nu au nevoie de niciun adnotator, fiindcă o demonstrație fie se verifică, fie nu.

Generările de mai sus vin din gpt2 și Qwen/Qwen2.5-0.5B-Instruct cu decodare greedy, așa că se reproduc exact. Capitolul 11 din Hugging Face LLM Course parcurge SFT și DPO cu trl și peft dacă vrei să rulezi lucrul real în locul simulării; capitolul 7 din Build a Large Language Model (From Scratch) de Sebastian Raschka implementează instruction fine-tuning cap-coadă fără o bibliotecă.