मूल्यांकन

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

गहन अध्ययन

AI में evaluation धोखेबाज़ रूप से कठिन है क्योंकि वह चीज़ जिसे आप मापने की कोशिश कर रहे हैं — "क्या यह आउटपुट अच्छा है?" — अक्सर subjective, context-निर्भर, और बहुआयामी है। "quantum entanglement की व्याख्या करें" के लिए एक मॉडल की प्रतिक्रिया सटीक हो सकती है लेकिन audience के लिए बहुत technical, या सुलभ लेकिन थोड़ी ग़लत, या पूरी तरह से सही लेकिन उबाऊ। पारंपरिक software testing में स्पष्ट pass/fail मानदंड हैं। AI evaluation शायद ही कभी ऐसा करती है। यही कारण है कि क्षेत्र ने कई पूरक दृष्टिकोण विकसित किए हैं: व्यापक क्षमता माप के लिए automated benchmarks, गुणवत्ता निर्णय के लिए मानव evaluation, मानव निर्णय के scalable अनुमानों के लिए LLM-as-judge, और संकीर्ण domains के लिए task-specific metrics। कोई एकल दृष्टिकोण पर्याप्त नहीं है। जो टीमें अच्छी तरह से evaluate करती हैं वे उन सभी का परतों में उपयोग करती हैं।

Benchmarks और उनकी सीमाएँ

MMLU, HumanEval, MATH, और GPQA जैसे public benchmarks आपको well-defined कार्यों पर मॉडलों की तुलना करने का एक मानकीकृत तरीका देते हैं। वे एक मॉडल की क्षमताओं का एक मोटा भाव प्राप्त करने और समय के साथ प्रगति को track करने के लिए उपयोगी हैं। लेकिन उनकी गंभीर सीमाएँ हैं जिन्हें आपको उन पर निर्भर रहने से पहले समझने की आवश्यकता है। Benchmark contamination व्यापक है — प्रशिक्षण डेटा अक्सर benchmark प्रश्नों को शामिल करता है, इसलिए उच्च scores क्षमता के बजाय memorization को दर्शा सकते हैं। Benchmark saturation का अर्थ है कि एक बार जब अधिकांश फ्रंटियर मॉडल एक test पर 90% से अधिक score करते हैं, तो यह informative होना बंद हो जाता है। और सबसे मौलिक समस्या यह है कि benchmarks संकीर्ण, well-defined कौशलों का परीक्षण करते हैं, जबकि वास्तविक applications को व्यापक, गन्दे, context-निर्भर reasoning की आवश्यकता होती है। एक मॉडल जो MMLU पर 92% और HumanEval पर 87% score करता है, फिर भी आपके विशिष्ट use case पर भयानक हो सकता है — Symfony controllers लिखना, French में क़ानूनी दस्तावेज़ों का सारांश देना, या आपके विशेष schema के लिए SQL उत्पन्न करना। Benchmarks आपको बताते हैं कि एक मॉडल सामान्य रूप से क्या कर सकता है। आपके अपने evals आपको बताते हैं कि यह आपके लिए क्या कर सकता है।

अपने स्वयं के evals बनाना

आप जो सबसे मूल्यवान evaluation काम कर सकते हैं वह आपके application के लिए विशिष्ट एक test suite बनाना है। 50 से 100 वास्तविक उदाहरणों को इकट्ठा करके शुरू करें कि आपका सिस्टम क्या इनपुट देखेगा, साथ ही एक अच्छा आउटपुट कैसा दिखता है। ये वास्तविक उपयोगकर्ता queries, synthetic edge cases, या adversarial inputs हो सकते हैं जो ज्ञात failure modes को probe करते हैं। हर उदाहरण के लिए, "correct" का अर्थ जितना संभव हो उतना concretely परिभाषित करें — अपेक्षित keywords, आवश्यक संरचना, factual दावे जो मौजूद होने चाहिए या नहीं होने चाहिए, tone मानदंड। फिर evaluation को automate करें: हर उदाहरण के विरुद्ध अपना prompt चलाएँ, आउटपुट को score करें (exact matching, regex, या एक LLM-as-judge का उपयोग करके), और परिणामों को समय के साथ track करें। Braintrust, Langfuse, और Promptfoo जैसे tools इसे आसान बनाते हैं, लेकिन आप इसे एक spreadsheet और एक script के साथ भी बना सकते हैं। बात यह है कि एक repeatable प्रक्रिया हो ताकि जब आप एक prompt बदलते हैं, एक मॉडल swap करते हैं, या अपना retrieval pipeline update करते हैं, तो आप तुरंत देख सकें कि चीज़ें बेहतर हुईं या बदतर।

LLM-as-Judge और मानव evaluation

एक LLM के आउटपुट का मूल्यांकन करने के लिए दूसरे LLM का उपयोग करना — "LLM-as-judge" pattern — scalable evaluation के लिए default दृष्टिकोण बन गया है। आप एक मज़बूत मॉडल (आम तौर पर GPT-4 या Claude) को मूल प्रश्न, मॉडल की प्रतिक्रिया, और एक rubric देते हैं, और इसे accuracy, helpfulness, और safety जैसे मानदंडों पर प्रतिक्रिया को score करने के लिए कहते हैं। यह कई कार्यों के लिए आश्चर्यजनक रूप से अच्छा काम करता है, विशेष रूप से जब आप विस्तृत rubrics और calibration उदाहरण प्रदान करते हैं। लेकिन इसके blind spots हैं: LLM judges लंबी प्रतिक्रियाओं को पसंद करते हैं, वे सूक्ष्म factual errors को miss कर सकते हैं, और वे position bias प्रदर्शित करते हैं (जो भी प्रतिक्रिया pairwise comparison में पहले दिखाई देती है उसे favouring करते हैं)। मानव evaluation गुणवत्ता-संवेदनशील applications के लिए स्वर्ण मानक बना हुआ है। Scale AI और Surge जैसी सेवाएँ trained annotators प्रदान करती हैं, लेकिन यहाँ तक कि informal मानव समीक्षा भी — तीन team members के साथ स्वतंत्र रूप से 50 आउटपुट rate करना — failure modes पकड़ती है जिन्हें automated evaluation miss करती है। सबसे robust evaluation pipelines automated metrics को एक तेज़ filter के रूप में, मध्यम-confidence निर्णयों के लिए LLM-as-judge, और high-stakes या ambiguous मामलों के लिए मानव समीक्षा का उपयोग करती हैं।

Eval mindset

Evaluation का सबसे कठिन हिस्सा technical नहीं है — यह सांस्कृतिक है। टीमें जो शानदार AI उत्पाद ship करती हैं वे evaluation को एक afterthought के बजाय एक first-class इंजीनियरिंग discipline के रूप में मानती हैं। वे prompts लिखने से पहले evals लिखती हैं, उसी तरह जैसे अच्छे developers कोड लिखने से पहले tests लिखते हैं। वे living eval suites बनाए रखती हैं जो production में नए failure modes की खोज करते समय बढ़ती हैं। और वे real-world प्रदर्शन की क़ीमत पर benchmark scores के लिए optimize करने के प्रलोभन का विरोध करती हैं। यदि आपका मॉडल आपके eval suite को aces करता है लेकिन उपयोगकर्ता शिकायत कर रहे हैं, तो आपके evals ग़लत हैं, आपके उपयोगकर्ता नहीं। सबसे अच्छे evaluation frameworks वे हैं जो आपको ईमानदार रखते हैं कि आपका सिस्टम वास्तव में क्या करता है, विशेष रूप से उन मामलों में जहाँ यह विफल होता है।

संबंधित अवधारणाएँ