લાર્જ લેંગ્વેજ મોડલ્સ (Large language models) ત્રણ જાણીતી પરિમાણોમાં વિકસ્યા છે. અમે તેમને વધુ ટેક્સ્ટ આપીને પ્રી-ટ્રેનિંગ (pre-training) ને સ્કેલ કરીએ છીએ. અમે ઇન્સ્ટ્રક્શન-ફોલોઇંગ (instruction-following) ને વધુ સચોટ બનાવવા માટે પોસ્ટ-ટ્રેનિંગ (post-training) દ્વારા તેમને રિફાઇન કરીએ છીએ. અમે જવાબોની ઝડપ વધારવા માટે ટેસ્ટ-ટાઇમ કમ્પ્યુટ (test-time compute) નો ઉપયોગ કરીએ છીએ. આ દરેક બાબત મોડલને વધુ સારું, ઝડપી અને વધુ સુસંગત લખાણ જનરેટ કરવા માટે પ્રેરે છે. આમાંથી એક પણ બાબત સીધી રીતે વધુ મુશ્કેલ સમસ્યાનું નિરાકરણ કરતી નથી: તે લખાણ ખરેખર સાચું છે કે નહીં તે જાણવું.
આ અંતર જોખમી બની રહ્યું છે. એક મોડલ પરફેક્ટ ઇન્ડેન્ટેશન અને લોજિકલ સ્ટ્રક્ચર સાથે પાયથોન (Python) સ્ક્રિપ્ટ આપી શકે છે, જે રન થતાની સાથે જ એરર (error) આપે. તે શાંત અને સત્તાવાર રીતે તબીબી લક્ષણો સમજાવી શકે છે પરંતુ નિદાન (diagnosis) ઉલટું કરી શકે છે. ચેટબોટ્સ માટે, આ શરમજનક બગ્સ (bugs) છે. માનવીય દેખરેખ વગર કામ કરતા ઓટોનોમસ એજન્ટ્સ (autonomous agents) માટે, આ વાસ્તવિક પરિણામો સાથેની નિષ્ફળતાઓ છે. જનરેશન (Generation) અને સત્ય (truth) એ એક સમાન કૌશલ્ય નથી, અને તે તફાવતને ઓળખવો એ આપણે ભરોસા કરી શકીએ તેવા સિસ્ટમ્સ બનાવવા તરફનું પ્રથમ પગલું છે.
જનરેશન ટ્રેપ (The Generation Trap)
ત્રણ પ્રમાણભૂત સ્કેલિંગ માર્ગો પ્રવાહિતા (fluency) અને કાર્ય પૂર્ણ કરવા માટે ઓપ્ટિમાઇઝ કરે છે, જ્ઞાનતત્ત્વિક સચોટતા (epistemic accuracy) માટે નહીં. પ્રી-ટ્રેનિંગ ટ્રિલિયન્સ ટોકન્સમાં વ્યાપક આંકડાકીય પેટર્ન બનાવે છે. પોસ્ટ-ટ્રેનિંગ મોડલને માનવીય પસંદગીઓ સાથે સુસંગત બનાવે છે, જે ઘણીવાર સખત સચોટતા કરતા નમ્રતા અને આત્મવિશ્વાસને વધુ મહત્વ આપે છે. ટેસ્ટ-ટાઇમ કમ્પ્યુટ દરેક રિક્વેસ્ટ દીઠ મોડલને વધુ 'થિંકિંગ ટોકન્સ' (thinking tokens) આપે છે, જેનાથી ફોર્મેટિંગ અને સ્ટેપ-બાય-સ્ટેપ સ્ટ્રક્ચરમાં સુધારો થાય છે, પરંતુ તે હજુ પણ અંતિમ આઉટપુટને ચકાસાયેલ જવાબને બદલે એક મોનોલોગ (monologue) તરીકે જ જુએ છે.
તેનું પરિણામ 'ફ્લુએન્સી ટ્રેપ' (fluency trap) છે. કોડ ચોખ્ખો લાગે છે. સમજૂતીઓ સત્તાવાર લાગે છે. તથ્યો સાચા લાગે છે. પરંતુ ઉપરની ચમક નીચે રહેલી ભૂલોને છુપાવે છે. જે ડેવલપર જનરેટ કરેલા કોડને તપાસ્યા વગર પ્રોડક્શન પાઇપલાઇનમાં પેસ્ટ કરે છે, તેને ડાઉનટાઇમ (downtime) નું જોખમ રહે છે. જો મોડલ બે સમાન ડ્રગ ઇન્ટરેક્શનને ભેગા કરી દે, તો AI આસિસ્ટન્ટનો ઉપયોગ કરનાર ક્લિનિશિયન ગંભીર જવાબદારીનો સામનો કરી શકે છે. અમે મોડલ્સને કામ કરવા માટે તાલીમ આપી છે, પોતાની જાતનું ઓડિટ કરવા માટે નહીં.
સ્કેલિંગ એક્સિસ તરીકે વેરિફિકેશન (Verification as a Scaling Axis)
LLM-as-a-Verifier નામનું ફ્રેમવર્ક આ સમસ્યાને સંપૂર્ણપણે નવો આકાર આપે છે. વેરિફિકેશનને પછીનો વિચાર અથવા અલગ માનવીય સમીક્ષાના પગલા તરીકે ગણવાને બદલે, તે સેલ્ફ-ઇવેલ્યુએશન (self-evaluation) ને પ્રી-ટ્રેનિંગ, પોસ્ટ-ટ્રેનિંગ અને ઇન્ફરન્સ એક્સિલરેશનની સાથે ચોથા સ્કેલિંગ એક્સિસ તરીકે જુએ છે.
વિચાર એ છે કે મોડલની હાલની રીઝનિંગ ક્ષમતાનો ઉપયોગ તેના પોતાના આઉટપુટને ચકાસવા માટે કરવો. એક સંભવિત જવાબ જનરેટ કર્યા પછી, તે જ મોડલ પાછળ હટીને તેનું મૂલ્યાંકન કરે છે. આ એક ક્લોઝ્ડ લૂપ બનાવે છે: જનરેટ કરો, સ્કોર કરો, સુધારો કરો, અને ફરીથી કરો. મોડલને નવા વેટ્સ (weights) અથવા ડેટાસેટ્સ સાથે ફરીથી તાલીમ આપવામાં આવતી નથી. તે ફક્ત તેની પાસે પહેલેથી જ રહેલી બુદ્ધિનો ઉપયોગ એક અલગ પ્રોમ્પ્ટ ટેમ્પલેટ માટે કરે છે, જે લેખકને બદલે એક વિવેચક (critic) તરીકે હોય છે.
આ ફેરફાર મહત્વપૂર્ણ છે કારણ કે તે ક્ષમતાને વિશ્વસનીયતાથી અલગ કરે છે. સારી રીતે વેરિફિકેશન કરી શકે તેવું નાનું મોડલ એવા મોટા મોડલ કરતા વધુ સારું પ્રદર્શન કરી શકે છે જે આવું કરી શકતું નથી. તમે માત્ર પેરામીટર કાઉન્ટને જ નહીં, પણ જજમેન્ટને સ્કેલ કરી રહ્યા છો, અને તે સિસ્ટમ સુરક્ષિત રીતે શું કરી શકે છે તે બદલી નાખે છે.
પ્રોબેબિલિસ્ટિક સ્કોરિંગની શક્તિ (The Power of Probabilistic Scoring)
મોટાભાગના વેરિફિકેશન પ્રયાસો નિષ્ફળ જાય છે કારણ કે તેઓ બાઈનરી (binary) ચુકાદાની માંગ કરે છે. શું આ જવાબ સાચો હતો? હા અથવા ના. તે કાચો સિગ્નલ માહિતીનો બગાડ કરે છે. એક પ્રતિસાદ મોટે ભાગે સાચો હોઈ શકે છે પરંતુ તેમાં એક જીવલેણ ખામી હોઈ શકે છે, અથવા મોટે ભાગે ખોટો હોઈ શકે છે પરંતુ તેમાં એક ઉપયોગી સમજ હોઈ શકે છે. બાઈનરી સ્કોર આ તમામ સૂક્ષ્મતાઓને એક સિંગલ બીટમાં સમાવી દે છે.
LLM-as-a-Verifier આને પ્રોબેબિલિસ્ટિક સ્કોરિંગ (probabilistic scoring) સાથે બદલે છે. થમ્બ્સ-અપ અથવા થમ્બ્સ-ડાઉન ને બદલે, મોડલ 0.92 જેવો સતત નંબર આપે છે. તે દશાંશ સંખ્યાનો અર્થ હોય છે. તે તમને જણાવે છે કે મોડલને લગભગ ખાતરી છે કે જવાબ સાચો છે, અથવા 0.34 પર તેને કંઈક ખોટું લાગે છે. સિસ્ટમ ચલાવતા માણસો થ્રેશોલ્ડ (thresholds) સેટ કરી શકે છે. 0.60 થી નીચેનું કંઈ પણ ઓટોમેટિક રિજનરેશન ટ્રિગર કરી શકે છે. 0.60 અને 0.85 વચ્ચેની રેન્જ માનવીય સમીક્ષા માટે ફ્લેગ કરી શકે છે. 0.90 થી ઉપર, સિસ્ટમ સ્વાયત્ત રીતે (autonomously) કાર્ય કરે છે.
સતત સ્કોર્સ આત્મવિશ્વાસ પર ગાણિતિક પ્રક્રિયાઓ પણ સક્ષમ બનાવે છે. તમે અનેક ચેકનું સરેરાશ કાઢી શકો છો, પ્રોમ્પ્ટ વેરિએશન દ્વારા તેમને વજન આપી શકો છો, અથવા શ્રેષ્ઠ પસંદ કરવા માટે વિવિધ સંભવિત જવાબોના સ્કોર્સની તુલના કરી શકો છો. બાઈનરી ચુકાદાઓ આ પ્રકારના ઝીણવટભર્યા નિર્ણય લેવાની પ્રક્રિયાને ટેકો આપતા નથી.
ત્રણ વ્યવહારુ ફાયદા (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