LLM Evaluation: LLM output कैसे evaluate करें

चरण 1: काम के लिए success criteria तय करें

फ़ीचर से शुरू करें, मॉडल से नहीं। काम क्या है, कौन इस्तेमाल करता है, अच्छा जवाब क्या करता है, और कोई जवाब कभी क्या नहीं करे? मॉडल प्रोवाइडर्स की अपनी evaluation गाइडेंस भी यही कहती है: कोई भी टेस्ट लिखने से पहले मानदंड विशिष्ट और मापने योग्य होने चाहिए। "जवाब मददगार हों" मानदंड नहीं है; "रिटर्न-पॉलिसी के सवाल पर जवाब प्रोडक्ट कैटेगरी की सही रिटर्न अवधि बताए और पॉलिसी पेज लिंक करे" मानदंड है।

मानदंड तीन स्तरों पर लिखें: कड़ी आवश्यकताएँ जो हर जवाब पूरा करे (valid schema, सही भाषा, कोई व्यक्तिगत डेटा नहीं, कोई निषिद्ध एक्शन नहीं), स्कोर किए जाने वाले task-quality मानदंड (सही, पूरा, grounded, relevant), और ऑपरेशनल सीमाएँ (p95 latency, अधिकतम tokens, प्रति अनुरोध लागत)। कड़ी आवश्यकताएँ deterministic जाँच बनती हैं; quality मानदंड rubrics बनते हैं।

• उन intents के नाम लिखें जिन्हें फ़ीचर को संभालना है, और उनके भी जिन्हें उसे मना करना या redirect करना है।
• हर intent के लिए "सही" का मतलब तय करें — एक सटीक वैल्यू, ज़रूरी बिंदुओं का सेट, या किसी source document से मेल।
• हर मानदंड की स्वीकार्य फ़ेलियर दर नतीजे देखने से पहले तय करें, बाद में नहीं।

चरण 2: evaluation dataset बनाएँ

Evaluation dataset (जिसे अक्सर golden set कहते हैं) inputs की सूची है जिसमें output को grade करने के लिए ज़रूरी जानकारी होती है: अपेक्षित वैल्यू, ज़रूरी बिंदुओं की सूची, reference sources, या यह लेबल कि मॉडल को मना करना है। इसे असली intents से बनाएँ — anonymise किए सपोर्ट टिकट, सर्च लॉग, प्रोडक्ट सवाल — साथ में जानबूझकर डिज़ाइन किए केस: edge cases, अस्पष्ट सवाल, दायरे से बाहर के अनुरोध, लंबे input, दूसरी भाषाएँ और adversarial शब्दावली। इसमें असली व्यक्तिगत डेटा कभी न रखें; नाम, ईमेल और ID काल्पनिक से बदलें।

आकार से ज़्यादा coverage मायने रखता है। हर केस पर intent, भाषा, कठिनाई और रिस्क का टैग लगाएँ, और जाँचें कि हर intent के पास ट्रेंड दिखाने लायक केस हों। हर अहम intent के लिए कुछ दर्जन अच्छे से चुने केस व्यावहारिक शुरुआत हैं; जब भी प्रोडक्शन ऐसा फ़ेलियर दिखाए जिसका केस नहीं था, सेट बढ़ाएँ।

• सेट को JSON Lines (हर लाइन में एक केस) के रूप में version control में रखें और हर रिलीज़ पर टैग करें; नतीजे सिर्फ़ उसी dataset वर्ज़न पर तुलनीय हैं।
• Tuning डेटा और evaluation डेटा अलग रखें। अगर आप prompt को उन्हीं केसों पर सुधारते हैं जिनसे उसे स्वीकार करते हैं, तो आप अपने ही उदाहरणों की याददाश्त माप रहे हैं — वही contamination समस्या जो उन सार्वजनिक benchmarks को प्रभावित करती है जिनके सवाल training डेटा में लीक हो जाते हैं।
• एक held-out सेट रखें जिसे prompt बदलते समय कोई न देखे, और उसे सिर्फ़ रिलीज़ फ़ैसलों के लिए इस्तेमाल करें।
• Negative केस शामिल करें: ऐसे सवाल जिनका उपलब्ध डेटा में जवाब नहीं, दायरे से बाहर के अनुरोध, और ऐसे input जिन पर इनकार होना चाहिए।

{"id":"ret-001","intent":"return_policy","lang":"en","input":"Can I return headphones after 20 days?","expected":{"must_include":["30 days","original packaging"],"must_not_include":["60 days"]},"tags":["core"]}
{"id":"ret-014","intent":"return_policy","lang":"ar","input":"هل يمكنني إرجاع سماعة بعد 20 يوماً؟","expected":{"must_include":["30"],"answer_lang":"ar"},"tags":["core","arabic"]}
{"id":"oos-003","intent":"out_of_scope","lang":"en","input":"Which stock should I buy this week?","expected":{"behaviour":"decline_and_redirect"},"tags":["scope"]}
{"id":"unk-007","intent":"return_policy","lang":"en","input":"Can I return a gift card bought in 2019?","expected":{"behaviour":"say_not_covered"},"tags":["no_answer"]}

आज़माएँ: JSON Lines वैलिडेटर आज़माएँ: JSON Lines फ़ॉर्मेटर आज़माएँ: बहुभाषी टेस्ट डेटा जनरेटर

चरण 3: तय करें कि गुणवत्ता का हर आयाम कैसे जाँचें

हर आयाम को अपनी जाँच चाहिए। सबसे सस्ती भरोसेमंद जाँच चुनें: पहले deterministic, फिर rubric।

• Correctness — labels, IDs, संख्याओं और तारीख़ों के लिए exact match; व्याख्याओं के लिए ज़रूरी बिंदुओं की सूची; डोमेन विशेषज्ञ द्वारा रिव्यू किए reference answer से तुलना।
• Relevance — जवाब पूछे गए सवाल का है, पड़ोसी सवाल का नहीं; rubric से स्कोर, "दूसरे सवाल का जवाब दिया" को स्पष्ट फ़ेलियर कैटेगरी मानकर।
• Groundedness / faithfulness — हर तथ्यात्मक दावा दिए गए context या cited source से समर्थित है। cited IDs का अस्तित्व deterministic तरीक़े से जाँचें; समर्थन rubric से।
• Hallucination (confabulation) — जवाब तथ्य, नीतियाँ, reference या URL गढ़ता है। ऐसे केस रखें जिनका सही जवाब "उपलब्ध नहीं" है; वहाँ गढ़ा हुआ जवाब साफ़ फ़ेलियर है।
• Consistency — एक ही सवाल दो बार, या दो तरह से पूछने पर संगत जवाब मिलें। दोहराए और paraphrase किए variants चलाएँ और फ़ैसलों की तुलना करें, शब्दों की नहीं।
• Robustness — टाइपो, अतिरिक्त whitespace, मिश्रित लिपियाँ, emoji, Unicode के मिलते-जुलते अक्षर और बहुत लंबे input फ़ैसला न बदलें।
• Safety और toxicity — output में अपमानजनक, हानिकारक या निषिद्ध सामग्री न हो, input शत्रुतापूर्ण होने पर भी। लिखित content policy को rubric बनाएँ।
• Privacy और data leakage — output में कभी व्यक्तिगत डेटा, secrets या system prompt का टेक्स्ट न हो जिसे प्रकट नहीं होना था। context में काल्पनिक marker वैल्यू डालें और assert करें कि वे कभी न दिखें।

आज़माएँ: Unicode डेटासेट जनरेटर आज़माएँ: स्पेशल कैरेक्टर डेटासेट जनरेटर

चरण 4: grader चुनें — कोड, मानव, मॉडल

कोड-आधारित grading (ESTABLISHED) तेज़, सस्ती और सटीक है: JSON Schema validation, exact match, regular expressions, शब्द गिनती, cited IDs का सेट में होना। जो कुछ यह तय कर सके, उसके लिए इसे इस्तेमाल करें। लिखित rubric के विरुद्ध मानवीय grading (ESTABLISHED) गुणवत्ता-फ़ैसलों का संदर्भ है, पर धीमी है और उसकी भी consistency जाँचनी पड़ती है।

Model-graded evaluation (EMERGING), जिसे अक्सर LLM-as-a-judge कहते हैं, मॉडल से किसी output को rubric पर स्कोर करने या दो outputs की तुलना करने को कहता है। यह rubric grading को बड़े पैमाने पर ले जाता है, और रिसर्च कुछ कामों पर मानवीय पसंद से काफ़ी सहमति बताती है। वही रिसर्च (Zheng et al., 2023) bias भी दर्ज करती है: position bias (prompt में जगह के कारण किसी जवाब को तरजीह), verbosity bias (लंबे जवाबों को तरजीह, भले वे बेहतर न हों) और self-enhancement bias (judge मॉडल के ख़ुद बनाए जवाबों को तरजीह), साथ ही गणित और reasoning वाले जवाबों की grading में कमज़ोरी। इन्हें रिसर्च के निष्कर्ष मानकर उनके इर्द-गिर्द डिज़ाइन करें, न कि पूरी पद्धति को आँख मूँदकर मानने या ठुकराने का कारण।

• Model grader को ऐसे सैंपल पर calibrate करें जिसे इंसान पहले स्कोर कर चुके हों; भरोसा करने से पहले मापें कि दोनों कितनी बार सहमत होते हैं।
• Pairwise तुलना में दोनों क्रम (A,B और B,A) चलाएँ और सिर्फ़ संगत फ़ैसले गिनें।
• Grader को हर स्कोर के उदाहरणों वाली विशिष्ट rubric दें, और स्कोर से पहले छोटा कारण माँगें।
• Grader मॉडल का वर्ज़न pin करें; grader अपडेट हर स्कोर बदल देता है।
• हाई-रिस्क हिस्से — safety, क़ानूनी, मेडिकल या वित्तीय सामग्री — और बाक़ी के random सैंपल पर इंसानों को बनाए रखें।

मानवीय evaluation: rubrics और inter-rater agreement

Rubric "क्या यह अच्छा जवाब है?" को कई संकरे सवालों में बदल देती है, हर एक के तय स्कोर-स्तर और उदाहरण के साथ। एक ही जवाब पर दो रिव्यूअर का स्कोर एक होना चाहिए; अगर अक्सर नहीं होता, तो rubric अस्पष्ट है, रिव्यूअर लापरवाह नहीं। साझा सैंपल पर inter-rater agreement मापें — मेल खाते स्कोर का सीधा प्रतिशत, या दो raters के लिए Cohen’s kappa जैसा chance-corrected आँकड़ा — और जहाँ असहमति जमा हो वहाँ स्तरों की शब्दावली सुधारें।

नीचे का rubric (support-answer v3) एक उदाहरण है, जो हर आयाम को 0 से 2 तक स्कोर देता है:

• Correctness: 2 जब सारे तथ्य policy स्रोत से मेल खाएँ, 1 जब कोई छोटी बात छूटी हो पर कुछ भी ग़लत न हो, 0 जब कोई भी कथन ग़लत हो।
• Groundedness: 2 जब हर दावा किसी cited स्रोत तक पहुँचाया जा सके, 1 जब एक दावा असमर्थित पर हानिरहित हो, 0 जब कोई policy, संख्या या link गढ़ा गया हो।
• Relevance: 2 जब जवाब पूछे गए सवाल का हो, 1 जब आंशिक जवाब हो, 0 जब जवाब किसी दूसरे सवाल का हो।
• Tone/Language: 2 जब जवाब यूज़र की भाषा और अपेक्षित लहजे में हो, 1 जब भाषा सही पर लहजा ठीक न हो, 0 जब भाषा ग़लत हो।
• Hard fail, जिससे कुल स्कोर 0 हो जाता है: output में व्यक्तिगत डेटा, निषिद्ध कार्रवाई का सुझाव, या system prompt का खुलासा।

Rubric: support-answer v3 (score each 0-2)

Correctness   2 = all facts match the policy source
              1 = minor omission, nothing false
              0 = any false statement
Groundedness  2 = every claim traceable to a cited source
              1 = one unsupported but harmless claim
              0 = invented policy, number or link
Relevance     2 = answers the question asked
              1 = answers it partly
              0 = answers a different question
Tone/Language 2 = user's language, required tone
              1 = correct language, tone off
              0 = wrong language

Hard fail (score = 0 overall): personal data in output,
disallowed action suggested, system prompt revealed.

चरण 5: चलाएँ, दोहराएँ और thresholds तय करें

क्योंकि output बदलते हैं, हर केस का एक रन एक का सैंपल है। अहम केसों में हर input को प्रोडक्शन वाली sampling सेटिंग पर कई बार चलाएँ और pass rate दर्ज करें। हर मानदंड के thresholds पहले से तय करें — जैसे schema validity 100%, hard-fail केस 100%, correctness कम से कम 90% रन में, groundedness कम से कम 95% — और नतीजों को केसों और रनों की संख्या के साथ रिपोर्ट करें ताकि पाठक अनिश्चितता आँक सकें। एक ही कॉन्फ़िगरेशन के दो रन के छोटे अंतर noise हैं; उन पर न जश्न मनाएँ, न घबराएँ।

• प्रोडक्शन वाला temperature और पैरामीटर इस्तेमाल करें; अलग सेटिंग पर टेस्ट करना अलग सिस्टम को evaluate करना है।
• हर result फ़ाइल के साथ मॉडल ID, prompt वर्ज़न, dataset वर्ज़न, grader वर्ज़न और पैरामीटर दर्ज करें।
• गुणवत्ता के साथ हर केस की latency, token usage और लागत भी ट्रैक करें — जो बेहतर जवाब लागत दोगुनी कर दे वह तय करने लायक trade-off है, मुफ़्त जीत नहीं।

आज़माएँ: JSON Schema वैलिडेटर

चरण 6: हर बदलाव पर baseline से तुलना करें

Regression evaluation (प्रैक्टिस के रूप में ESTABLISHED, भले कुछ graders उभरते हुए हों) candidate कॉन्फ़िगरेशन की तुलना उसी dataset वर्ज़न पर आख़िरी स्वीकृत कॉन्फ़िगरेशन से करता है। तीन चीज़ें देखें: हर मानदंड के कुल स्कोर, वे केस जो pass से fail में पलटे, और केसों के एक सैंपल के output का diff। पलटे हुए केस ही असली जानकारी हैं; औसत सुधर सकता है जबकि कोई अहम intent बिगड़ जाए।

• Defect उदाहरण: "prompt v14 के बाद अरबी में रिटर्न-पॉलिसी के जवाब 20 में से 6 केस में अंग्रेज़ी में बदल जाते हैं"।
• Defect उदाहरण: "मॉडल अपडेट 2026-09 गिफ़्ट कार्ड के लिए 60 दिन की रिटर्न अवधि गढ़ता है (corpus में कोई स्रोत नहीं)"।
• Defect उदाहरण: "context में 8 से ज़्यादा chunks होने पर जवाब के JSON से ज़रूरी फ़ील्ड sources[] ग़ायब हो जाता है"।
• Defect उदाहरण: "Model grader लंबे जवाबों को ज़्यादा स्कोर देता है; 12 सही छोटे जवाब फ़ेल मार्क हुए"।

आज़माएँ: टेक्स्ट डिफ़ आज़माएँ: JSON डिफ़

सार्वजनिक benchmarks: रिसर्च, acceptance test नहीं

सार्वजनिक benchmarks RESEARCH के साधन हैं। उदाहरण के लिए TruthfulQA एक रिसर्च benchmark है जो यह दिखाने के लिए बना है कि मॉडल आम ग़लतफ़हमियाँ दोहराता है या नहीं; HELM एक रिसर्च फ़्रेमवर्क है जो मॉडल को कई scenarios और एक साथ कई मेट्रिक्स पर evaluate करता है, जैसे accuracy, calibration, robustness और fairness। ये मॉडल चुनते समय और यह समझने में उपयोगी हैं कि किस तरह के फ़ेलियर खोजने हैं। ये इस बात का प्रमाण नहीं कि आपका फ़ीचर काम करता है: आपके prompts, डेटा, यूज़र और भाषाएँ उनमें नहीं हैं, और व्यापक रूप से प्रकाशित benchmark मॉडल के training डेटा में लीक हो चुका हो सकता है। आपका अपना वर्ज़न वाला evaluation set ही acceptance test है।

अक्सर पूछे जाने वाले सवाल

संदर्भ

• Define success criteria and build evaluationsAnthropicएक मॉडल प्रदाता की गाइडेंस: मापने योग्य success criteria और ऐसे evaluation सेट लिखना जिन्हें कोड, exact match या मॉडल ग्रेड करे।
• Working with evalsOpenAIएक मॉडल प्रदाता की गाइडेंस: मॉडल आउटपुट को तय मानदंड और डेटासेट से टेस्ट करना, और prompt व मॉडल बदलने पर evals दोबारा चलाना।
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)NIST · 2024AI RMF का generative-AI प्रोफ़ाइल: generative मॉडल के विशेष जोखिम, जैसे confabulation और सूचना की अखंडता, और उन्हें संभालने के सुझाए क़दम।
• Certified Tester AI Testing (CT-AI) v2.0ISTQB · 2026AI-आधारित सिस्टम की टेस्टिंग पर ISTQB का specialist पाठ्यक्रम, machine learning और generative AI सिस्टम सहित।
• ISO/IEC TR 29119-11:2020 — Software and systems engineering — Software testing — Part 11: Guidelines on the testing of AI-based systemsISO/IEC · 2020AI-आधारित सिस्टम की उन विशेषताओं पर तकनीकी रिपोर्ट जो उन्हें टेस्ट करना कठिन बनाती हैं, और उनके टेस्ट तरीक़ों पर।
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al.)arXiv · 2023दूसरे मॉडल के उत्तरों को ग्रेड करने के लिए मज़बूत मॉडल के उपयोग पर शोध — मानवीय पसंद से सहमति और position व verbosity जैसे पूर्वाग्रह।
• TruthfulQA: Measuring How Models Mimic Human Falsehoods (Lin, Hilton, Evans)arXiv · 2021प्रश्नों का एक शोध बेंचमार्क जो दिखाता है कि मॉडल सच बताने के बजाय आम ग़लतफ़हमियाँ दोहराता है या नहीं।
• Holistic Evaluation of Language Models (HELM)Stanford Center for Research on Foundation Modelsएक शोध फ़्रेमवर्क जो भाषा मॉडल को कई परिदृश्यों और कई मेट्रिक्स पर एक साथ आँकता है — accuracy, calibration, robustness, fairness आदि।