मुख्य कंटेंट तक स्किप करें

अपने Claude एजेंट का मूल्यांकन करें (Evals)

उन्नत

आपने एक प्रॉम्प्ट में बदलाव किया और यह बेहतर लगता है — पर क्या वाकई है? evals (मूल्यांकन) के बिना आप अंधेरे में उड़ रहे हैं: हर बदलाव एक सिक्का उछालने जैसा है, और आपको पता तब चलता है कि कुछ टूट गया जब एक गुस्साया उपयोगकर्ता बताता है, कोई टेस्ट नहीं। Evals "अंदाज़े" को एक ऐसे आँकड़े में बदल देते हैं जिस पर आप भरोसा कर सकते हैं, जिसका बचाव कर सकते हैं, और जिसे समय के साथ देख सकते हैं। यही एक चीज़ है जो शौकिया प्रॉम्प्ट को प्रोडक्शन-ग्रेड Claude काम से सबसे ज़्यादा अलग करती है।

What you'll learn
  • "मुझे तो अच्छा लगता है" एक टेस्ट क्यों नहीं है — और इसके बजाय क्या मापें
  • असली विफलताओं (नीचे-से-ऊपर) से एक golden dataset बनाएँ, काल्पनिक विफलताओं से नहीं
  • जहाँ कोड से स्कोर कर सकें वहाँ कोड से, और जहाँ न कर सकें वहाँ LLM-as-judge से
  • evals को CI में जोड़ें ताकि कोई प्रॉम्प्ट या मॉडल बदलाव कभी चुपचाप रिग्रेस न कर सके

मानसिकता: मापें, अंदाज़ा न लगाएँ​

तीन नियम जो आपको बचाते हैं:

  • नीचे-से-ऊपर, ऊपर-से-नीचे को हरा देता है। पहले असली विफलताएँ इकट्ठा करें, फिर उन्हें पकड़ने के लिए मेट्रिक डिज़ाइन करें। असली टूट-फूट से बना eval असली टूट-फूट की भविष्यवाणी करता है; व्हाइटबोर्ड पर गढ़ा गया eval ज़्यादातर आपकी कल्पना को मापता है।
  • एक आँकड़ा जिसे आप दोबारा चला सकें। एक eval दोहराने योग्य होता है: समान इनपुट → तुलनीय स्कोर। यही वह चीज़ है जो आपको प्रॉम्प्ट v1 बनाम v2, या claude-haiku-4-5 बनाम claude-sonnet-4-6 की ईमानदारी से तुलना करने देती है।
  • चलाने में सस्ता, बार-बार चलाएँ। अगर इसमें किसी इंसान की पूरी दोपहर लग जाए, तो यह कभी होगा नहीं। इसे स्वचालित करें।

एक golden dataset बनाएँ (नीचे-से-ऊपर)​

आपका golden dataset हर eval का दिल होता है — ज्ञात-अच्छी अपेक्षाओं वाले इनपुट का एक संक्षेपित सेट।

Guided walkthrough1 of 4
  1. असल खराब आउटपुट से शुरू करें: production traces, बग रिपोर्ट, सपोर्ट टिकट। यही वे मामले हैं जो मायने रखते हैं।

स्कोर करें: पहले कोड, फिर judge​

सबसे सस्ती भरोसेमंद जाँच को पहले अपनाएँ।

  • प्रोग्रामेटिक (नियतात्मक) जाँचें — इन्हें वहाँ इस्तेमाल करें जहाँ उत्तर की कोई संरचना हो: सटीक/कीवर्ड मैच, "इस schema के विरुद्ध valid JSON", "क्या इसने सही args के साथ सही टूल कॉल किया", "N tokens से कम / X ms से कम"। तेज़, मुफ़्त, और कभी अस्थिर नहीं।
  • LLM-as-judge — उन धुंधले आयामों (सहायकता, लहज़ा, किसी स्रोत के प्रति निष्ठा) के लिए जो कोड से नहीं नापे जा सकते। judge को एक रूब्रिक दें, अंदाज़ा नहीं, और उस पर भरोसा करने से पहले उसे मानव लेबल के विरुद्ध कैलिब्रेट करें।

:::warning judges में पूर्वाग्रह होते हैं LLM judges लंबे उत्तरों की ओर झुकते हैं (verbosity bias) और जो भी विकल्प पहले दिखाया जाए उसकी ओर (position bias)। बचाव: एक सख़्त रूब्रिक, निरपेक्ष स्कोरिंग के बजाय जोड़ी-वार तुलना, उत्तरों का क्रम बदलना, और judge को एक मानव-लेबल वाले हिस्से के विरुद्ध फिर से जाँचना। एक judge एक परत है, पूरा टेस्ट नहीं। :::

LLM-as-judge रूब्रिक (शुरुआती)

You are a strict grader. You are given a QUESTION, a REFERENCE answer, and a MODEL answer.
Score the MODEL answer from 1-5 on (a) faithfulness to the reference and (b) helpfulness.
Output ONLY JSON, nothing else: {"score": <1-5>, "reason": "<one short sentence>"}

QUESTION: {{question}}
REFERENCE: {{reference}}
MODEL: {{model_answer}}

एजेंटों के लिए, trajectory का भी परीक्षण करें​

एक एजेंट सही अंतिम उत्तर तक गलत तरीके से पहुँच सकता है — लूप में फँसकर, किसी विनाशकारी टूल को कॉल करके, या आपका बजट जलाकर। इसलिए सिर्फ़ मंज़िल नहीं, रास्ते का मूल्यांकन करें: क्या इसने सही टूल कॉल किए, एक समझदार क्रम में, बिना लूप के, बजट के भीतर? टूल-कॉल शुद्धता और trajectory जाँचें ऐसी विफलताएँ पकड़ती हैं जो केवल-अंतिम-उत्तर वाला eval कभी नहीं देख पाता।

इसे CI में जोड़ें​

यहीं evals फ़ायदा देते हैं: रिग्रेशन को मर्ज करना असंभव बना दें।

Guided walkthrough1 of 3
  1. जहाँ संभव हो प्रोग्रामेटिक रूप से स्कोर करें; बाकी पर judge चलाएँ।
Eval शब्दावली
Term shown.
1 / 4

खुद को परखें

0/3
  1. किसी eval को स्कोर करने के लिए सबसे भरोसेमंद पहली पसंद क्या है?
  2. एक golden dataset के मामले ज़्यादातर कहाँ से आने चाहिए?
  3. एक एजेंट के लिए, अंतिम उत्तर के अलावा आपको किसका मूल्यांकन करना चाहिए?
Key takeaways
  • कोई eval नहीं = सिर्फ़ अंदाज़े पर शिप करना। किसी प्रॉम्प्ट या एजेंट पर भरोसा करने से पहले एक बनाएँ।
  • Golden dataset असली विफलताओं से; इसे हर हफ़्ते नए रिग्रेशन से बढ़ाएँ।
  • पहले कोड-आधारित जाँचें; धुंधले हिस्सों के लिए LLM-as-judge (रूब्रिक के साथ, कैलिब्रेटेड)।
  • एजेंटों के लिए, सिर्फ़ आउटपुट नहीं, trajectory को ग्रेड करें।
  • इसे CI में चलाएँ और गिरावट पर बिल्ड फेल करें — इसी तरह गुणवत्ता का रिग्रेस होना रुकता है।

स्रोत और आगे पढ़ने के लिए​

आगे​