Chain of Thought, RLVR și Test-Time Compute, măsurate

Tentația este să spui că a doua versiune „s-a gândit la problemă”. Rezistă tentației, pentru că mecanismul este în același timp mai simplu și mai util de înțeles.

Un transformer face o cantitate fixă de calcul pentru fiecare token generat. O trecere forward: aceleași layers, aceleași matrice, același număr de operații, indiferent dacă întrebarea este cât face 2+2 sau demonstrează această teoremă. Nu există în interiorul modelului un buton pentru „încearcă mai tare aici”.

Așadar, când unui model i se cere răspunsul imediat, tot calculul disponibil pentru el este o singură trecere forward. Fiecare cantitate intermediară trebuie să încapă în activările acelei singure treceri, iar ceea ce nu poate calcula acolo, nu poate calcula deloc.

Emiterea de token schimbă asta, și o schimbă în două moduri distincte care merită separate:

• Mai mult calcul. Fiecare token generat este încă o trecere forward completă. O sută patruzeci și cinci de token de lucru înseamnă de o sută patruzeci și cinci de ori aritmetica necesară pentru a răspunde direct.
• Memorie externalizată. Token sunt scriși în context, așa că următoarea trecere îi poate citi. 5 × 13 = 65 devine un fapt în input, nu o valoare pe care modelul trebuie să o țină într-o activare și să o ducă mai departe. Modelul își folosește propriul output ca pe o ciornă.

Al doilea punct este cel pe care oamenii îl ratează și explică de ce lucrul trebuie să fie scris ca să ajute. Un model căruia i se cere „gândește-te în tăcere și apoi răspunde” nu are unde să pună gândul.

Nimic din toate acestea nu cere ceva mistic și produce o predicție fermă: chain of thought ar trebui să ajute cel mai mult la probleme cu structură serială — unde pasul doi are nevoie de rezultatul pasului unu — și cel mai puțin la probleme care sunt o singură căutare. Exact asta găsește literatura, și de aceea „gândește pas cu pas” nu face nimic pentru care este capitala Franței.

Tehnica a apărut în 2022 în două bucăți. Wei et al. au arătat că includerea de exemple rezolvate în prompt — demonstrații în care răspunsul este precedat de raționament — producea câștiguri mari pe benchmark-uri de aritmetică și bun-simț.¹ Kojima et al. au arătat apoi ceva mai straniu: nu ai nevoie de exemple. Adăugarea expresiei „Let's think step by step” la un prompt zero-shot surprinde mare parte din același câștig.²

Al doilea rezultat este cel care îți spune ce se întâmplă. Dacă o frază magică deblochează comportamentul, comportamentul era deja în model — pretraining-ul este plin de soluții rezolvate, iar fraza este un indicator către acea regiune a distribuției. Chain of thought nu a învățat modelul nimic. A selectat ceva ce modelul avea deja.

Această încadrare prezice și obsolescența finală a tehnicii, la care revenim la sfârșitul capitolului.

Următoarea mișcare evidentă: dacă un lanț de raționament poate fi greșit, samplează mai multe și ia răspunsul majoritar. Aceasta este self-consistency.³ Este o cheltuială strict mai mare — $n$ generări complete în loc de una — iar intuiția este că răspunsurile greșite se împrăștie, pe când cele corecte coincid.

Măsurat pe 16 dintre aceleași probleme, cu sampling la temperature 0.8, vot majoritar peste $n$ lanțuri:

Șaisprezece probleme înseamnă un numitor mic, iar regula din Capitolul 4 se aplică acestui tabel la fel de mult ca oricărui altul. 13 din 16 înseamnă 81 % cu un interval Wilson de 95 % de [57, 93]; 16 din 16 înseamnă 100 % cu [81, 100]. Acestea se suprapun. Citește forma curbei, care este constatarea; nu citi treapta exactă la care se aplatizează, pe care șaisprezece probleme nu o pot localiza.

Două lucruri în acel tabel, iar al doilea nu este ce mă așteptam.

Curba se aplatizează la $n = 3$. La al treilea sample, acuratețea este la plafon, iar celelalte două sample nu cumpără nimic, dar costă câte 172 de token fiecare, 345 împreună. Aceasta este forma fiecărei curbe de self-consistency raportate în literatură și apare mult mai devreme decât sugerează încadrarea „mai multe sample înseamnă mai bine”.

Iar greedy decoding era deja la 100 %. Uită-te înapoi la începutul capitolului: un lanț, fără sampling, 145 de token, 24/24. Sampling la temperature 0.8 a scăzut acuratețea la 81 %, iar self-consistency a avut nevoie de trei generări ca să urce înapoi acolo unde o singură trecere greedy era deja — la de 3,6 ori mai mulți token, sau de șase ori dacă rulezi sweep-ul până la cinci fără să știi unde se aplatizează.

Acesta nu este un argument împotriva self-consistency. Este o afirmație precisă despre ce face: temperature cumpără diversitate injectând erori, iar votul elimină erorile pe care tocmai le-a injectat. La probleme unde greedy decoding eșuează — unde lanțul cel mai probabil duce într-un loc greșit, iar unul mai puțin probabil este corect — schimbul merită, și de aceea există tehnica. La probleme unde greedy reușește deja, este o metodă de a cheltui de șase ori bugetul ca să ieși pe zero.

Nimeni nu publică al doilea caz, motiv pentru care merită să-l măsori pe propriul task înainte să adopți tehnica. Acestea sunt probleme ușoare în doi pași pentru un model mic; acesta este regimul în care rezultatul iese așa.

Tot ce s-a întâmplat până acum are loc la momentul prompt pe un model care nu a fost antrenat special pentru asta. Schimbarea care a produs generația actuală de modele de raționament a fost mutarea acestui lucru în antrenare — iar cheia care a făcut posibil acest lucru este mai îngustă decât pare.

Post-training-ul din Capitolul 11 avea nevoie de preferințe umane, pentru că „a fost acesta un răspuns bun?” nu are un răspuns programatic. Dar pentru unele întrebări are. Un răspuns matematic fie este egal cu valoarea corectă, fie nu. Codul fie trece testele, fie nu. O demonstrație fie se verifică, fie nu.

Pentru acele domenii poți înlocui reward model-ul cu un verificator, iar tot ce urmează devine mai bun dintr-odată: fără adnotatori, fără fit Bradley–Terry, fără reward hacking de tipul măsurat în Capitolul 11 — pentru că nu poți linguși un unit test. Aceasta este reinforcement learning from verifiable rewards, iar acesta este contextul pentru care a fost construit GRPO: samplează un grup de încercări de soluție pentru aceeași problemă, verifică fiecare, și folosește scorul mediu al grupului ca baseline. Fără critic, fără adnotator, fără reward model. Doar un program care spune corect sau greșit.

Rezultatul care a reîncadrat domeniul a venit de la DeepSeek la începutul lui 2025.⁶ Au luat un base model și au aplicat reinforcement learning with verifiable rewards direct, fără nicio etapă de supervised fine-tuning înainte — etapa pe care Capitolul 11 o prezintă ca fundament al tuturor lucrurilor. Lanțuri lungi de raționament au emergat oricum. La fel și comportamente pe care nu le antrenase nimeni: modelul a început să-și reverifice propriii pași și, în pasajul cel mai citat al lucrării, să reconsidere spontan o abordare în mijlocul soluției.

Lectura onestă nu este că raționamentul este magie. Este că atunci când singurul lucru recompensat este să fii corect, iar a fi corect la o problemă grea cere să o lucrezi până la capăt, atunci lucrul până la capăt este ceea ce găsește optimizer-ul — inclusiv părțile lucrului până la capăt pe care le fac și oamenii, pentru că ele sunt cerute de problemă, nu pentru că le-a predat cineva.

Consecința practică a tuturor acestor lucruri este că un model de raționament produce token pe care i-ai cerut și token pe care nu i-ai cerut, iar tu plătești pentru ambele.

Providerii gestionează asta diferit, iar diferența contează:

• Majoritatea API-urilor numără reasoning tokens în interiorul output token count. Factura ta și limita ta max_tokens includ ambele gândirea pe care nu o vezi niciodată.
• Gemini de la Google raportează thinking tokens ca un câmp separat, în afara standard output count.

Aceasta este o incompatibilitate reală între două moduri de a număra același lucru, iar orice cod care calculează costuri sau impune un buget între provideri trebuie să o normalizeze. Capitolul 16 este locul unde asta devine bani, iar Capitolul 23 unde devine un buget pe care îl poți impune.

Cealaltă consecință este una de latență, care îi surprinde pe oameni prima dată. Timpul până la primul token vizibil al unui model de raționament include toată gândirea lui, așa că o cerere care nu transmite nimic timp de opt secunde și apoi răspunde într-una nu este o conexiune blocată — este modelul care lucrează. Orice interfață care afișează un spinner fără explicație timp de opt secunde are o problemă de design, nu una de rețea.

Un avertisment de final, pentru că acesta este cel mai comun mod în care materialul din capitolul acesta este aplicat greșit.

Tot ce apare în prima jumătate este o tehnică pentru a face un model care nu a fost antrenat să raționeze să producă totuși raționament. Modelele antrenate cu RLVR o fac deja: își emit propriul lucru, la propria lungime, înainte să răspundă. Să-i spui unui astfel de model să gândească pas cu pas este, în cel mai bun caz, redundant și, în cel mai rău caz, dăunător — poate produce un lanț scurt, modelat de prompt, în locul celui mai lung pe care modelul l-ar fi generat singur, iar unii provideri documentează exact acest lucru.

Același lucru se aplică schelelor elaborate de raționament construite în codul aplicației. Un prompt care plimbă un model printr-un arbore de decizie pe care îl navighează deja intern îți cheltuie token pentru a constrânge un comportament care a fost antrenat direct. Aceasta este prima apariție a unei teme care traversează restul cursului: tehnici care erau esențiale în 2022 au devenit superstiție până în 2025, iar singura metodă de a spune care este care pentru modelul tău, astăzi, este să le măsori pe ambele.

Capitolul 15 este locul unde acea măsurare devine o disciplină, nu o opinie.

Raționamentul are o proprietate incomodă: este singura capacitate al cărei cost scalează cu cât de grea este întrebarea. Un model care gândește timp de nouă sute de token face nouă sute de treceri forward, păstrează în memorie un cache în creștere pentru toate și ține un GPU ocupat pe toată durata.

Asta face ca economia servirii unui model de raționament să fie mult mai proastă decât servirea unui model de chat și transformă un set de detalii de implementare în diferența dintre un produs viabil și unul neviabil: cum este stocat și reutilizat cache-ul cheilor și valorilor trecute, câte cereri pot împărți o trecere forward și de câtă precizie au nevoie de fapt weights.

Capitolul 13 este ultimul în care modelul este un obiect în memoria ta, nu un serviciu în spatele unui port, și este despre cum să faci acel obiect suficient de ieftin pentru a fi servit. Încasează și o promisiune din acest capitol: speculative decoding, care produce mai mulți token la aproximativ prețul unuia singur, punând un model mic să ghicească și unul mare să verifice — un truc care are sens doar după ce ai văzut cât de mult dintr-o trecere forward se consumă așteptând memoria, nu făcând aritmetică.

Toate măsurătorile din acest capitol vin din Qwen/Qwen2.5-0.5B-Instruct pe 24 de probleme generate, enunțate în cuvinte și în doi pași, cu decodare greedy cu excepția cazurilor în care este menționat sampling, și cu zero generări trunchiate la plafoanele de token folosite. Sunt reproductibile și sunt un model mic pe probleme ușoare: citește rezultatul de self-consistency ca pe o demonstrație a mecanismului, nu ca pe un benchmark. Capitolul 18 din notițele de curs CS229 și capitolul 12 din Hugging Face LLM Course acoperă ambele acest material cu modele mai mari și benchmark-uri adecvate.