હું જોવા માંગતો હતો કે શું એક જ પ્રશ્ન 51 વખત પૂછવાથી જવાબ વધુ વિશ્વસનીય બનશે. મેં એક લોકલ LLM લીધું, તેને પ્રોડક્શન કોડનો એક ભાગ આપ્યો અને રિવ્યુ કરવા કહ્યું. પછી મેં તે ફરીથી કર્યું. અને ફરીથી. કુલ બાવન વખત, "શ્રેષ્ઠ" પ્રતિસાદ પસંદ કરવા માટે મેજોરિટી વોટિંગ (majority voting) નો ઉપયોગ કર્યો. વિચાર સરળ હતો: જો મોડેલ એક વાર ભૂલ કરે, તો કદાચ 51 વખતના પરિણામોના સમૂહ જ્ઞાનથી તે ભૂલ (noise) દૂર થઈ જાય અને સાચું વિશ્લેષણ સામે આવે. પણ એવું થયું નહીં. પ્રયોગે દર્શાવ્યું કે મેજોરિટી વોટિંગ સાચા જવાબની પસંદગી નથી કરતું. તે એ પસંદ કરે છે જેના વિશે મોડેલ સૌથી વધુ જિદ્દી છે.
આ તફાવત મહત્વનો છે કારણ કે LLM પાઇપલાઇન્સમાં મેજોરિટી વોટિંગ એક લોકપ્રિય હેક (hack) બની ગયું છે. આ પદ્ધતિ સીધી છે. તમે એક જ પ્રોમ્પ્ટ પર મોડેલને ઘણી વખત ચલાવો છો, આઉટપુટ એકત્રિત કરો છો, અને જે જવાબ સૌથી વધુ વખત આવે તેને રાખો છો. મેડિકલ ઇમેજિંગ અથવા સ્પામ ડિટેક્શન જેવા ક્ષેત્રોમાં, એન્સેમ્બલ પદ્ધતિઓ (ensemble methods) કામ કરે છે કારણ કે વિવિધ મોડેલો, અથવા ડેટાના વિવિધ દ્રષ્ટિકોણ, સ્વતંત્ર ભૂલો પેદા કરે છે જે ખરેખર એકબીજાને રદ કરી દે છે. લાર્જ લેંગ્વેજ મોડેલ્સ સ્વતંત્ર મતદારો નથી. તેઓ એક જ ટ્રેનિંગ હિસ્ટ્રી, એક જ વેટ્સ (weights) અને પૂર્વગ્રહોના એક જ વિશ્વ ધરાવતી એક જ સિસ્ટમ છે. જ્યારે તમે એક જ મોડેલને 51 વખત એક જ પ્રશ્ન પૂછો છો, ત્યારે તમે કોઈ સમિતિ નથી બોલાવી રહ્યા. તમે થોડા અલગ મૂડમાં એક જ વ્યક્તિનું સર્વે કરી રહ્યા છો.
સતત રહેવાની સમસ્યા
મુખ્ય સમસ્યા એ છે કે LLM ની ભૂલો ભાગ્યે જ યાદચ્છિક (random) હોય છે. તે ટ્રેનિંગ ડેટા અને આર્કિટેક્ચરમાં રહેલી પેટર્ન છે. જે મોડેલ એક વાર ચોક્કસ Python ડેકોરેટરને ખોટી રીતે વાંચે છે, તે આગલી વાર પણ તેને ખોટી રીતે વાંચવાની શક્યતા છે. જે મોડેલ વેરિએબલનું નામ પાસવર્ડ જેવું દેખાવાને કારણે સિક્યુરિટી વલ્નરેબિલિટી (security vulnerability) ની ભ્રમણા (hallucinate) કરે છે, તે કદાચ 47મી વખત પણ તે જ ભૂલ કરશે. તમે જે નોઈઝ (noise) ને દૂર કરવાનો પ્રયાસ કરી રહ્યા છો તે સામાન્ય રીતે શબ્દો અથવા ફોર્મેટિંગમાં સપાટી પરના ફેરફારો છે. મૂળ તર્ક (reasoning) ઘણીવાર એ જ સ્થિતિમાં રહે છે.
એક ચોક્કસ ઉદાહરણ લો. કલ્પના કરો કે એક ફંક્શન રેગ્યુલર એક્સપ્રેશન (regular expression) નો ઉપયોગ કરીને લોગ ફાઇલોને પાર્સ કરે છે. તે regex કડક અને સુરક્ષિત છે. પરંતુ r'...' સ્ટ્રિંગમાં એવા અક્ષરો છે જે અન્ય સંદર્ભમાં ઇન્જેક્શન (injection) નો ખતરો ઊભો કરી શકે છે. આની રિવ્યુ કરવા માટે LLM ને કહો. જો મોડેલે લોગ પાર્સર્સમાં regex ઇન્જેક્શન સામે ચેતવણી આપતી હજારો Stack Overflow પોસ્ટ્સ જોઈ હશે, તો તે આ સુરક્ષિત સ્નિપેટને જોખમ તરીકે દર્શાવી શકે છે. તેને એકવાર ચલાવો, તમને 'ફોલ્સ પોઝિટિવ' (false positive) મળશે. તેને 51 વખત ચલાવો, અને પૂરી શક્યતા છે કે તમને 51 ફોલ્સ પોઝિટિવ મળે, અથવા ઓછામાં ઓછું મોટો બહુમતી મળે. હવે મેજોરિટી વોટ એ ભ્રમણાને વધુ મજબૂત બનાવે છે. મોડેલ જિદ્દી છે, તેથી "સંમતિ" (consensus) પણ જિદ્દી છે.
આવું એટલા માટે થાય છે કારણ કે ટેમ્પરેચર (temperature) અને સેમ્પલિંગ ટ્રિક્સ મોડેલ શું જાણે છે તે બદલતા નથી. તેઓ માત્ર તે કેવી રીતે બોલે છે તે બદલે છે. ઊંચું ટેમ્પરેચર સમજૂતીને વધુ લાંબી અથવા ટૂંકી બનાવી શકે છે. તે સમાનાર્થી શબ્દો બદલી શકે છે. તે અચાનક મોડેલને એ નથી શીખવતું કે regex ખરેખર નુકસાનકારક નથી. તમે જેના પર વોટ કરી રહ્યા છો તે ફેરફારો માત્ર દેખાવ પૂરતા (cosmetic) છે. ભૂલ માળખાગત (structural) છે.
51 રન શું દર્શાવે છે
જ્યારે મેં તે 51 આઉટપુટ ટેબલ પર ફેલાવ્યા, ત્યારે પેટર્ન સ્પષ્ટ હતી. મોડેલે કોડના 51 અલગ અર્થઘટનો શોધ્યા નહોતા. તેણે માત્ર એક જ અર્થઘટનને થોડા અલગ અવાજોમાં રજૂ કર્યું હતું. થોડા રનમાં તે અલગ રીતે કામ કરી રહ્યા હતા, જેમ કે એજ-કેસ (edge-case) ફિક્સ સૂચવવા અથવા અસંબંધિત સ્ટાઇલની સમસ્યાઓ નોંધવી. પરંતુ મુખ્ય જૂથ, જે સ્પષ્ટ બહુમતી હતી, તે સતત એ જ ખોટા મુખ્ય દાવા પર પાછી આવતી હતી. તે દાવો સાચો નહોતો. તે માત્ર પરિચિત હતો.
મેજોરિટી વોટિંગનું ગણિત સ્વતંત્ર બર્નુલી ટ્રાયલ્સ (Bernoulli trials) ધારે છે. બહુમતી વ્યક્તિગત ભૂલ કરતા વધુ સારી રીતે કામ કરે તે માટે તમારે અસંબંધિત ભૂલોની જરૂર હોય છે. મારા પ્રયોગમાં, ભૂલો ઊંડાણપૂર્વક જોડાયેલી હતી. તેનું મૂળ કારણ એક જ હતું: મોડેલનું ટ્રેનિંગ ડિસ્ટ્રિબ્યુશન અમુક ચોક્કસ કોડિંગ ટ્રોપ્સ (coding tropes) ને વધુ મહત્વ આપે છે. તેથી, મેજોરિટી વોટે ભૂલ ઘટાડી નહીં, પરંતુ બહુમતી પૂર્વગ્રહને વધારી દીધો. તેણે ખામીયુક્ત વિશ્લેષણને ચોકસાઈનો ખોટો અહેસાસ કરાવ્યો.
કોડ રિવ્યુમાં આ ખાસ કરીને જોખમી છે કારણ કે ડેવલપર્સ સર્વસંમત અથવા લગભગ સર્વસંમત 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