रीज़निंग मॉडल प्रॉम्प्ट से नहीं, ट्रेनिंग से बनते हैं

पिछले साल एक टीम लंच में मैंने एक राय बहुत बुरी तरह डिफेंड की थी, और तब से अब तक मुझे उस पर और भी पक्का यकीन हो गया है: अगर आपका रीज़निंग मॉडल के बारे में मानसिक मॉडल यह है कि “यह एक आम LLM है जिसे बस step by step सोचने को कहा गया है,” तो आप रीज़निंग मॉडल को असल में समझते ही नहीं — और यही गलतफहमी प्रोडक्शन में चुपचाप आपका पैसा और accuracy दोनों खा रही है। रीज़निंग मॉडल कोई प्रॉम्प्टिंग तकनीक नहीं हैं। ये एक ट्रेनिंग का नतीजा हैं। Chain-of-thought वाला व्यवहार, जो इन्हें math और code में अच्छा बनाता है, verifiable rewards वाले reinforcement learning से पैदा होता है, न कि उस चीज़ से जो आप system prompt में लिखते हैं। मैं इसे ठीक से तब समझ पाया जब Sebastian Raschka के नए 11 घंटे के build-a-reasoning-model कोर्स वाली ज़मीन पर काम किया: एक छोटा Qwen3 base model लोड किया, एक verifier बनाया, GRPO चलाया, और देखा कि reasoning traces लंबे होते गए और accuracy बढ़ती गई। एक बार अपने ट्रेनिंग लूप में यह होते देख लिया, तो फिर इसे अनदेखा नहीं कर सकते।

पहले मैं इस दावे को ठीक से डिफेंड करता हूँ, फिर जहाँ इसे पीछे हटना चाहिए वहाँ पीछे हटूँगा — क्योंकि एक जगह प्रॉम्प्टिंग सच में मायने रखती है, और उसे नज़रअंदाज़ करना एक अलग तरह का हाइप होगा।

“बस प्रॉम्प्ट कर दो” वाला मॉडल क्यों टूटता है

कहानी आम तौर पर ऐसे सुनाई जाती है: 2022 में शोधकर्ताओं ने पाया कि प्रॉम्प्ट के अंत में “Let's think step by step” जोड़ने से अंकगणित की accuracy नाटकीय रूप से बढ़ जाती है, और chain-of-thought प्रॉम्प्टिंग का जन्म हुआ। यह बात वहाँ तक सही है। पर कहानी यह नहीं बताती कि आगे क्या हुआ — labs ने उस व्यवहार को reinforcement learning के ज़रिए weights में ही उतार दिया। एक आधुनिक रीज़निंग मॉडल को आपके step-by-step मंत्र की ज़रूरत नहीं होती। वह डिफ़ॉल्ट रूप से लंबे reasoning traces बनाता है, क्योंकि उसे ऐसा करने के लिए प्रशिक्षित किया गया है, और सही जवाब पर पहुँचने वाले traces के लिए उसे इनाम मिलता है।

यह आप खुद एक दोपहर के प्रयोग से देख सकते हैं। एक base model लीजिए — Qwen3 0.6B एक सामान्य consumer GPU पर आराम से चल जाता है — और उसे MATH-500 पर chain-of-thought प्रॉम्प्टिंग के साथ और उसके बिना परखिए। आपको मामूली सा उछाल दिखेगा। अब उसी model family का RLVR-ट्रेन्ड variant लीजिए। इन दोनों हालातों के बीच का फ़र्क उछाल नहीं, एक खड़ी चट्टान है। कोई भी लिखा गया system prompt इस खाई को नहीं भर सकता। मेरे दावे का अनुभवजन्य आधार यही है: क्षमता weights में रहती है, और weights ट्रेनिंग से वैसे बने हैं, inference के समय token की चालाकी से नहीं।

यह भ्रम इसलिए बना रहता है क्योंकि बाहर से दोनों एक जैसे दिखते हैं: मॉडल जवाब देने से पहले लंबा मध्यवर्ती reasoning लिखता है। लेकिन ऊपरी समानता के नीचे एक कारण-प्रभाव का फर्क छिपा है। किसी base model से step by step सोचने को कहना वैसा है जैसे कोई मानसिक गणित करते हुए अपनी सोच बोलकर सुनाए — बोलना क्षमता के पीछे चलता है। RL ट्रेनिंग असल में क्षमता को ही बदलती है, क्योंकि मॉडल को शुरू से अंत तक जवाब की सही होने की दृष्टि से optimize किया जाता है, और कठिन सवालों पर सही जवाब पाने के लिए लंबा reasoning एक उपयोगी रणनीति बन जाता है।

Verifier ही पूरी चाल है

जब मैं ML इंजीनियर था, तो RLHF का वह हिस्सा मुझे हमेशा थोड़ा मनहूस लगा जो reward model था। आप इंसानी पसंद की नकल करने वाला एक अलग neural network ट्रेन करते हैं, फिर अपनी policy को उसके खिलाफ optimize करते हैं, और प्रोजेक्ट का बाकी हिस्सा reward hacking से लड़ने में निकल जाता है — policy कोई ऐसा विकृत output ढूँढ लेती है जो reward model की नज़र में ऊँचा स्कोर करता है पर असली इंसानों के लिए बेकार होता है। यह एक प्रतिकूल रिश्ता है जो आर्किटेक्चर में ही बसा हुआ है।

Reinforcement learning with verifiable rewards — RLVR — इस पूरी समस्या को किनारे कर देता है, और verifier को शून्य से बनाने पर इस चाल की खूबसूरती समझ आती है। Math के लिए verifier एक उबाऊ, deterministic program है: मॉडल के output से अंतिम उत्तर निकालिए, उसे normalize कीजिए (भिन्न, दशमलव और समतुल्य रूपों जैसे 1/2 और 0.5 को संभालिए), और गणितीय समानता जाँचिए। सही उत्तर को इनाम एक, गलत को शून्य। यहाँ कोई सीखा हुआ reward model नहीं है जिसे धोखा दिया जा सके। Reward संकेत ही ground truth है।

इसी वजह से रीज़निंग मॉडल सबसे पहले math और code में अच्छे हुए। दोनों क्षेत्रों में सस्ते और भरोसेमंद verifiers मौजूद हैं — math के लिए symbolic equivalence checker, code के लिए unit tests। आपको human annotators की ज़रूरत नहीं जो outputs को रैंक करें; आपको बस एक Python function चाहिए जो boolean लौटाए। जो कोई अपने domain के लिए reasoning बनाना चाहता है, उसके लिए इसका सीधा मतलब यह है: अगर आप अपने domain के लिए verifier लिख सकते हैं, तो आप शायद उसके लिए reasoner भी ट्रेन कर सकते हैं। अगर नहीं लिख सकते — यानी आपके domain में सही होना स्वाद की बात है, जैसे marketing copy — तो आप RLHF और उसकी reward-hacking की परेशानियों में फँसे रहेंगे।

किसी नए domain में reasoning की असली रुकावट compute या data नहीं है। रुकावट यह है कि क्या आप “सही” का मतलब एक program के रूप में लिख सकते हैं।

Training से पहले verifier पहले बनाने की एक बात मुझे बहुत पसंद है: वह दोहरा काम करता है। जो grader evaluation के लिए आपके base model को MATH-500 पर स्कोर करता है, वही RL के दौरान reward function बन जाता है। इसे खुद लागू करने पर आपको दिखता है कि उसमें कितना बारीक काम छिपा है — उत्तर निकालना सच में झंझट भरा है, क्योंकि मॉडल अंतिम उत्तर दर्जनों तरीकों से लिखते हैं, और कमज़ोर extractor चुपचाप आपके reward संकेत को बिगाड़ देता है। जो मॉडल लिखता है “इसलिए x = 7”, वह गलत गिना जा सकता है अगर आपका regex सिर्फ boxed उत्तर खोजता है। ढीले verifiers ढीली policies सिखाते हैं। यह ऐसा सबक है जो पेपर पढ़कर कभी नहीं सीखा जा सकता।

GRPO असल में weights के साथ क्या करता है

Training loop अपने सरलीकृत, शून्य से बने रूप में आश्चर्यजनक रूप से छोटा है। Group Relative Policy Optimization — वह algorithm जिसे DeepSeek ने लोकप्रिय बनाया — उस critic network को हटा देता है जो PPO को इतनी ज़्यादा memory खाने वाला बनाता था। value function सीखने के बजाय आप एक ही prompt पर responses का group बनाते हैं, उन सबको verifier से स्कोर करते हैं, और हर response का advantage group के औसत के सापेक्ष निकालते हैं। जो responses group माध्य से बेहतर हैं, उनके token probabilities बढ़ाए जाते हैं; जो खराब हैं, उन्हें घटाया जाता है।

def grpo_advantages(rewards: torch.Tensor) -> torch.Tensor:
# rewards: [group_size], one per sampled response to the same prompt
mean = rewards.mean()
std = rewards.std().clamp_min(1e-4)
return (rewards - mean) / std  # relative advantage per response
# Training step: maximize advantage-weighted log-probability
def grpo_loss(logprobs: torch.Tensor, advantages: torch.Tensor) -> torch.Tensor:
# logprobs: summed sequence log-prob under the current policy
return -(advantages.detach() * logprobs).mean()

असली implementations में मॉडल को reference model से बहुत दूर बहने से रोकने के लिए KL penalty और PPO से लिया गया clipping जुड़ता है, पर ऊपर का ढाँचा ईमानदारी से इस विचार का मूल है। और इसे चलते हुए देखना जादुई लगता है: आप मॉडल को reasoning की शैली के बारे में कुछ नहीं बताते। आप सिर्फ सही अंतिम उत्तरों को इनाम देते हैं। फिर भी ट्रेनिंग के दौरान response की लंबाई बढ़ती है। मॉडल traces के बीच में खुद को सुधारने लगता है — “रुको, जाँच लेता हूँ” — क्योंकि verification वाले व्यवहार से बने traces सही उत्तर पर खत्म होने की संभावना ज़्यादा रखते हैं, और सही उत्तर ही वह चीज़ है जिस पर इनाम मिलता है। Chain-of-thought की शैली optimization समस्या का एक उभरता हुआ हल है, किसी ने इसे इंजीनियर नहीं किया। इसलिए मैं कहता हूँ कि यह ट्रेन होती है, प्रॉम्प्ट नहीं: प्रॉम्प्टिंग के दौर वाला यह व्यवहार असल में इंसानों द्वारा उस चीज़ की नकल थी जिसे RL ने बाद में खुद खोज निकाला।

हाइप वाला चक्र जिस व्यावहारिक इंजीनियरिंग नोट को छोड़ देता है, वह यह है: एक ठीक-ठाक GPU वाला 0.6B मॉडल इस प्रक्रिया को असली रूप में देखने के लिए काफी है। जिस हार्डवेयर को आप कुछ डॉलर प्रति घंटे पर किराए पर ले सकते हैं, उस पर भी GRPO से MATH-500 में मापने लायक सुधार दिख जाएगा। आपको frontier model नहीं मिलेगा। यह ठीक है — अभ्यास का मकसद वह है भी नहीं।

Inference-time scaling: जहाँ compute ट्रेनिंग की जगह लेता है (आंशिक रूप से)

किसी भी RL से पहले ऐसी तकनीकों का एक परिवार है जो weights को जमे हुए रखकर भी जवाबों को बेहतर बनाता है: temperature और top-p के साथ कई उम्मीदवार बनाइए, फिर उन्हें मिलाइए। Self-consistency इसका मुख्य घोड़ा है — k जवाब बनाइए और अंतिम उत्तरों पर बहुमत से वोट लीजिए। यह बेहद अच्छा काम करता है, और यह base models पर भी काम करता है, जो मेरे शुरुआती दावे में पहली दरार है जिसे मैं मानता हूँ: inference-time compute सुधार का एक असली और स्वतंत्र आयाम है।

पर देखिए ये तकनीकें असल में क्या माँगती हैं। Majority voting तभी मदद करता है जब मॉडल के पास सही जवाब देने की गैर-तुच्छ संभावना पहले से हो — वोटिंग मौजूद संकेत को बढ़ाती है, शून्य से संकेत नहीं बनाती। Scoring-based selection (उम्मीदवारों को sequence log-probability से रैंक करना) में भी यही गुण है। और self-refinement loops, जहाँ मॉडल अपने ही उत्तर की आलोचना करके सुधारता है, base models पर निराशाजनक रूप से कमज़ोर निकलते हैं, क्योंकि ईमानदार self-critique खुद एक क्षमता है जिसे RL स्थापित करता है। हर inference-time trick ट्रेनिंग के साथ जुड़ता है; कोई उसकी जगह नहीं लेता। Frontier systems RL-ट्रेन्ड models को inference scaling के साथ इसलिए मिलाते हैं क्योंकि दोनों जुड़ते नहीं, गुणा होते हैं।

Practitioners के लिए लागत वाला पहलू मायने रखता है। k=16 के साथ self-consistency आपकी inference लागत सोलह गुना कर देता है। यह सौदा अच्छा है या नहीं, यह पूरी तरह आपके accuracy-per-dollar curve पर निर्भर है, और इसका एक ईमानदार जवाब बस यही है कि आप खुद MATH-500 accuracy को candidate count के मुकाबले प्लॉट करें। इसी तरह के compute-placement सवाल पर हमने flash-tier models और inference efficiency पर अपनी नज़र में बात की थी — बार-बार आने वाला विषय यह है कि “ज़्यादा compute खर्च करो” के कम से कम तीन अलग अर्थ हैं, और वे आपस में बदले नहीं जा सकते।

Distillation, और वह एक जगह जहाँ प्रॉम्प्टिंग बचती है

शून्य से बनी pipeline का आख़िरी चरण distillation है: किसी मज़बूत (आम तौर पर बड़े) reasoner के लंबे reasoning traces लीजिए और एक छोटे मॉडल को उन पर सीधे fine-tune कीजिए, सादी supervised learning से। कोई RL नहीं, लूप में कोई verifier नहीं। आपके व्यवहार में आने वाले कई सस्ते, छोटे reasoning models इसी तरह बने हैं। और यह मेरे दावे को कमज़ोर करने के बजाय मज़बूत करता है — reasoning का व्यवहार अब भी RL-ट्रेन्ड model द्वारा बनाए गए training data से आ रहा है, बस इनाम की जगह gradient descent से स्थानांतरित होकर। क्षमता कभी prompt के समय नहीं डाली जाती; वह हमेशा optimization से भीतर बैठाई जाती है।

तो मेरा विरोधी दावा कहाँ टूटता है? यहाँ ईमानदारी से: प्रॉम्प्टिंग हाशिये पर अब भी मायने रखती है, और वह हाशिया शून्य नहीं है। Reasoning effort controls — आज के मॉडल जो low/medium/high thinking-budget सेटिंग देते हैं — ऐसे inference-time लीवर हैं जो accuracy और latency/लागत के बीच सार्थक समझौता करते हैं। Structured output constraints, verifier-in-the-loop pipelines और constrained decoding भी prompt-और-harness स्तर की तकनीकें हैं जिनका असली मूल्य है, जैसा हमने constrained decoding पर अपने लेख में तर्क दिया था। और अगर आप एक base model तक सीमित हैं और कुछ ट्रेन नहीं कर सकते, तो chain-of-thought प्रॉम्प्टिंग अब भी evals पर अच्छे अंक दिला सकती है। “ट्रेन होता है, प्रॉम्प्ट नहीं” यह दावा इस बारे में है कि क्षमता कहाँ से आती है, इस बारे में नहीं कि inference-time चुनाव मायने नहीं रखते।

पढ़ने से बनाना बेहतर क्यों है

आम जगहों पर एक उचित आपत्ति उठी: क्या अपना reasoning model बनाने का tutorial भी एक “अपना CPU बनाओ” गाइड जैसा नहीं है — आकर्षक, पर बेकार, क्योंकि असली training runs को clusters और proprietary data चाहिए? मुझे लगता है यह इस अभ्यास के मकसद को नहीं समझता, और मैं यही बात क्लासिक “अपना shell बनाओ” tutorial के बारे में भी कहूँगा, जिसकी हमने What Building a Shell Teaches You About Unix में इसी वजह से तारीफ़ की थी। कोई shell बस bash की जगह लेने के लिए नहीं लिखता। आप इसलिए लिखते हैं ताकि fork, exec, pipes और signal handling सिर्फ रटी हुई अवधारणाएँ न रहें, बल्कि वह मशीनरी बन जाएँ जिसे आपने खुद हाथ में पकड़ा हो।

यहाँ भी यही है। जिन चीज़ों ने reasoning models के साथ मेरे काम करने का तरीका स्थायी रूप से बदला, वे पेपर से नहीं, implementation की बारीकियों से आईं:

• Verifier लिखने ने मुझे सिखाया कि reward की गुणवत्ता एक software engineering समस्या है — normalization के edge cases ट्रेनिंग को चुपचाप बिगाड़ देते हैं, और “reward ही ground truth है” तभी तक सच है जब तक आपका answer extractor सही है।
• Sequence log-probability scoring लागू करने से (उसके numerical-stability के पेच-पुर्ज़ों के साथ) post-training साहित्य के आधे loss functions का रहस्य खुल गया। वे सभी इस पर आ जाते हैं कि विभिन्न policies के तहत responses कितने संभावित हैं, इसकी तुलना।
• GRPO के दौरान बिना prompt किए response की लंबाई बढ़ते देखना मेरे आख़िरी बचे उस विश्वास को खत्म कर गया कि reasoning की शैली सतही व्यवहार है। जब सही होना ही एकमात्र लक्ष्य हो, तो optimization यही खोजता है।
• Self-consistency के लिए candidate count के मुकाबले accuracy प्लॉट करने से accuracy-per-dollar के समझौते की एक असली समझ मिली, जो कोई benchmark table कभी नहीं दे पाई।

सीखने के उद्देश्य के लिए compute की चिंता भी ज़रूरत से ज़्यादा है। शुरुआती हिस्से — base model लोड करना, KV caching के साथ streaming generation, verifier बनाना, MATH-500 चलाना — लैपटॉप या उसके आसपास के CPU पर ही हो जाते हैं। GRPO training को GPU चाहिए, पर एक ही, और घंटे के हिसाब से किराए पर लेने पर वह ज़्यादातर textbooks से सस्ता पड़ता है। घर पर जो नहीं दोहराया जा सकता वह है पैमाना, और पैमाना सच में एक अलग विषय है — यह उन DeepSeek के inference engine के मिथकों में से एक है जिन्हें हमने परखा था: किसी frontier lab का serving stack ऐसी समस्याएँ हल करता है जो tutorial के पैमाने पर होती ही नहीं, और इसका उल्टा भी सच है।

व्यावहारिक निष्कर्ष

इन सबमें से अगर आप एक चीज़ लें, तो वह है verifier-केंद्रित नज़रिया। आधुनिक reasoning stack यह है: एक base model, एक program जो तय करता है कि “सही” क्या है, एक RL algorithm जो उसके खिलाफ optimize करता है, और inference-time तकनीकें जो परिणाम को गुणा करती हैं। प्रॉम्प्टिंग इस पूरे system के सबसे बाहरी किनारे पर बैठती है, और उस क्षमता को दिशा देती है जिसे ट्रेनिंग ने बनाया। जो टीमें यह समझती हैं, वे अपनी मेहनत वहाँ लगाती हैं जहाँ वह बढ़ती है — बेहतर verifiers, बेहतर reward design, और बेहतर evaluation loops में, जैसे उन loops की हम वकालत करते आए हैं जो ज़्यादातर असली काम को न मापने वाले AI benchmarks में गायब हैं। जो टीमें ऐसा नहीं समझतीं, वे system prompts बदलती रहती हैं और सोचती हैं कि accuracy क्यों रुक गई है।

लंच-टेबल वाले मेरे दावे में एक शर्त जुड़ती है: reasoning models ट्रेन होते हैं, प्रॉम्प्ट नहीं होते — लेकिन उनके चारों ओर आप जो harness बनाते हैं, उसमें प्रॉम्प्ट भी शामिल हैं, और वही तय करता है कि उस ट्रेन्ड क्षमता का कितना हिस्सा आप सच में निकाल पाते हैं। कभी छोटा संस्करण खुद बनाकर देखिए। ग्यारह घंटे कोड करते हुए सीखना इस बात को हमेशा के लिए साफ़ करने की एक सस्ती कीमत है।