प्रशिक्षण

LLM-as-Judge

इसे भी कहा जाता है: LLM Judge, LLM-as-a-Judge

Evaluation technique जिसमें human raters पर निर्भर होने के बजाय large language model दूसरे model, या अपने, outputs grade करता है। Judge को original prompt, एक या दो candidate responses और scoring rubric मिलती है, और वह score, preference verdict या critique लौटाता है। Open-ended generation evaluate करने का यह default method बन गया है, जहाँ BLEU तथा ROUGE जैसे string-overlap metrics काम नहीं करते।

यह क्यों मायने रखता है

Open-ended text judge करने के लिए human evaluation gold standard है, लेकिन slow और expensive है: serious eval round weeks ले सकता है और thousands of dollars cost कर सकता है। LLM judge कुछ dollars में minutes के भीतर thousands of judgments लौटाता है, जिससे हर prompt change, model swap तथा release candidate evaluate करना practical होता है। Modern alignment training द्वारा scale पर consume होने वाले preference labels भी यही बनाता है।

गहन अध्ययन

Setup में तीन ingredients हैं: test prompt, एक या अधिक candidate responses और evaluator model को grade करना बताने वाला judging prompt। Judging prompt में आम तौर पर original input, candidate output, optional reference answer और rubric होता है — उदाहरण के लिए, "helpfulness, accuracy तथा clarity को 1 से 5 scale पर rate करें, reasoning explain करें, फिर final score दें।" Score से पहले judge को विचार-शृंखला step में reason करने को कहना bare number माँगने के मुकाबले human raters से agreement consistently बेहतर करता है। Rubric लिखने के बाद वही judge call कुछ cents per case में hundreds या thousands of test cases पर चलता है, और यही continuous मूल्यांकन को एनोटेशन (Annotation) की cost के छोटे fraction पर practical बनाता है।

Pairwise बनाम Pointwise Scoring

दो basic setups हैं। Pointwise scoring में judge एक response देखता और rubric के विरुद्ध grade करता है, आम तौर पर 1–5 या 1–10 scale पर; early तथा influential 2023 framework G-Eval ने दिखाया कि judge को rubric step by step follow कराना summarization तथा dialogue tasks पर human ratings से track करने वाले scores बनाता है। Pairwise comparison में judge same prompt के दो responses देखता और winner चुनता है, और MT-Bench तथा अधिकतर arena-style automated evals ऐसे ही काम करते हैं। Pairwise आम तौर पर अधिक reliable है, क्योंकि two candidates में चुनना absolute score calibrate करने से आसान task है, और इससे हर response के 5 में 4 पर आने की problem बचती है। दूसरी ओर single system output scale पर grade करने में pointwise सस्ता है, क्योंकि हर test case को केवल one judge call चाहिए। अधिकतर production pipelines दोनों इस्तेमाल करती हैं: regression tracking के pointwise scores और head-to-head model comparisons के pairwise verdicts।

Benchmarks से Training Loops तक

Same machinery तीन अलग jobs करती है। पहला, benchmarks: MT-Bench strong judge model से multi-turn chat responses grade करता और chat quality का standard leaderboard metric बना। दूसरा, training data: responses के pairs पर judge preferences सिंथेटिक डेटा preference data बनती हैं जो Reward Model train करती हैं, और वह फिर RLHF-style optimization चलाता है — यही pipeline मूलतः RLAIF कहलाती है, और labs human labelers की capacity से आगे preference learning इसी तरह scale करती हैं। तीसरा, regression testing: product teams test prompts का fixed set रखती हैं और हर model या prompt change पर outputs फिर judge करती हैं, release से पहले quality regressions पकड़कर। तीनों jobs में judge वह work करता है जिसे humans scale नहीं कर सकते या consistently नहीं कर सकते।

Bias Problem

LLM judges के documented failure modes हैं और उन्हें ignore करने से garbage rankings बनती हैं। Position bias: कई judges first या second आने वाले response को favor करते हैं, इसलिए serious pipelines हर pair दोनों orders में चलाती और केवल swap survive करने वाले verdicts रखती हैं। Verbosity bias: judges systematically longer, more structured answers prefer करते हैं, extra length से कुछ न जुड़ने पर भी, इसीलिए length-controlled scoring variants मौजूद हैं। Self-preference bias: judge के रूप में इस्तेमाल model अपनी family के outputs को independent judge से अधिक rate करता है, इसलिए safest setups grading वाले model से अलग family के model से judge करती हैं। Surface formatting भी मायने रखती है — markdown headers, bullet lists और confident tone, सभी scores ऊपर nudging करते हैं। इनमें कोई fatal नहीं, लेकिन इनका अर्थ है कि judging prompt तथा protocol judge model जितने ही महत्वपूर्ण हैं।

यह Human Judgment की जगह नहीं लेगा

एक आम गलतफ़हमी है कि strong judge मानव मूल्यांकन (Human Evaluation) obsolete बनाता है। MT-Bench जैसे benchmarks पर top judge models और human raters के बीच reported agreement 80% से अधिक है — लगभग two humans के agreement जितना — लेकिन यह average है और per-example reliability अधिक shaky है। Judges confident, well-formatted हैलूसिनेशन पकड़ने में खराब हैं, क्योंकि text अच्छा पढ़ता है और judge भी अक्सर correct answer नहीं जानता। वे अपने blind spots inherit करते हैं, इसलिए high-stakes evals — medical advice, self-harm और jailbreak resistance — को अब भी human review चाहिए, और leaderboard claims को Chatbot Arena जैसे human preference votes के विरुद्ध sanity-check करना best है। Honest framing: LLM judge human preference का cheap, noisy proxy है, ranking तथा regression detection के लिए excellent, ground truth source नहीं।

Judge पर कब भरोसा करें

Rule of thumb में judging वहाँ best काम करती है जहाँ quality exact correctness के बजाय चीज़ कैसे कही गई है उस पर है: instruction following, tone, helpfulness, summarization fluency और chat quality। यह factual frontier पर worst काम करती है जहाँ judge भी answer नहीं जानता, specialized domains में जहाँ judge model weak है और low-resource languages में। Standard hygiene few hundred human-labeled examples का small gold set बनाना, scale up करने से पहले judge-human agreement measure करना और judge model, rubric या task distribution बदलने पर फिर validate करना है। यह step छोड़ने वाली teams user के बजाय judge को please करने के लिए models optimize करती हैं — वह failure mode जो longer, more decorated और subtly worse answers लिखने वाले models के रूप में दिखता है।