लार्ज लँग्वेज मॉडेल्सनी (Large language models) तीन परिचित परिमाणांच्या आधारे प्रगती केली आहे. आम्ही त्यांना अधिक मजकूर देऊन प्री-ट्रेनिंग (pre-training) वाढवतो. सूचनांचे पालन अधिक अचूक करण्यासाठी आम्ही पोस्ट-ट्रेनिंगद्वारे (post-training) त्यांना अधिक परिष्कृत करतो. उत्तरे जलद करण्यासाठी आम्ही टेस्ट-टाइम कम्प्युट (test-time compute) वापरतो. यापैकी प्रत्येक गोष्ट मॉडेलला अधिक चांगली, जलद आणि सुसंगत मजकूर तयार करण्यास प्रवृत्त करते. परंतु यापैकी कोणतीही गोष्ट एका कठीण समस्येवर थेट उपाय शोधत नाही: तो मजकूर खरोखर बरोबर आहे की नाही हे ओळखणे.
ही दरी आता धोकादायक ठरत आहे. एखादे मॉडेल अचूक इंडेंटेशन (indentation) आणि तार्किक रचनेसह पायथन स्क्रिप्ट (Python script) तयार करू शकते, जी चालवताच त्रुटी (error) दर्शवते. ते एखाद्या वैद्यकीय लक्षणाचे अत्यंत आत्मविश्वासाने स्पष्टीकरण देऊ शकते, परंतु निदान पूर्णपणे चुकीचे असू शकते. चॅटबॉट्ससाठी, या लाजिरवाण्या त्रुटी (bugs) आहेत. मानवी देखरेखीशिवाय काम करणाऱ्या स्वायत्त एजंट्ससाठी (autonomous agents), या वास्तविक परिणाम घडवून आणणारे अपयश आहेत. मजकूर तयार करणे (Generation) आणि सत्यता (Truth) ही दोन भिन्न कौशल्ये आहेत, आणि हा फरक ओळखणे ही आपण विश्वास ठेवू शकू अशी प्रणाली विकसित करण्याच्या दिशेने पहिले पाऊल आहे.
जनरेशन ट्रॅप (The Generation Trap)
तीन मानक स्केलिंग मार्ग प्रवाहीपणा (fluency) आणि कार्य पूर्ण करण्यावर लक्ष केंद्रित करतात, ज्ञानशास्त्रीय अचूकतेवर (epistemic accuracy) नाही. प्री-ट्रेनिंग ट्रिलियन्स टोकन्समध्ये व्यापक सांख्यिकीय नमुने (statistical patterns) तयार करते. पोस्ट-ट्रेनिंग मॉडेलला मानवी आवडीनुसार जुळवून घेते, जे अनेकदा कठोर अचूकतेपेक्षा नम्रता आणि आत्मविश्वासाला अधिक महत्त्व देते. टेस्ट-टाइम कम्प्युट मॉडेलला प्रत्येक विनंतीसाठी अधिक 'थिंकिंग टोकन्स' (thinking tokens) देते, ज्यामुळे फॉरमॅटिंग आणि टप्प्याटप्प्याने रचना सुधारते, परंतु तरीही अंतिम आउटपुटला तपासलेल्या उत्तराऐवजी केवळ एक स्वगत (monologue) मानले जाते.
याचा परिणाम म्हणजे 'फ्लुएंसी ट्रॅप' (fluency trap). कोड स्वच्छ दिसतो. स्पष्टीकरणे अधिकृत वाटतात. तथ्ये योग्य वाटतात. परंतु वरवरची चकाकी खालच्या त्रुटी लपवून ठेवते. एखादा डेव्हलपर जो तयार केलेला कोड तपासणीशिवाय थेट प्रोडक्शन पाईपलाईनमध्ये (production pipeline) वापरतो, त्याला सिस्टम डाउनटाइमचा धोका असतो. जर मॉडेलने दोन सारख्या औषधांच्या परस्परसंवादांमध्ये (drug interactions) गोंधळ घातला, तर एआय असिस्टंट वापरणाऱ्या डॉक्टरांना गंभीर कायदेशीर जबाबदारीला सामोरे जावे लागू शकते. आम्ही मॉडेल्सना काम करण्यासाठी प्रशिक्षित केले आहे, स्वतःचे ऑडिट करण्यासाठी नाही.
स्केलिंग अॅक्सिस म्हणून व्हेरिफिकेशन (Verification as a Scaling Axis)
'LLM-as-a-Verifier' नावाचा एक फ्रेमवर्क या समस्येला पूर्णपणे नवीन दृष्टिकोनातून पाहतो. व्हेरिफिकेशनला (verification) केवळ नंतरची गोष्ट किंवा मानवी पुनरावलोकनाची स्वतंत्र पायरी मानण्याऐवजी, हा फ्रेमवर्क स्व-मूल्यांकनाला (self-evaluation) प्री-ट्रेनिंग, पोस्ट-ट्रेनिंग आणि इन्फरन्स अॅक्सिलरेशन (inference acceleration) सोबतच चौथ्या स्केलिंग अॅक्सिस (scaling axis) म्हणून मानतो.
मॉडेलची स्वतःची उत्तरे तपासण्यासाठी त्याच्याकडे असलेल्या तर्कशक्तीचा (reasoning capacity) वापर करणे, ही यामागची कल्पना आहे. संभाव्य उत्तर तयार केल्यानंतर, तेच मॉडेल मागे वळून त्याचे मूल्यमापन करते. यामुळे एक 'क्लोज्ड लूप' (closed loop) तयार होतो: तयार करा, स्कोअर द्या, सुधारणा करा आणि पुन्हा करा. मॉडेलला नवीन वेट्स (weights) किंवा डेटासेटसह पुन्हा प्रशिक्षित केले जात नाही. ते फक्त त्याच्याकडे असलेल्या बुद्धिमत्तेचा वापर एका वेगळ्या प्रॉम्प्ट टेम्पलेटसाठी करते, जे लेखकाऐवजी एका समीक्षकाचे (critic) असते.
हा बदल महत्त्वाचा आहे कारण तो क्षमता (capability) आणि विश्वासार्हता (reliability) यांना एकमेकांपासून वेगळे करतो. चांगले व्हेरिफिकेशन करणारे लहान मॉडेल, चांगले व्हेरिफिकेशन न करणाऱ्या मोठ्या मॉडेलपेक्षा अधिक प्रभावी ठरू शकते. तुम्ही केवळ पॅरामीटरची संख्या (parameter count) नाही, तर निर्णयक्षमता (judgment) वाढवत आहात, आणि यामुळे सिस्टम सुरक्षितपणे काय करू शकते हे बदलते.
प्रोबॅबिलिस्टिक स्कोअरिंगची शक्ती (The Power of Probabilistic Scoring)
बहुतेक व्हेरिफिकेशन प्रयत्न अपयशी ठरतात कारण ते 'बायनरी' (binary) निर्णयाची मागणी करतात. हे उत्तर बरोबर होते का? हो किंवा नाही. हा कच्चा संकेत माहितीचा अपव्यय करतो. एखादा प्रतिसाद बहुतांश बरोबर असू शकतो परंतु त्यात एक गंभीर त्रुटी असू शकते, किंवा तो बहुतांश चुकीचा असूनही त्यात एक उपयुक्त माहिती असू शकते. बायनरी स्कोअर या सर्व बारकाव्यांना एका सिंगल बिटमध्ये (single bit) मर्यादित करतो.
LLM-as-a-Verifier याला 'प्रोबॅबिलिस्टिक स्कोअरिंग'ने (probabilistic scoring) बदलतो. 'थंब्स-अप' किंवा 'थंब्स-डाऊन' ऐवजी, मॉडेल 0.92 सारखा एक सलग अंक (continuous number) देते. त्या दशांश अंकात अर्थ असतो. तो तुम्हाला सांगतो की मॉडेलला उत्तर बरोबर असल्याची खात्री आहे, किंवा 0.34 वर त्याला काहीतरी चुकीचे वाटत आहे. सिस्टम चालवणारे मनुष्यमानव थ्रेशोल्ड (thresholds) सेट करू शकतात. 0.60 च्या खाली काहीही असल्यास स्वयंचलित पुनरुत्पादन (automatic regeneration) सुरू होऊ शकते. 0.60 आणि 0.85 च्या दरम्यानची श्रेणी मानवी पुनरावलोकनासाठी (human review) सूचित करू शकते. 0.90 च्या वर, सिस्टम स्वायत्तपणे (autonomously) कार्य करते.
सलग स्कोअरमुळे आत्मविश्वासावर आधारित गणिती प्रक्रिया करणे शक्य होते. तुम्ही अनेक तपासण्यांची सरासरी काढू शकता, प्रॉम्प्टमधील फरकानुसार त्यांना वेटेज देऊ शकता किंवा सर्वोत्तम उत्तर निवडण्यासाठी विविध संभाव्य उत्तरांच्या स्कोअरची तुलना करू शकता. बायनरी निर्णय अशा प्रकारच्या सूक्ष्म निर्णयक्षमतेला (fine-grained decision-making) समर्थन देत नाहीत.
तीन व्यावहारिक फायदे (Three Practical Advantages)
हा फ्रेमवर्क तीन विशिष्ट गुणधर्मांमुळे सामर्थ्य प्राप्त करतो.
सूक्ष्मता (Granularity). ०.८२ चा स्कोअर अशी माहिती देतो जी "बरोबर" (correct) हा शब्द देऊ शकत नाही. याचा अर्थ असा की, थोड्या प्रमाणात शंका असूनही ती गोष्ट जवळजवळ निश्चित आहे. सॉफ्टवेअर इंजिनिअरिंगमध्ये, याचा अर्थ असा असू शकतो की कोड कंपाईल होतो आणि मुख्य केस हाताळतो, परंतु कदाचित एखादी 'एज कंडिशन' (edge condition) सुटली असू शकते. वैद्यकीय तर्कात, हे अशा संभाव्य निदानाचे संकेत देऊ शकते ज्यासाठी अजूनही पुष्टीकरणात्मक चाचणीची (confirmatory test) आवश्यकता आहे. सूक्ष्म स्कोअरमुळे (Granular scores) डाउनस्ट्रीम सिस्टम्स सर्व यशांना समान न मानता त्यांच्या प्रतिसादाचे अचूक कॅलिब्रेशन करू शकतात.
पुनरावृत्ती (Repetition). जनरेशनच्या तुलनेत व्हेरिफिकेशन स्वस्त असल्याने, तुम्ही प्रॉम्प्टमधील थोडे बदल किंवा टेम्परेचर सेटिंग्स वापरून ते अनेक वेळा चालवू शकता. जर तीन स्वतंत्र तपासण्यांनी ०.९१, ०.८९ आणि ०.९३ असे निकाल दिले, तर तुमच्याकडे एक एकमत (consensus) आहे. जर ते खूप विखुरलेले असतील, उदा. ०.९१, ०.४२ आणि ०.८७, तर तुम्हाला समजते की मॉडेल अनिश्चित आहे आणि उत्तरावर अधिक काम करण्याची गरज आहे. बायनरी जजेसमधील (binary judges) बहुमताने मतदान करणे हे अपुरे आहे. सततच्या स्कोअरची सरासरी काढल्यामुळे संदिग्धता (ambiguity) समोर येते.
विघटन (Decomposition). जटिल कार्ये सहसा एकाच वेळी सर्वत्र निकामी होत नाहीत. रोबोटिक्समधील एखादे कार्य पर्सेप्शन (perception), प्लॅनिंग (planning) आणि मोटर एक्झिक्यूशन (motor execution) मध्ये विभागले जाऊ शकते. सॉफ्टवेअर इंजिनिअरिंगमधील एखादे कार्य अल्गोरिदम डिझाइन, अंमलबजावणी (implementation) आणि टेस्टिंग कव्हरेजमध्ये विभागले जाऊ शकते. संभाव्यता आधारित स्कोअरिंगमुळे (Probabilistic scoring) व्हेरिफायरला प्रत्येक उप-घटकाचे (sub-component) स्वतंत्रपणे मूल्यांकन करता येते. तुम्हाला केवळ उत्तर कमकुवत आहे हेच समजत नाही, तर ते नेमके कुठे कमकुवत आहे हे देखील समजते. ही निदानात्मक अचूकता (diagnostic precision) दुरुस्ती अधिक जलद आणि लक्ष्यित बनवते.
कठीण क्षेत्रांमधील निकाल (Results in Difficult Domains)
या फ्रेमवर्कची उपयुक्तता दिसून येते