Chain of Thought, RLVR og Test-Time Compute målt

Fristelsen er at sige, at den anden version "tænkte over det". Modstå den, for mekanismen er både enklere og mere nyttig at kende.

En transformer udfører en fast mængde beregning pr. genereret token. Ét forward pass: de samme lag, de samme matricer, det samme antal operationer, uanset om spørgsmålet er hvad er 2+2 eller bevis denne sætning. Der er ingen knap inde i modellen til "prøv hårdere på den her".

Så når en model bliver bedt om et svar med det samme, er hele den beregning, den har til rådighed, ét forward pass. Hver mellemliggende størrelse skal passe ind i aktiveringerne i det ene pass, og alt, den ikke kan beregne dér, kan den ikke beregne.

At udsende tokens ændrer det, og det ændrer det på to forskellige måder, som er værd at holde adskilt:

• Mere beregning. Hver genereret token er endnu et fuldt forward pass. Hundrede og femogfyrre tokens med udregning er hundrede og femogfyrre gange aritmetikken ved at svare med det samme.
• Eksternaliseret hukommelse. Tokens skrives ind i context, så næste pass kan læse dem. 5 × 13 = 65 bliver et faktum i inputtet, ikke en værdi modellen skal holde i en aktivering og bære videre. Modellen bruger sit eget output som kladdepapir.

Det andet punkt er det, folk overser, og det forklarer, hvorfor udregningen skal skrives ned for at hjælpe. En model, der bliver bedt om at "tænke over det i stilhed og derefter svare", har ingen steder at lægge tanken.

Intet af dette kræver noget mystisk, og det giver en klar forudsigelse: chain of thought bør hjælpe mest på problemer med seriel struktur — hvor trin to har brug for resultatet af trin ét — og mindst på problemer, der er et enkelt opslag. Det er præcis, hvad litteraturen finder, og det er derfor, "tænk trin for trin" ikke gør noget for hvad er Frankrigs hovedstad.

Teknikken kom i 2022 i to dele. Wei et al. viste, at det at inkludere gennemarbejdede eksempler i prompt — demonstrationer hvor svaret indledes af ræsonnement — gav store gevinster på benchmarks for aritmetik og sund fornuft.¹ Kojima et al. viste derefter noget mere mærkeligt: du behøver ikke eksemplerne. At tilføje "Let's think step by step" til et zero-shot prompt indfanger meget af den samme gevinst.²

Det andet resultat er det, der fortæller dig, hvad der foregår. Hvis en magisk frase låser adfærden op, var adfærden allerede i modellen — pretraining er fuld af gennemarbejdede løsninger, og frasen er en pointer til det område af distributionen. Chain of thought lærte ikke modellen noget. Det valgte noget, modellen allerede havde.

Den ramme forudsiger også teknikkens senere forældelse, som vi vender tilbage til sidst i kapitlet.

Det oplagte næste skridt: Hvis én ræsonnementskæde kan være forkert, så sample flere og tag flertallets svar. Det er self-consistency.³ Det er et strengt større forbrug — $n$ fulde genereringer i stedet for én — og intuitionen er, at forkerte svar spreder sig, mens rigtige svar er enige.

Målt på 16 af de samme opgaver, sampling ved temperature 0,8, flertalsafstemning over $n$ kæder:

Seksten opgaver er en lille nævner, og reglen fra kapitel 4 gælder for denne tabel lige så meget som for alle andre. 13 ud af 16 er 81 % med et 95 % Wilson-interval på [57, 93]; 16 ud af 16 er 100 % med [81, 100]. De overlapper. Læs kurvens form, som er fundet; læs ikke det præcise trin, hvor den flader ud, for det kan seksten opgaver ikke lokalisere.

To ting i den tabel, og den anden var ikke, hvad jeg forventede.

Kurven flader ud ved $n = 3$. Ved den tredje sample er nøjagtigheden ved sit loft, og de resterende to samples køber ingenting, mens de koster 172 tokens hver, 345 tilsammen. Det er formen på hver self-consistency-kurve, der rapporteres i litteraturen, og det er meget tidligere, end "flere samples er mere bedre"-rammen antyder.

Og greedy decoding var allerede på 100 %. Kig tilbage på begyndelsen af kapitlet: én kæde, ingen sampling, 145 tokens, 24/24. Sampling ved temperature 0,8 sænkede nøjagtigheden til 81 %, og self-consistency krævede tre genereringer for at klatre tilbage til dér, hvor ét enkelt greedy pass allerede var — ved 3,6 gange så mange tokens, eller seks gange hvis du kører sweepet til fem uden at vide, hvor det flader ud.

Det er ikke et argument imod self-consistency. Det er en præcis beskrivelse af, hvad det gør: temperature køber diversitet ved at injicere fejl, og afstemning fjerner de fejl, den lige har injiceret. På problemer hvor greedy decoding fejler — hvor den ene mest sandsynlige kæde fører et forkert sted hen, og en mindre sandsynlig er rigtig — betaler den handel sig, og det er derfor, teknikken findes. På problemer hvor greedy allerede lykkes, er det en måde at bruge seks gange budgettet på for at gå i nul.

Ingen publicerer det andet tilfælde, og derfor er det værd at måle på din egen opgave, før du tager teknikken i brug. Det her er nemme totrinsopgaver for en lille model; det er det regime, hvor svaret kommer ud på denne måde.

Alt indtil nu sker ved prompt-tid på en model, der aldrig blev specifikt trænet til det. Skiftet, der skabte den nuværende generation af reasoning-modeller, var at flytte det ind i træningen — og nøglen, der gjorde det muligt, er snævrere, end den lyder.

Kapitel 11's post-training krævede menneskelige præferencer, fordi "var dette et godt svar?" ikke har et programmatisk svar. Men for nogle spørgsmål har det. Et matematisk svar er enten lig med den korrekte værdi, eller også er det ikke. Kode består enten testene, eller også gør den ikke. Et bevis checker enten, eller også gør det ikke.

For de domæner kan du erstatte reward-modellen med en verifier, og alt downstream bliver bedre på én gang: ingen annotatorer, ingen Bradley–Terry-tilpasning, ingen reward hacking af den slags, der blev målt i kapitel 11 — for du kan ikke smigre en unit test. Dette er reinforcement learning from verifiable rewards, og det er den setting, GRPO blev bygget til: sample en gruppe løsningsforsøg til det samme problem, check hver enkelt, og brug gruppens gennemsnitlige score som baseline. Ingen critic, ingen annotator, ingen reward-model. Bare et program, der siger rigtigt eller forkert.

Resultatet, der omformede feltet, kom fra DeepSeek i begyndelsen af 2025.⁶ De tog en base model og anvendte reinforcement learning with verifiable rewards direkte, uden først at have en supervised fine-tuning-fase — den fase, kapitel 11 præsenterer som fundamentet for alt. Lange ræsonnementskæder opstod alligevel. Det samme gjorde adfærd, ingen havde trænet til: modellen begyndte at genchecke sine egne trin og, i artiklens mest citerede passage, spontant genoverveje en tilgang midt i løsningen.

Den ærlige læsning er ikke, at reasoning er magi. Det er, at når det eneste, der belønnes, er at have ret, og det at have ret på et svært problem kræver at arbejde sig igennem det, så er det at arbejde sig igennem det, optimizeren finder — inklusive de dele af arbejdet, som mennesker også gør, fordi de er, hvad problemet kræver, snarere end hvad nogen lærte den.

Den praktiske konsekvens af alt dette er, at en reasoning-model producerer tokens, du bad om, og tokens, du ikke bad om, og du betaler for begge.

Udbydere håndterer det forskelligt, og forskellen betyder noget:

• De fleste API'er tæller reasoning tokens inden i output-token-antallet. Din regning og din max_tokens-grænse inkluderer begge den tænkning, du aldrig ser.
• Googles Gemini rapporterer thinking tokens som et separat felt, uden for det almindelige output-antal.

Det er en reel inkompatibilitet mellem to måder at tælle det samme på, og enhver kode, der beregner omkostning eller håndhæver et budget på tværs af udbydere, må normalisere den. Kapitel 16 er dér, hvor det bliver til penge, og kapitel 23 hvor det bliver et budget, du kan håndhæve.

Den anden konsekvens er en latency-konsekvens, der overrasker folk første gang. En reasoning-models tid til første synlige token inkluderer al dens tænkning, så en request, der streamer ingenting i otte sekunder og derefter svarer på ét, er ikke en forbindelse, der hænger — det er modellen, der arbejder. Enhver grænseflade, der viser en spinner uden forklaring i otte sekunder, har et designproblem, ikke et netværksproblem.

En afsluttende advarsel, fordi det er den mest almindelige måde, materialet i dette kapitel anvendes forkert på.

Alt i første halvdel er en teknik til at få en model, der ikke blev trænet til at reason, til alligevel at producere reasoning. Modeller trænet med RLVR gør det allerede: De udsender deres egen udregning, i deres egen længde, før de svarer. At bede en sådan model om at tænke trin for trin er i bedste fald redundant og i værste fald skadeligt — det kan producere en kort, prompt-formet kæde i stedet for den længere, modellen ville have genereret af sig selv, og nogle udbydere dokumenterer præcis dette.

Det samme gælder udførlige reasoning-stilladser bygget i applikationskode. Et prompt, der fører en model gennem et beslutningstræ, den allerede navigerer internt, bruger dine tokens på at begrænse en adfærd, der er trænet ind. Dette er den første forekomst af et tema, der løber gennem resten af kurset: teknikker, der var essentielle i 2022, var blevet overtro i 2025, og den eneste måde at afgøre, hvad der er hvad for din model i dag, er at måle begge.

Kapitel 15 er dér, hvor den måling bliver en disciplin snarere end en holdning.

Reasoning har en ubehagelig egenskab: Det er den ene capability, hvis omkostning skalerer med, hvor svært spørgsmålet er. En model, der tænker i ni hundrede tokens, udfører ni hundrede forward passes, holder en voksende cache i hukommelsen for dem alle og optager en GPU i hele perioden.

Det gør økonomien i at serve en reasoning-model markant dårligere end at serve en chatmodel, og det forvandler en række implementeringsdetaljer til forskellen mellem et levedygtigt produkt og et ulevedygtigt: hvordan cachen af tidligere keys og values lagres og genbruges, hvor mange requests der kan dele et forward pass, og hvor meget precision vægtene faktisk behøver.

Kapitel 13 er det sidste, hvor modellen er et objekt i din hukommelse snarere end en service bag en port, og det handler om at gøre det objekt billigt nok at serve. Det indløser også et løfte fra dette kapitel: speculative decoding, som producerer flere tokens til omtrent prisen for én ved at lade en lille model gætte og en stor checke — et trick, der først giver mening, når du har set, hvor meget af et forward pass der bruges på at vente på hukommelse snarere end på at lave aritmetik.

Alle målinger i dette kapitel kommer fra Qwen/Qwen2.5-0.5B-Instruct på 24 genererede totrins-tekstopgaver, greedy decoding undtagen hvor sampling er angivet, med nul trunkerede genereringer ved de anvendte token caps. De er reproducerbare, og de er en lille model på nemme problemer: Læs self-consistency-resultatet som en demonstration af mekanismen, ikke som et benchmark. Kapitel 18 i CS229-forelæsningsnoterne og kapitel 12 i Hugging Face LLM Course dækker begge dette materiale med større modeller og egentlige benchmarks.