विषय-सूची
आपने एक multi-agent सिस्टम जोड़ा, उसे टूल्स दिए, और उसे Agent SDK के साथ चलाया—तो आप यह कैसे मापेंगे कि agent सचमुच अपना काम कर रहा है या नहीं? किसी एक आउटपुट के लिए आप उसे AI evals से स्कोर कर सकते हैं। लेकिन एक agent कई चरणों पर योजना बनाता है, टूल्स को कॉल करता है, और स्टेट के साथ कार्य करता है। भले ही आख़िरी वाक्य सही दिखे, वह रास्ते में किसी ख़तरनाक पुल को पार कर चुका हो सकता है। यहीं पर agent evals केंद्र में आ जाते हैं।
यह लेख आधिकारिक जानकारी के आधार पर बताता है कि agent evals क्या हैं, वे LLM evals से कैसे अलग हैं, क्या मापें (5 आयाम), कैसे ग्रेड करें (3 ग्रेडर), इनकी अनोखी मुश्किलें, और व्यावहारिक वर्कफ़्लो साथ ही बेंचमार्क। मुख्य बिंदु पहले। ① Agent evals केवल "अंतिम आउटपुट" नहीं बल्कि क्रियाओं की "trajectory" को मापते हैं। ② Anthropic पथ नहीं, बल्कि परिणाम (अंतिम स्टेट) को ग्रेड करने की सलाह देता है—क्योंकि रटी-रटाई चरण-जाँच भंगुर होती है। ③ असली विफलताओं से निकाले गए 20–50 कार्यों के एक छोटे eval सेट से शुरुआत करें, और स्वचालित ग्रेडिंग चलाएँ।
"अंतिम उत्तर" और "चला हुआ रास्ता" दोनों मापें
— केवल आउटपुट evals काफ़ी नहीं; agents बहु-चरणीय, टूल-उपयोगी, स्टेटफ़ुल होते हैं
Anthropic पथ के बजाय परिणाम को ग्रेड करने की सलाह देता है—लेकिन trajectory आपको बताती है कि वह क्यों विफल हुआ। सही काम के लिए दोनों का उपयोग करें।
1. Agent Evals क्या हैं?
Agent evals यह व्यवस्थित रूप से मापने की प्रक्रिया है कि एक "agent"—जो टूल्स का उपयोग करता है और किसी लक्ष्य तक पहुँचने के लिए कई चरण लेता है—सचमुच अपने कार्य पूरे कर सकता है या नहीं। ये LLM evals का एक विकास हैं, जो किसी एकल प्रॉम्प्ट की गुणवत्ता आँकते हैं; लक्ष्य "एक आउटपुट" से बढ़कर "क्रियाओं का एक अनुक्रम" बन जाता है।
यह क्यों मायने रखता है: agent evals पर अपनी गाइड में Anthropic बताता है कि "जितना अधिक आप प्रतीक्षा करते हैं, evals बनाना उतना ही कठिन होता जाता है। शुरुआत में, उत्पाद आवश्यकताएँ स्वाभाविक रूप से टेस्ट केस में बदल जाती हैं," और सलाह देता है कि "असली विफलताओं से निकाले गए 20–50 सरल कार्य एक शानदार शुरुआत हैं।" दूसरे शब्दों में, agent evals "लगता है काम कर रहा है" को पुनरुत्पाद्य संख्याओं में बदल देते हैं। यह AI observability (रन को देखना) के साथ जुड़ता है—जिन ट्रेस को आप देखते हैं वे मूल्यांकन की सामग्री बन जाते हैं।
2. ये LLM evals से क्यों अलग हैं (आउटपुट बनाम trajectory)
पारंपरिक LLM evals मूलतः "इनपुट → एक आउटपुट" को स्कोर करते हैं। लेकिन एक agent योजना बनाता है, टूल्स कॉल करता है, परिणामों को देखता है, अगली चाल तय करता है, और स्टेट अपडेट करता है। इसलिए केवल अंतिम आउटपुट देखना पर्याप्त नहीं है। Google भी कहता है कि "केवल आउटपुट जाँचना पर्याप्त नहीं है; हमें agent की क्रियाओं के पीछे का 'क्यों' समझने की ज़रूरत है," और मूल्यांकन को दो परिवारों में बाँटता है: "final response" और "trajectory।" Microsoft भी कहता है कि आपको "न केवल अंतिम आउटपुट, बल्कि प्रत्येक चरण की गुणवत्ता और दक्षता का भी मूल्यांकन" करना चाहिए, और इसे system (end-to-end) और process (step-by-step) मूल्यांकन में विभाजित करता है।
💡 मूल विचार: एक "सही अंतिम उत्तर" एक टूटी हुई प्रक्रिया को छिपा सकता है। इसके विपरीत, उत्तर सही हो सकता है पर वहाँ तक क़िस्मत, संयोग या किसी ख़तरनाक शॉर्टकट से पहुँचा गया हो। इसलिए agents के लिए आप "परिणाम" और "प्रक्रिया" दोनों को देखते हैं। एकल-आउटपुट मूल्यांकन और LLM-as-judge की बुनियादी बातों के लिए, AI evals लेख देखें।
3. क्या मापें: 5 आयाम
यहाँ agent मूल्यांकन के लिए आमतौर पर इस्तेमाल किए जाने वाले पाँच नज़रिए हैं।
क्या वह लक्ष्य तक पहुँचा? अंतिम स्टेट से आँकें—क्या DB में कोई आरक्षण मौजूद है—न कि "मैंने बुक कर दिया" कथन से।
क्या उसने उचित चरण लिए? क्या उसने सही क्रम और संख्या में सही टूल्स इस्तेमाल किए? कोई बेकार चक्कर या ख़तरनाक चालें?
क्या उसने सही टूल चुना और सही आर्गुमेंट पास किए? फ़ंक्शन नाम, आर्गुमेंट प्रकार और मान जाँचें (और अनावश्यक कॉल का पता लगाएँ)।
कितने चरण, टोकन, डॉलर और सेकंड? यदि लागत बेतहाशा बढ़ जाए तो सही उत्तर भी अव्यावहारिक है। इसे देखे गए मेट्रिक्स से जोड़ना ज़रूरी है।
क्या आउटपुट प्रासंगिक, सटीक और पूर्ण है? ओपन-एंडेड सामग्री को LLM-as-judge या किसी रूब्रिक से स्कोर करें।
ध्यान दें: 4. दक्षता (टोकन, लागत, latency) को किसी एक वेंडर ने औपचारिक रूप से "eval मेट्रिक" के रूप में संहिताबद्ध नहीं किया है; व्यवहार में यह अक्सर observability संकेत होते हैं जिन्हें मूल्यांकन में लाया जाता है। फिर भी, लूप में फँसकर बेक़ाबू हो जाने वाले agent को रोकने के लिए यह एक आवश्यक आयाम है।
4. कैसे ग्रेड करें: 3 ग्रेडर और "परिणाम बनाम पथ"
मोटे तौर पर तीन तरह के ग्रेडर होते हैं। Anthropic के ढाँचे के अनुसार, हर एक के अपने ट्रेड-ऑफ़ हैं।
| ग्रेडर | ताक़त | कमज़ोरियाँ |
|---|---|---|
| Code (प्रोग्रामेटिक) | तेज़, सस्ता, वस्तुनिष्ठ, पुनरुत्पाद्य | वैध विविधताओं / विकल्पों के प्रति भंगुर |
| LLM-as-judge (मॉडल) | लचीला, स्केलेबल, बारीकियों को पकड़ता है | अनिर्धारणीय, अधिक महँगा, मनुष्यों के साथ कैलिब्रेशन चाहिए |
| Human (मानव) | गुणवत्ता का स्वर्ण-मानक | महँगा, धीमा (हो सके तो टालें) |
मानक रणनीति: जो code से ग्रेड हो सके वह करें, केवल व्यक्तिपरक, ओपन-एंडेड हिस्सों को LLM-as-judge के रूप में किसी अलग मॉडल को सौंपें, और प्रमुख बिंदुओं पर स्पॉट-चेक के लिए मनुष्यों का उपयोग करें। LLM-as-judge का डिज़ाइन (विस्तृत रूब्रिक, असतत आउटपुट, judge bias) LLM evals लेख में गहराई से शामिल है।
रटी-रटाई "trajectory मैचिंग" भंगुर होती है
तो आप trajectory को कैसे ग्रेड करें? यहाँ Anthropic एक स्पष्ट रुख़ अपनाता है: "एक आम प्रवृत्ति यह जाँचने की होती है कि agents ने सही क्रम में टूल कॉल जैसे बहुत विशिष्ट चरणों का पालन किया या नहीं। हमने पाया है कि यह तरीक़ा बहुत कठोर है और अत्यधिक भंगुर टेस्ट बनाता है, क्योंकि agents नियमित रूप से ऐसे वैध तरीक़े खोज लेते हैं जिनकी eval डिज़ाइनर ने कल्पना नहीं की थी। रचनात्मकता को अनावश्यक रूप से दंडित न करने के लिए, अक्सर बेहतर यह होता है कि agent ने जो उत्पन्न किया उसे ग्रेड करें, न कि उसने जो पथ लिया।" उदाहरण के लिए, फ़्लाइट बुकिंग में आप अंतिम स्टेट के रूप में मापते हैं कि क्या पर्यावरण के SQL DB में सचमुच कोई आरक्षण मौजूद है—न कि "मैंने बुक कर दिया" कथन को।
वहीं, Google और Microsoft औपचारिक मेट्रिक्स के रूप में trajectory-match की डिग्रियाँ (exact / in-order / any-order, आदि) पेश करते हैं। दोनों परस्पर विरोधी नहीं हैं—trajectory evals "वह क्यों विफल हुआ" का निदान करने में अच्छे हैं, और outcome evals वैध रचनात्मकता को दंडित करने से बचाते हैं। व्यवहार में, यथार्थवादी बीच का रास्ता यह है कि सख़्त exact match से बचें और इसे ढीला करके एक key-action जाँच बनाएँ: "क्या महत्वपूर्ण टूल्स कॉल किए गए थे?"
5. Agent evals की अपनी ख़ास समस्याएँ
Agent evals में ऐसी कठिनाइयाँ होती हैं जो एकल-आउटपुट मूल्यांकन में नहीं होतीं।
- अनिर्धारणीयता (एक ही इनपुट अलग-अलग पथ लेता है): एक सफलता का मतलब यह नहीं कि वह दोहराई जाएगी। आपको विश्वसनीयता मेट्रिक्स चाहिए जैसे क्या यह सभी k रन में सफल होता है (pass^k)। τ-bench पेपर बताता है कि "जैसे-जैसे k बढ़ता है, मॉडल काफ़ी गिरते हैं, जिससे उनकी अविश्वसनीयता उजागर होती है" (आँकड़े समय-विशिष्ट हैं)।
- संयोजी त्रुटियाँ (compounding errors): यदि कोई एकल चरण p प्रायिकता से सफल होता है, तो t चरण लगभग pt पर सफल होते हैं। शृंखला जितनी लंबी होगी, वह उतनी ही तेज़ी से ढहती है—यही कारण है कि long-horizon कार्यों में सफलता तेज़ी से गिरती है।
- Reward hacking / specification gaming: ऐसा व्यवहार जो असली लक्ष्य हासिल किए बिना ग्रेडर के अक्षर का पालन करता है। DeepMind के उदाहरण में, एक रोबोट आर्म ने ख़ुद को कैमरे और वस्तु के बीच रख लिया, जिससे मूल्यांकनकर्ता धोखा खा गए कि उसने वस्तु को पकड़ लिया है, जबकि उसने नहीं पकड़ा था। "सही दिखता है पर ख़तरनाक पथ" को पकड़ने के लिए trajectory और साइड इफ़ेक्ट का मूल्यांकन ज़रूरी है।
- Eval सेट का पुराना पड़ना / contamination: जब कोई बेंचमार्क ट्रेनिंग डेटा में लीक हो जाता है (contamination), तो स्कोर असली क्षमता को परिलक्षित करना बंद कर देते हैं। जैसे-जैसे agent परिपक्व होता है, आपको अपने regression evals को अपडेट करते रहना पड़ता है।
"ख़तरनाक पथ" की समस्या AI guardrails के साथ निरंतर जुड़ी है। केवल अंतिम उत्तर देखने वाला eval इन जालों के ठीक बग़ल से गुज़र जाता है।
6. वर्कफ़्लो और बेंचमार्क
Anthropic की सिफ़ारिशों पर आधारित होकर, वर्कफ़्लो सरल है।
- छोटे से शुरू करें, असली विफलताओं से: आपको सैकड़ों की ज़रूरत नहीं। प्रोडक्शन में हुई 20–50 विफलताओं को टेस्ट केस में बदलें।
- स्वचालित ग्रेडिंग चलाएँ: पहले code, केवल ओपन-एंडेड हिस्सों के लिए LLM-as-judge। हाथ से ग्रेड की गुणवत्ता पर मात्रा को प्राथमिकता दें।
- दो प्रकार अलग करें: capability evals (यह किसमें अच्छा है?) और regression evals (क्या यह अब भी वही कर पाता है जो पहले करता था?)।
- इसे एक जीवनचक्र पर रखें: ① लॉन्च-पूर्व स्वचालित evals (CI में बने हुए) → ② प्रोडक्शन मॉनिटरिंग → ③ A/B टेस्टिंग → ④ यूज़र फ़ीडबैक और ट्रेस समीक्षा, परत-दर-परत।
- इन्हें जल्दी लिखें: जितना अधिक आप प्रतीक्षा करते हैं, evals बनाना उतना ही कठिन होता जाता है।
प्रसिद्ध agent बेंचमार्क भी अपने ख़ुद के evals बनाने के लिए उपयोगी संदर्भ हैं (कुंजी यह पढ़ना है कि "हर एक क्या मापता है"; स्कोर मॉडल और वर्शन के साथ बदलते हैं, इसलिए उन्हें अंकित मूल्य पर न लें)।
| बेंचमार्क | यह क्या मापता है |
|---|---|
| SWE-bench / Verified | असली GitHub इश्यू को पैच से हल करना, टेस्ट सूट द्वारा pass/fail ग्रेड किया गया (execution-based) |
| τ-bench / τ²-bench | रिटेल, एयरलाइन आदि में multi-turn tool×user संवाद + नीति-पालन; अंतिम DB स्टेट पर ग्रेड किया गया |
| WebArena | यथार्थवादी साइट प्रतिकृतियों पर स्वायत्त वेब-संचालन कार्य की पूर्ति |
| GAIA | सामान्य-सहायक कार्य जो मनुष्यों के लिए आसान पर AI के लिए कठिन (reasoning + टूल्स + ब्राउज़िंग) |
| OSWorld | असली OS पर GUI संचालित करते हुए computer use, execution-based मूल्यांकन |
| BFCL | function/tool calling की सटीकता (फ़ंक्शन नाम, आर्गुमेंट संरचना, निष्पादनयोग्यता) |
टूलिंग की बात करें तो, LangSmith, Braintrust, DeepEval, और Arize Phoenix trajectory और tool-call मूल्यांकन का समर्थन करते हैं। अधिकांश traces पर आधारित होते हैं, और step, run, तथा dataset स्तरों पर स्कोर करते हैं। ध्यान दें कि Claude Managed Agents में outcomes-based ग्रेडिंग—जहाँ एक अलग ग्रेडर आपके रूब्रिक के विरुद्ध मूल्यांकन करता है—पहले से बनी हुई आती है।
सारांश
Agent evals यह मापने की प्रक्रिया है कि एक टूल-उपयोगी, बहु-चरणीय agent सचमुच अपने कार्य पूरे कर सकता है या नहीं। एकल आउटपुट देखने वाले LLM evals के विपरीत, वे "अंतिम उत्तर (outcome)" और "चला हुआ रास्ता (trajectory)" दोनों की जाँच करते हैं। आयाम हैं ① outcome ② trajectory ③ टूल-उपयोग ④ दक्षता ⑤ अंतिम गुणवत्ता। code → LLM-as-judge → human से ग्रेड करें, और Anthropic "पथ नहीं, बल्कि परिणाम (अंतिम स्टेट) को ग्रेड करें" की सलाह देता है (रटी-रटाई चरण-जाँच भंगुर होती है)।
इनकी अनोखी मुश्किलें हैं अनिर्धारणीयता (pass^k), संयोजी त्रुटियाँ, reward hacking, और पुराने पड़ चुके eval सेट। व्यवहार में, मानक रणनीति यह है कि असली विफलताओं से 20–50 केस के साथ छोटे से शुरू करें, CI में स्वचालित ग्रेडिंग चलाएँ, capability और regression evals को अलग करें, और इन्हें जल्दी लिखें। संबंधित: AI evals, observability, multi-agent सिस्टम कैसे बनाएँ, Managed Agents।
FAQ
Q. Agent evals क्या हैं?
A. यह व्यवस्थित रूप से मापने की प्रक्रिया कि एक टूल-उपयोगी, बहु-चरणीय agent सचमुच अपने कार्य पूरे कर सकता है या नहीं। ये LLM evals का एक विकास हैं, जो किसी एकल प्रॉम्प्ट को स्कोर करते हैं; लक्ष्य "एक आउटपुट" से बढ़कर "क्रियाओं का एक अनुक्रम" बन जाता है। इसकी पहचान केवल अंतिम उत्तर नहीं, बल्कि वहाँ तक पहुँचाने वाली trajectory (कौन से टूल्स कैसे कॉल किए गए) को देखना है।
Q. ये सामान्य LLM evals से कैसे अलग हैं?
A. इसमें कि आप "एक आउटपुट" देखते हैं या "क्रियाओं की एक शृंखला।" चूँकि एक agent योजना बनाता है, टूल्स कॉल करता है, और स्टेट अपडेट करता है, इसलिए केवल अंतिम आउटपुट पर्याप्त नहीं है। एक सही उत्तर एक टूटी हुई प्रक्रिया को छिपा सकता है, और एक सही उत्तर किसी ख़तरनाक शॉर्टकट से आया हो सकता है। इसलिए आप outcome (अंतिम स्टेट) और trajectory (प्रक्रिया) दोनों का मूल्यांकन करते हैं।
Q. मुझे क्या मापना चाहिए?
A. सामान्य पाँच आयाम: ① outcome (कार्य की सफलता = क्या अंतिम स्टेट लक्ष्य से मेल खाता है?) ② trajectory (उचित चरण?) ③ टूल-उपयोग की शुद्धता (सही टूल, सही आर्गुमेंट?) ④ दक्षता (चरण, टोकन, लागत, latency) ⑤ अंतिम-प्रतिक्रिया की गुणवत्ता (प्रासंगिक, सटीक, पूर्ण?)। आयाम 4 observability संकेत लाता है और बेक़ाबू रनों को रोकने के लिए महत्वपूर्ण है।
Q. क्या मुझे trajectory (चरण) को exact match के लिए जाँचना चाहिए?
A. नहीं—सख़्त exact match भंगुर होता है। Anthropic सलाह देता है: "यह जाँचना कि टूल कॉल सही क्रम में हुए, बहुत कठोर और भंगुर है; agents वैध विकल्प खोज लेते हैं, इसलिए पथ नहीं, बल्कि परिणाम को ग्रेड करना बेहतर है।" व्यवहार में, exact match से बचें और इसे ढीला करके एक key-action जाँच बनाएँ: "क्या महत्वपूर्ण टूल्स कॉल किए गए थे?" उस के बावजूद, trajectory वह क्यों विफल हुआ का निदान करने में उपयोगी है, इसलिए हर एक का उपयोग वहाँ करें जहाँ वह फ़िट बैठता है।
Q. मैं शुरुआत कैसे करूँ?
A. 20–50 प्रोडक्शन विफलताओं को टेस्ट केस में बदलने से शुरुआत करें। जैसा Anthropic कहता है, "आपको सैकड़ों की ज़रूरत नहीं; असली विफलताओं से निकाले गए 20–50 सरल कार्य एक शानदार शुरुआत हैं।" स्वचालित रूप से ग्रेड करें—जो code माप सकता है उसके लिए code, और केवल ओपन-एंडेड हिस्सों के लिए एक अलग-मॉडल LLM-as-judge—और regressions पकड़ने के लिए इसे CI में रखें। capability evals (यह किसमें अच्छा है) को regression evals (जो काम करता था उसे बनाए रखना) से अलग करें, और अपने evals जल्दी लिखें।
