विषय-सूची

आपने अपने prompts को निखारा, RAG से ज्ञान जोड़ा, और शायद fine-tuning भी की — तो आप कैसे पक्का करेंगे कि यह "सचमुच बेहतर हुआ"? यहीं AI evals (मूल्यांकन) मुख्य भूमिका में आते हैं। 2026 तक मूल्यांकन AI बनाने के लिए इतना ज़रूरी हो गया है कि लोग इसे "infrastructure" कहते हैं।

यह लेख शुरुआती लोगों के लिए स्पष्ट करता है कि AI evals क्या हैं, इनकी ज़रूरत क्यों है, मूल्यांकन के दो तरीके, खूब चर्चित "LLM-as-judge" कैसे काम करता है और इसके खतरे, और इसे व्यवहार में कैसे चलाएँ।

AI EVALS · जो मापेंगे वही सुधार पाएंगे

मापने लायक चीज़ कोड से, और रुचि-आधारित बातें AI से जाँचें

— "ठीक-ठाक लगता है" को एक संख्या में बदलें

📏

मानदंड तय करें

"एक अच्छा आउटपुट" को एक ठोस पैमाने में बदलें।

⚙️

अपने-आप स्कोर करें

कोड या AI से हर बार एक-सा मूल्यांकन करें।

📈

बदलाव पर नज़र रखें

क्या बेहतर हुआ और क्या बिगड़ा, इसे लगातार देखते रहें।

1. AI evals क्या हैं?

AI evals का मतलब है किसी LLM के आउटपुट की गुणवत्ता को व्यवस्थित रूप से मापना। "क्या यह उत्तर सटीक है?" "क्या इसमें hallucinations (गढ़े हुए तथ्य) हैं?" "क्या यह ज़रूरी फ़ॉर्मैट का पालन करता है?" "क्या लहजा उपयुक्त है?" — आप उस पल के अंदाज़े के बजाय एक तय पैमाने पर इन्हें स्कोर करते हैं।

"एक परीक्षा जाँचने" की कल्पना करें। आप छात्र (AI) को एक प्रश्न (input) देते हैं और उसे एक आदर्श उत्तर या rubric के विरुद्ध स्कोर करते हैं। एक बार स्कोर कर पाने पर ही आपको आख़िर दिखता है कि "किस बदलाव ने इसे बेहतर बनाया और किसने बिगाड़ा।" evals के बिना, सुधार महज़ एक अंदाज़ा भर है।

💡 एक पंक्ति में: evals = "एक ऐसा तंत्र जो AI के आउटपुट को स्कोर करता है।" Prompt की छेड़छाड़ और fine-tuning का मतलब तभी है जब उन्हें मापने का कोई पैमाना हो।

2. इनकी ज़रूरत क्यों: अंदाज़े पर शिप न करें

एक आम प्रोग्राम तय होता है — "input A हमेशा output B देगा" — पर AI एक ही input पर भी अलग-अलग नतीजे देता है (यह non-deterministic है), और "अच्छा या बुरा" अक्सर व्यक्तिपरक होता है। इसलिए "मैंने कुछ आज़माए और वे अच्छे लगे, शिप कर दो" जोखिम भरा है। जो थोड़े-से आपको दिख गए वे महज़ संयोग से अच्छे हो सकते हैं।

मूल्यांकन को व्यवस्थित करने से आप यह कर पाते हैं:

  • बदलावों को संख्याओं से परखें: जब आप कोई prompt या मॉडल बदलें, तो स्कोर से तुलना करें
  • Regressions पकड़ें: देखें कि कहीं किसी "सुधार" ने कुछ और तो नहीं तोड़ दिया
  • प्रोडक्शन गुणवत्ता पर नज़र: संचालन के दौरान AI का प्रदर्शन गिरने पर तुरंत भाँप लें

यह spec-driven development के साथ अच्छी तरह जुड़ता है। तय करें कि "क्या बनाना है" (spec) और "जो बनाया उसे मापें" (evals) — दोनों होने पर ही AI विकास अंततः प्रबंधन योग्य बन जाता है।

3. दो तरीके: कोड बनाम LLM-as-judge

मूल्यांकन के मोटे तौर पर दो तरीके हैं। जो यांत्रिक रूप से मापने योग्य है उसे कोड से मापें; जो व्यक्तिपरक है उसका मूल्यांकन AI से कराएँ — यही बँटवारा बुनियादी सिद्धांत है।

CODE-BASED (deterministic)

नियमों से यांत्रिक रूप से जाँचें

  • सटीक मिलान, ज़रूरी फ़ॉर्मैट (JSON आदि)
  • ज़रूरी शब्द मौजूद हो / प्रतिबंधित शब्द से बचे
  • तेज़, सस्ता, हर बार एक-सा नतीजा
  • जहाँ स्पष्ट सही उत्तर हो, वहाँ सर्वोत्तम
LLM-AS-JUDGE (model-graded)

एक AI से दूसरे AI का मूल्यांकन कराएँ

  • Hallucination, प्रासंगिकता, उपयोगिता, लहजा
  • व्यक्तिपरक बातें जिनका कोई एक सही उत्तर नहीं
  • इंसानों से तेज़ और सस्ता, बड़े पैमाने पर
  • पर इसकी आदतों (biases) से सावधान रहें

आम नियम: "जो कोड से माप सकते हैं उसका मूल्यांकन AI से न कराएँ।" कोड मूल्यांकन तेज़, सस्ता और ज़्यादा स्थिर है। LLM-as-judge को उन व्यक्तिपरक बातों के लिए बचाकर रखें जिन्हें जाँचना कोड के लिए मुश्किल है, जैसे कि कोई hallucination है या नहीं।

4. LLM-as-judge कैसे काम करता है

LLM-as-judge का मतलब है किसी शक्तिशाली LLM को "रेफ़री" की तरह इस्तेमाल करके दूसरे AI के आउटपुट को स्कोर करना। आप जज LLM को एक prompt देते हैं जिसमें मानदंड, input और output होता है, और वह एक स्कोर, एक pass/fail, या "कौन-सा बेहतर है" लौटाता है। इसके दो मुख्य तरीके हैं।

Pairwise तुलना

दो उत्तरों को आमने-सामने रखकर पूछें "कौन-सा बेहतर है?" तुलनात्मक रूप से कौन ज़्यादा मज़बूत है, यह आँकने में AI अच्छा है। A/B तुलना के लिए बढ़िया।

एकल-आउटपुट स्कोरिंग

किसी एक उत्तर को rubric के विरुद्ध आँककर उसे एक स्कोर दें। समय के साथ निरपेक्ष गुणवत्ता पर नज़र रखने के लिए अच्छा।

⚠️ मोटी स्कोरिंग ज़्यादा सटीक होती है: बारीक 1–10 स्कोरिंग में AI कमज़ोर है और डगमगाता है। "pass/fail" या "1–3" जैसा मोटा पैमाना असल में ज़्यादा स्थिर नतीजे देता है।

5. खतरा: जज की biases

LLM-as-judge में "रेफ़री की आदतें" होती हैं। इन्हें न जानकर आप स्कोर पर ज़रूरत से ज़्यादा भरोसा कर बैठेंगे और ग़लत सुधार करेंगे। इन तीन बड़ी biases को ध्यान में रखें।

① Verbosity bias

लंबे, ज़्यादा जटिल उत्तरों को ऊँचा स्कोर देने की प्रवृत्ति — पतली सामग्री भी बस लंबाई से फ़ायदा उठा लेती है।

② Position bias

आप उत्तरों को जिस क्रम में रखते हैं (जैसे जो पहले दिखाया गया) उससे फ़ायदा या नुक़सान बन जाता है।

③ Self-preference

ख़ुद के लिखे (एक ही परिवार के मॉडल के) उत्तरों को ऊँचा आँकने की प्रवृत्ति।

इनसे निपटने के उपाय सरल हैं।

  • मूल्यांकनकर्ता के तौर पर अलग मॉडल इस्तेमाल करें: GPT के आउटपुट को GPT से न आँकें। self-preference से बचने के लिए किसी अलग परिवार — Claude, Gemini आदि — से रेफ़रीगिरी कराएँ।
  • क्रम बदलकर दो बार आँकें: दोनों सहमत हों तो नतीजा रखें, टकराएँ तो हटा दें (position-bias नियंत्रण)।
  • rubric में "संक्षिप्तता" डालें: सिर्फ़ "लंबाई से न आँकें" काफ़ी नहीं। एक संक्षिप्तता मानदंड जोड़ें और जज को verbosity पर अंक काटने का निर्देश दें।
  • मानवीय निर्णय के विरुद्ध calibrate करें: किसी व्यक्ति से एक छोटा नमूना आँकवाएँ और मानदंडों को AI के स्कोर से मिलाने के लिए ट्यून करें। यह सबसे असरदार कदम है।

6. व्यवहार में: मूल्यांकन को "infrastructure" मानना

2026 के व्यवहार में, मूल्यांकन एक बार का काम नहीं है — मानक यह है कि इसे तीन स्तरों पर लगातार चलाया जाए ("मूल्यांकन ही infrastructure")।

① हर बदलाव पर तुरंत जाँच

हर कोड बदलाव पर हल्के code-based evals अपने-आप चलाएँ (CI)। ज़ाहिर टूट-फूट को तुरंत रोकें।

② रात्रिकालीन regression टेस्ट

रातभर LLM-as-judge से थोक में गुणवत्ता आँकें। धीमी, रेंगती गिरावट पकड़ें।

③ लगातार प्रोडक्शन निगरानी

लाइव आउटपुट पर नज़र रखें और गुणवत्ता गिरने पर अलर्ट करें। असली उपयोगकर्ताओं पर असर सीमित रखें।

उपकरण भी परिपक्व हो चुके हैं। हल्के CI रन के लिए DeepEval (जो pytest जैसा लगता है) या Promptfoo; ख़ासतौर पर RAG के लिए RAGAS (faithfulness, प्रासंगिकता आदि मापना)। मानवीय समीक्षा, dashboards और प्रोडक्शन निगरानी के लिए Braintrust, LangSmith और Arize जैसे platforms। व्यवहार में, "एक हल्के CI उपकरण" को "एक निगरानी platform" के साथ जोड़ना ही आम चलन है। यही मूल्यांकन-तंत्र AI agents बनाने में भी गुणवत्ता का आधार बनता है।

※ उपकरणों के नाम और तरीके विभिन्न गाइड और प्रकटीकरणों से लिए गए हैं (जून 2026 तक)। सर्वोत्तम सेटअप टीम के आकार और उपयोग-स्थिति के अनुसार बदलता है।

सारांश

AI evals पर तीन मुख्य बातें।

  • ये क्या हैं: एक तंत्र जो LLM के आउटपुट को स्कोर करता है, सुधार को "अंदाज़े" से "संख्याओं" में बदल देता है। AI विकास का एक अनिवार्य कदम।
  • दो तरीके: deterministic बातों के लिए code evals, व्यक्तिपरक बातों के लिए LLM-as-judge. जो कुछ कोड माप सकता है उसे कोड से ही मापें।
  • सावधानी: LLM-as-judge में verbosity, position और self-preference biases होती हैं। इनसे एक अलग मूल्यांकनकर्ता मॉडल, एक मोटे पैमाने और मानवीय calibration से निपटें।

शुरुआत अपने AI से "अच्छे आउटपुट" और "बुरे आउटपुट" के 10-10 इकट्ठा करके और उन्हें सरल मानदंडों पर स्कोर करके करें। वही आपका पहला पैमाना बन जाता है। AI को सुधारने की पूरी तस्वीर के लिए इसके साथ fine-tuning और context engineering भी पढ़ें।

FAQ

Q. क्या किसी AI को आँकते AI पर सचमुच भरोसा किया जा सकता है?

A. आँख मूँदकर नहीं। verbosity, position और self-preference biases के कारण किसी अलग परिवार के मॉडल से आँकना और एक छोटे मानव-आँके नमूने के विरुद्ध calibrate करना ज़रूरी है। एक बार calibrate हो जाने पर यह इंसान-जैसी सटीकता से बड़े पैमाने पर चलता है।

Q. मुझे कितने eval उदाहरण चाहिए?

A. आप बस कुछ दर्जन से ठीक-ठाक शुरुआत कर सकते हैं। चाल यह है कि असली अच्छे और बुरे उदाहरण इकट्ठा करें और पहले एक छोटा eval सेट बनाएँ। पूर्णता का लक्ष्य रखने के बजाय, चलते-चलते मानदंडों को बढ़ाते जाएँ — यह ज़्यादा व्यावहारिक है।

Q. code evals या LLM-as-judge — मुझे कौन-सा इस्तेमाल करना चाहिए?

A. दोनों। जो यांत्रिक रूप से मापने योग्य है, जैसे फ़ॉर्मैट और ज़रूरी शब्द, उसके लिए code evals; और hallucination तथा लहजे जैसी व्यक्तिपरक बातों के लिए LLM-as-judge इस्तेमाल करें। जो आप deterministic ढंग से माप सकते हैं, उसका मूल्यांकन AI से कराने की कोई ज़रूरत नहीं।

Q. क्या अकेले काम करने वाले डेवलपर्स को evals की ज़रूरत है?

A. पैमाना चाहे जो हो, ये मदद करते हैं। "एक अच्छे आउटपुट का मानक" छोटा-सा भी हो तो भी आप बता सकते हैं कि कोई prompt या मॉडल बदलाव सुधार है या regression। बस कुछ उदाहरणों को हाथ से आँकना भी एक उपयोगी शुरुआत है।