లార్జ్ లాంగ్వేజ్ మోడల్స్ (Large language models) మూడు తెలిసిన కొలతల (dimensions) ద్వారా అభివృద్ధి చెందాయి. మేము వాటికి మరింత టెక్స్ట్ను అందించడం ద్వారా ప్రీ-ట్రైనింగ్ను (pre-training) విస్తరిస్తాము. సూచనలను పాటించే సామర్థ్యాన్ని (instruction-following) మెరుగుపరచడానికి మేము పోస్ట్-ట్రైనింగ్ (post-training) ద్వారా వాటిని శుద్ధి చేస్తాము. సమాధానాలను వేగవంతం చేయడానికి మేము టెస్ట్-టైమ్ కంప్యూట్ (test-time compute) ను ఉపయోగిస్తాము. ఇవన్నీ మోడల్ మెరుగైన, వేగవంతమైన మరియు మరింత స్పష్టమైన గద్యం (prose) రూపొందించేలా ప్రేరేపిస్తాయి. అయితే, ఇవేవీ ఒక కఠినమైన సమస్యను నేరుగా పరిష్కరించవు: ఆ గద్యం నిజంగా సరైనదా కాదా అని తెలుసుకోవడం.
ఆ అంతరం ప్రమాదకరంగా మారుతోంది. ఒక మోడల్ ఖచ్చితమైన ఇండెంటేషన్ (indentation) మరియు తార్కిక నిర్మాణంతో కూడిన పైథాన్ (Python) స్క్రిప్ట్ను ఇవ్వవచ్చు, కానీ అది రన్ అయిన వెంటనే ఎర్రర్ను చూపుతుంది. అది ఒక వైద్య లక్షణాన్ని ఎంతో నమ్మకంగా వివరించవచ్చు, కానీ రోగ నిర్ధారణను తప్పుగా చెప్పవచ్చు. చాట్బాట్ల విషయానికి వస్తే, ఇవి ఇబ్బందికరమైన బగ్స్ (bugs). మానవ పర్యవేక్షణ లేకుండా పనిచేసే స్వయంప్రతిపత్తి కలిగిన ఏజెంట్ల (autonomous agents) విషయానికి వస్తే, ఇవి వాస్తవ పరిణామాలను కలిగించే వైఫల్యాలు. జనరేషన్ (Generation) మరియు సత్యం (truth) అనేవి ఒకే నైపుణ్యాలు కావు, మరియు ఆ తేడాను గుర్తించడమే మనం నమ్మదగిన వ్యవస్థలను నిర్మించడానికి మొదటి అడుగు.
జనరేషన్ ట్రాప్ (The Generation Trap)
మూడు ప్రామాణిక స్కేలింగ్ మార్గాలు ఫ్లూయెన్సీ (fluency) మరియు టాస్క్ పూర్తి చేయడం కోసం ఆప్టిమైజ్ చేయబడ్డాయి, జ్ఞానపరమైన ఖచ్చితత్వం (epistemic accuracy) కోసం కాదు. ప్రీ-ట్రైనింగ్ ట్రిలియన్ల టోకెన్ల ద్వారా విస్తృతమైన గణాంక నమూనాలను (statistical patterns) నిర్మిస్తుంది. పోస్ట్-ట్రైనింగ్ మోడల్ను మానవ ప్రాధాన్యతలకు అనుగుణంగా మారుస్తుంది, ఇది తరచుగా కచ్చితత్వం కంటే మర్యాద మరియు ఆత్మవిశ్వాసానికి ఎక్కువ ప్రాధాన్యత ఇస్తుంది. టెస్ట్-టైమ్ కంప్యూట్ ప్రతి రిక్వెస్ట్కు మోడల్కు మరిన్ని థింకింగ్ టోకెన్లను అందిస్తుంది, దీనివల్ల ఫార్మాటింగ్ మరియు స్టెప్-బై-స్టెప్ నిర్మాణం మెరుగుపడుతుంది, కానీ ఇది ఇప్పటికీ తుది అవుట్పుట్ను తనిఖీ చేసిన సమాధానంలా కాకుండా ఒక మోనోలాగ్ (monologue) లాగానే పరిగణిస్తుంది.
దీని ఫలితం ఒక ఫ్లూయెన్సీ ట్రాప్ (fluency trap). కోడ్ చూడటానికి శుభ్రంగా ఉంటుంది. వివరణలు అధికారికంగా అనిపిస్తాయి. వాస్తవాలు సరైనవిగా అనిపిస్తాయి. కానీ పైపైన కనిపించే మెరుపు లోపల ఉన్న తప్పులను కప్పిపుచ్చుతుంది. ఒక డెవలపర్ తనిఖీ చేయకుండా జనరేట్ చేయబడిన కోడ్ను ప్రొడక్షన్ పైప్లైన్లో ఉపయోగిస్తే, అది డౌన్టైమ్ (downtime) కలిగించే ప్రమాదం ఉంది. ఒక క్లినిషియన్ AI అసిస్టెంట్ను ఉపయోగిస్తున్నప్పుడు, మోడల్ రెండు సారూప్యమైన డ్రగ్ ఇంటరాక్షన్లను (drug interactions) కలిపి చూపిస్తే, అది తీవ్రమైన బాధ్యతలకు దారితీస్తుంది. మేము మోడళ్లను పని చేయడానికి శిక్షణ ఇచ్చాము, తమను తాము ఆడిట్ (audit) చేసుకోవడానికి కాదు.
స్కేలింగ్ యాక్సిస్గా వెరిఫికేషన్ (Verification as a Scaling Axis)
LLM-as-a-Verifier అనే ఫ్రేమ్వర్క్ ఈ సమస్యను పూర్తిగా కొత్త కోణంలో చూస్తుంది. వెరిఫికేషన్ను ఒక అదనపు ఆలోచనగా లేదా విడిగా మానవ సమీక్ష దశగా చూడటానికి బదులుగా, ఇది సెల్ఫ్-ఎవల్యూయేషన్ను (self-evaluation) ప్రీ-ట్రైనింగ్, పోస్ట్-ట్రైనింగ్ మరియు ఇన్ఫరెన్స్ యాక్సిలరేషన్ (inference acceleration) తో పాటు నాల్గవ స్కేలింగ్ యాక్సిస్గా పరిగణిస్తుంది.
మోడల్ యొక్క ప్రస్తుత రీజనింగ్ సామర్థ్యాన్ని (reasoning capacity) ఉపయోగించి దాని స్వంత అవుట్పుట్లను అంచనా వేయడమే దీని ఉద్దేశ్యం. ఒక సమాధానాన్ని రూపొందించిన తర్వాత, అదే మోడల్ వెనక్కి తగ్గి దానిని విశ్లేషిస్తుంది. ఇది ఒక క్లోజ్డ్ లూప్ను సృష్టిస్తుంది: జనరేట్ చేయండి, స్కోర్ చేయండి, సవరించండి, మళ్ళీ చేయండి. మోడల్ను కొత్త వెయిట్స్ (weights) లేదా డేటాసెట్లతో మళ్ళీ శిక్షణ ఇవ్వడం లేదు. ఇది కేవలం తన వద్ద ఉన్న తెలివితేటలను ఒక రచయితగా కాకుండా, ఒక విమర్శకుడి (critic) ప్రాంప్ట్ టెంప్లేట్కు వర్తింపజేస్తుంది.
ఈ మార్పు ముఖ్యమైనది ఎందుకంటే ఇది సామర్థ్యాన్ని (capability) మరియు విశ్వసనీయతను (reliability) వేరు చేస్తుంది. బాగా వెరిఫై చేయగల చిన్న మోడల్, అలా చేయలేని పెద్ద మోడల్ కంటే మెరుగైన ఫలితాలను ఇవ్వగలదు. మీరు కేవలం పారామీటర్ల సంఖ్యను మాత్రమే కాకుండా, తీర్పు చెప్పే సామర్థ్యాన్ని (judgment) స్కేల్ చేస్తున్నారు, ఇది సిస్టమ్ సురక్షితంగా చేయగలిగే పనులను మారుస్తుంది.
ప్రాబబిలిస్టిక్ స్కోరింగ్ యొక్క శక్తి (The Power of Probabilistic Scoring)
చాలా వెరిఫికేషన్ ప్రయత్నాలు విఫలమవుతాయి ఎందుకంటే అవి బైనరీ తీర్పును (binary verdict) కోరుకుంటాయి. ఈ సమాధానం సరైనదా? అవును లేదా కాదు. అటువంటి మొరటు సంకేతం సమాచారాన్ని వృధా చేస్తుంది. ఒక సమాధానం ఎక్కువగా సరైనది కావచ్చు కానీ అందులో ఒక致命మైన (fatal) లోపం ఉండవచ్చు, లేదా ఒక మంచి అంశంతో ఎక్కువగా తప్పుగా ఉండవచ్చు. బైనరీ స్కోర్ ఆ సూక్ష్మతను (nuance) ఒకే బిట్గా కుదిపేస్తుంది.
LLM-as-a-Verifier దీనిని ప్రాబబిలిస్టిక్ స్కోరింగ్తో (probabilistic scoring) భర్తీ చేస్తుంది. థంబ్స్-అప్ లేదా థంబ్స్-డౌన్ కి బదులుగా, మోడల్ 0.92 వంటి నిరంతర సంఖ్యను అందిస్తుంది. ఆ దశాంశ సంఖ్యకు ఒక అర్థం ఉంటుంది. సమాధానం సరైనదని మోడల్ దాదాపు ఖచ్చితంగా ఉందని లేదా 0.34 వద్ద ఏదో తప్పు ఉందని అది మీకు చెబుతుంది. సిస్టమ్ను నడిపించే మనుషులు థ్రెషోల్డ్లను (thresholds) సెట్ చేయవచ్చు. 0.60 కంటే తక్కువ ఉన్నది ఆటోమేటిక్ రీజనరేషన్ను (automatic regeneration) ప్రేరేపించవచ్చు. 0.60 మరియు 0.85 మధ్య ఉన్నది మానవ సమీక్ష కోసం ఫ్లాగ్ చేయవచ్చు. 0.90 కంటే ఎక్కువ ఉంటే, సిస్టమ్ స్వయంప్రతిపత్తితో (autonomously) పనిచేస్తుంది.
నిరంతర స్కోర్లు కాన్ఫిడెన్స్ (confidence) పై గణిత ప్రక్రియలను కూడా అనుమతిస్తాయి. మీరు బహుళ తనిఖీల సగటును లెక్కించవచ్చు, ప్రాంప్ట్ వైవిధ్యం ఆధారంగా వాటికి వెయిటేజీ ఇవ్వవచ్చు, లేదా ఉత్తమమైన దానిని ఎంచుకోవడానికి వివిధ అభ్యర్థి సమాధానాల స్కోర్లను పోల్చవచ్చు. బైనరీ తీర్పులు అటువంటి సూక్ష్మమైన నిర్ణయ ప్రక్రియలకు (fine-grained decision-making) మద్దతు ఇవ్వవు.
మూడు ఆచరణాత్మక ప్రయోజనాలు (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