मला हे पाहायचे होते की एकच प्रश्न ५१ वेळा विचारल्याने उत्तर अधिक विश्वसनीय होईल का. मी एक स्थानिक (local) LLM घेतला, त्याला प्रोडक्शन कोडचा एक भाग दिला आणि त्याचे पुनरावलोकन (review) करण्यास सांगितले. मग मी ते पुन्हा पुन्हा केले. एकूण ५१ वेळा, आणि 'मॅजॉरिटी वोटिंग'चा (majority voting) वापर करून 'सर्वोत्तम' प्रतिसाद निवडण्याचा प्रयत्न केला. कल्पना साधी होती: जर मॉडेल एका वेळी चुकत असेल, तर ५१ वेळा निर्माण झालेल्या उत्तरांच्या समूहातील 'सामूहिक बुद्धिमत्ता' (wisdom of the crowd) गोंधळ (noise) दूर करून अचूक विश्लेषण समोर आणू शकेल. पण तसे झाले नाही. प्रयोगातून असे दिसून आले की मॅजॉरिटी वोटिंग अचूकता निवडत नाही. ते मॉडेल ज्या गोष्टीवर सर्वात जास्त ठाम आहे, तीच गोष्ट निवडते.
हा फरक महत्त्वाचा आहे कारण LLM पाइपलाईन्समध्ये मॅजॉरिटी वोटिंग ही एक लोकप्रिय पद्धत (hack) बनली आहे. ही पद्धत सरळ आहे. तुम्ही एकाच प्रॉम्प्टवर मॉडेल अनेक वेळा चालवता, आउटपुट्स गोळा करता आणि जो उत्तर सर्वात जास्त वेळा येतो तो ठेवता. मेडिकल इमेजिंग किंवा स्पॅम डिटेक्शन सारख्या क्षेत्रांमध्ये, 'एन्सेम्बल मेथड्स' (ensemble methods) काम करतात कारण वेगवेगळी मॉडेल्स किंवा डेटाचे वेगवेगळे दृष्टिकोन स्वतंत्र चुका निर्माण करतात ज्या प्रत्यक्षात एकमेकांना खोडून काढतात. लार्ज लँग्वेज मॉडेल्स हे स्वतंत्र मतदार नाहीत. ते एकच सिस्टम आहे ज्याचा ट्रेनिंग इतिहास, वेट्सचा (weights) एक संच आणि पूर्वग्रहांचे (biases) एकच जग आहे. जेव्हा तुम्ही एकाच मॉडेलला ५१ वेळा तोच प्रश्न विचारता, तेव्हा तुम्ही एखादी समिती बोलावलेली नसते. तुम्ही एकाच उत्तरदात्याचे (respondent) थोड्या वेगळ्या मनस्थितीत सर्वेक्षण करत असता.
The Persistence Problem
मुख्य समस्या ही आहे की LLM च्या चुका क्वचितच यादृच्छिक (random) असतात. त्या ट्रेनिंग डेटा आणि आर्किटेक्चरमध्ये अंतर्भूत असलेले पॅटर्न असतात. एखादे मॉडेल एका वेळी विशिष्ट Python decorator चुकीचा वाचत असेल, तर ते पुढच्या वेळीही तोच चूक करण्याची शक्यता असते. एखादे मॉडेल व्हेरिएबलचे नाव पासवर्डसारखे दिसत असल्यामुळे सुरक्षेतील त्रुटी असल्याचे भासवत (hallucinate) असेल, तर ते ४७ व्या वेळीही पुन्हा तेच भासवेल. तुम्ही ज्या गोंधळाला (noise) सरासरी काढण्याचा प्रयत्न करत आहात, तो सहसा शब्दावली किंवा फॉरमॅटिंगमधील वरवरचा बदल असतो. मूळ तर्क (reasoning) अनेकदा तसाच राहतो.
एक ठोस उदाहरण घेऊया. समजा एक फंक्शन आहे जे रेग्युलर एक्स्प्रेशन (regular expression) वापरून लॉग फाइल्स पार्स करते. तो regex कडक आणि सुरक्षित आहे. पण r'...' या स्ट्रिंगमध्ये असे कॅरेक्टर्स आहेत जे वेगळ्या संदर्भात इंजेक्शन (injection) प्रवृत्त करू शकतात. LLM ला याचे पुनरावलोकन करण्यास सांगा. जर मॉडेलने लॉग पार्सर्समधील regex इंजेक्शनबद्दल चेतावणी देणारे हजारो Stack Overflow पोस्ट्स पाहिले असतील, तर ते या सुरक्षित कोडला जोखमीचे म्हणून चिन्हांकित करू शकते. एकदा चालवले तर तुम्हाला 'फॉल्स पॉझिटिव्ह' (false positive) मिळेल. ५१ वेळा चालवले तर ५१ वेळा फॉल्स पॉझिटिव्ह मिळण्याची किंवा किमान मोठा बहुमत मिळण्याची दाट शक्यता आहे. आता मॅजॉरिटी वोटिंगमुळे ते 'हॅलुसिनेशन' (hallucination) अधिक घट्ट होते. मॉडेल ठाम आहे, म्हणून 'एकमत' (consensus) देखील ठाम असते.
असे घडते कारण 'टेम्परेचर' (temperature) आणि 'सॅम्पलिंग' (sampling) युक्त्या मॉडेलला काय माहित आहे हे बदलत नाहीत. त्या फक्त मॉडेलच्या बोलण्याची पद्धत बदलतात. उच्च टेम्परेचरमुळे स्पष्टीकरण अधिक बोलके किंवा संक्षिप्त होऊ शकते. ते समानार्थी शब्द बदलू शकते. पण यामुळे मॉडेलला अचानक हे शिकवले जात नाही की तो regex प्रत्यक्षात निरुपद्रवी आहे. तुम्ही ज्या बदलांवर मतदान करत आहात ते केवळ बाह्य (cosmetic) आहेत. चूक ही संरचनात्मक (structural) आहे.
What 51 Runs Reveal
जेव्हा मी ते ५१ आउटपुट्स माझ्या टेबलावर पसरवले, तेव्हा पॅटर्न स्पष्ट होता. मॉडेलने कोडचे ५१ वेगवेगळे अर्थ शोधले नाहीत. त्याने फक्त एकाच अर्थाची थोड्या वेगळ्या आवाजात पुनरावृत्ती केली. काही रनमध्ये मॉडेलने वेगळे उत्तर दिले, जसे की 'एज-केस' (edge-case) फिक्स सुचवणे किंवा असंबंधित स्टाईलच्या समस्यांकडे लक्ष देणे. पण मुख्य गट, म्हणजेच स्पष्ट बहुमत, वारंवार त्याच चुकीच्या मुख्य दाव्याकडे परतत होते. तो दावा बरोबर नव्हता, तो फक्त परिचित होता.
मॅजॉरिटी वोटिंगचे गणित 'स्वतंत्र बर्नोली ट्रायल्स' (independent Bernoulli trials) गृहीत धरते. बहुमताने वैयक्तिक उत्तरापेक्षा चांगले काम करण्यासाठी तुम्हाला असंबंधित चुकांची गरज असते. माझ्या प्रयोगात, चुका एकमेकांशी खोलवर संबंधित होत्या. त्यांचे मूळ कारण एकच होते: मॉडेलच्या ट्रेनिंग डिस्ट्रिब्युशनमध्ये काही विशिष्ट कोडिंग ट्रोप्सना (coding tropes) जास्त महत्त्व दिले गेले आहे. त्यामुळे, मॅजॉरिटी वोटिंगने त्रुटी कमी केल्या नाहीत. उलट, त्याने बहुमताचा पूर्वग्रह (majority bias) वाढवला. त्याने एका सदोष विश्लेषणाला चुकीची खात्री दिली.
कोड रिव्ह्यूमध्ये हे विशेषतः धोकादायक आहे कारण डेव्हलपर्स एकमत किंवा जवळजवळ एकमत असलेल्या AI आउटपुटला अधिकृत मानतात. एखादे साधे साशंकतेने दिलेले सुचवणे नाकारणे सोपे असते. पण ५१ रनमध्ये स्थिर राहणारी शिफारस ही 'ग्राउंड ट्रुथ' (ground truth) असल्यासारखी वाटते. पण तसे नाहीये. ते फक्त एक 'ग्राउंड लूप' (ground loop) आहे.
Where Voting Actually Works
याचा अर्थ असा नाही की तुम्ही मॉडेल एकदाच चालवले पाहिजे. जेव्हा काम साधे असते आणि चुका खरोखरच यादृच्छिक (random) असतात, अशा मर्यादित परिस्थितीत 'मॅजॉरिटी वोटिंग' (बहुमत मतदान) उपयुक्त ठरू शकते. मॉडेलला दोन सिंटॅक्टिक फॉरमॅटमधून एक निवडायला सांगणे, व्हेरिएबल नेमिंग कन्व्हेन्शन निवडणे किंवा लॉग लाईनमधून डेट स्ट्रिंग काढणे—अशी कमी जोखमीची कामे कधीकधी वारंवार सॅम्पलिंग केल्यामुळे फायदेशीर ठरतात. त्यातील तफावत ही केवळ गोंधळ (noise) असते आणि जलद मतदान केल्याने ती दूर होऊ शकते.
समस्या तेव्हा सुरू होते जेव्हा कामासाठी हेतूचा (intent) विचार करून तर्क (reasoning) करण्याची आवश्यकता असते. हा auth check इथे असणे योग्य आहे का? ही async call सुरक्षित आहे का? हा cache key collision खरोखरच एक्सप्लॉइट करण्यायोग्य आहे का? या प्रश्नांसाठी केवळ पॅटर्न मॅचिंग पुरेसे नाही, तर संदर्भाची (context) समज असणे आवश्यक आहे. मॉडेलचा पॅटर्न मॅचर त्याच्या पूर्वग्रहामध्ये (bias) डिटरमिनिस्टिक असतो. ते तुमच्या कोडबेससाठी सर्वात अचूक उत्तर देण्याऐवजी, त्याच्या ट्रेनिंग डेटातील सर्वात सामान्य उत्तर देण्याचा प्रयत्न करेल.
तुमचा कम्प्युट (Compute) वापरण्याचे अधिक स्मार्ट मार्ग
लोकल मॉडेलचे ५१ वेळा रन करणे म्हणजे तुमचा वेळ आणि वीज खर्च करणे होय. तो कम्प्युट गुंतवण्यासाठी अधिक चांगले मार्ग आहेत. जर तुम्हाला विश्वासार्हता सुधारायची असेल, तर संख्येपेक्षा वैविध्य (diversity) अधिक महत्त्वाचे आहे. दोन वेगळी मॉडेल्स चालवा...