ഒരേ ചോദ്യം 51 തവണ ആവർത്തിച്ച് ചോദിച്ചാൽ ഉത്തരം കൂടുതൽ വിശ്വസനീയമാകുമോ എന്ന് എനിക്ക് പരിശോധിക്കണമെന്നുണ്ടായിരുന്നു. ഞാൻ ഒരു ലോക്കൽ LLM എടുത്ത്, അതിലേക്ക് പ്രൊഡക്ഷൻ കോഡിന്റെ ഒരു ഭാഗം നൽകി, ഒരു റിവ്യൂ ആവശ്യപ്പെട്ടു. എന്നിട്ട് ഞാൻ അത് വീണ്ടും ചെയ്തു. വീണ്ടും വീണ്ടും. ആകെ അൻപത്തിയൊന്ന് തവണ, ഏറ്റവും "മികച്ച" മറുപടി തിരഞ്ഞെടുക്കാൻ മജോറിറ്റി വോട്ടിംഗ് (majority voting) ഉപയോഗിച്ചു. ആശയം ലളിതമായിരുന്നു: ഒരു തവണ ചെയ്യുമ്പോൾ മോഡൽ തെറ്റിക്കുകയാണെങ്കിൽ, 51 തവണയുടെ കൂട്ടായ വിവേകം ആ പിശകുകളെ ഒഴിവാക്കി ശരിയായ വിശകലനം നൽകും എന്ന് ഞാൻ കരുതി. എന്നാൽ സംഭവിച്ചത് അതല്ല. മജോറിറ്റി വോട്ടിംഗ് കൃത്യത തിരഞ്ഞെടുക്കുന്നില്ലെന്ന് പരീക്ഷണം കാണിച്ചുതന്നു. മറിച്ച്, മോഡൽ ഏത് കാര്യത്തിലാണോ ഏറ്റവും കൂടുതൽ വാശി കാണിക്കുന്നത്, അത് തന്നെയാണ് അത് തിരഞ്ഞെടുക്കുന്നത്.
ഈ വ്യത്യാസം വളരെ പ്രധാനമാണ്, കാരണം LLM പൈപ്പ്ലൈനുകളിൽ മജോറിറ്റി വോട്ടിംഗ് ഒരു പ്രചാരമുള്ള രീതിയായി മാറിയിരിക്കുന്നു. ഇതിന്റെ രീതി ലളിതമാണ്. ഒരേ പ്രോംപ്റ്റ് ഉപയോഗിച്ച് മോഡലിനെ പലതവണ പ്രവർത്തിപ്പിക്കുക, ലഭിക്കുന്ന ഔട്ട്പുട്ടുകൾ ശേഖരിക്കുക, ഏറ്റവും കൂടുതൽ തവണ വരുന്ന ഉത്തരം നിലനിർത്തുക. മെഡിക്കൽ ഇമേജിംഗ് അല്ലെങ്കിൽ സ്പാം ഡിറ്റക്ഷൻ പോലുള്ള മേഖലകളിൽ എൻസെംബിൾ മെത്തേഡുകൾ (ensemble methods) ഫലപ്രദമാണ്, കാരണം വ്യത്യസ്ത മോഡലുകൾ അല്ലെങ്കിൽ ഡാറ്റയുടെ വ്യത്യസ്ത കാഴ്ചപ്പാടുകൾ സ്വതന്ത്രമായ പിശകുകൾ ഉണ്ടാക്കുന്നു, അവ പരസ്പരം ഇല്ലാതാക്കാൻ സാധിക്കും. എന്നാൽ ലാർജ് ലാംഗ്വേജ് മോഡലുകൾ സ്വതന്ത്രമായ വോട്ടർമാരല്ല. അവ ഒരേ പരിശീലന ചരിത്രവും (training history), ഒരേ സെറ്റ് വെയ്റ്റുകളും (weights), ഒരേ പക്ഷപാതങ്ങളും (biases) ഉള്ള ഒരു സിസ്റ്റമാണ്. ഒരേ മോഡലിനോട് ഒരേ ചോദ്യം അൻപത്തിയൊന്ന് തവണ ചോദിക്കുമ്പോൾ, നിങ്ങൾ ഒരു കമ്മിറ്റിയെ വിളിക്കുകയല്ല ചെയ്യുന്നത്. മറിച്ച്, നേരിയ വ്യത്യാസങ്ങളുള്ള മാനസികാവസ്ഥയിൽ ഒരേ വ്യക്തിയോട് തന്നെ വോട്ട് ചോദിക്കുകയാണ് ചെയ്യുന്നത്.
സ്ഥിരതയുടെ പ്രശ്നം
പ്രധാന പ്രശ്നം എന്തെന്നാൽ, LLM പിശകുകൾ അപൂർവ്വമായി മാത്രമേ റാൻഡം (random) ആയി സംഭവിക്കാറുള്ളൂ. അവ പരിശീലന ഡാറ്റയിലും ആർക്കിടെക്ചറിലും അന്തർലീനമായ പാറ്റേണുകളാണ്. ഒരു തവണ ഒരു പ്രത്യേക പൈത്തൺ ഡെക്കറേറ്റർ (Python decorator) തെറ്റായി വായിക്കുന്ന മോഡൽ, അടുത്ത തവണയും അത് തെറ്റായി വായിക്കാൻ സാധ്യതയുണ്ട്. ഒരു വേരിയബിൾ പേര് പാസ്വേഡ് പോലെ തോന്നുന്നത് കാരണം ഒരു സെക്യൂരിറ്റി വൾനറബിലിറ്റി (security vulnerability) ഉണ്ടെന്ന് മോഡൽ തെറ്റായി പറയുകയാണെങ്കിൽ, നാൽപ്പത്തിയേഴാമത്തെ തവണയും അത് വീണ്ടും തെറ്റായി പറയാൻ സാധ്യതയുണ്ട്. നിങ്ങൾ ശരാശരി എടുക്കാൻ ശ്രമിക്കുന്ന 'നോയിസ്' (noise) എന്നത് സാധാരണയായി വാക്കുകളിലോ ഫോർമാറ്റിംഗിലോ ഉള്ള ഉപരിപ്ലവമായ വ്യത്യാസങ്ങൾ മാത്രമാണ്. എന്നാൽ അടിസ്ഥാനപരമായ യുക്തി (reasoning) മാറ്റമില്ലാതെ തുടരുന്നു.
ഒരു ഉദാഹരണം നോക്കാം. ഒരു റെഗുലർ എക്സ്പ്രഷൻ (regular expression) ഉപയോഗിച്ച് ലോഗ് ഫയലുകൾ പാഴ്സ് ചെയ്യുന്ന ഒരു ഫംഗ്ഷൻ സങ്കൽപ്പിക്കുക. ആ regex കൃത്യവും സുരക്ഷിതവുമാണ്. എന്നാൽ r'...' എന്ന സ്ട്രിംഗിൽ മറ്റ് സാഹചര്യങ്ങളിൽ ഇൻജക്ഷന് (injection) കാരണമായേക്കാവുന്ന ക്യാരക്ടറുകൾ ഉണ്ടാകാം. ഇത് റിവ്യൂ ചെയ്യാൻ ഒരു LLM-നോട് ആവശ്യപ്പെടുക. ലോഗ് പാഴ്സറുകളിൽ regex ഇൻജക്ഷനെതിരെ മുന്നറിയിപ്പ് നൽകുന്ന ആയിരക്കണക്കിന് സ്റ്റാക്ക് ഓവർഫ്ലോ (Stack Overflow) പോസ്റ്റുകൾ ഈ മോഡൽ കണ്ടിട്ടുണ്ടെങ്കിൽ, ഈ സുരക്ഷിതമായ കോഡ് ഒരു റിസ്ക് ആയി അത് അടയാളപ്പെടുത്തിയേക്കാം. ഇത് ഒരു തവണ ചെയ്താൽ നിങ്ങൾക്ക് ഒരു 'ഫോൾസ് പോസിറ്റീവ്' (false positive) ലഭിക്കും. ഇത് 51 തവണ ചെയ്താൽ, 51 തവണയും ഫോൾസ് പോസിറ്റീവ് ലഭിക്കാനോ അല്ലെങ്കിൽ വലിയൊരു ഭൂരിപക്ഷത്തിന് തെറ്റായ ഉത്തരം ലഭിക്കാനോ സാധ്യതയുണ്ട്. ഇപ്പോൾ മജോറിറ്റി വോട്ട് ആ തെറ്റായ ധാരണയെ (hallucination) കൂടുതൽ ഉറപ്പിക്കുന്നു. മോഡൽ വാശിയുള്ളതാണ്, അതിനാൽ "ഏകോപനം" (consensus) देखील വാശിയുള്ളതായി മാറുന്നു.
ഇതിന് കാരണം ടെമ്പറേച്ചറും (temperature) സാമ്പിളിംഗ് ട്രിക്കുകളും മോഡലിന് അറിയാവുന്ന കാര്യങ്ങളെ മാറ്റുന്നില്ല എന്നതാണ്. അവ മോഡൽ സംസാരിക്കുന്ന രീതിയെ മാത്രമേ മാറ്റുന്നുള്ളൂ. ഉയർന്ന ടെമ്പറേച്ചർ ഒരു വിശദീകരണത്തെ കൂടുതൽ സംസാരശൈലിയിലുള്ളതാക്കുകയോ അല്ലെങ്കിൽ ചുരുക്കിക്കുകയോ ചെയ്തേക്കാം. അത് പര്യായപദങ്ങൾ മാറ്റിയേക്കാം. എന്നാൽ ആ regex യഥാർത്ഥത്തിൽ ദോഷകരമല്ലെന്ന് അത് പെട്ടെന്ന് മോഡലിനെ പഠിപ്പിക്കില്ല. നിങ്ങൾ വോട്ട് ചെയ്യുന്ന വ്യത്യാസങ്ങൾ കേവലം ബാഹ്യമായവയാണ്. പിശക് ഘടനാപരമാണ്.
51 റണ്ണുകൾ വെളിപ്പെടുത്തുന്നത്
ആ 51 ഔട്ട്പുട്ടുകളും എന്റെ മേശപ്പുറത്ത് നിരത്തി വെച്ചപ്പോൾ പാറ്റേൺ വ്യക്തമായിരുന്നു. മോഡൽ കോഡിന്റെ 51 വ്യത്യസ്ത വ്യാഖ്യാനങ്ങൾ പരീക്ഷിക്കുകയല്ല ചെയ്തത്. മറിച്ച്, ഒരേ വ്യാഖ്യാനം തന്നെ നേരിയ വ്യത്യാസങ്ങളുള്ള ശബ്ദങ്ങളിൽ ആവർത്തിക്കുകയായിരുന്നു ചെയ്തത്. ഏതാനും റണ്ണുകൾ മാത്രം പാതയിൽ നിന്ന് വ്യതിചലിക്കുകയും, എഡ്ജ് കേസ് (edge-case) പരിഹാരങ്ങൾ നിർദ്ദേശിക്കുകയോ അല്ലെങ്കിൽ ബന്ധമില്ലാത്ത സ്റ്റൈൽ പ്രശ്നങ്ങൾ ശ്രദ്ധിക്കുകയോ ചെയ്തു. എന്നാൽ ഭൂരിഭാഗം റണ്ണുകളും ഒരേ തെറ്റായ പ്രധാന വാദത്തിലേക്കാണ് തിരികെ വന്നത്. ആ വാദം ശരിയായിരുന്നില്ല, അത് പരിചിതമായിരുന്നതുകൊണ്ട് മാത്രം ആവർത്തിക്കപ്പെട്ടു.
മജോറിറ്റി വോട്ടിംഗിന്റെ ഗണിതശാസ്ത്രം സ്വതന്ത്രമായ ബെർണൗളി ട്രയലുകളെ (Bernoulli trials) അടിസ്ഥാനമാക്കിയുള്ളതാണ്. ഭൂരിപക്ഷം വ്യക്തിഗതമായതിനേക്കാൾ മികച്ചതാകണമെങ്കിൽ പിശകുകൾ പരസ്പരബന്ധമില്ലാത്തതായിരിക്കണം. എന്റെ പരീക്ഷണത്തിൽ, പിശകുകൾ ആഴത്തിൽ ബന്ധപ്പെട്ടവയായിരുന്നു. അവയ്ക്ക് ഒരേ മൂലകാരണമുണ്ടായിരുന്നു: മോഡലിന്റെ പരിശീലന വിതരണം (training distribution) ചില കോഡിംഗ് രീതികൾക്ക് (coding tropes) അമിത പ്രാധാന്യം നൽകുന്നു. അതിനാൽ, മജോറിറ്റി വോട്ട് പിശകുകൾ കുറയ്ക്കുകയല്ല ചെയ്തത്, മറിച്ച് ഭൂരിപക്ഷ പക്ഷപാതത്തെ (majority bias) വർദ്ധിപ്പിക്കുകയാണ് ചെയ്തത്. അത് തെറ്റായ വിശകലനത്തിന് ഒരു തെറ്റായ ഉറപ്പ് നൽകി.
കോഡ് റിവ്യൂവിൽ ഇത് വളരെ അപകടകരമാണ്, കാരണം ഡെവലപ്പർമാർ AI-യുടെ ഏകകണ്ഠമായ അല്ലെങ്കിൽ ഏകകണ്ഠത്തോട് അടുത്ത ഔട്ട്പുട്ടുകളെ ആധികാരികമായി കണക്കാക്കുന്നു. ഒരു ചെറിയ സംശയാസ്പദമായ നിർദ്ദേശം എളുപ്പത്തിൽ തള്ളിക്കളയാം. എന്നാൽ അൻപത്തിയൊന്ന് റണ്ണുകളിലുടനീളം നിലനിൽക്കുന്ന ഒരു ശുപാർശ സത്യമാണെന്ന് തോന്നിപ്പിക്കും. എന്നാൽ അത് സത്യമല്ല. അത് ഒരു 'ഗ്രൗണ്ട് ലൂപ്പ്' (ground loop) ആണ്.
വോട്ടിംഗ് യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നത് എവിടെ
ഇതൊന്നും ഒരു മോഡൽ ഒരിക്കലും ഒന്നിലധികം തവണ പ്രവർത്തിപ്പിക്കരുത് എന്നല്ല അർത്ഥമാക്കുന്നത്. ടാസ്ക് വളരെ ലളിതവും പിശകുകൾ തികച്ചും യാദൃശ്ചികവുമാണെങ്കിൽ ഭൂരിപക്ഷ വോട്ടിംഗ് (majority voting) സഹായിച്ചേക്കാം. രണ്ട് സിന്റാക്റ്റിക് ഫോർമാറ്റുകളിൽ നിന്ന് ഒന്ന് തിരഞ്ഞെടുക്കാൻ ആവശ്യപ്പെടുകയോ, ഒരു വേരിയബിൾ നാമിംഗ് കൺവെൻഷൻ തിരഞ്ഞെടുക്കുകയോ, അല്ലെങ്കിൽ ഒരു ലോഗ് ലൈനിൽ നിന്ന് ഒരു ഡേറ്റ് സ്ട്രിംഗ് വേർതിരിച്ചെടുക്കുകയോ ചെയ്യുന്നത് പോലുള്ള കുറഞ്ഞ പ്രാധാന്യമുള്ള ജോലികൾക്ക് ആവർത്തിച്ചുള്ള സാമ്പിളിംഗ് ചിലപ്പോൾ ഗുണകരമാകും. ഈ വ്യതിയാനം യഥാർത്ഥമായ നോയിസ് ആണ്, ഒരു വേഗത്തിലുള്ള വോട്ടിംഗ് അത് പരിഹരിക്കും.
ടാസ്ക് ഒരു ഉദ്ദേശ്യത്തെക്കുറിച്ച് (intent) യുക്തിപരമായി ചിന്തിക്കാൻ ആവശ്യപ്പെടുമ്പോഴാണ് പ്രശ്നം തുടങ്ങുന്നത്. ഈ auth check ഇവിടെ വേണോ? ഈ async call സുരക്ഷിതമാണോ? ഈ cache key collision യഥാർത്ഥത്തിൽ ഉപയോഗപ്പെടുത്താൻ കഴിയുന്നതാണോ? ഇത്തരം ചോദ്യങ്ങൾക്ക് പാറ്റേൺ മാച്ചിംഗ് മാത്രമല്ല, സന്ദർഭത്തെക്കുറിച്ചുള്ള (context) ധാരണയും ആവശ്യമാണ്. ഒരു മോഡലിന്റെ പാറ്റേൺ മാച്ചർ അതിന്റെ ചായ്വിൽ (bias) നിശ്ചിതമായിരിക്കും. അത് നിങ്ങളുടെ കോഡ്ബേസിനു വേണ്ടിയുള്ള ഏറ്റവും കൃത്യമായ ഉത്തരത്തിന് പകരം, അതിന്റെ ട്രെയിനിംഗ് ഡാറ്റയിൽ നിന്നുള്ള ഏറ്റവും സാധാരണമായ ഉത്തരമായിരിക്കും നൽകുക.
നിങ്ങളുടെ കമ്പ്യൂട്ട് കൂടുതൽ ബുദ്ധിപരമായി ഉപയോഗിക്കാനുള്ള വഴികൾ
ഒരു ലോക്കൽ മോഡൽ അമ്പത്തിയൊന്ന് തവണ പ്രവർത്തിപ്പിക്കുന്നത് സമയവും വൈദ്യുതിയും ചെലവാക്കുന്നു. ആ കമ്പ്യൂട്ട് ഉപയോഗിക്കാൻ മികച്ച വഴികളുണ്ട്. നിങ്ങൾക്ക് വിശ്വസനീയത വർദ്ധിപ്പിക്കണമെന്നുണ്ടെങ്കിൽ, അളവിനേക്കാൾ വൈവിധ്യത്തിനാണ് മുൻതൂക്കം. രണ്ട് വ്യത്യസ്ത മോഡലുകൾ ഉപയോഗിച്ച്...