सामग्री पर जाएँ
12/30अध्याय 12 / 30

Chain of Thought, RLVR और Test-Time Compute: माप के साथ

वही 24 समस्याएँ: 1.9 token में 0 % सही, 145 में 100 %। फिर self-consistency और greedy decoding वाली accuracy वापस खरीदना।

इस पेज पर

चौबीस दो-चरणों वाली word problems. एक छोटा model — आधा अरब parameters, वही जो अध्याय 11 में था — हर समस्या से दो बार पूछा जाता है।

पहले, सीधे उत्तर माँगा गया:

TEXT
"...How many bolts are left?  Reply with only the final number, nothing else."

  0 / 24 correct        1.9 tokens per answer

फिर उत्तर माँगा गया, लेकिन पहले काम करने की अनुमति देकर:

TEXT
"...How many bolts are left?  Think step by step, then give the final
 number on its own line."

  24 / 24 correct       145.2 tokens per answer

शून्य से सौ प्रतिशत। वही model, वही weights, वही समस्याएँ, वही greedy decoding. सिर्फ़ फ़र्क यह है कि दूसरे version को किसी संख्या पर commit करने से पहले 143 और token emit करने की अनुमति थी।

यह अध्याय उसी अंतर के बारे में है: वह वास्तव में क्या है, कितनी दूर तक जाता है, इसकी लागत क्या है, और तब क्या हुआ जब field ने इसे prompt में माँगना बंद करके training में शामिल करना शुरू किया।

model सोचता नहीं है। वह ज़्यादा देर compute करता है।

सेक्शन का लिंक: model सोचता नहीं है। वह ज़्यादा देर compute करता है।

लुभावना यह कहना है कि दूसरे version ने "इसके बारे में सोचा"। इससे बचिए, क्योंकि mechanism जानने के लिए इससे सरल और ज़्यादा उपयोगी है।

एक transformer हर generate किए गए token पर computation की एक fixed मात्रा करता है। एक forward pass: वही layers, वही matrices, operations की वही संख्या, चाहे प्रश्न 2+2 क्या है हो या इस theorem को prove करो। model के भीतर "इस पर ज़्यादा मेहनत करो" के लिए कोई dial नहीं है।

इसलिए जब किसी model से तुरंत उत्तर माँगा जाता है, तो उसके पास उपलब्ध पूरा computation एक forward pass होता है। हर intermediate quantity को उसी single pass की activations में fit होना पड़ता है, और जो कुछ वह वहाँ compute नहीं कर सकता, वह compute नहीं कर सकता।

token emit करने से यह बदलता है, और यह दो अलग-अलग तरीकों से बदलता है जिन्हें अलग रखना ज़रूरी है:

  • ज़्यादा computation. हर generated token एक और पूरा forward pass है। working के सौ पैंतालीस token, सीधे जवाब देने की arithmetic के सौ पैंतालीस गुना हैं।
  • Externalised memory. token context में लिख दिए जाते हैं, इसलिए अगला pass उन्हें पढ़ सकता है। 5 × 13 = 65 input में एक fact बन जाता है, कोई ऐसी value नहीं जिसे model को activation में पकड़कर आगे ले जाना हो। model अपने ही output को scratchpad की तरह इस्तेमाल कर रहा है।

दूसरा point वही है जिसे लोग अक्सर चूक जाते हैं, और यही समझाता है कि मदद के लिए working को लिखना क्यों पड़ता है। किसी model से अगर कहा जाए कि "चुपचाप इसके बारे में सोचो और फिर जवाब दो", तो उसके पास उस thought को रखने की जगह नहीं होती।

इसमें किसी रहस्यवाद की ज़रूरत नहीं है, और यह एक ठोस prediction देता है: chain of thought उन समस्याओं पर सबसे ज़्यादा मदद करनी चाहिए जिनकी structure serial है — जहाँ step two को step one के result की ज़रूरत होती है — और उन समस्याओं पर सबसे कम जिनमें बस एक lookup है। literature में ठीक यही मिलता है, और इसी वजह से "think step by step" France की राजधानी क्या है पर कुछ नहीं करता।

यह technique 2022 में दो हिस्सों में आई। Wei et al. ने दिखाया कि prompt में worked examples शामिल करना — ऐसे demonstrations जहाँ answer से पहले reasoning आती है — arithmetic और commonsense benchmarks पर बड़े gains देता है।1 फिर Kojima et al. ने कुछ ज़्यादा अजीब दिखाया: examples की ज़रूरत नहीं है। zero-shot prompt में "Let's think step by step" जोड़ना उसी gain का बड़ा हिस्सा capture कर लेता है।2

दूसरा result बताता है कि असल में क्या हो रहा है। अगर कोई magic phrase behaviour को unlock करता है, तो behaviour model में पहले से था — pretraining worked solutions से भरी है, और phrase distribution के उस क्षेत्र की ओर pointer है। Chain of thought ने model को कुछ सिखाया नहीं। उसने model में पहले से मौजूद चीज़ को select किया।

यह framing technique के अंततः अप्रचलित होने की भी भविष्यवाणी करती है, जिस पर हम अध्याय के अंत में लौटेंगे।

Self-consistency, और एक result जिसने मुझे चौंकाया

सेक्शन का लिंक: Self-consistency, और एक result जिसने मुझे चौंकाया

अगला obvious कदम: अगर reasoning की एक chain गलत हो सकती है, तो कई sample करें और majority answer लें। यही self-consistency है।3 यह strictly बड़ा खर्च है — एक के बजाय nn full generations — और intuition यह है कि गलत answers बिखरते हैं जबकि सही answers सहमत होते हैं।

उन्हीं समस्याओं में से 16 पर मापा गया, temperature 0.8 पर sampling, nn chains पर majority vote:

nnaccuracycumulative tokenstokens per problem
181 %2,952185
281 %5,618351
3100 %8,417526
4100 %11,103694
5100 %13,933871

सोलह समस्याएँ छोटा denominator हैं, और अध्याय 4 का rule इस table पर भी उतना ही लागू होता है जितना किसी और पर। 16 में से 13 यानी 81 % है, 95 % Wilson interval [57, 93] के साथ; 16 में से 16 यानी 100 % है, [81, 100] के साथ। ये overlap करते हैं। curve का shape पढ़िए, वही finding है; उस exact rung को मत पढ़िए जहाँ यह flat होता है, क्योंकि सोलह समस्याएँ उसे locate नहीं कर सकतीं।

उस table में दो बातें हैं, और दूसरी वह नहीं है जिसकी मुझे उम्मीद थी।

curve n=3n = 3 पर flat हो जाता है। तीसरे sample तक accuracy अपने ceiling पर है और बचे हुए दो samples कुछ नहीं खरीदते, जबकि हर एक की लागत 172 token है, दोनों मिलाकर 345। literature में report की गई हर self-consistency curve का shape यही है, और यह "more samples is more better" framing से कहीं पहले आ जाता है।

और greedy decoding पहले से 100 % पर था। अध्याय की शुरुआत पर लौटकर देखिए: one chain, no sampling, 145 token, 24/24. temperature 0.8 पर sampling ने accuracy को घटाकर 81 % कर दिया, और self-consistency को वहाँ वापस चढ़ने के लिए तीन generations चाहिए थीं जहाँ एक single greedy pass पहले से था — 3.6 गुना token पर, या छह गुना अगर आप यह जाने बिना sweep को पाँच तक चलाएँ कि curve कहाँ flat होता है।

यह self-consistency के ख़िलाफ़ argument नहीं है। यह सटीक statement है कि वह करती क्या है: temperature errors inject करके diversity खरीदता है, और voting वही errors हटाती है जो उसने अभी inject किए। जिन समस्याओं पर greedy decoding fail होती है — जहाँ single most likely chain गलत जगह ले जाती है और कोई less likely chain सही होती है — वहाँ यह trade payoff करता है, और इसी वजह से technique मौजूद है। जिन समस्याओं पर greedy पहले से सफल है, वहाँ यह budget को छह गुना खर्च करके break even करने का तरीका है।

दूसरा case कोई publish नहीं करता, इसलिए अपनी task पर technique अपनाने से पहले इसे measure करना क़ीमती है। ये एक small model के लिए आसान two-step problems हैं; यही वह regime है जहाँ answer इस तरह आता है।

अब तक सब कुछ prompt time पर ऐसे model पर हो रहा है जिसे इसके लिए specifically train नहीं किया गया था। reasoning models की current generation बनाने वाला shift इसे training में ले जाना था — और वह key जिसने इसे possible बनाया, सुनने में जितनी broad लगती है उससे narrow है।

अध्याय 11 की post-training को human preferences चाहिए थीं, क्योंकि "क्या यह अच्छा answer था?" का कोई programmatic answer नहीं है। लेकिन कुछ questions के लिए होता है। mathematical answer या तो correct value के बराबर होता है या नहीं। Code या तो tests pass करता है या नहीं। Proof या तो check होती है या नहीं।

इन domains के लिए आप reward model को verifier से replace कर सकते हैं, और downstream सब कुछ एक साथ बेहतर हो जाता है: कोई annotators नहीं, कोई Bradley–Terry fitting नहीं, अध्याय 11 में मापे गए तरह का कोई reward hacking नहीं — क्योंकि आप unit test की चापलूसी नहीं कर सकते। यह reinforcement learning from verifiable rewards है, और यही वह setting है जिसके लिए GRPO बनाया गया था: same problem के लिए solution attempts का group sample करें, हर एक को check करें, और group के mean score को baseline की तरह use करें। कोई critic नहीं, कोई annotator नहीं, कोई reward model नहीं। बस एक program जो कहता है सही या गलत।

Outcome reward. सिर्फ़ final answer score करें। सस्ता — एक string comparison — और इसमें obvious hole है: गलत reasoning से सही number तक पहुँचने वाला solution बिल्कुल correct solution की तरह rewarded होता है, इसलिए policy plausible-looking nonsense सीखने के लिए free है जो संयोग से land कर जाए।

Process reward. हर step को score करें। Lightman et al.5 ने ऐसा करने वाले model को train करने के लिए 800,000 human-labelled reasoning steps का dataset बनाया, और दिखाया कि यह hard maths पर outcome supervision से substantially outperform करता है। लागत नाम में ही है: किसी ने 800,000 steps label किए।

field को reframe करने वाला result 2025 की शुरुआत में DeepSeek से आया।6 उन्होंने एक base model लिया और verifiable rewards के साथ reinforcement learning directly apply किया, पहले कोई supervised fine-tuning stage लगाए बिना — वही stage जिसे अध्याय 11 हर चीज़ की foundation की तरह प्रस्तुत करता है। reasoning की long chains फिर भी emerge हुईं। ऐसे behaviours भी जिनके लिए किसी ने train नहीं किया था: model ने अपने steps को re-check करना शुरू किया और, paper के सबसे ज़्यादा quoted passage में, mid-solution किसी approach पर spontaneously reconsider किया।

ईमानदार reading यह नहीं है कि reasoning magic है। बात यह है कि जब reward केवल right होने को मिलता है, और hard problem पर right होने के लिए उसे work through करना पड़ता है, तो optimiser वही find करता है — जिसमें work through करने के वे हिस्से भी शामिल हैं जो humans भी करते हैं, क्योंकि वे problem की requirement हैं, किसी की teaching नहीं।

इन सबका practical consequence यह है कि reasoning model वे tokens produce करता है जो आपने माँगे थे और वे tokens भी जो आपने नहीं माँगे, और आप दोनों के लिए pay करते हैं।

Providers इसे अलग-अलग handle करते हैं, और फर्क मायने रखता है:

  • Most APIs reasoning tokens को output token count के inside count करती हैं। आपके bill और आपकी max_tokens limit, दोनों में वह thinking शामिल है जिसे आप कभी देखते नहीं।
  • Google's Gemini thinking tokens को standard output count के बाहर एक separate field के रूप में report करता है।

यह एक ही चीज़ को count करने के दो तरीकों के बीच real incompatibility है, और providers के across cost compute करने या budget enforce करने वाले किसी भी code को इसे normalise करना होगा। अध्याय 16 में यह money बनता है, और अध्याय 23 में वह budget जिसे आप enforce कर सकते हैं।

दूसरा consequence latency वाला है, जो लोगों को पहली बार चौंकाता है। reasoning model के पहले visible token तक का time उसकी सारी thinking शामिल करता है, इसलिए कोई request जो आठ seconds तक कुछ stream नहीं करती और फिर एक second में answer देती है, hung connection नहीं है — model काम कर रहा है। कोई भी interface जो आठ seconds तक बिना explanation spinner दिखाता है, उसमें design problem है, networking problem नहीं।

जब "think step by step" मदद करना बंद कर देता है

सेक्शन का लिंक: जब "think step by step" मदद करना बंद कर देता है

एक closing warning, क्योंकि यही इस अध्याय की material को गलत apply करने का सबसे common तरीका है।

पहले half की हर चीज़ ऐसी technique है जो उस model से reasoning produce करवाती है जिसे reason करने के लिए train नहीं किया गया था। RLVR से trained models यह पहले से करते हैं: वे answer देने से पहले अपनी working, अपनी length पर, emit करते हैं। ऐसे model से think step by step कहना best case में redundant और worst case में harmful है — यह उस longer chain की जगह short, prompt-shaped chain produce कर सकता है जो model अपने आप generate करता, और कुछ providers exactly यही document करते हैं।

Application code में बने elaborate reasoning scaffolds पर भी यही लागू होता है। ऐसा prompt जो model को decision tree से walk कराता है जिसे वह internally पहले से navigate करता है, आपके tokens खर्च करके उस behaviour को constrain कर रहा है जिसे training में डाला गया था। यह उस theme की पहली appearance है जो course के बाकी हिस्से में चलती है: जो techniques 2022 में essential थीं, वे 2025 तक superstition बन गईं, और आज आपके model के लिए कौन सी कौन है, यह जानने का एकमात्र तरीका दोनों को measure करना है।

अध्याय 15 में वही measurement opinion के बजाय discipline बनता है।

Reasoning की एक असहज property है: यह इकलौती capability है जिसकी cost question की difficulty के साथ scale होती है। नौ सौ tokens तक सोचने वाला model नौ सौ forward passes करता है, उन सभी के लिए memory में बढ़ता हुआ cache रखता है, और duration भर GPU hold करता है।

इससे reasoning model serve करने की economics, chat model serve करने की तुलना में sharp रूप से worse हो जाती है, और implementation details का एक set viable product और unviable product के बीच फर्क बन जाता है: past keys और values का cache कैसे store और reuse होता है, कितनी requests एक forward pass share कर सकती हैं, और weights को वास्तव में कितनी precision चाहिए।

अध्याय 13 आख़िरी अध्याय है जहाँ model किसी port के पीछे service होने के बजाय आपकी memory में object है, और यह उस object को इतना cheap बनाने के बारे में है कि उसे serve किया जा सके। यह इस chapter का एक promise भी cash करता है: speculative decoding, जो एक small model से guess करवाकर और large model से check करवाकर roughly one token की कीमत पर कई tokens produce करता है — एक trick जो तभी समझ में आती है जब आप देख चुके हों कि forward pass का कितना हिस्सा arithmetic करने के बजाय memory का इंतज़ार करने में खर्च होता है।


इस अध्याय में सभी measurements Qwen/Qwen2.5-0.5B-Instruct से आए हैं, 24 generated two-step word problems पर, जहाँ sampling stated है उसे छोड़कर greedy decoding, और used token caps पर zero truncated generations के साथ। वे reproducible हैं, और वे easy problems पर small model हैं: self-consistency result को mechanism की demonstration की तरह पढ़िए, benchmark की तरह नहीं। CS229 lecture notes का अध्याय 18 और Hugging Face LLM Course का अध्याय 12, दोनों इस material को larger models और proper benchmarks के साथ cover करते हैं।

  1. Wei, J. et al. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903 (2022).

  2. Kojima, T., Gu, S. S., Reid, M., Matsuo, Y. and Iwasawa, Y. Large Language Models are Zero-Shot Reasoners. arXiv:2205.11916 (2022). "let's think step by step" result.

  3. Wang, X. et al. Self-Consistency Improves Chain of Thought Reasoning in Language Models. arXiv:2203.11171 (2022).

  4. Yao, S. et al. Tree of Thoughts: Deliberate Problem Solving with Large Language Models. arXiv:2305.10601 (2023).

  5. Lightman, H. et al. Let's Verify Step by Step. arXiv:2305.20050 (2023). PRM800K introduce करता है, 800,000-step process supervision dataset.

  6. DeepSeek-AI. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948 (2025). R1-Zero result — reinforcement learning सीधे base model पर apply किया गया, कोई supervised fine-tuning stage नहीं — section 2.2 में है।

  7. Snell, C., Lee, J., Xu, K. and Kumar, A. Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters. arXiv:2408.03314 (2024).


निर्माता

David Vicente Campos

NeuraLIA Labs के संस्थापक और MyRealFood के सह-संस्थापक

मैं लेओन विश्वविद्यालय से कंप्यूटर इंजीनियर हूँ। मैंने MyRealFood की सह-स्थापना की, जहाँ CTO के रूप में मैंने वह ऐप बनाया जिसे लाखों लोग बेहतर खान-पान के लिए इस्तेमाल कर चुके हैं, और मैंने NeuraLIA Labs की स्थापना की, जहाँ मैं AI प्रोडक्ट्स बनाता हूँ। यहाँ मैं उन बातों के बारे में लिखता हूँ जो इस सफ़र में मुझे समझनी पड़ीं, उस तरह जिस तरह काश किसी ने मुझे समझाई होतीं।

लेखक के बारे में और जानें

NeuraLIA Labs द्वारा प्रकाशित।

नए पोस्ट अपने इनबॉक्स में पाएं

AI समाचार, गाइड और प्रोडक्ट अपडेट — जब भी हम कुछ उपयोगी प्रकाशित करें, एक छोटा ईमेल।

कोर्स सूची

Abstract software decision engine with branching paths, probability nodes, and glowing gates.
jev13 मिनट पढ़ें

Jev AI मॉडल गद्य के लिए नहीं, निर्णयों के लिए बना है

TypeSafe AI का Jev ध्यान खींच रहा है क्योंकि यह सॉफ्टवेयर इंटेलिजेंस को संभावना की समस्या मानता है: सही शाखा चुनें, भरोसे का स्तर जोड़ें, और जब कोड को निर्णय चाहिए तो LLM से टेक्स्ट लिखवाने पर खर्च न करें।

Abstract agent runtime sorting documents, memory blocks and pointer nodes inside a bounded context frame.
context-engineering14 मिनट पढ़ें

लॉन्ग-होराइजन AI एजेंट्स के लिए कॉन्टेक्स्ट इंजीनियरिंग

लंबे समय तक चलने वाले एजेंट सिर्फ इसलिए असफल नहीं होते कि विंडो छोटी है। वे तब असफल होते हैं जब फ़ाइलें, टूल आउटपुट और पुराना इतिहास उस काम को ही पीछे धकेल देते हैं जिसे एजेंट को पूरा करना था।

मॉडल चुनने का काम LIA पर छोड़ने के लिए तैयार हैं?

हर AI मॉडल एक ही जगह — आज ही मुफ़्त शुरू करें।