Agent Evals क्या हैं? परिणाम और Trajectory दोनों मापना
Agent evals यह व्यवस्थित रूप से मापने की प्रक्रिया है कि एक agent—जो टूल्स का उपयोग करता है और किसी लक्ष्य तक पहुँचने के लिए कई चरण लेता है—सचमुच अपने कार्य पूरे कर सकता है या नहीं। ये LLM evals का विकास हैं, जो लक्ष्य को "एक आउटपुट" से बढ़ाकर "क्रियाओं का एक अनुक्रम" बना देते हैं। चूँकि एक agent योजना बनाता है, टूल्स कॉल करता है, और स्टेट अपडेट करता है, इसलिए केवल अंतिम आउटपुट पर्याप्त नहीं है; Google कहता है कि आपको agent की क्रियाओं के पीछे का "क्यों" समझना होगा और मूल्यांकन को final response तथा trajectory में बाँटता है। पाँच आयाम हैं: outcome (कार्य की सफलता, अंतिम स्टेट से आँकी गई—क्या DB में आरक्षण मौजूद है, न कि "मैंने बुक कर दिया" कथन), trajectory (उचित चरण, सही क्रम में सही टूल्स), टूल-उपयोग की शुद्धता (सही टूल और आर्गुमेंट, फ़ंक्शन नाम व प्रकार जाँचना), दक्षता (चरण, टोकन, लागत, latency—अक्सर observability संकेत जो मूल्यांकन में लाए जाते हैं), और अंतिम-प्रतिक्रिया की गुणवत्ता (LLM-as-judge या रूब्रिक से)। ग्रेडर हैं code (तेज़/सस्ता/पुनरुत्पाद्य पर भंगुर), LLM-as-judge (लचीला पर अनिर्धारणीय और कैलिब्रेशन चाहिए), और human (स्वर्ण-मानक पर महँगा—हो सके तो टालें)। Anthropic पथ नहीं, बल्कि परिणाम को ग्रेड करने की सलाह देता है: रटी-रटाई trajectory मैचिंग "बहुत कठोर और भंगुर" है क्योंकि agents वैध विकल्प खोज लेते हैं, जबकि Google और Microsoft विफलताओं के निदान के लिए trajectory-match मेट्रिक्स देते हैं। अनोखी मुश्किलें हैं अनिर्धारणीयता (pass^k), संयोजी त्रुटियाँ (p^t), reward hacking (DeepMind का रोबोट आर्म पकड़ का नाटक करते हुए), और पुराने या contaminated eval सेट। Anthropic के अनुसार व्यावहारिक रणनीति: 20-50 प्रोडक्शन विफलताओं को टेस्ट केस में बदलें, CI में स्वचालित ग्रेडिंग चलाएँ, capability और regression evals अलग करें, और इन्हें जल्दी लिखें। SWE-bench, tau-bench, WebArena, GAIA, OSWorld, और BFCL जैसे बेंचमार्क उपयोगी संदर्भ हैं (स्कोर वर्शन के साथ बदलते हैं, इसलिए उन्हें अंकित मूल्य पर न लें)। आधिकारिक जानकारी पर आधारित, अनिश्चितताओं को चिह्नित करते हुए।
