लार्ज लैंग्वेज मॉडल्स (Large language models) तीन परिचित आयामों के साथ विकसित हुए हैं। हम उन्हें अधिक टेक्स्ट खिलाकर प्री-ट्रेनिंग (pre-training) को स्केल करते हैं। हम निर्देश-अनुपालन (instruction-following) को बेहतर बनाने के लिए पोस्ट-ट्रेनिंग (post-training) के साथ उन्हें रिफाइन करते हैं। हम उत्तरों की गति बढ़ाने के लिए टेस्ट-टाइम कंप्यूट (test-time compute) का उपयोग करते हैं। इनमें से प्रत्येक मॉडल को बेहतर, तेज़ और अधिक सुसंगत गद्य (prose) उत्पन्न करने के लिए प्रेरित करता है। इनमें से कोई भी सीधे तौर पर एक कठिन समस्या का समाधान नहीं करता है: यह जानना कि क्या वह गद्य वास्तव में सही है।

वह अंतर खतरनाक होता जा रहा है। एक मॉडल सटीक इंडेंटेशन और तार्किक संरचना के साथ एक पायथन (Python) स्क्रिप्ट दे सकता है, जो चलते ही त्रुटि (error) दे देती है। यह शांत अधिकार के साथ किसी चिकित्सा लक्षण की व्याख्या कर सकता है और निदान (diagnosis) को उल्टा कर सकता है। चैटबॉट्स के लिए, ये शर्मनाक बग (bugs) हैं। मानवीय देखरेख के बिना काम करने वाले स्वायत्त एजेंटों (autonomous agents) के लिए, ये वास्तविक परिणामों वाली विफलताएं हैं। जनरेशन (generation) और सत्यता (truth) एक ही कौशल नहीं हैं, और इस अंतर को पहचानना उन प्रणालियों के निर्माण की ओर पहला कदम है जिन पर हम भरोसा कर सकते हैं।

जनरेशन ट्रैप (The Generation Trap)

तीन मानक स्केलिंग पथ प्रवाह (fluency) और कार्य पूरा करने के लिए अनुकूलित होते हैं, न कि ज्ञान संबंधी सटीकता (epistemic accuracy) के लिए। प्री-ट्रेनिंग खरबों टोकन में व्यापक सांख्यिकीय पैटर्न बनाती है। पोस्ट-ट्रेनिंग मॉडल को मानवीय प्राथमिकताओं के साथ संरेखित करती है, जो अक्सर कठोर सटीकता के बजाय विनम्रता और आत्मविश्वास को पुरस्कृत करती है। टेस्ट-टाइम कंप्यूट प्रति अनुरोध मॉडल को अधिक 'थिंकिंग टोकन' (thinking tokens) देता है, जिससे फॉर्मेटिंग और चरण-दर-चरण संरचना में सुधार होता है, लेकिन फिर भी अंतिम आउटपुट को एक जांचे गए उत्तर के बजाय एक स्वगत भाषण (monologue) के रूप में ही मानता है।

इसका परिणाम एक 'फ्लुएंसी ट्रैप' (fluency trap) है। कोड साफ दिखता है। व्याख्याएं अधिकारपूर्ण लगती हैं। तथ्य सही लगते हैं। लेकिन सतही चमक अंतर्निहित त्रुटियों को छिपा देती है। एक डेवलपर जो बिना जांचे जनरेट किए गए कोड को प्रोडक्शन पाइपलाइन में पेस्ट करता है, वह डाउनटाइम का जोखिम उठाता है। एक चिकित्सक जो AI सहायक का उपयोग कर रहा है, उसे गंभीर कानूनी जिम्मेदारी का सामना करना पड़ सकता है यदि मॉडल दो समान दवा अंतःक्रियाओं (drug interactions) को मिला देता है। हमने मॉडलों को प्रदर्शन करने के लिए प्रशिक्षित किया है, स्वयं का ऑडिट करने के लिए नहीं।

स्केलिंग एक्सिस के रूप में सत्यापन (Verification as a Scaling Axis)

LLM-as-a-Verifier नामक एक फ्रेमवर्क समस्या को पूरी तरह से नए तरीके से पेश करता है। सत्यापन को बाद के विचार या एक अलग मानवीय समीक्षा चरण के रूप में मानने के बजाय, यह आत्म-मूल्यांकन (self-evaluation) को प्री-ट्रेनिंग, पोस्ट-ट्रेनिंग और इन्फरेंस एक्सेलेरेशन (inference acceleration) के साथ चौथे स्केलिंग एक्सिस के रूप में मानता है।

विचार यह है कि मॉडल की मौजूदा तर्क क्षमता (reasoning capacity) का उपयोग उसके अपने आउटपुट का निर्णय लेने के लिए किया जाए। एक संभावित उत्तर उत्पन्न करने के बाद, वही मॉडल पीछे हटता है और उसका मूल्यांकन करता है। यह एक क्लोज्ड लूप बनाता है: जनरेट करें, स्कोर करें, संशोधित करें, दोहराएं। मॉडल को नए वेट्स (weights) या डेटासेट के साथ फिर से प्रशिक्षित नहीं किया जा रहा है। यह केवल अपनी मौजूदा बुद्धिमत्ता को एक अलग प्रॉम्प्ट टेम्पलेट पर लागू करता है, जो एक लेखक के बजाय एक आलोचक का होता है।

यह बदलाव महत्वपूर्ण है क्योंकि यह क्षमता (capability) को विश्वसनीयता (reliability) से अलग करता है। एक छोटा मॉडल जो अच्छी तरह से सत्यापन करता है, वह एक बड़े मॉडल से बेहतर प्रदर्शन कर सकता है जो ऐसा नहीं करता है। आप केवल पैरामीटर काउंट को नहीं, बल्कि निर्णय लेने की क्षमता (judgment) को स्केल कर रहे हैं, और यह बदल देता है कि सिस्टम सुरक्षित रूप से क्या कर सकता है।

संभाव्य स्कोरिंग की शक्ति (The Power of Probabilistic Scoring)

अधिकांश सत्यापन प्रयास विफल हो जाते हैं क्योंकि वे एक बाइनरी निर्णय (binary verdict) की मांग करते हैं। क्या यह उत्तर सही था? हाँ या नहीं। वह कच्चा संकेत जानकारी को बर्बाद कर देता है। एक प्रतिक्रिया ज्यादातर सही हो सकती है लेकिन उसमें एक घातक दोष हो सकता है, या ज्यादातर गलत हो सकती है लेकिन उसमें एक उपयोगी अंतर्दृष्टि हो सकती है। एक बाइनरी स्कोर उन सभी बारीकियों को एक सिंगल बिट में समेट देता है।

LLM-as-a-Verifier इसे संभाव्य स्कोरिंग (probabilistic scoring) से बदल देता है। थम्स-अप या थम्स-डाउन के बजाय, मॉडल 0.92 जैसा एक निरंतर नंबर लौटाता है। वह दशमलव अर्थ रखता है। यह आपको बताता है कि मॉडल लगभग आश्वस्त है कि उत्तर सही है, या 0.34 पर उसे कुछ गड़बड़ लग रही है। सिस्टम चलाने वाले इंसान थ्रेशोल्ड (thresholds) सेट कर सकते हैं। 0.60 से नीचे कुछ भी स्वचालित पुनरुत्पादन (automatic regeneration) को ट्रिगर कर सकता है। 0.60 और 0.85 के बीच का बैंड मानवीय समीक्षा के लिए फ्लैग कर सकता है। 0.90 से ऊपर, सिस्टम स्वायत्त रूप से कार्य करता है।

निरंतर स्कोर आत्मविश्वास पर अंकगणित (arithmetic) को भी सक्षम बनाते हैं। आप कई जांचों का औसत निकाल सकते हैं, उन्हें प्रॉम्प्ट भिन्नता के आधार पर वेट दे सकते हैं, या सबसे अच्छे को चुनने के लिए विभिन्न संभावित उत्तरों के स्कोर की तुलना कर सकते हैं। बाइनरी निर्णय इस तरह के सूक्ष्म निर्णय लेने (fine-grained decision-making) का समर्थन नहीं करते हैं।

तीन व्यावहारिक लाभ (Three Practical Advantages)

यह फ्रेमवर्क तीन विशिष्ट गुणों से अपनी शक्ति प्राप्त करता है।

सूक्ष्मता। 0.82 का स्कोर कुछ ऐसा संप्रेषित करता है जो "सही" नहीं कर पाता। यह शेष संदेह के साथ लगभग पूर्ण निश्चितता का संकेत देता है। सॉफ्टवेयर इंजीनियरिंग में, इसका अर्थ यह हो सकता है कि कोड कंपाइल हो जाता है और मुख्य केस को संभाल लेता है, लेकिन संभवतः किसी 'एज कंडीशन' (edge condition) को छोड़ देता है। मेडिकल रीजनिंग में, यह एक संभावित निदान का संकेत दे सकता है जिसके लिए अभी भी पुष्टिकरण परीक्षण की आवश्यकता है। सूक्ष्म स्कोर डाउनस्ट्रीम सिस्टम को सभी सफलताओं को समान मानने के बजाय अपनी प्रतिक्रिया को कैलिब्रेट करने की अनुमति देते हैं।

पुनरावृत्ति। चूंकि जनरेशन की तुलना में वेरिफिकेशन सस्ता है, इसलिए आप प्रॉम्प्ट में मामूली बदलाव या टेम्परेचर सेटिंग्स के साथ इसे कई बार चला सकते हैं। यदि तीन स्वतंत्र जांच 0.91, 0.89 और 0.93 परिणाम देती हैं, तो आपके पास एक सर्वसम्मति है। यदि वे व्यापक रूप से भिन्न होते हैं, जैसे कि 0.91, 0.42 और 0.87, तो आप जानते हैं कि मॉडल अनिश्चित है और उत्तर में सुधार की आवश्यकता है। बाइनरी जजों के बीच बहुमत मतदान एक मोटा तरीका है। निरंतर स्कोर का औसत निकालना अस्पष्टता को सामने लाता है।

विघटन। जटिल कार्य शायद ही कभी एक साथ हर जगह विफल होते हैं। रोबोटिक्स कार्य को धारणा (perception), योजना (planning) और मोटर निष्पादन (motor execution) में विभाजित किया जा सकता है। सॉफ्टवेयर इंजीनियरिंग कार्य को एल्गोरिदम डिज़ाइन, कार्यान्वयन और टेस्टिंग कवरेज में अलग किया जा सकता है। संभाव्य स्कोरिंग सत्यापनकर्ता को प्रत्येक उप-घटक का व्यक्तिगत रूप से मूल्यांकन करने की अनुमति देती है। आप न केवल यह सीखते हैं कि उत्तर कमजोर है, बल्कि यह भी कि वह कहाँ कमजोर है। वह नैदानिक सटीकता सुधार को तेज़ और अधिक लक्षित बनाती है।

कठिन क्षेत्रों में परिणाम

फ्रेमवर्क की उपयोगिता दिखाई देती है