ലാർജ് ലാംഗ്വേജ് മോഡലുകൾ (Large language models) മൂന്ന് പരിചിതമായ തലങ്ങളിലൂടെ വളർന്നു വന്നിരിക്കുന്നു. കൂടുതൽ ടെക്സ്റ്റ് നൽകിക്കൊണ്ട് നമ്മൾ പ്രീ-ട്രെയിനിംഗ് (pre-training) വ്യാപിപ്പിക്കുന്നു. നിർദ്ദേശങ്ങൾ കൃത്യമായി പാലിക്കാനുള്ള കഴിവ് മെച്ചപ്പെടുത്താൻ പോസ്റ്റ്-ട്രെയിനിംഗിലൂടെ (post-training) അവയെ പരിഷ്കരിക്കുന്നു. ഉത്തരങ്ങൾ വേഗത്തിലാക്കാൻ ടെസ്റ്റ്-ടൈം കമ്പ്യൂട്ട് (test-time compute) ഉപയോഗിക്കുന്നു. ഇവ ഓരോന്നും മോഡലിനെ കൂടുതൽ മികച്ചതും വേഗതയേറിയതും സുതാര്യവുമായ വാചകങ്ങൾ നിർമ്മിക്കാൻ പ്രേരിപ്പിക്കുന്നു. എന്നാൽ ഇവയൊന്നും ഒരു കഠിനമായ പ്രശ്നത്തെ നേരിടുന്നില്ല: നിർമ്മിക്കപ്പെട്ട വാചകങ്ങൾ ശരിയാണോ എന്ന് എങ്ങനെ തിരിച്ചറിയാം എന്നത്.
ആ വിടവ് അപകടകരമായി മാറിക്കൊണ്ടിരിക്കുകയാണ്. കൃത്യമായ ഇൻഡന്റേഷനും (indentation) ലോജിക്കൽ ഘടനയുമുള്ള ഒരു പൈത്തൺ സ്ക്രിപ്റ്റ് ഒരു മോഡൽ നൽകിയേക്കാം, എന്നാൽ അത് പ്രവർത്തിപ്പിക്കുമ്പോൾ തന്നെ എറർ (error) കാണിച്ചേക്കാം. ഒരു മെഡിക്കൽ ലക്ഷണത്തെക്കുറിച്ച് വളരെ ആത്മവിശ്വാസത്തോടെ വിവരിക്കുകയും എന്നാൽ രോഗനിർണ്ണയം തെറ്റായി നൽകുകയും ചെയ്തേക്കാം. ചാറ്റ്ബോട്ടുകളെ സംബന്ധിച്ചിടത്തോളം ഇവ നാണക്കേടുണ്ടാക്കുന്ന ബഗുകളാണ് (bugs). മനുഷ്യന്റെ മേൽനോട്ടമില്ലാതെ പ്രവർത്തിക്കുന്ന ഓട്ടോണമസ് ഏജന്റുകളെ (autonomous agents) സംബന്ധിച്ചിടത്തോളം, ഇവ യഥാർത്ഥ പ്രത്യാഘാതങ്ങൾ ഉണ്ടാക്കുന്ന പരാജയങ്ങളാണ്. വിവരങ്ങൾ നിർമ്മിക്കാനുള്ള കഴിവും (generation) സത്യം തിരിച്ചറിയാനുള്ള കഴിവും ഒന്നല്ല; ആ വ്യത്യാസം തിരിച്ചറിയുന്നതാണ് നമുക്ക് വിശ്വസിക്കാവുന്ന സിസ്റ്റങ്ങൾ നിർമ്മിക്കുന്നതിനുള്ള ആദ്യ പടി.
ജനറേഷൻ കെണി (The Generation Trap)
മൂന്ന് സാധാരണ സ്കെയിലിംഗ് രീതികളും ഒഴുക്കോടെയുള്ള സംസാരത്തിനും (fluency) ടാസ്ക് പൂർത്തീകരണത്തിനുമാണ് മുൻഗണന നൽകുന്നത്, അറിവിന്റെ കൃത്യതയ്ക്കല്ല (epistemic accuracy). പ്രീ-ട്രെയിനിംഗ് ട്രില്യൺ കണക്കിന് ടോക്കണുകളിൽ (tokens) വിശാലമായ സ്റ്റാറ്റിസ്റ്റിക്കൽ പാറ്റേണുകൾ നിർമ്മിക്കുന്നു. പോസ്റ്റ്-ട്രെയിനിംഗ് മോഡലിനെ മനുഷ്യരുടെ താൽപ്പര്യങ്ങൾക്ക് അനുസൃതമാക്കുന്നു, ഇത് പലപ്പോഴും കൃത്യതയേക്കാൾ ഉപരിയായി മര്യാദയ്ക്കും ആത്മവിശ്വാസത്തിനും മുൻഗണന നൽകുന്നു. ടെസ്റ്റ്-ടൈം കമ്പ്യൂട്ട് ഓരോ അഭ്യർത്ഥനയ്ക്കും കൂടുതൽ 'തിങ്കിംഗ് ടോക്കണുകൾ' (thinking tokens) നൽകി ഫോർമാറ്റിംഗും ഘട്ടം ഘട്ടമായുള്ള ഘടനയും മെച്ചപ്പെടുത്തുന്നുണ്ടെങ്കിലും, അന്തിമ ഔട്ട്പുട്ടിനെ പരിശോധിച്ച ഉത്തരമായി കാണുന്നതിന് പകരം ഒരു ഏകപക്ഷീയമായ പ്രസ്താവനയായി (monologue) മാത്രമാണ് കണക്കാക്കുന്നത്.
ഇതിന്റെ ഫലം ഒരു 'ഫ്ലുവൻസി ട്രാപ്പ്' (fluency trap) ആണ്. കോഡ് വൃത്തിയുള്ളതായി തോന്നും. വിശദീകരണങ്ങൾ ആധികാരികമായി തോന്നും. വസ്തുതകൾ ശരിയാണെന്ന് തോന്നും. എന്നാൽ ഉപരിപ്ലവമായ ഈ മിനുക്കുപണികൾ ഉള്ളിലെ തെറ്റുകളെ മറച്ചുവെക്കുന്നു. നിർമ്മിക്കപ്പെട്ട കോഡ് പരിശോധിക്കാതെ ഒരു പ്രൊഡക്ഷൻ പൈപ്പ്ലൈനിൽ (production pipeline) ഉപയോഗിക്കുന്ന ഡെവലപ്പർക്ക് സിസ്റ്റം തകരാറിലാകാനുള്ള (downtime) സാധ്യതയുണ്ട്. ഒരു ക്ലിനീഷ്യൻ AI അസിസ്റ്റന്റ് ഉപയോഗിക്കുമ്പോൾ, മോഡൽ രണ്ട് സമാനമായ മരുന്നുകളുടെ പ്രതിപ്രവർത്തനങ്ങളെ (drug interactions) തമ്മിൽ കൂട്ടിക്കലർത്തുകയാണെങ്കിൽ അത് ഗുരുതരമായ നിയമപരമായ ഉത്തരവാദിത്തങ്ങൾക്ക് കാരണമാകും. നമ്മൾ മോഡലുകളെ പ്രവർത്തിക്കാൻ മാത്രമാണ് പരിശീലിപ്പിച്ചിട്ടുള്ളത്, അവയെത്തന്നെ പരിശോധിക്കാൻ (audit) അല്ല.
വെരിഫിക്കേഷൻ ഒരു സ്കെയിലിംഗ് അച്ചുതണ്ടായി (Verification as a Scaling Axis)
LLM-as-a-Verifier എന്ന ഫ്രെയിംവർക്ക് ഈ പ്രശ്നത്തെ പൂർണ്ണമായും പുനർനിർവചിക്കുന്നു. വെരിഫിക്കേഷനെ ഒരു പിൽക്കാല ചിന്തയായോ അല്ലെങ്കിൽ മനുഷ്യർ നടത്തുന്ന പ്രത്യേക പരിശോധനയായോ കാണുന്നതിന് പകരം, പ്രീ-ട്രെയിനിംഗ്, പോസ്റ്റ്-ട്രെയിനിംഗ്, ഇൻഫറൻസ് ആക്സിലറേഷൻ (inference acceleration) എന്നിവയ്ക്കൊപ്പം സ്വയം വിലയിരുത്തലിനെ (self-evaluation) നാലാമതൊരു സ്കെയിലിംഗ് അച്ചുതണ്ടായി ഇത് പരിഗണിക്കുന്നു.
മോഡലിന്റെ നിലവിലുള്ള യുക്തിചിന്താ ശേഷി (reasoning capacity) ഉപയോഗിച്ച് അതിന്റെ തന്നെ ഔട്ട്പുട്ടുകൾ വിലയിരുത്തുക എന്നതാണ് ഇതിന്റെ ആശയം. ഒരു ഉത്തരം നിർമ്മിച്ച ശേഷം, അതേ മോഡൽ തന്നെ പിന്നോട്ട് മാറി അത് വിലയിരുത്തുന്നു. ഇത് ഒരു ക്ലോസ്ഡ് ലൂപ്പ് (closed loop) സൃഷ്ടിക്കുന്നു: നിർമ്മിക്കുക, സ്കോർ ചെയ്യുക, പരിഷ്കരിക്കുക, ആവർത്തിക്കുക. മോഡലിനെ പുതിയ വെയിറ്റുകൾ (weights) ഉപയോഗിച്ചോ ഡാറ്റാസെറ്റുകൾ ഉപയോഗിച്ചോ വീണ്ടും പരിശീലിപ്പിക്കേണ്ടതില്ല. ഒരു എഴുത്തുകാരന് പകരം ഒരു വിമർശകന്റെ (critic) റോൾ സ്വീകരിക്കുന്ന രീതിയിലുള്ള ഒരു പ്രോംപ്റ്റ് ടെംപ്ലേറ്റിലേക്ക് (prompt template) അത് നിലവിലുള്ള ബുദ്ധിശക്തിയെ പ്രയോഗിക്കുക മാത്രമാണ് ചെയ്യുന്നത്.
ഈ മാറ്റം പ്രധാനമാണ്, കാരണം ഇത് കഴിവിനെയും (capability) വിശ്വാസ്യതയെയും (reliability) തമ്മിൽ വേർതിരിക്കുന്നു. നന്നായി വെരിഫൈ ചെയ്യാൻ കഴിയുന്ന ഒരു ചെറിയ മോഡലിന്, അത് ചെയ്യാത്ത ഒരു വലിയ മോഡലിനേക്കാൾ മികച്ച പ്രകടനം കാഴ്ചവെക്കാൻ കഴിയും. നിങ്ങൾ സ്കെയിൽ ചെയ്യുന്നത് പാരാമീറ്റർ എണ്ണത്തെ മാത്രമല്ല, മറിച്ച് വിധിനിർണ്ണയ ശേഷിയെയാണ് (judgment), ഇത് സിസ്റ്റത്തിന് സുരക്ഷിതമായി ചെയ്യാൻ കഴിയുന്ന കാര്യങ്ങളെ മാറ്റുന്നു.
പ്രോബബിലിസ്റ്റിക് സ്കോറിംഗിന്റെ കരുത്ത് (The Power of Probabilistic Scoring)
മിക്ക വെരിഫിക്കേഷൻ ശ്രമങ്ങളും പരാജയപ്പെടുന്നത് അവ ഒരു ബൈനറി വിധി (binary verdict) ആവശ്യപ്പെടുന്നതുകൊണ്ടാണ്. ഈ ഉത്തരം ശരിയാണോ? അതെ അല്ലെങ്കിൽ അല്ല. ഇത്തരത്തിലുള്ള ഒരു ലളിതമായ സൂചന വിവരങ്ങൾ നഷ്ടപ്പെടുത്തുന്നു. ഒരു മറുപടി മിക്കവാറും ശരിയായിരിക്കാം എന്നാൽ അതിൽ ഒരു വലിയ തെറ്റുണ്ടാകാം, അല്ലെങ്കിൽ മിക്കവാറും തെറ്റായിരിക്കാം എന്നാൽ അതിൽ ഒരു ശരിയായ കാര്യം ഉണ്ടാകാം. ഒരു ബൈനറി സ്കോർ ഈ സൂക്ഷ്മതകളെല്ലാം ഒരു ബിറ്റിലേക്ക് (bit) ചുരുക്കുന്നു.
LLM-as-a-Verifier ഇതിന് പകരം പ്രോബബിലിസ്റ്റിക് സ്കോറിംഗ് (probabilistic scoring) ഉപയോഗിക്കുന്നു. ഒരു 'തമ്പ്സ്-അപ്പ്' (thumbs-up) അല്ലെങ്കിൽ 'തമ്പ്സ്-ഡൗൺ' (thumbs-down) എന്നതിന് പകരം, മോഡൽ 0.92 പോലുള്ള ഒരു തുടർച്ചയായ സംഖ്യ നൽകുന്നു. ആ ദശാംശ സംഖ്യയ്ക്ക് അർത്ഥമുണ്ട്. ഉത്തരം ശരിയാണെന്ന് മോഡൽ ഏകദേശം ഉറപ്പിച്ചു പറയുന്നു എന്നോ, അല്ലെങ്കിൽ 0.34 എന്ന സ്കോർ വഴി എന്തോ പിശക് ഉണ്ടെന്ന് സൂചിപ്പിക്കുന്നു എന്നോ ഇത് നിങ്ങൾക്ക് പറഞ്ഞുതരുന്നു. സിസ്റ്റം പ്രവർത്തിപ്പിക്കുന്ന മനുഷ്യർക്ക് പരിധികൾ (thresholds) നിശ്ചയിക്കാം. 0.60-ന് താഴെയുള്ളവ സ്വയമേവ വീണ്ടും നിർമ്മിക്കാൻ (automatic regeneration) പ്രേരിപ്പിച്ചേക്കാം. 0.60-നും 0.85-നും ഇടയിലുള്ളവ മനുഷ്യന്റെ പരിശോധനയ്ക്കായി മാറ്റിവെക്കാം. 0.90-ന് മുകളിൽ സിസ്റ്റം സ്വയം പ്രവർത്തിക്കും.
തുടർച്ചയായ സ്കോറുകൾ ആത്മവിശ്വാസത്തെ അടിസ്ഥാനമാക്കിയുള്ള കണക്കുകൂട്ടലുകൾക്കും (arithmetic) സഹായിക്കുന്നു. നിങ്ങൾക്ക് ഒന്നിലധികം പരിശോധനകളുടെ ശരാശരി എടുക്കാം, പ്രോംപ്റ്റ് വ്യതിയാനത്തിനനുസരിച്ച് അവയ്ക്ക് മുൻഗണന നൽകാം, അല്ലെങ്കിൽ ഏറ്റവും മികച്ചത് തിരഞ്ഞെടുക്കുന്നതിനായി വിവിധ ഉത്തരങ്ങളിലെ സ്കോറുകൾ താരതമ്യം ചെയ്യാം. ബൈനറി വിധിനിർണ്ണയങ്ങൾക്ക് ഇത്തരത്തിലുള്ള സൂക്ഷ്മമായ തീരുമാനങ്ങൾ എടുക്കാൻ കഴിയില്ല.
മൂന്ന് പ്രായോഗിക നേട്ടങ്ങൾ (Three Practical Advantages)
ഈ ഫ്രെയിംവർക്ക് മൂന്ന് പ്രത്യേക ഗുണങ്ങളിൽ നിന്നാണ് അതിന്റെ കരുത്ത് നേടുന്നത്.
Granularity. A score of 0.82 communicates something that "correct" does not. It implies near-certainty with residual doubt. In software engineering, that might mean the code compiles and handles the main case but possibly misses an edge condition. In medical reasoning, it might indicate a likely diagnosis that still requires a confirmatory test. Granular scores let downstream systems calibrate their response rather than treating all successes as equal.
Repetition. Because verification is cheap compared to generation, you can run it multiple times with slight prompt variations or temperature settings. If three independent checks return 0.91, 0.89, and 0.93, you have a consensus. If they scatter widely, say 0.91, 0.42, and 0.87, you know the model is uncertain and the answer needs work. Majority voting among binary judges is blunt. Averaging continuous scores surfaces ambiguity.
Decomposition. Complex tasks rarely fail everywhere at once. A robotics task might break down into perception, planning, and motor execution. A software engineering task might separate into algorithm design, implementation, and testing coverage. Probabilistic scoring lets the verifier assess each sub-component individually. You learn not just that the answer is weak, but where it is weak. That diagnostic precision makes repair faster and more targeted.
Results in Difficult Domains
The framework's utility shows up