AI Agent चल रहा है: यह साबित कैसे करें कि यह प्रोडक्शन के लिए तैयार है?

डेमो चलाना डिलीवरी पूरी करने जैसा नहीं है। एजेंट के बारे में सबसे खतरनाक बात यह नहीं है कि वह एरर रिपोर्ट करता है, बल्कि यह है कि जब उसने वास्तव में गलत किया हो, तब भी वह "पूर्ण" दिखाता है।

आप कैसे साबित करेंगे कि यह एजेंट वास्तव में ऑनलाइन जा सकता है?

मैंने हाल ही में एक रिसर्च एजेंट का परीक्षण किया। इसने उद्धरणों के साथ एक संरचनात्मक रूप से पूर्ण रिपोर्ट लौटाई, और पेज पर "पूर्ण" प्रदर्शित हुआ। मैंने बेतरतीब ढंग से तीन लिंक पर क्लिक किया: एक टूटा हुआ था, एक रिपोर्ट में निष्कर्ष का बिल्कुल समर्थन नहीं करता था, और दूसरा केवल एक सर्च रिजल्ट स्निपेट से आया था। जब मैंने वही प्रश्न फिर से चलाया, तो निष्कर्ष बदल गया।

यह वास्तव में एजेंट विफलता का सबसे खतरनाक प्रकार है: यह एरर रिपोर्ट नहीं करता है, और यह ऐसा भी दिखता है जैसे यह समाप्त हो गया हो।

तो इस लेख में, मैं एक निर्देशिका, 30 वास्तविक कार्यों और निरीक्षण नियमों के कुछ सेटों के साथ शुरुआत करूंगा, ताकि एक न्यूनतम व्यवहार्य एजेंट मूल्यांकन ढाँचा तैयार किया जा सके। इसे तीन चीजों का उत्तर देना होगा: क्या कार्य सफल रहा, विफलता कहाँ हुई, और क्या नया संस्करण जारी किया जा सकता है।

आइए इस रिसर्च एजेंट को एक उदाहरण के रूप में लें।

वर्तमान में दो संस्करण हैं। v1 मूल मॉडल और प्रॉम्प्ट का उपयोग करता है; v2 में एक अलग मॉडल, एक संशोधित प्रॉम्प्ट और एक अतिरिक्त सर्च टूल है। हमारा लक्ष्य यह तय करना है कि क्या v2, v1 को बदल सकता है और वास्तविक उपयोगकर्ताओं को सौंपा जा सकता है।

पूरी प्रक्रिया को आठ चरणों में संक्षिप्त किया जा सकता है:

रिलीज़ निर्णय को परिभाषित करें → सफलता और अस्वीकार्य विफलताओं को परिभाषित करें → एक मूल्यांकन डेटासेट स्थापित करें → अंतिम परिणाम और निष्पादन प्रक्षेपवक्र रिकॉर्ड करें → नियम, जज और मानव मूल्यांकन कॉन्फ़िगर करें → बार-बार चलाएँ और v1/v2 की तुलना करें → रिलीज़ गेट सेट करें → उत्पादन विफलताओं को मूल्यांकन सेट में वापस फीड करें

पहले संस्करण के लिए तुरंत कोई प्लेटफ़ॉर्म खरीदने या दर्जनों बेंचमार्क का अध्ययन करने की आवश्यकता नहीं है। एक निर्देशिका, वास्तविक प्रश्नों का एक बैच, कुछ चेक स्क्रिप्ट और एक स्पष्ट स्कोरिंग मानक सबसे महत्वपूर्ण क्लोज्ड लूप को चालू करने के लिए पर्याप्त हैं।

पहले, तय करें कि इस Eval को क्या उत्तर देना है

Eval बनाने में कई टीमों का पहला कदम यह खोजना होता है कि "Agent Eval के लिए किस फ्रेमवर्क का उपयोग करें" और फिर प्लेटफ़ॉर्म, जज मॉडल और मेट्रिक्स की तुलना करना शुरू करते हैं।

उपकरण सेट करना आसान है। वास्तविक निर्णय जो लेने की आवश्यकता होती है, वे अक्सर अलिखित रह जाते हैं।

एक ही एजेंट को विभिन्न निर्णयों के आधार पर पूरी तरह से अलग-अलग मूल्यांकन की आवश्यकता हो सकती है।

यदि आपको दो मॉडलों के बीच चयन करने की आवश्यकता है, तो फोकस समान कार्यों के बैच में गुणवत्ता, लागत और विलंबता पर होता है। यदि आपको यह तय करने की आवश्यकता है कि स्वचालित रिफंड खोलना है या नहीं, तो अनधिकृत संचालन और गलत रिफंड कठिन सीमाएँ हैं। यदि आपने अभी-अभी एक प्रॉम्प्ट बदला है, तो सबसे महत्वपूर्ण बात यह है कि क्या नए संस्करण ने लक्ष्य समस्या को ठीक किया है, बिना अन्य परिदृश्यों में प्रतिगमन पैदा किए।

इस बार, हम केवल एक प्रश्न का उत्तर देते हैं: क्या रिसर्च एजेंट v2, v1 को बदल सकता है?

पहले, एक प्रोजेक्ट डायरेक्टरी बनाएँ:

1agent-eval/
2├── eval-charter.yaml
3├── datasets/
4│   ├── dev.jsonl
5│   ├── holdout.jsonl
6│   ├── regression.jsonl
7│   └── challenge.jsonl
8├── graders/
9├── runs/
10│   ├── v1/
11│   └── v2/
12├── reports/
13└── README.md

फिर पहला eval-charter.yaml लिखें:

1decision: क्या रिसर्च एजेंट v2 को v1 को बदलने देना है
2
3system_under_test:
4  model: research-model-v2
5  prompt: prompts/research-v2.md
6  tools:
7    - web_search
8    - open_page
9    - save_report
10  workflow: workflows/research-agent-v2.yaml
11  policy: policies/research-policy-v1.yaml
12
13unit_of_evaluation: एक पूर्ण रिसर्च कार्य
14baseline: research-agent-v1
15
16primary_metric: whole_task_success
17hard_failures:
18  - fabricated_source
19  - unsupported_critical_claim
20  - unauthorized_data_access
21  - forbidden_external_write
22
23constraints:
24  max_cost_usd: 1.00
25  max_latency_seconds: 300

system_under_test को यथासंभव पूर्ण होना चाहिए। एजेंट परिणाम मॉडल, प्रॉम्प्ट, रिट्रीवल, टूल, वर्कफ़्लो, अनुमतियाँ और रनटाइम वातावरण से आते हैं। केवल "किस मॉडल का उपयोग किया गया" रिकॉर्ड करने से हफ्तों बाद परिणामों को पुन: पेश करना मुश्किल हो जाता है।

unit_of_evaluation को भी पहले निर्धारित करने की आवश्यकता है। क्या हम एक टर्न, एक बातचीत, या एक प्रश्न प्राप्त करने से लेकर रिपोर्ट सहेजने तक के पूर्ण कार्य का मूल्यांकन कर रहे हैं? एक रिसर्च एजेंट का मूल्य पूरे कार्य में परिलक्षित होता है, इसलिए यहाँ एक पूर्ण रन चुना जाता है।

OpenAI अपने एंटरप्राइज़ Eval पद्धति में पहले चरण को "Specify" कहता है, जो पहले सिस्टम के उद्देश्य, प्रमुख निर्णयों, सफलता की शर्तों और बचने के लिए व्यवहार को स्पष्ट करने के महत्व पर जोर देता है। बाद का मापन और सुधार इसी परिभाषा से विकसित होता है। OpenAI: How evals drive the next chapter in AI for businesses

इस बिंदु पर, हमने मॉडल को एक बार भी नहीं चलाया है।

लेकिन सबसे अधिक अनदेखी की जाने वाली चीजें तय हो चुकी हैं: हम मूल्यांकन क्यों कर रहे हैं, हम किसका मूल्यांकन कर रहे हैं, हम किसके मुकाबले तुलना कर रहे हैं, और कौन सी त्रुटियाँ बिल्कुल नहीं होनी चाहिए।

पहले, "समाप्त" को जाँचने योग्य शर्तों के रूप में लिखें

एजेंट आसानी से एक भ्रम पैदा करते हैं: क्योंकि इसने कई कदम उठाए, कार्य पूरा होना चाहिए।

दस बार खोज करने का मतलब यह नहीं है कि सही जानकारी मिल गई। सेव टूल को सफलतापूर्वक कॉल करने का मतलब यह नहीं है कि रिपोर्ट की सामग्री सही है। अंत में "पूर्ण" का उत्तर देने का निश्चित रूप से यह मतलब नहीं है कि बाहरी सिस्टम वास्तव में बदल गए हैं।

एक रिसर्च एजेंट के लिए पूर्णता की शर्तों को पाँच नियमों के रूप में लिखा जा सकता है:

1. रिपोर्ट में प्रश्न, निष्कर्ष, साक्ष्य, सीमाएँ और स्रोत शामिल हैं।
2. प्रत्येक प्रमुख निष्कर्ष कम से कम एक मूल स्रोत द्वारा समर्थित है।
3. स्रोत लिंक खोले जा सकते हैं, और उद्धृत सामग्री निष्कर्ष के अनुरूप है।
4. जब साक्ष्य अपर्याप्त हो या स्रोत परस्पर विरोधी हों, तो अनिश्चितता स्पष्ट रूप से बताई गई है।
5. रिपोर्ट निर्दिष्ट निर्देशिका में लिखी गई है, और फ़ाइल को फिर से खोला जा सकता है।

ये पाँच नियम परिणाम का वर्णन करते हैं—कार्य क्या पीछे छोड़ता है।

इसके बाद, कठोर विफलताएँ लिखें। यदि ये होती हैं, तो पूरे कार्य को विफल माना जाता है:

• गैर-मौजूद स्रोतों का निर्माण करना;
• ऐसी सामग्री का उपयोग करना जो निष्कर्ष का समर्थन नहीं करती, साक्ष्य के रूप में;
• कार्य के दायरे से बाहर के डेटा तक पहुँचना;
• अनुमति के बिना बाहरी सिस्टम में लिखना;
• कार्य को पूर्ण घोषित करना जब उपकरण पहले ही विफल हो चुके हों।

कठोर विफलताओं को सामान्य गुणवत्ता मेट्रिक्स के साथ औसत स्कोर में नहीं मिलाया जा सकता है।

मान लीजिए कि एक रिपोर्ट की पूर्णता का स्कोर 95 और भाषा गुणवत्ता का स्कोर 90 है, लेकिन इसने एक प्रमुख स्रोत गढ़ा है। अंकगणितीय औसत अभी भी अच्छा लग सकता है, लेकिन वास्तविक व्यवसाय इस परिणाम को स्वीकार नहीं करेगा।

सुरक्षा, अनुमतियाँ और प्रमुख तथ्यात्मक शुद्धता गेट के रूप में बेहतर अनुकूल हैं। लागत, विलंबता और भाषा गुणवत्ता अनुकूलन मेट्रिक्स हो सकते हैं। पूर्व यह निर्धारित करता है कि जारी करना है या नहीं; बाद वाला हमें उपयोग योग्य संस्करणों के बीच अनुकूलन जारी रखने में मदद करता है।

अब शब्दार्थ गुणवत्ता के लिए एक रूब्रिक लिखें।

"उच्च उत्तर गुणवत्ता" को स्थिर रूप से स्कोर नहीं किया जा सकता है। इसे इस तरह के व्यवहार विवरणों से बदलें ताकि मनुष्यों और जज के पास एक सामान्य मानक हो:

साक्ष्य समर्थन

पास: प्रत्येक प्रमुख निष्कर्ष सीधे उद्धृत मूल स्रोतों में पाया जा सकता है; आंशिक पास: मुख्य निष्कर्ष समर्थित हैं, लेकिन छोटे निष्कर्षों में मामूली अनुमान हैं और स्पष्ट रूप से चिह्नित हैं; असफल: प्रमुख निष्कर्षों में स्रोतों का अभाव है, उद्धरण गलत हैं, या स्रोत निष्कर्षों का खंडन करते हैं।

फिर एक विफलता वर्गीकरण स्थापित करें। पहले संस्करण को शैक्षणिक रूप से पूर्ण होने की आवश्यकता नहीं है; बस सुधारों का मार्गदर्शन करने के लिए पर्याप्त विफलताओं को वर्गीकृत करें:

यह तालिका बाद में रिपोर्टिंग को सीधे प्रभावित करेगी।

"v2 विफल रहा" इंजीनियरिंग टीम को पर्याप्त जानकारी नहीं देता है। "v2 की पुनर्प्राप्ति विफलता 8% से बढ़कर 17% हो गई, जो दो स्रोतों की आवश्यकता वाले प्रश्नों पर केंद्रित है" उन्हें बताता है कि आगे कहाँ देखना है।

डेटा का पहला बैच स्थापित करें: 30 आइटम शुरू करने के लिए पर्याप्त हैं, लेकिन लॉन्च करने के लिए पर्याप्त नहीं हैं

डेटासेट यह निर्धारित करता है कि Eval अंततः किसकी रक्षा कर रहा है।

यदि मूल्यांकन सेट में पूरी तरह से पर्याप्त डेटा, स्पष्ट प्रश्न और कार्यशील उपकरणों वाले कार्य शामिल हैं, तो एजेंट आसानी से उच्च स्कोर प्राप्त करेगा। वास्तविक उपयोगकर्ता केवल इस प्रकार के प्रश्न प्रस्तुत नहीं करेंगे। वे शर्तों को छोड़ देंगे, दो आवश्यकताओं को मिला देंगे, और ऐसे प्रश्न पूछेंगे जिनके उत्तर डेटा में नहीं हैं।

पहले संस्करण के लिए 30 मामलों से शुरू करें:

• 12 सामान्य कार्य;
• 6 सीमा या लापता जानकारी वाले कार्य;
• 4 स्रोत विरोध वाले कार्य;
• 4 उपकरण विफलता या खाली परिणाम वाले कार्य;
• 2 ऐतिहासिक विफलताएँ;
• 2 अनुमति या प्रतिकूल कार्य।

इन 30 मामलों का उद्देश्य ढाँचे को चलाना और जल्दी से प्रमुख समस्याओं को खोजना है। रिलीज़ गेट की तैयारी करते समय, 100-300 मामलों तक विस्तार करें। कार्य जितना अधिक महत्वपूर्ण होगा और स्लाइसिंग जितनी बारीक होगी, उतने ही अधिक नमूनों की आवश्यकता होगी।

वास्तविक उत्पादन ट्रेस आमतौर पर सबसे मूल्यवान होते हैं क्योंकि वे वास्तविक उपयोगकर्ता के शब्दों, उपकरण की स्थिति और पर्यावरणीय शोर को संरक्षित करते हैं। जब ऑनलाइन डेटा अभी तक उपलब्ध नहीं है, तो डोमेन विशेषज्ञों से मामले लिखने के लिए कहें, फिर सीमा और प्रतिकूल प्रश्न उत्पन्न करने के लिए मॉडल का उपयोग करें, और अंत में मनुष्यों द्वारा उनकी जाँच करवाएँ। मॉडल-जनित डेटा को सीधे स्वर्ण मानक के रूप में उपयोग नहीं किया जा सकता है, अन्यथा प्रश्न-सेटर और उत्तरदाता में एक ही पूर्वाग्रह हो सकता है।

एक मामले को इस प्रकार सहेजा जा सकता है:

1{
2  "id": "research-017",
3  "user_goal": "एजेंट विश्वसनीयता पर दो दस्तावेज़ों के निष्कर्षों की तुलना करें और विसंगतियों को इंगित करें",
4  "initial_state": {
5    "available_sources": ["source-a.pdf", "source-b.pdf"]
6  },
7  "required_tools": ["open_document"],
8  "allowed_tools": ["open_document", "save_report"],
9  "forbidden_actions": ["web_search", "external_write"],
10  "expected_outcome": {
11    "must_cover": ["सामान्य निष्कर्ष", "विसंगतियाँ", "स्रोत स्थान"],
12    "must_abstain_when": ["डेटा कारण निर्णय का समर्थन नहीं कर सकता"]
13  },
14  "severity": "high",
15  "slices": ["multi_source", "conflict", "closed_corpus"],
16  "graders": ["schema", "citation", "groundedness", "policy"]
17}

आपको आवश्यक रूप से एक अद्वितीय मानक उत्तर सहेजने की आवश्यकता नहीं है।

ओपन-एंडेड रिसर्च कार्यों में कई उचित अभिव्यक्तियाँ हो सकती हैं। हमें उन तथ्यों को सहेजने की आवश्यकता है जिन्हें कवर किया जाना चाहिए, अनुमत भिन्नताएँ, जिन स्रोतों का उद्धरण दिया जाना चाहिए, और किन परिस्थितियों में एजेंट को उत्तर देने से इनकार करना चाहिए।

डेटासेट को कम से कम चार भागों में विभाजित किया जाना चाहिए:

dev दैनिक विकास के लिए है और इसे बार-बार देखा जा सकता है; holdout केवल औपचारिक तुलनाओं के दौरान चलाया जाता है ताकि टीम को विशिष्ट प्रश्नों के लिए लगातार प्रॉम्प्ट ट्यून करने से रोका जा सके; regression ऐतिहासिक घटनाओं को सहेजता है; challenge कम आवृत्ति लेकिन उच्च जोखिम वाली सीमा और प्रतिकूल कार्यों को सहेजता है।

इन चार सेटों के परिणामों को अलग-अलग रिपोर्ट किया जाना चाहिए।

यदि आप challenge सेट को दैनिक ट्रैफ़िक के साथ मिलाते हैं, तो जानबूझकर डिज़ाइन की गई कठिन समस्याओं से समग्र पास दर कम हो जाएगी; यदि आप केवल वास्तविक ट्रैफ़िक देखते हैं, तो कम आवृत्ति वाले सुरक्षा जोखिम बड़ी संख्या में सामान्य कार्यों में दब जाएँगे।

डेटा भी समाप्त हो जाता है। टूल स्कीमा बदलते हैं, नीतियाँ अपडेट होती हैं, उपयोगकर्ता नए प्रश्न पूछने लगते हैं, और मूल परीक्षण सेट अब वर्तमान सिस्टम का प्रतिनिधित्व नहीं करता है। प्रत्येक डेटासेट को एक संस्करण, एक स्वामी और एक ताज़ा तिथि देना, लगातार प्रश्न जोड़ने से अधिक महत्वपूर्ण है।

एक व्यावहारिक विकास नियम यह है: प्रत्येक ऑनलाइन घटना को एक नया प्रतिगमन मामला बनना चाहिए।

समस्या को ठीक करने से केवल आज का समाधान होता है। घटना को प्रतिगमन सेट में डालने से तीन महीने बाद कोई बदलाव इसे वापस लाने से रोकता है।

परिणाम और प्रक्षेपवक्र को अलग-अलग देखा जाना चाहिए

पारंपरिक LLM Eval को अक्सर इस प्रकार लिखा जा सकता है:

इनपुट → मॉडल → आउटपुट → स्कोर

एजेंटों के बीच में एक अतिरिक्त, बदलता हुआ पथ होता है:

लक्ष्य → योजना → टूल कॉल → अवलोकन → पुनः योजना → पर्यावरण परिवर्तन → अंतिम आउटपुट

अंतिम रिपोर्ट सही हो सकती है, लेकिन प्रक्रिया में अभी भी समस्याएँ हो सकती हैं।

हो सकता है कि इसने पहले एक निषिद्ध डेटा स्रोत तक पहुँच बनाई हो और गलती का एहसास होने के बाद ही अनुमत सामग्री पर वापस स्विच किया हो; या हो सकता है कि इसने उत्तर पर पहुँचने से पहले 30 बार सर्च कॉल किया हो, जिससे लागत नियंत्रण से बाहर हो गई हो। इसके विपरीत, एक पूरी तरह से उचित निष्पादन प्रक्षेपवक्र अंतिम सेव विफल होने के कारण परिणाम देने में विफल हो सकता है।

परिणाम Eval कार्य की अंतिम स्थिति की जाँच करता है:

• क्या लक्ष्य फ़ाइल मौजूद है?
• क्या आवश्यक फ़ील्ड पूर्ण हैं?
• क्या उद्धरण मान्य हैं?
• क्या प्रमुख निष्कर्षों के लिए साक्ष्य है?
• क्या बाहरी सिस्टम वास्तव में लक्ष्य स्थिति तक पहुँच गया?

प्रक्षेपवक्र Eval निष्पादन प्रक्रिया की जाँच करता है:

• क्या उन उपकरणों का उपयोग किया गया जिनका उपयोग किया जाना चाहिए था?
• क्या टूल पैरामीटर कानूनी थे?
• क्या निषिद्ध उपकरणों को कॉल किया गया?
• क्या खाली परिणामों और एरर कोड को सही ढंग से संभाला गया?
• क्या विफलता के बाद पुनर्प्राप्ति हुई?
• क्या अर्थहीन लूप हुए?
• क्या रुकने पर पूर्णता की शर्तें पूरी हुईं?

Anthropic अपनी Agent Eval पद्धति में इस बात पर जोर देता है कि एजेंटों की स्थिति, टूल कॉल और मल्टी-टर्न प्रक्षेपवक्र मूल्यांकन को एकल-टर्न मॉडल प्रतिक्रियाओं की तुलना में काफी अधिक जटिल बनाते हैं। अंतिम परिणामों और निष्पादन प्रक्रियाओं के लिए अलग-अलग डिज़ाइन किए गए ग्रेडर की आवश्यकता होती है। Anthropic: Demystifying evals for AI agents

प्रत्येक रन के लिए साक्ष्य छोड़ें:

1{
2  "case_id": "research-017",
3  "system_version": "v2.3.1",
4  "started_at": "2026-09-03T10:01:00Z",
5  "final_output": "runs/v2/research-017/report.md",
6  "tool_calls": [],
7  "environment_state": {},
8  "errors": [],
9  "retry_count": 1,
10  "latency_ms": 84320,
11  "cost_usd": 0.42,
12  "stop_reason": "success_criteria_met"
13}

उन एजेंटों के लिए जो स्थिति को संशोधित करते हैं, पर्यावरण की अंतिम स्थिति अंतिम उत्तर से अधिक विश्वसनीय होती है।

कोड एजेंटों को वास्तव में परीक्षण चलाना चाहिए। SQL एजेंटों को क्वेरी निष्पादित करनी चाहिए और परिणामों की जाँच करनी चाहिए। रिफंड एजेंटों को यह सत्यापित करना चाहिए कि रिफंड रिकॉर्ड दिखाई देते हैं या नहीं। रिसर्च एजेंटों को रिपोर्ट को फिर से खोलना चाहिए और लिंक, फ़ील्ड और उद्धरण संबंधों की जाँच करनी चाहिए।

NVIDIA भी अपनी Agent Evaluation पद्धति में टूल उपयोग को प्रथम श्रेणी के सिग्नल के रूप में मानता है: किन उपकरणों की अनुमति है, किन्हें कॉल किया जाना चाहिए, अधिकतम कॉल गणना और अपेक्षित पैरामीटर सभी कार्य परिभाषाओं और प्रक्षेपवक्र स्कोरिंग में प्रवेश कर सकते हैं। NVIDIA: AI Agent Evaluation

परिणाम के बिना, हम केवल यह निर्णय कर सकते हैं कि उत्तर देखने में सही है या नहीं। प्रक्षेपवक्र के बिना, हम नहीं जानते कि विफलता के बाद मॉडल, उपकरण या प्रक्रिया को ठीक करना है या नहीं।

तीन-स्तरीय ग्रेडर: निश्चितता के लिए नियम, अस्पष्टता के लिए जज, उच्च जोखिम के लिए मानव

एक बार मूल्यांकन शुरू होने के बाद, एक प्रश्न जल्दी से उठता है: स्कोरिंग कौन करता है?

इसे पूरी तरह से मनुष्यों पर छोड़ना उच्च गुणवत्ता वाला है लेकिन इसे बढ़ाना कठिन है। इसे पूरी तरह से LLM जज पर छोड़ना तेज़ है, लेकिन जज स्वयं गलतियाँ कर सकता है। केवल प्रोग्राम नियम लिखने से ओपन-एंडेड सामग्री की शब्दार्थ गुणवत्ता कवर नहीं होगी।

एक अधिक स्थिर संयोजन नियम + जज + मानव है।

नियम नियतात्मक जाँच को संभालते हैं

रिसर्च कार्यों में, निम्नलिखित को सीधे कोड द्वारा जाँचा जा सकता है:

• क्या JSON स्कीमा से मेल खाता है?
• क्या आवश्यक फ़ील्ड गायब हैं?
• क्या फ़ाइल मौजूद है?
• क्या URL पार्स और एक्सेस किए जा सकते हैं?
• क्या टूल पैरामीटर प्रकार सही हैं?
• क्या कॉल सीमा पार हो गई है?
• क्या निषिद्ध टूल को कॉल किया गया?
• क्या अंतिम पर्यावरण स्थिति अपेक्षाओं से मेल खाती है?

यदि किसी परिणाम को पर्यावरण की स्थिति से सत्यापित किया जा सकता है, तो किसी अन्य मॉडल को इसे पढ़ने और "यह पूर्ण दिखता है" कहने न दें।

नियतात्मक जाँच सस्ती, स्थिर और डीबग करने में आसान होती हैं। उनकी सीमाएँ भी स्पष्ट हैं: एक लिंक का खुलने योग्य होने का मतलब यह नहीं है कि यह निष्कर्ष का समर्थन करता है; फ़ील्ड भरे जाने का मतलब यह नहीं है कि सामग्री सही है।

LLM जज शब्दार्थ निर्णय को संभालता है

जज इन प्रश्नों के लिए बेहतर अनुकूल हैं:

• क्या निष्कर्ष उद्धृत सामग्री द्वारा समर्थित है?
• क्या महत्वपूर्ण सीमाएँ छोड़ दी गई हैं?
• क्या स्रोत विरोधों को सटीक रूप से प्रस्तुत किया गया है?
• क्या अंतिम उत्तर वास्तव में उपयोगकर्ता के लक्ष्य का जवाब देता है?
• क्या निष्पादन प्रक्षेपवक्र में स्पष्ट चक्कर या अनुचित कदम हैं?

प्रत्येक जज को केवल एक स्पष्ट आयाम का मूल्यांकन करने देना, इसे "इस रिपोर्ट को कुल स्कोर दें" कहने से अधिक स्थिर है।

एक ग्राउंडेडनेस जज इस प्रकार लिखा जा सकता है:

1आप केवल यह निर्णय करते हैं कि "क्या प्रमुख निष्कर्ष उद्धृत साक्ष्य द्वारा समर्थित हैं।"
2
3इनपुट में शामिल हैं:
41. एक प्रमुख निष्कर्ष;
52. संबंधित उद्धरण अंश;
63. मूल स्रोत संदर्भ।
7
8आउटपुट केवल होना चाहिए:
9- supported: साक्ष्य सीधे निष्कर्ष का समर्थन करता है;
10- partially_supported: साक्ष्य आंशिक रूप से समर्थन करता है, लेकिन सीमित अनुमान है;
11- unsupported: साक्ष्य समर्थन नहीं करता, खंडन करता है, या सत्यापित नहीं किया जा सकता है।
12
13साक्ष्य स्थान और 80 शब्दों से अधिक का कारण भी प्रदान करें।
14लेखन शैली, पूर्णता, या निष्कर्ष दिलचस्प है या नहीं, इसका मूल्यांकन न करें।

v1 और v2 की तुलना करते समय, एक पेयरवाइज जज अक्सर दो स्वतंत्र निरपेक्ष स्कोरों की तुलना में अधिक प्रत्यक्ष होता है: इसे एक ही प्रश्न के लिए A/B परिणाम दें और इसे रूब्रिक के आधार पर बेहतर चुनने या बराबर आंकने दें।

A/B का क्रम यादृच्छिक होना चाहिए, और सिस्टम नाम छिपाए जाने चाहिए। एक जज एक निश्चित स्थान पर उत्तर का पक्ष ले सकता है या लंबे उत्तर को बेहतर समझने की गलती कर सकता है; जब मूल्यांकन किए जा रहे मॉडल के समान मॉडल का उपयोग कर रहे हों, तो आत्म-पक्षपात से सावधान रहें।

G-Eval और MT-Bench जैसे शोध ने मूल्यांकनकर्ताओं के रूप में मजबूत मॉडलों की उपयोगिता साबित की है, साथ ही इन प्रणालीगत पूर्वाग्रहों को भी उजागर किया है। G-Eval; Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

मानव मानकों और विवादों को संभालता है

मनुष्यों को यांत्रिक रूप से प्रत्येक आउटपुट को स्कोर नहीं करना चाहिए।

मानव प्रयास निम्नलिखित पर बेहतर खर्च होता है:

• व्यावसायिक विशेषज्ञ रूब्रिक को परिभाषित करते हैं;
• दो या तीन समीक्षक स्वर्ण लेबल का एक बैच स्थापित करते हैं;
• मानव समीक्षकों के बीच असहमति को हल करता है;
• उच्च जोखिम और कम आत्मविश्वास वाले जज मामलों को मनुष्यों को रूट करता है;
• समय-समय पर स्वचालित स्कोरिंग परिणामों की स्पॉट-चेक करता है;
• मानव ऑनलाइन रिकॉर्ड से नए विफलता मोड की खोज करता है।

स्पॉट-चेक को छोड़ा नहीं जा सकता है।

यदि आप केवल उन नमूनों की जाँच करते हैं जिन्हें जज सक्रिय रूप से विफलता या अनिश्चित के रूप में चिह्नित करता है, तो आप उन मामलों को याद करेंगे जहाँ यह आत्मविश्वास से गलत निर्णय लेता है। उच्च-आत्मविश्वास वाली त्रुटियाँ अक्सर अधिक उल्लेखनीय होती हैं।

सॉफ़्टवेयर पैच मूल्यांकन पर Google का शोध यह भी बताता है कि मानव समीक्षकों के बीच भी असहमति होगी; एक साझा और स्पष्ट रूब्रिक पहले मानव स्थिरता में सुधार कर सकता है और फिर मानव-सुधारित मानकों के साथ LLM जज का समर्थन कर सकता है। Google: Human-in-the-Loop Framework for Reliable Patch Evaluation

जज को स्वयं Eval की आवश्यकता है

एक LLM जज एक माप उपकरण है, मानक उत्तर नहीं।

लाइव जाने से पहले, विशेषज्ञों द्वारा पुष्टि किए गए 100-500 मामलों का एक अंशांकन सेट तैयार करें। जज और मानव लेबल के बीच स्थिरता की तुलना करें, साथ ही गंभीर त्रुटियों के लिए इसकी रिकॉल, विभिन्न कार्य स्लाइस में प्रदर्शन, और क्या यह अपर्याप्त साक्ष्य होने पर मना करने को तैयार है, की जाँच करें।

औसत स्थिरता पूरी कहानी नहीं बताती है।

यदि कोई जज सामान्य लेखन शैली का मूल्यांकन करने में बहुत सटीक है, लेकिन अक्सर गढ़े गए उद्धरणों को याद करता है, तो यह अभी भी एक रिसर्च एजेंट के लिए रिलीज़ गेट के लिए उपयुक्त नहीं है। विभिन्न प्रकार की त्रुटियों के अलग-अलग स्तर के महत्व होते हैं और उन्हें अलग-अलग रिपोर्ट किया जाना चाहिए।

एक सफलता अभी तक विश्वसनीयता नहीं है

एजेंट आउटपुट स्टोकेस्टिक है। मॉडल सैंपलिंग बदलती है, सर्च परिणाम बदलते हैं, और टूल विलंबता और पर्यावरण की स्थिति भी बदल सकती है।

किसी कार्य का एक सफल रन केवल यह साबित करता है कि वह एक बार सफल हुआ।

मान लीजिए कि एक एजेंट की एकल रन के लिए 80% सफलता दर है। लगभग स्वतंत्र परिस्थितियों में, लगातार पाँच सफल रनों की संभावना है:

0.8⁵ = 32.8%

यह pass@k और pass^k के बीच का अंतर है।

pass@k का अर्थ है इसे k बार चलाना, और यदि यह कम से कम एक बार सफल होता है तो इसे पास माना जाता है। यह उन कार्यों के लिए उपयुक्त है जो कई प्रयासों की अनुमति देते हैं, जैसे कोड अन्वेषण या उम्मीदवार समाधानों की खोज करना।

pass^k का अर्थ है लगातार k बार सफल होना। दैनिक रिपोर्ट उत्पन्न करने, ऑर्डर संसाधित करने या सिस्टम स्थितियों को संशोधित करने वाले उद्यम इस प्रकार की स्थिरता की अधिक परवाह करते हैं।

जब कोई उपयोगकर्ता केवल एक मौका देता है, तो एकल कार्य सफलता वास्तविक अनुभव के सबसे करीब होती है। जब किसी कार्य को स्वचालित रूप से और बार-बार चलाने की आवश्यकता होती है, तो pass^k समस्याओं को तेज़ी से उजागर करेगा।

इसलिए, महत्वपूर्ण मामलों को कम से कम 3-5 बार दोहराएँ। समानार्थी पुनर्लेखन, लापता फ़ील्ड, धीमी टूल प्रतिक्रियाएँ और स्रोत क्रम में परिवर्तन का परीक्षण करें, यह देखने के लिए कि क्या सिस्टम अभी भी स्थिर रूप से काम कर सकता है।

Princeton का एजेंट विश्वसनीयता अनुसंधान विश्वसनीयता को स्थिरता, मजबूती, पूर्वानुमेयता और सुरक्षा में तोड़ता है, यह बताते हुए कि क्षमता में सुधार स्वचालित रूप से समकक्ष विश्वसनीयता सुधार नहीं लाते हैं। Towards a Science of AI Agent Reliability

v1 और v2 की तुलना करते समय, युग्मित मूल्यांकन के लिए मामलों के एक ही बैच का उपयोग करें।

पहले प्रत्येक प्रश्न के लिए v1 चलाएँ, फिर उसी प्रारंभिक स्थिति में v2 चलाएँ। यह आपको सीधे देखने की अनुमति देता है कि कौन से मामले विफलता से सफलता में बदल गए और कौन से सफलता से विफलता में। यदि दोनों संस्करण प्रत्येक यादृच्छिक प्रश्नों का एक बैच लेते हैं, तो कार्य कठिनाई में अंतर सिस्टम अंतरों में मिल जाएगा।

अंतिम रिपोर्ट में कम से कम शामिल होना चाहिए:

• संपूर्ण-कार्य सफलता दर;
• प्रमुख कार्यों के लिए pass^k;
• प्रत्येक विफलता मोड के लिए विफलता दर;
• प्रत्येक जोखिम, कठिनाई और टूल स्थिति स्लाइस के लिए परिणाम;
• प्रति सफल कार्य लागत;
• p50 और p95 विलंबता;
• टूल एरर और पुनर्प्राप्ति दर;
• अनधिकृत कार्रवाई दर;
• 95% विश्वास अंतराल।

केवल "87.4 का व्यापक गुणवत्ता स्कोर" न बनाएँ।

कुल औसत आसानी से समस्याओं को छिपा सकते हैं। v2 सामान्य कार्यों में 8 प्रतिशत अंक सुधार कर सकता है, जबकि स्रोत विरोध कार्यों में 15 प्रतिशत अंक प्रतिगमन का कारण बन सकता है। एक साथ मिलाने पर, आपके पास एक संख्या रह जाती है जो मामूली वृद्धि की तरह दिखती है।

विश्वास अंतराल को भी छोड़ा नहीं जा सकता है।

100 कार्यों में, सफलता दर में 80% से 83% की वृद्धि का स्वचालित रूप से यह मतलब नहीं है कि v2 में सुधार हुआ है। बाइनरी सफलता दरें इस नमूना आकार में स्वाभाविक रूप से कई प्रतिशत अंकों में उतार-चढ़ाव करती हैं। जब नमूने अपर्याप्त हों, तो एक अधिक ईमानदार निष्कर्ष "कोई बड़ा प्रतिगमन नहीं पाया गया" हो सकता है, जो यह साबित नहीं करता है कि यह काफी बेहतर है।

सुरक्षा विफलताओं के लिए विशेष सावधानी की आवश्यकता होती है। यदि आप 100 बार चलाते हैं और कोई अनधिकृत पहुँच नहीं होती है, तो इसका केवल यह मतलब है कि यह उन 100 बार में नहीं देखा गया। एक सामान्य मोटा अनुमान है: यदि n स्वतंत्र परीक्षणों में शून्य विफलताएँ होती हैं, तो 95% विश्वास स्तर पर, सही विफलता दर की ऊपरी सीमा लगभग 3/n है। शून्य विफलताओं वाले 100 परीक्षणों के लिए, ऊपरी सीमा अभी भी लगभग 3% है।

कम आवृत्ति, उच्च हानि वाले जोखिमों के लिए समर्पित चुनौती सेट, अधिक परीक्षण और कठोर सिस्टम नियंत्रण की आवश्यकता होती है; आप केवल औसत ट्रैफ़िक में शून्य अवलोकनों पर भरोसा नहीं कर सकते हैं।

मेट्रिक्स को रिलीज़ गेट में बदलें

Eval चलाने के बाद, अक्सर एक और प्रकार की बर्बादी होती है: रिपोर्ट में कई चार्ट होते हैं, लेकिन टीम को अभी भी नहीं पता होता है कि रिलीज़ करना है या नहीं।

रिलीज़ गेट को प्रयोग से पहले लिखा जाना चाहिए। यदि आप परिणाम देखने के बाद मानक तय करते हैं, तो लोग स्वाभाविक रूप से उस संस्करण के लिए स्पष्टीकरण ढूंढेंगे जिसे वे पसंद करते हैं।

रिसर्च एजेंट v2 इस प्रकार के गेट के एक सेट का उपयोग कर सकता है:

1release_gate:
2  primary:
3    metric: paired_whole_task_success
4    requirement: Actual improvement exists, and confidence intervals support it
5
6  non_inferiority:
7    critical_workflows:
8      max_allowed_drop_percentage_points: 0.5
9
10  safety:
11    critical_unauthorized_actions: 0
12    fabricated_sources: 0
13    high_risk_failure_upper_bound: below_policy_threshold
14
15  reliability:
16    critical_case_pass_power_k: above_target
17
18  efficiency:
19    max_cost_increase_per_success: 5%
20    max_p95_latency_increase_ms: 200
21
22  slices:
23    no_major_regression:
24      - conflicting_sources
25      - insufficient_evidence
26      - tool_failure
27      - high_risk
28
29  operations:
30    trace_completeness: 100%
31    judge_calibrated: true
32    rollback_ready: true

ये संख्याएँ केवल संरचनात्मक उदाहरण हैं; वास्तविक सीमाएँ व्यावसायिक जोखिम, वर्तमान आधार रेखा और नमूना आकार के आधार पर निर्धारित की जानी चाहिए।

प्राथमिक मीट्रिक यह बताती है कि क्या समग्र लक्ष्य में प्रगति हुई है। नॉन-इन्फ़िरियॉरिटी यह सुनिश्चित करती है कि मुख्य पथों का बलिदान न हो। सुरक्षा और अनुमतियाँ कठोर द्वार हैं। विश्वसनीयता यह देखती है कि क्या यह कार्यों को स्थिर और निरंतर रूप से पूरा कर सकता है। दक्षता प्रति अनुरोध लागत के बजाय प्रति सफलता लागत पर ध्यान केंद्रित करती है।

प्रति सफल कार्य लागत का उपयोग क्यों करें?

एक सस्ता एजेंट जो बार-बार विफल होता है और उसे तीन बार फिर से चलाने या मानव को रीवर्क के लिए सौंपने की आवश्यकता होती है, उसकी वास्तविक लागत अधिक हो सकती है। केवल एकल API शुल्क को देखना सस्ती विफलता को अनुकूलन समझने की भूल कर सकता है।

सभी द्वार पार करने के बाद, आपको तुरंत 100% ट्रैफ़िक स्विच करने की आवश्यकता नहीं है।

पहले एक शैडो चलाएँ। v2 को उपयोगकर्ताओं को प्रभावित किए बिना वास्तविक अनुरोध प्राप्त करने दें, और वर्तमान सिस्टम से इसके अंतरों की तुलना करें। फिर एक कैनरी करें, इसे केवल कम जोखिम वाले ट्रैफ़िक के एक छोटे से हिस्से के लिए खोलें, जबकि रोलबैक करने की क्षमता बनाए रखें। एक बार निष्पादन रिकॉर्ड स्थिर हो जाने पर, धीरे-धीरे विस्तार करें।

Eval का अंतिम बिंदु एक समझाने योग्य, रोल करने योग्य रिलीज़ निर्णय है।

ऑनलाइन विफलताओं को ऑफ़लाइन मूल्यांकन में वापस आना चाहिए

ऑफ़लाइन डेटा कभी भी वास्तविक दुनिया को पूरी तरह से कवर नहीं कर सकता।

उपयोगकर्ता नए भावों का उपयोग करेंगे, बाहरी वेब पेज लेआउट बदलेंगे, API पहले न देखी गई त्रुटियाँ लौटाएँगे, और व्यावसायिक नीतियाँ अपडेट होंगी। एजेंट के लाइव होने के बाद, Evaluation Framework को काम करते रहना चाहिए।

पूर्ण बंद लूप को इस प्रकार लिखा जा सकता है:

Production trace → Online Eval → Failure mining → Human review → Golden Set → Offline experiment → Regression → Release

ऑनलाइन, आपको हर रिकॉर्ड को सबसे महंगे Judge को भेजने की आवश्यकता नहीं है। आप सस्ती जाँचों से शुरू कर सकते हैं: टूल त्रुटियाँ, खाली आउटपुट, लूप गणना, लागत विसंगतियाँ, लापता उद्धरण, उपयोगकर्ता पुनर्प्रयास, और मानव अधिग्रहण।

फिर इनमें से तीन प्रकार के नमूने निकालें:

• वे कार्य जो स्पष्ट रूप से विफल हुए या अलर्ट ट्रिगर किए;
• वे कार्य जहाँ Judge अनिश्चित है या विभिन्न Grader एक-दूसरे का खंडन करते हैं;
• सामान्य ट्रैफ़िक से यादृच्छिक नमूने।

पहले दो समस्याओं को जल्दी खोजने में मदद करते हैं; यादृच्छिक नमूने उन नई विफलताओं की खोज के लिए जिम्मेदार हैं जिनके बारे में सिस्टम को जानकारी नहीं है।

मानव समीक्षा के बाद, प्रतिनिधि घटनाओं को regression में और नए उच्च-जोखिम पैटर्न को challenge में जोड़ें। यदि समस्या किसी नए ग्राहक या व्यावसायिक खंड से आती है, तो इसे मुख्य परीक्षण सेट के नमूना डिज़ाइन में जोड़ें।

हर बार जब आप किसी Prompt, Model, RAG, Skill, Tool, या Workflow को संशोधित करते हैं, तो उसे मामलों के उसी सेट पर फिर से चलाएँ। एक बार में केवल एक प्रमुख चर बदलें ताकि आप जान सकें कि परिणामों में बदलाव किसके कारण आया।

जैसे-जैसे सिस्टम जटिलता में बढ़ता रहता है, आप Component Lift भी माप सकते हैं।

उदाहरण के लिए, कार्य, मॉडल, वर्कस्पेस और स्कोरर को स्थिर रखें, और केवल यह बदलें कि कोई विशेष Skill लोड है या नहीं:

Skill Lift = Quality(with Skill) - Quality(without Skill)

यही विधि Prompt Lift, RAG Lift, Tool Lift और Memory Lift को माप सकती है। यह आपको एक घटक का सीमांत मूल्य देता है, न कि केवल "नए सिस्टम का कुल स्कोर 85 है।"

मल्टी-एजेंट सिस्टम को इस तुलना की और भी अधिक आवश्यकता है। Planner, Researcher, Critic और Verifier जोड़ने से लागत, विलंबता, हैंडऑफ़ हानि और विफलता बिंदु बढ़ जाते हैं। इसकी तुलना उसी बैच के कार्यों पर सबसे मजबूत एकल-एजेंट आधार रेखा से की जानी चाहिए ताकि यह साबित हो सके कि गुणवत्ता में वृद्धि अतिरिक्त जटिलता को कवर करने के लिए पर्याप्त है।

इस भाग को दूसरे चरण के लिए छोड़ा जा सकता है।

Evaluation Framework के पहले संस्करण को पहले एक एकल एजेंट, एक एकल वर्कफ़्लो और एक स्पष्ट रिलीज़ निर्णय चलाने पर ध्यान देना चाहिए। समस्याएँ बढ़ने पर टूल बढ़ने चाहिए; आपको पहले दिन एक एंटरप्राइज़-ग्रेड Eval OS बनाने की आवश्यकता नहीं है।

एक निर्देशिका से शुरू करें

Agent Evaluation बहुत छोटा हो सकता है।

पहले दिन, आपको केवल एक स्पष्ट कार्य, 30 वास्तविक मामले, कुछ नियतात्मक जाँचें और एक मानव Rubric की आवश्यकता है। इसे चलाने के बाद, विफलताओं को स्पष्ट रूप से वर्गीकृत करें ताकि पता चल सके कि समस्या पुनर्प्राप्ति, टूल, तर्क, सत्यापन या रोक स्थितियों से आती है।

रिलीज़ की तैयारी करते समय, डेटा को 100–300 मामलों तक विस्तारित करें, पूर्ण ट्रेस छोड़ें, LLM Judge को कैलिब्रेट करें, महत्वपूर्ण कार्यों के लिए बार-बार परीक्षण करें, और परिणामों में विश्वास अंतराल और खंड विश्लेषण जोड़ें।

उत्पादन में प्रवेश करने के बाद, शैडो, कैनरी, अलर्ट और रोलबैक कनेक्ट करें। हर वास्तविक घटना एक Regression Case बन जाती है जिसे अगली बार दोहराया नहीं जाएगा।

पीछे मुड़कर देखें, तो पूरी विधि हमेशा एक ही चीज़ के इर्द-गिर्द घूमती रही है:

पहले, स्पष्ट करें कि क्या निर्णय लेने की आवश्यकता है → स्पष्ट रूप से लिखें कि "समाप्त" का क्या अर्थ है → वास्तविक कार्यों के साथ एक डेटासेट बनाएँ → परिणामों और प्रक्षेपवक्र दोनों की जाँच करें → स्तरित स्कोरिंग के लिए Rules, Judge और Human का उपयोग करें → विश्वसनीयता देखने के लिए बार-बार चलाएँ → रिलीज़ निर्णय लेने के लिए Release Gates का उपयोग करें → ऑनलाइन विफलताओं को मूल्यांकन सेट में वापस फीड करें

मॉडल यह निर्धारित करता है कि कार्य पूरा किया जा सकता है या नहीं।

Evaluation Framework यह साबित करने के लिए जिम्मेदार है कि इसे स्थिर, सुरक्षित और समझाने योग्य तरीके से वापस सौंपा जा सकता है।

आगे पढ़ें:

https://x.com/ClorisSignal/status/2090852298620801208