ದೊಡ್ಡ ಭಾಷಾ ಮಾದರಿಗಳು (Large language models) ಮೂರು ಪರಿಚಿತ ಆಯಾಮಗಳಲ್ಲಿ ಬೆಳೆದಿವೆ. ನಾವು ಅವುಗಳಿಗೆ ಹೆಚ್ಚಿನ ಪಠ್ಯವನ್ನು ನೀಡುವ ಮೂಲಕ ಪ್ರಿ-ಟ್ರೈನಿಂಗ್ ಅನ್ನು ವಿಸ್ತರಿಸುತ್ತೇವೆ. ಸೂಚನೆಗಳನ್ನು ಅನುಸರಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಚುರುಕುಗೊಳಿಸಲು ನಾವು ಪೋಸ್ಟ್-ಟ್ರೈನಿಂಗ್ ಮೂಲಕ ಅವುಗಳನ್ನು ಪರಿಷ್ಕರಿಸುತ್ತೇವೆ. ಉತ್ತರಗಳನ್ನು ವೇಗಗೊಳಿಸಲು ನಾವು ಟೆಸ್ಟ್-ಟೈಮ್ ಕಂಪ್ಯೂಟ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಇವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಮಾದರಿಯು ಉತ್ತಮವಾದ, ವೇಗವಾದ ಮತ್ತು ಹೆಚ್ಚು ಸುಸಂಬದ್ಧವಾದ ಗದ್ಯವನ್ನು ರಚಿಸಲು ಪ್ರೇರೇಪಿಸುತ್ತದೆ. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಕಠಿಣವಾದ ಸಮಸ್ಯೆಯನ್ನು ನೇರವಾಗಿ ಪರಿಹರಿಸುವುದಿಲ್ಲ: ಅಂದರೆ ಆ ಗದ್ಯವು ನಿಜವಾಗಿಯೂ ಸರಿಯಾಗಿದೆಯೇ ಎಂದು ತಿಳಿಯುವುದು.
ಆ ಅಂತರವು ಅಪಾಯಕಾರಿಯಾಗುತ್ತಿದೆ. ಒಂದು ಮಾದರಿಯು ಪರಿಪೂರ್ಣ ಇಂಡೆಂಟೇಶನ್ ಮತ್ತು ತಾರ್ಕಿಕ ರಚನೆಯನ್ನು ಹೊಂದಿರುವ ಪೈಥಾನ್ (Python) ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ನೀಡಬಹುದು, ಆದರೆ ಅದು ರನ್ ಆದ ತಕ್ಷಣ ದೋಷವನ್ನು (error) ತೋರಿಸಬಹುದು. ಅದು ವೈದ್ಯಕೀಯ ಲಕ್ಷಣವನ್ನು ಅತ್ಯಂತ ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ವಿವರಿಸಬಹುದು ಮತ್ತು ರೋಗನಿರ್ಣಯವನ್ನು ತಪ್ಪು ಮಾಡಬಹುದು. ಚಾಟ್ಬಾಟ್ಗಳಿಗೆ, ಇವು ಮುಜುಗರ ತರುವ ದೋಷಗಳು (bugs). ಮಾನವ ಮೇಲ್ವಿಚಾರಣೆಯಿಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್ಗಳಿಗೆ (autonomous agents), ಇವು ನಿಜವಾದ ಪರಿಣಾಮಗಳನ್ನು ಬೀರುವ ವೈಫಲ್ಯಗಳಾಗಿವೆ. ರಚನೆ (Generation) ಮತ್ತು ಸತ್ಯ (Truth) ಎಂಬುದು ಒಂದೇ ರೀತಿಯ ಕೌಶಲಗಳಲ್ಲ, ಮತ್ತು ಆ ವ್ಯತ್ಯಾಸವನ್ನು ಗುರುತಿಸುವುದು ನಾವು ನಂಬಬಹುದಾದ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸುವ ಮೊದಲ ಹೆಜ್ಜೆಯಾಗಿದೆ.
ಜನರೇಷನ್ ಟ್ರ್ಯಾಪ್ (The Generation Trap)
ಮೂರು ಪ್ರಮಾಣಿತ ಸ್ಕೇಲಿಂಗ್ ಮಾರ್ಗಗಳು ಸರಾಗತೆ ಮತ್ತು ಕಾರ್ಯದ ಪೂರ್ಣಗೊಳಿಸುವಿಕೆಗೆ ಒತ್ತು ನೀಡುತ್ತವೆ, ಜ್ಞಾನದ ನಿಖರತೆಗೆ (epistemic accuracy) ಅಲ್ಲ. ಪ್ರಿ-ಟ್ರೈನಿಂಗ್ ಟ್ರಿಲಿಯನ್ಗಟ್ಟಲೆ ಟೋಕನ್ಗಳ ಮೂಲಕ ವ್ಯಾಪಕವಾದ ಸಾಂಖ್ಯಿಕ ಮಾದರಿಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ. ಪೋಸ್ಟ್-ಟ್ರೈನಿಂಗ್ ಮಾದರಿಯನ್ನು ಮಾನವ ಆದ್ಯತೆಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ರೂಪಿಸುತ್ತದೆ, ಇದು ಹೆಚ್ಚಾಗಿ ಕಟ್ಟುನಿಟ್ಟಾದ ನಿಖರತೆಗಿಂತ ವಿನಯ ಮತ್ತು ಆತ್ಮವಿಶ್ವಾಸಕ್ಕೆ ಹೆಚ್ಚಿನ ಪ್ರಾಮುಖ್ಯತೆ ನೀಡುತ್ತದೆ. ಟೆಸ್ಟ್-ಟೈಮ್ ಕಂಪ್ಯೂಟ್ ಪ್ರತಿ ವಿನಂತಿಗೆ ಮಾದರಿಗೆ ಹೆಚ್ಚಿನ 'ಥಿಂಕಿಂಗ್ ಟೋಕನ್ಗಳನ್ನು' ನೀಡುತ್ತದೆ, ಇದು ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಮತ್ತು ಹಂತ-ಹಂತದ ರಚನೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ, ಆದರೆ ಇಂದಿಗೂ ಅಂತಿಮ ಫಲಿತಾಂಶವನ್ನು ಪರಿಶೀಲಿಸಿದ ಉತ್ತರವನ್ನಾಗಿ ನೋಡುವ ಬದಲು ಏಕಪಕ್ಷೀಯ ಮಾತುಗಳನ್ನಾಗಿ (monologue) ಪರಿಗಣಿಸುತ್ತದೆ.
ಇದರ ಪರಿಣಾಮ 'ಫ್ಲೂಯೆನ್ಸಿ ಟ್ರ್ಯಾಪ್' (fluency trap). ಕೋಡ್ ಸ್ವಚ್ಛವಾಗಿ ಕಾಣುತ್ತದೆ. ವಿವರಣೆಗಳು ಅಧಿಕಾರಯುತವಾಗಿ ಕೇಳಿಸುತ್ತವೆ. ಸತ್ಯಗಳು ಸರಿಯಾಗಿವೆ ಎಂದು ಅನಿಸುತ್ತದೆ. ಆದರೆ ಮೇಲ್ನೋಟದ ಹೊಳಪು ಒಳಗಿರುವ ದೋಷಗಳನ್ನು ಮರೆಮಾಚುತ್ತದೆ. ಯಾವುದೇ ಪರಿಶೀಲನೆ ಇಲ್ಲದೆ ಜನರೇಟ್ ಮಾಡಿದ ಕೋಡ್ ಅನ್ನು ಪ್ರೊಡಕ್ಷನ್ ಪೈಪ್ಲೈನ್ಗೆ ಬಳಸುವ ಡೆವಲಪರ್, ಸಿಸ್ಟಮ್ ಸ್ಥಗಿತಗೊಳ್ಳುವ (downtime) ಅಪಾಯವನ್ನು ಎದುರಿಸಬಹುದು. ಮಾದರಿಯು ಎರಡು ಒಂದೇ ರೀತಿಯ ಔಷಧಿಯ ಸಂವಹನಗಳನ್ನು (drug interactions) ತಪ್ಪಾಗಿ ಗುರುತಿಸಿದರೆ, AI ಸಹಾಯಕನನ್ನು ಬಳಸುವ ವೈದ್ಯರು ಗಂಭೀರವಾದ ಹೊಣೆಗಾರಿಕೆಯನ್ನು ಎದುರಿಸಬೇಕಾಗುತ್ತದೆ. ನಾವು ಮಾದರಿಗಳನ್ನು ಕಾರ್ಯನಿರ್ವಹಿಸಲು ತರಬೇತಿಗೊಳಿಸಿದ್ದೇವೆವೇ ಹೊರತು, ಅವು ತಮ್ಮನ್ನು ತಾವು ಪರಿಶೀಲಿಸಿಕೊಳ್ಳಲು (audit) ಅಲ್ಲ.
ಸ್ಕೇಲಿಂಗ್ ಆಯಾಮವಾಗಿ ಪರಿಶೀಲನೆ (Verification as a Scaling Axis)
'LLM-as-a-Verifier' ಎಂಬ ಚೌಕಟ್ಟು ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮರುರೂಪಿಸುತ್ತದೆ. ಪರಿಶೀಲನೆಯನ್ನು ನಂತರದ ಹಂತ ಅಥವಾ ಪ್ರತ್ಯೇಕ ಮಾನವ ವಿಮರ್ಶೆಯ ಹಂತ ಎಂದು ಪರಿಗಣಿಸುವ ಬದಲು, ಇದು ಸ್ವಯಂ-ಮೌಲ್ಯಮಾಪನವನ್ನು ಪ್ರಿ-ಟ್ರೈನಿಂಗ್, ಪೋಸ್ಟ್-ಟ್ರೈನಿಂಗ್ ಮತ್ತು ಇನ್ಫರೆನ್ಸ್ ಅಕ್ಸೆಲರೇಶನ್ ಜೊತೆಗೆ ನಾಲ್ಕನೇ ಸ್ಕೇಲಿಂಗ್ ಆಯಾಮವಾಗಿ ಪರಿಗಣಿಸುತ್ತದೆ.
ಮಾದರಿಯು ತನ್ನದೇ ಆದ ಫಲಿತಾಂಶಗಳನ್ನು ನಿರ್ಣಯಿಸಲು ಅದರ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ತಾರ್ಕಿಕ ಸಾಮರ್ಥ್ಯವನ್ನು ಬಳಸಿಕೊಳ್ಳುವುದು ಇದರ ಉದ್ದೇಶವಾಗಿದೆ. ಒಂದು ಸಂಭಾವ್ಯ ಉತ್ತರವನ್ನು ನೀಡಿದ ನಂತರ, ಅದೇ ಮಾದರಿಯು ಹಿಂದಕ್ಕೆ ಸರಿದು ಅದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ. ಇದು ಒಂದು ಮುಚ್ಚಿದ ಲೂಪ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ: ರಚಿಸು, ಅಂಕ ನೀಡು, ತಿದ್ದಿ, ಪುನರಾವರ್ತಿಸು. ಮಾದರಿಯನ್ನು ಹೊಸ ತೂಕಗಳು (weights) ಅಥವಾ ಡೇಟಾಸೆಟ್ಗಳೊಂದಿಗೆ ಮರು ತರಬೇತಿಗೊಳಿಸಲಾಗುತ್ತಿಲ್ಲ. ಇದು ಕೇವಲ ತನ್ನಲ್ಲಿರುವ ಬುದ್ಧಿವಂತಿಕೆಯನ್ನು ಲೇಖಕನ ಬದಲು ವಿಮರ್ಶಕನ ಪ್ರಾಂಪ್ಟ್ ಟೆಂಪ್ಲೇಟ್ಗೆ ಅನ್ವಯಿಸುತ್ತದೆ.
ಈ ಬದಲಾವಣೆಯು ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಸಾಮರ್ಥ್ಯವನ್ನು ವಿಶ್ವಾಸಾರ್ಹತೆಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಉತ್ತಮವಾಗಿ ಪರಿಶೀಲಿಸುವ ಸಣ್ಣ ಮಾದರಿಯು, ಪರಿಶೀಲಿಸದ ದೊಡ್ಡ ಮಾದರಿಗಿಂತ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು. ನೀವು ಕೇವಲ ಪ್ಯಾರಾಮೀಟರ್ ಸಂಖ್ಯೆಯನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ನಿರ್ಣಯ ಸಾಮರ್ಥ್ಯವನ್ನು (judgment) ವಿಸ್ತರಿಸುತ್ತಿದ್ದೀರಿ, ಮತ್ತು ಇದು ವ್ಯವಸ್ಥೆಯು ಸುರಕ್ಷಿತವಾಗಿ ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ.
ಪ್ರೊಬಾಬಿಲಿಸ್ಟಿಕ್ ಸ್ಕೋರಿಂಗ್ನ ಶಕ್ತಿ (The Power of Probabilistic Scoring)
ಹೆಚ್ಚಿನ ಪರಿಶೀಲನಾ ಪ್ರಯತ್ನಗಳು ವಿಫಲವಾಗುತ್ತವೆ ಏಕೆಂದರೆ ಅವು ಬೈನರಿ ತೀರ್ಪನ್ನು (binary verdict) ಬಯಸುತ್ತವೆ. ಈ ಉತ್ತರ ಸರಿಯಾಗಿದೆಯೇ? ಹೌದು ಅಥವಾ ಇಲ್ಲ. ಅಂತಹ ಕಚ್ಚಾ ಸಂಕೇತವು ಮಾಹಿತಿಯನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ. ಒಂದು ಪ್ರತಿಕ್ರಿಯೆಯು ಬಹುಪಾಲು ಸರಿಯಾಗಿರಬಹುದು ಆದರೆ ಅದರಲ್ಲಿ ಒಂದು 치명ವಾದ ದೋಷವಿರಬಹುದು, ಅಥವಾ ಬಹುಪಾಲು ತಪ್ಪಾಗಿರಬಹುದು ಆದರೆ ಅದರಲ್ಲಿ ಒಂದು ಉಪಯುಕ್ತ ಅಂಶವಿರಬಹುದು. ಬೈನರಿ ಸ್ಕೋರ್ ಈ ಎಲ್ಲಾ ಸೂಕ್ಷ್ಮತೆಗಳನ್ನು ಒಂದೇ ಬಿಟ್ಗೆ ಕುಗ್ಗಿಸುತ್ತದೆ.
LLM-as-a-Verifier ಇದನ್ನು ಪ್ರೊಬಾಬಿಲಿಸ್ಟಿಕ್ ಸ್ಕೋರಿಂಗ್ನಿಂದ ಬದಲಾಯಿಸುತ್ತದೆ. ಅಂದರೆ 'ಥಂಬ್ಸ್-ಅಪ್' ಅಥವಾ 'ಥಂಬ್ಸ್-ಡೌನ್' ಬದಲಿಗೆ, ಮಾದರಿಯು 0.92 ನಂತಹ ನಿರಂತರ ಸಂಖ್ಯೆಯನ್ನು ನೀಡುತ್ತದೆ. ಆ ದಶಮಾಂಶವು ಅರ್ಥವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಉತ್ತರವು ಸರಿಯಾಗಿದೆ ಎಂದು ಮಾದರಿಯು ಬಹುತೇಕ ಖಚಿತವಾಗಿದೆ ಅಥವಾ 0.34 ರಂದು ಏನೋ ತಪ್ಪಾಗಿದೆ ಎಂದು ಅದು ಸೂಚಿಸುತ್ತದೆ. ವ್ಯವಸ್ಥೆಯನ್ನು ನಡೆಸುವ ಮಾನವರು ಮಿತಿಯನ್ನು (thresholds) ನಿಗದಿಪಡಿಸಬಹುದು. 0.60 ಕ್ಕಿಂತ ಕಡಿಮೆ ಇದ್ದರೆ ಸ್ವಯಂಚಾಲಿತ ಮರು-ಸೃಷ್ಟಿಯನ್ನು (automatic regeneration) ಪ್ರಾರಂಭಿಸಬಹುದು. 0.60 ಮತ್ತು 0.85 ರ ನಡುವಿನ ಮೌಲ್ಯಗಳನ್ನು ಮಾನವ ವಿಮರ್ಶೆಗಾಗಿ ಗುರುತಿಸಬಹುದು. 0.90 ಕ್ಕಿಂತ ಹೆಚ್ಚಿದ್ದರೆ, ವ್ಯವಸ್ಥೆಯು ಸ್ವಾಯತ್ತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ನಿರಂತರ ಸ್ಕೋರ್ಗಳು ಆತ್ಮವಿಶ್ವಾಸದ ಮೇಲೆ ಗಣಿತದ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತವೆ. ನೀವು ಹಲವಾರು ಪರಿಶೀಲನೆಗಳ ಸರಾಸರಿಯನ್ನು ಪಡೆಯಬಹುದು, ಪ್ರಾಂಪ್ಟ್ ವ್ಯತ್ಯಾಸಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಅವುಗಳಿಗೆ ತೂಕ ನೀಡಬಹುದು ಅಥವಾ ಉತ್ತಮ ಉತ್ತರವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ವಿವಿಧ ಸಂಭಾವ್ಯ ಉತ್ತರಗಳ ಸ್ಕೋರ್ಗಳನ್ನು ಹೋಲಿಸಬಹುದು. ಬೈನರಿ ತೀರ್ಪುಗಳು ಇಂತಹ ಸೂಕ್ಷ್ಮ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳಲು ಬೆಂಬಲ ನೀಡುವುದಿಲ್ಲ.
ಮೂರು ಪ್ರಾಯೋಗಿಕ ಪ್ರಯೋಜನಗಳು (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