Chain of Thought، RLVR اور Test-Time Compute کی پیمائش
وہی 24 مسائل: 1.9 tokens میں 0% درست، 145 میں 100%۔ پھر self-consistency، جو greedy decoding کی درستگی واپس خریدتی ہے۔
اس صفحے پر
چوبیس دو مرحلوں والے لفظی مسائل۔ ایک چھوٹا model — نصف ارب parameters، وہی جو باب 11 میں تھا — ہر مسئلہ دو بار پوچھا جاتا ہے۔
پہلے، صرف جواب مانگا جاتا ہے:
"...How many bolts are left? Reply with only the final number, nothing else."
0 / 24 correct 1.9 tokens per answerپھر جواب مانگا جاتا ہے، مگر پہلے کام کرنے کی اجازت کے ساتھ:
"...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۔ فرق صرف یہ تھا کہ دوسرے ورژن کو کسی عدد پر پکا ہونے سے پہلے مزید 143 tokens خارج کرنے دیے گئے۔
یہ باب اسی فرق کے بارے میں ہے: یہ اصل میں کیا ہے، کہاں تک جاتا ہے، اس کی لاگت کیا ہے، اور کیا ہوا جب field نے اسے prompt میں مانگنا چھوڑ کر اسے training میں شامل کرنا شروع کیا۔
model سوچتا نہیں۔ وہ زیادہ دیر compute کرتا ہے۔
اس حصے کا لنک: model سوچتا نہیں۔ وہ زیادہ دیر compute کرتا ہے۔دل چاہتا ہے کہ کہا جائے دوسرے ورژن نے “اس پر سوچا”۔ اس سے بچیں، کیونکہ mechanism زیادہ سادہ بھی ہے اور جاننا زیادہ مفید بھی۔
ایک transformer ہر generated token پر computation کی مقررہ مقدار کرتا ہے۔ ایک forward pass: وہی layers، وہی matrices، operations کی وہی تعداد، چاہے سوال 2+2 کیا ہے ہو یا یہ theorem ثابت کریں۔ model کے اندر “اس بار زیادہ کوشش کرو” کا کوئی dial نہیں ہوتا۔
اس لیے جب model سے فوراً جواب مانگا جاتا ہے، اس کے لیے دستیاب پوری computation ایک forward pass ہوتی ہے۔ ہر intermediate quantity کو اسی ایک pass کی activations میں fit ہونا پڑتا ہے، اور جو چیز وہ وہاں compute نہیں کر سکتا، وہ compute نہیں کر سکتا۔
tokens خارج کرنا یہ بدل دیتا ہے، اور دو الگ طریقوں سے بدلتا ہے جنہیں جدا رکھنا ضروری ہے:
- زیادہ computation۔ ہر generated token ایک اور مکمل forward pass ہے۔ کام کے ایک سو پینتالیس tokens کا مطلب ہے فوراً جواب دینے کے مقابلے میں ایک سو پینتالیس گنا arithmetic۔
- Externalised memory۔ tokens context میں لکھ دیے جاتے ہیں، اس لیے اگلا pass انہیں پڑھ سکتا ہے۔
5 × 13 = 65input میں ایک fact بن جاتا ہے، وہ value نہیں جسے model کو activation میں پکڑ کر آگے لے جانا ہو۔ model اپنی ہی output کو scratchpad کے طور پر استعمال کر رہا ہے۔
دوسرا نقطہ ہی وہ ہے جو لوگ چھوڑ دیتے ہیں، اور یہی بتاتا ہے کہ مدد کے لیے working کو لکھنا کیوں ضروری ہے۔ جس model سے کہا جائے “خاموشی سے سوچو اور پھر جواب دو” اس کے پاس thought رکھنے کی کوئی جگہ نہیں۔
اس میں کسی پراسرار چیز کی ضرورت نہیں، اور یہ ایک مضبوط پیش گوئی کرتا ہے: chain of thought ان مسائل پر سب سے زیادہ مدد کرے گا جن کی ساخت serial ہو — جہاں مرحلہ دو کو مرحلہ ایک کے نتیجے کی ضرورت ہو — اور ان مسائل پر سب سے کم جن میں صرف ایک lookup ہو۔ literature بالکل یہی دکھاتا ہے، اور اسی لیے “think step by step” کا فرانس کا دارالحکومت کیا ہے پر کوئی اثر نہیں ہوتا۔
Chain of thought، بطور prompting تکنیک
اس حصے کا لنک: Chain of thought، بطور prompting تکنیکیہ تکنیک 2022 میں دو حصوں میں آئی۔ Wei et al. نے دکھایا کہ prompt میں worked examples شامل کرنا — ایسی demonstrations جہاں جواب سے پہلے reasoning ہو — arithmetic اور commonsense benchmarks پر بڑی بہتری لاتا ہے۔1 پھر Kojima et al. نے کچھ زیادہ عجیب دکھایا: examples کی ضرورت نہیں۔ zero-shot prompt کے آخر میں “Let's think step by step” لگانے سے اسی فائدے کا بڑا حصہ مل جاتا ہے۔2
دوسرا نتیجہ بتاتا ہے کہ اصل میں کیا ہو رہا ہے۔ اگر کوئی magic phrase behaviour کھول دیتی ہے، تو behaviour پہلے ہی model میں موجود تھا — pretraining worked solutions سے بھری ہوتی ہے، اور phrase distribution کے اس region کی طرف اشارہ ہے۔ Chain of thought نے model کو کچھ نہیں سکھایا۔ اس نے وہ چیز select کی جو model کے پاس پہلے ہی تھی۔
یہ framing اس تکنیک کے آخرکار obsolete ہونے کی بھی پیش گوئی کرتی ہے، جس پر ہم باب کے آخر میں واپس آتے ہیں۔
Self-consistency، اور ایک نتیجہ جس نے مجھے حیران کیا
اس حصے کا لنک: Self-consistency، اور ایک نتیجہ جس نے مجھے حیران کیااگلا واضح قدم: اگر reasoning کی ایک chain غلط ہو سکتی ہے، تو کئی sample کریں اور majority answer لے لیں۔ یہ self-consistency ہے۔3 یہ لازماً بڑا خرچ ہے — ایک کے بجائے مکمل generations — اور intuition یہ ہے کہ غلط جواب بکھر جاتے ہیں جبکہ درست جواب متفق ہوتے ہیں۔
انہی مسائل میں سے 16 پر measured، temperature 0.8 پر sampling، chains پر majority vote:
| accuracy | cumulative tokens | tokens per problem | |
|---|---|---|---|
| 1 | 81 % | 2,952 | 185 |
| 2 | 81 % | 5,618 | 351 |
| 3 | 100 % | 8,417 | 526 |
| 4 | 100 % | 11,103 | 694 |
| 5 | 100 % | 13,933 | 871 |
سولہ مسائل ایک چھوٹا denominator ہے، اور باب 4 کا rule اس table پر بھی اتنا ہی لاگو ہوتا ہے جتنا کسی اور پر۔ 16 میں سے 13، 81 % ہے، 95 % Wilson interval [57, 93] کے ساتھ؛ 16 میں سے 16، 100 % ہے، [81, 100] کے ساتھ۔ یہ overlap کرتے ہیں۔ curve کی shape پڑھیں، یہی finding ہے؛ وہ exact rung نہ پڑھیں جہاں یہ flatten ہوتی ہے، کیونکہ سولہ مسائل اسے locate نہیں کر سکتے۔
اس table میں دو چیزیں ہیں، اور دوسری وہ نہیں تھی جس کی مجھے توقع تھی۔
curve پر flatten ہوتی ہے۔ تیسرے sample تک accuracy اپنی ceiling پر ہے اور باقی دو samples کچھ نہیں خریدتے جبکہ ہر ایک کی لاگت 172 tokens ہے، دونوں ملا کر 345۔ literature میں report ہونے والی ہر self-consistency curve کی یہی shape ہے، اور یہ “more samples is more better” والی framing کے اشارے سے کہیں پہلے آ جاتی ہے۔
اور greedy decoding پہلے ہی 100 % پر تھا۔ باب کے شروع کو دوبارہ دیکھیں: ایک chain، کوئی sampling نہیں، 145 tokens، 24/24۔ temperature 0.8 پر sampling نے accuracy کو گرا کر 81 % کر دیا، اور self-consistency کو وہاں واپس پہنچنے کے لیے تین generations چاہیے تھیں جہاں ایک single greedy pass پہلے ہی تھا — 3.6 گنا tokens پر، یا چھ گنا اگر آپ sweep کو پانچ تک چلاتے ہیں یہ جانے بغیر کہ یہ کہاں flatten ہوتا ہے۔
یہ self-consistency کے خلاف دلیل نہیں۔ یہ بالکل درست بیان ہے کہ وہ کیا کرتی ہے: temperature errors inject کر کے diversity خریدتا ہے، اور voting وہ errors ہٹاتی ہے جو اس نے ابھی inject کیے تھے۔ جن مسائل میں greedy decoding ناکام ہوتی ہے — جہاں single most likely chain غلط جگہ لے جاتی ہے اور کم likely chain درست ہوتی ہے — وہاں یہ trade فائدہ دیتا ہے، اور اسی لیے یہ تکنیک موجود ہے۔ جن مسائل میں greedy پہلے ہی کامیاب ہو، وہاں یہ بجٹ چھ گنا خرچ کر کے break even کرنے کا طریقہ ہے۔
دوسرا case کوئی publish نہیں کرتا، اسی لیے technique اپنانے سے پہلے اسے اپنی task پر measure کرنا ضروری ہے۔ یہ ایک چھوٹے model کے لیے آسان دو مرحلوں والے مسائل ہیں؛ یہی وہ regime ہے جہاں answer اس طرح نکلتا ہے۔
مانگنے سے training تک
اس حصے کا لنک: مانگنے سے training تکاب تک سب کچھ prompt time پر ایسے model کے ساتھ ہوتا ہے جسے خاص طور پر اس کے لیے train نہیں کیا گیا تھا۔ reasoning models کی موجودہ generation پیدا کرنے والی shift یہ تھی کہ اسے training میں منتقل کیا جائے — اور جس key نے یہ ممکن بنایا وہ سننے میں جتنی وسیع لگتی ہے، اس سے زیادہ narrow ہے۔
باب 11 کی post-training کو human preferences چاہیے تھیں، کیونکہ “کیا یہ اچھا جواب تھا؟” کا کوئی programmatic answer نہیں۔ مگر کچھ سوالات کے لیے ہوتا ہے۔ mathematical answer یا تو correct value کے برابر ہوتا ہے یا نہیں۔ code یا تو tests pass کرتا ہے یا نہیں۔ proof یا تو check ہوتا ہے یا نہیں۔
ان domains کے لیے آپ reward model کو verifier سے بدل سکتے ہیں، اور downstream ہر چیز ایک ساتھ بہتر ہو جاتی ہے: نہ annotators، نہ Bradley–Terry fitting، نہ اس قسم کی reward hacking جو باب 11 میں measure کی گئی — کیونکہ آپ unit test کی خوشامد نہیں کر سکتے۔ یہ reinforcement learning from verifiable rewards ہے، اور یہی وہ setting ہے جس کے لیے GRPO بنایا گیا تھا: ایک ہی problem کے لیے solution attempts کا group sample کریں، ہر ایک check کریں، اور group کے mean score کو baseline کے طور پر استعمال کریں۔ نہ critic، نہ annotator، نہ reward model۔ بس ایک program جو کہتا ہے right یا wrong۔
Outcome reward۔ صرف final answer کو score کریں۔ سستا — string comparison — اور اس میں ایک واضح سوراخ ہے: جو solution غلط reasoning کے ذریعے درست number تک پہنچے اسے بالکل correct solution کی طرح reward ملتا ہے، اس لیے policy plausible-looking nonsense سیکھنے کے لیے آزاد ہے جو اتفاقاً land کر جائے۔
Process reward۔ ہر step کو score کریں۔ Lightman et al.5 نے ایسا کرنے والا model train کرنے کے لیے 800,000 human-labelled reasoning steps کا dataset بنایا، اور دکھایا کہ یہ hard maths پر outcome supervision سے کافی بہتر ہے۔ cost نام ہی میں ہے: کسی نے 800,000 steps label کیے۔
جس result نے field کو reframe کیا وہ 2025 کے شروع میں DeepSeek سے آیا۔6 انہوں نے ایک base model لیا اور verifiable rewards کے ساتھ reinforcement learning directly apply کی، پہلے کوئی supervised fine-tuning stage نہیں — وہی stage جسے باب 11 ہر چیز کی بنیاد کے طور پر پیش کرتا ہے۔ long chains of reasoning پھر بھی emerge ہو گئیں۔ ایسے behaviours بھی جن کے لیے کسی نے train نہیں کیا تھا: model نے اپنے steps دوبارہ check کرنا شروع کیے اور paper کے سب سے زیادہ quoted passage میں، solution کے بیچ spontaneously approach reconsider کی۔
ایمان دارانہ reading یہ نہیں کہ reasoning magic ہے۔ بلکہ یہ ہے کہ جب reward صرف right ہونے پر ہو، اور hard problem پر right ہونے کے لیے اس پر کام کرنا ضروری ہو، تو optimiser وہی ڈھونڈتا ہے — اس پر کام کرنے کے وہ حصے بھی شامل ہیں جو humans بھی کرتے ہیں، کیونکہ وہ problem کا تقاضا ہیں، نہ کہ کسی نے سکھائے ہیں۔
Reasoning tokens بل پر ایک line ہیں
اس حصے کا لنک: Reasoning tokens بل پر ایک line ہیںاس سب کا practical نتیجہ یہ ہے کہ reasoning model وہ tokens بھی produce کرتا ہے جو آپ نے مانگے، اور وہ بھی جو آپ نے نہیں مانگے، اور آپ دونوں کے لیے pay کرتے ہیں۔
Providers اسے مختلف طریقوں سے handle کرتے ہیں، اور یہ فرق اہم ہے:
- اکثر APIs reasoning tokens کو output token count کے اندر count کرتی ہیں۔ آپ کا bill اور آپ کی
max_tokenslimit دونوں وہ thinking شامل کرتے ہیں جو آپ کبھی نہیں دیکھتے۔ - Google کا Gemini thinking tokens کو standard output count سے باہر، separate field کے طور پر report کرتا ہے۔
یہ ایک ہی چیز کو count کرنے کے دو طریقوں کے درمیان حقیقی incompatibility ہے، اور providers کے across cost compute کرنے یا budget enforce کرنے والے ہر code کو اسے normalise کرنا پڑتا ہے۔ باب 16 وہ جگہ ہے جہاں یہ money بنتا ہے، اور باب 23 وہ جگہ جہاں یہ enforceable budget بنتا ہے۔
دوسرا نتیجہ latency کا ہے جو لوگوں کو پہلی بار حیران کرتا ہے۔ reasoning model کا time to first visible token اپنی ساری thinking شامل کرتا ہے، اس لیے ایسی request جو آٹھ seconds تک کچھ stream نہ کرے اور پھر ایک second میں answer دے، hung connection نہیں — model کام کر رہا ہے۔ کوئی بھی interface جو آٹھ seconds تک explanation کے بغیر spinner دکھاتا ہے، networking کا نہیں design کا مسئلہ رکھتا ہے۔
جب “think step by step” مدد کرنا چھوڑ دیتا ہے
اس حصے کا لنک: جب “think step by step” مدد کرنا چھوڑ دیتا ہےآخر میں ایک warning، کیونکہ اس باب کے material کو غلط apply کرنے کا سب سے عام طریقہ یہی ہے۔
پہلے نصف میں ہر چیز ایسی technique ہے جو ایسے model سے reasoning produce کرواتی ہے جسے reasoning کے لیے train نہیں کیا گیا۔ RLVR سے trained models یہ پہلے ہی کرتے ہیں: وہ جواب سے پہلے اپنی working، اپنی length پر، خود emit کرتے ہیں۔ ایسے model کو think step by step کہنا بہترین صورت میں redundant اور بدترین صورت میں harmful ہے — یہ اس longer chain کی جگہ ایک short، prompt-shaped chain produce کر سکتا ہے جو model خود generate کرتا، اور کچھ providers بالکل یہی document کرتے ہیں۔
application code میں بنائے گئے elaborate reasoning scaffolds پر بھی یہی لاگو ہوتا ہے۔ ایسا prompt جو model کو decision tree سے گزارے جسے وہ internally پہلے ہی navigate کرتا ہے، آپ کے tokens خرچ کر کے ایک trained-in behaviour کو constrain کر رہا ہے۔ یہ اس theme کی پہلی appearance ہے جو course کے باقی حصے میں چلتی ہے: جو techniques 2022 میں essential تھیں، 2025 تک superstition بن گئیں، اور آج آپ کے model کے لیے کون سی کون ہے یہ جاننے کا واحد طریقہ دونوں کو measure کرنا ہے۔
باب 15 وہ جگہ ہے جہاں یہ measurement opinion کے بجائے discipline بنتی ہے۔
آگے یہ کہاں جاتا ہے
اس حصے کا لنک: آگے یہ کہاں جاتا ہےreasoning کی ایک uncomfortable property ہے: یہ وہ capability ہے جس کی cost سوال کی difficulty کے ساتھ scale ہوتی ہے۔ جو model نو سو tokens تک سوچتا ہے وہ نو سو forward passes کرتا ہے، ان سب کے لیے memory میں growing cache رکھتا ہے، اور duration کے لیے GPU hold کرتا ہے۔
یہ reasoning model serve کرنے کی economics کو chat model serve کرنے کے مقابلے میں بہت خراب بنا دیتا ہے، اور implementation details کے ایک set کو viable product اور unviable product کے فرق میں بدل دیتا ہے: past keys اور values کا cache کیسے store اور reuse ہوتا ہے، کتنی requests forward pass share کر سکتی ہیں، اور weights کو actually کتنی precision چاہیے۔
باب 13 آخری باب ہے جہاں model آپ کی memory میں ایک object ہے، port کے پیچھے service نہیں، اور یہ اس object کو serve کرنے کے لیے کافی cheap بنانے کے بارے میں ہے۔ یہ اس باب کا ایک promise بھی cash کرتا ہے: speculative decoding، جو small model سے guess اور large model سے check کروا کر تقریباً ایک token کی قیمت میں کئی tokens produce کرتا ہے — ایک trick جو تبھی سمجھ آتی ہے جب آپ دیکھ چکے ہوں کہ forward pass کا کتنا حصہ arithmetic کرنے کے بجائے memory کا انتظار کرنے میں خرچ ہوتا ہے۔
Sources and method
اس حصے کا لنک: Sources and methodاس باب کی تمام measurements Qwen/Qwen2.5-0.5B-Instruct سے آئیں، 24 generated two-step word problems پر، sampling جہاں stated ہے اس کے علاوہ greedy decoding کے ساتھ، اور استعمال شدہ token caps پر zero truncated generations کے ساتھ۔ یہ reproducible ہیں، اور یہ easy problems پر small model ہے: self-consistency result کو mechanism کی demonstration کے طور پر پڑھیں، benchmark کے طور پر نہیں۔ CS229 lecture notes کا Chapter 18 اور Hugging Face LLM Course کا chapter 12 دونوں اس material کو larger models اور proper benchmarks کے ساتھ cover کرتے ہیں۔
حوالہ جات
اس حصے کا لنک: حوالہ جات-
Wei, J. et al. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. arXiv:2201.11903 (2022). ↩
-
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۔ ↩
-
Wang, X. et al. Self-Consistency Improves Chain of Thought Reasoning in Language Models. arXiv:2203.11171 (2022). ↩
-
Yao, S. et al. Tree of Thoughts: Deliberate Problem Solving with Large Language Models. arXiv:2305.10601 (2023). ↩
-
Lightman, H. et al. Let's Verify Step by Step. arXiv:2305.20050 (2023). PRM800K متعارف کراتا ہے، 800,000-step process supervision dataset۔ ↩
-
DeepSeek-AI. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948 (2025). R1-Zero result — reinforcement learning کو base model پر directly apply کیا گیا، بغیر supervised fine-tuning stage کے — section 2.2 میں ہے۔ ↩
-
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). ↩