ஒரே கேள்வியை 51 முறை கேட்பதன் மூலம் பதில் அதிக நம்பகத்தன்மை கொண்டதாக இருக்குமா என்று நான் பார்க்க விரும்பினேன். நான் ஒரு local LLM-ஐ எடுத்து, அதில் ஒரு production code பகுதியை உள்ளீடு செய்து, அதை ஆய்வு செய்யக் கேட்டேன். பிறகு அதை மீண்டும் மீண்டும் செய்தேன். மொத்தம் ஐம்பத்தொன்று முறை செய்து, majority voting முறையைப் பயன்படுத்தி சிறந்த பதிலைத் தேர்ந்தெடுத்தேன். இதன் நோக்கம் எளிமையானது: ஒரு முறை இயங்கும்போது மாடல் தடுமாறினால், 51 முறை கிடைக்கும் பதில்களின் கூட்டுக் கருத்து (wisdom of the crowd) அந்தத் தவறுகளைத் தணித்து சரியான ஆய்வை வெளிப்படுத்தும் என்று நினைத்தேன். ஆனால் அப்படி நடக்கவில்லை. majority voting என்பது சரியான பதிலைத் தேர்ந்தெடுப்பதில்லை என்பதை இந்தச் சோதனை காட்டியது. மாறாக, மாடல் எதில் மிகவும் பிடிவாதமாக இருக்கிறதோ, அதையே அது தேர்ந்தெடுத்துக் காட்டுகிறது.
இந்த வேறுபாடு முக்கியமானது, ஏனெனில் LLM pipelines-களில் majority voting ஒரு பிரபலமான தந்திரமாக (hack) மாறிவிட்டது. இதன் முறை நேரடியானது. ஒரே prompt-ஐ வைத்து மாடலை பலமுறை இயக்கி, வரும் பதில்களைச் சேகரித்து, அடிக்கடி வரும் பதிலை மட்டும் எடுத்துக்கொள்வது. மருத்துவப் படமாக்கம் (medical imaging) அல்லது ஸ்பேம் கண்டறிதல் (spam detection) போன்ற துறைகளில், ensemble முறைகள் சிறப்பாகச் செயல்படுகின்றன. ஏனெனில் அங்கு வெவ்வேறு மாடல்கள் அல்லது தரவுகளின் வெவ்வேறு பார்வைகள், ஒன்றையொன்று ரத்து செய்யக்கூடிய தனித்தனித் தவறுகளை உருவாக்குகின்றன. ஆனால் Large language models தனித்தனி வாக்காளர்கள் அல்ல. அவை ஒரே பயிற்சி வரலாறு, ஒரே எடைத் தொகுப்பு (weights) மற்றும் ஒரே மாதிரியான சார்புகளைக் (biases) கொண்ட ஒரு அமைப்பு. நீங்கள் ஒரே மாடலிடம் ஒரே கேள்வியை ஐம்பத்தொன்று முறை கேட்கும்போது, நீங்கள் ஒரு குழுவைக் கூட்டவில்லை; மாறாக, ஒரே நபரிடம் சற்று மாறுபட்ட மனநிலைகளில் கருத்துக்கணிப்பு நடத்துகிறீர்கள்.
பிடிவாதமான சிக்கல்
முக்கியப் பிரச்சனை என்னவென்றால், LLM தவறுகள் அரிதாகவே தற்செயலாக (random) நடக்கின்றன. அவை பயிற்சித் தரவு மற்றும் கட்டமைப்பிலேயே (architecture) ஊறிப்போயுள்ள வடிவங்கள் (patterns). ஒரு முறை ஒரு குறிப்பிட்ட Python decorator-ஐத் தவறாகப் புரிந்துகொள்ளும் மாடல், அடுத்த முறையும் அதைத் தவறாகப் புரிந்துகொள்ளவே அதிக வாய்ப்புள்ளது. ஒரு மாறியின் பெயர் (variable name) கடவுச்சொல் போலத் தெரிவதால், ஒரு பாதுகாப்பு ஓட்டையை (security vulnerability) மாடல் கற்பனை செய்து (hallucinate) காட்டினால், நாற்பத்தேழாவது முறையிலும் அது அதையே கற்பனை செய்து காட்டக்கூடும். நீங்கள் சராசரி செய்ய முயற்சிக்கும் 'noise' என்பது பொதுவாக வார்த்தைகள் அல்லது வடிவமைப்பில் உள்ள மேலோட்டமான மாற்றங்களே தவிர, அதன் அடிப்படையிலான தர்க்கம் (reasoning) மாறாமல் அப்படியே இருக்கும்.
ஒரு உதாரணத்தைப் பார்ப்போம். ஒரு regular expression-ஐப் பயன்படுத்தி log கோப்புகளைப் பகுப்பாய்வு செய்யும் (parse) ஒரு function-ஐக் கற்பனை செய்து கொள்ளுங்கள். அந்த regex மிகவும் பாதுகாப்பானது. ஆனால் அந்த r'...' என்ற string-இல் உள்ள எழுத்துக்கள், வேறு சூழலில் இருந்தால் injection தாக்குதலுக்கு வழிவகுக்கலாம். இதை ஆய்வு செய்ய ஒரு LLM-இடம் கேளுங்கள். log parsers-களில் regex injection குறித்து எச்சரிக்கும் ஆயிரக்கணக்கான Stack Overflow பதிவுகளை அந்த மாடல் பார்த்திருந்தால், இந்த பாதுகாப்பான குறியீட்டையே அது ஒரு ஆபத்தாகக் குறிகாட்டலாம். ஒருமுறை இயக்கிப் பார்த்தால், அது ஒரு தவறான எச்சரிக்கையை (false positive) வழங்கும். அதை 51 முறை இயக்கிப் பார்த்தால், 51 முறையும் தவறான எச்சரிக்கையே கிடைக்க அதிக வாய்ப்புள்ளது, அல்லது குறைந்தபட்சம் ஒரு வலுவான பெரும்பான்மைத் தவறான முடிவையே காட்டும். இப்போது majority vote அந்தத் தவறான கற்பனையை (hallucination) ஆழமாகப் பதிய வைக்கிறது. மாடல் பிடிவாதமாக இருப்பதால், அதன் "ஒருமித்த கருத்து"வும் (consensus) பிடிவாதமாகவே இருக்கிறது.
இது temperature மற்றும் sampling போன்ற நுட்பங்கள் மாடல் எதைச் சொல்கிறது என்பதை மாற்றாது; அது எப்படிச் சொல்கிறது என்பதை மட்டுமே மாற்றும் என்பதால் நடக்கிறது. அதிக temperature ஒரு விளக்கத்தை மிக நீளமாகவோ அல்லது சுருக்கமாகவோ மாற்றலாம். அது ஒத்த சொற்களை (synonyms) மாற்றலாம். ஆனால் அந்த regex உண்மையில் பாதுகாப்பானது என்பதை அது மாடலுக்குக் கற்பிக்காது. நீங்கள் எதற்கு வாக்களிக்கிறீர்களோ அந்த மாற்றங்கள் வெறும் வெளித்தோற்றத் (cosmetic) தன்மையுடையவை; ஆனால் அந்தத் தவறு கட்டமைப்பானது (structural).
51 முறையிலான ஓட்டங்கள் எதைக் காட்டுகின்றன
அந்த 51 வெளியீடுகளையும் என் மேசையில் பரப்பிக் கிடத்தியபோது, அதன் வடிவம் தெளிவாகத் தெரிந்தது. மாடல் அந்த code-க்கான 51 வெவ்வேறு விளக்கங்களை ஆராயவில்லை. மாறாக, ஒரே விளக்கத்தையே சற்று மாறுபட்ட குரல்களில் திரும்பத் திரும்பச் சொல்லிக் கொண்டிருந்தது. சில முறை மட்டும் வழக்கத்திற்கு மாறாக, edge-case சரிசெய்தல்களைப் பரிந்துரைக்கலாம் அல்லது தொடர்பில்லாத style சிக்கல்களைக் கவனிக்கலாம். ஆனால் பெரும்பான்மையான பதில்கள் அனைத்தும் ஒரே தவறான மையக் கருத்தையே மீண்டும் மீண்டும் சொல்லிக்கொண்டிருந்தன. அந்தத் தவறு சரியானது அல்ல; அது வெறும் பரிச்சயமானது மட்டுமே.
majority voting-ன் கணிதவியல் முறை, 'independent Bernoulli trials' என்பதை அடிப்படையாகக் கொண்டது. தனிப்பட்ட முடிவுகளை விட பெரும்பான்மை முடிவு சிறப்பாக இருக்க வேண்டுமானால், பிழைகள் ஒன்றோடு ஒன்று தொடர்பில்லாததாக இருக்க வேண்டும். ஆனால் எனது சோதனையில், பிழைகள் ஆழமாகத் தொடர்புடையவை. அவை ஒரே மூல காரணத்தைப் பகிர்ந்து கொண்டன: மாடலின் பயிற்சித் தரவு (training distribution) சில குறிப்பிட்ட coding முறைகளை (tropes) அளவுக்கு அதிகமாக முன்னிலைப்படுத்துகிறது. எனவே, majority vote பிழையைக் குறைக்கவில்லை; மாறாக பெரும்பான்மை சார்பை (majority bias) அதிகப்படுத்தியது. இது ஒரு தவறான ஆய்விற்குத் தவறான நம்பிக்கையை அளித்தது.
இது code review-வில் மிகவும் ஆபத்தானது, ஏனெனில் டெவலப்பர்கள் AI வழங்கும் ஒருமித்த அல்லது கிட்டத்தட்ட ஒருமித்த முடிவுகளை அதிகாரப்பூர்வமானதாகக் கருதுகிறார்கள். ஒரு தயக்கமான ஆலோசனையை எளிதில் நிராகரிக்கலாம். ஆனால் 51 முறை இயக்கியும் மாறாமல் வரும் ஒரு பரிந்துரை, அதுதான் உண்மையான உண்மை (ground truth) என்று தோன்றும். ஆனால் அது உண்மையல்ல; அது ஒரு ground loop.
வாக்குப்பதிவு உண்மையில் எங்குச் செயல்படுகிறது
None of this means you should never run a model more than once. Majority voting can help in narrow situations where the task is shallow and the errors are truly random. Asking a model to pick between two syntactic formats, to choose a variable naming convention, or to extract a date string from a log line—these low-stakes tasks sometimes benefit from repeated sampling. The variation is genuine noise, and a quick vote cleans it up.
The trouble starts when the task requires reasoning about intent. Does this auth check belong here? Is this async call safe? Is this cache key collision actually exploitable? These questions demand an understanding of context, not just pattern matching. A model's pattern matcher is deterministic in its bias. It will reach for the most common answer from its training data, not the most accurate answer for your codebase.
Smarter Ways to Spend Your Compute
Fifty-one runs of a local model cost real time and electricity. There are better ways to invest that compute. If you want to improve reliability, diversity beats volume. Run two different models with