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

प्रोडक्शन में टेक्स्ट बेंचमार्क क्यों विफल हो जाते हैं

स्टैंडर्ड बेंचमार्क पर उच्च स्कोर अब सुकून का एक भ्रामक रूप बन गया है। एक एजेंट जो सुंदर गद्य (prose) लिखता है, वह फिर भी एक ऑपरेशनल खतरा हो सकता है। जब आपका सिस्टम अपॉइंटमेंट बुक करता है, डेटाबेस रिकॉर्ड संपादित करता है, या सपोर्ट टिकट फाइल करता है, तो जनरेट किया गया टेक्स्ट वर्कफ़्लो की केवल दृश्य सतह (visible surface) होती है। इसके नीचे, एजेंट इस बारे में ठोस निर्णय ले रहा होता है कि किस एंडपॉइंट (endpoint) को हिट करना है, क्या पेलोड (payload) भेजना है, और कब रुकना है। यह रीडिंग-कंप्रिहेंशन लीडरबोर्ड में शीर्ष पर हो सकता है, जबकि संसाधनों की डबल-बुकिंग करके, गलत रो (row) को बदलकर, या लॉग फ़ाइल में संवेदनशील स्टेट (sensitive state) लीक करके आपको पैसे का नुकसान पहुँचा सकता है। आपको काम की मैकेनिक्स को सत्यापित करने की आवश्यकता है, न कि केवल आउटपुट की चमक-धमक को। यदि कोई एजेंट ऑफलाइन QA टेस्ट में अच्छा स्कोर कर सकता है और फिर भी लूपिंग या टूल के गलत उपयोग के कारण आपके वर्कफ़्लो को विफल कर देता है, तो आपका मूल्यांकन गलत संकेतों को देख रहा है।

पाँच निर्भरताओं (Dependencies) का मानचित्रण करना

Van Data Team की टीम हर मूल्यांकन की शुरुआत पाँच विशिष्ट कंट्रोल पॉइंट्स का मानचित्रण करके करती है। यह सवाल को पूरी तरह से बदल देता है। आप यह पूछना बंद कर देते हैं कि क्या एक मॉडल दूसरे से स्मार्ट है। आप यह पूछना शुरू करते हैं कि क्या एजेंट वास्तव में आपकी वास्तविक बाधाओं (constraints) के तहत एक प्रोडक्शन टास्क पूरा कर सकता है।

बिजनेस आउटकम्स (Business outcomes)। डॉलर और ग्राहक प्रभाव के संदर्भ में "पूरा" (done) होने का अर्थ परिभाषित करें। कोई कार्य इसलिए पूरा नहीं हो जाता क्योंकि एजेंट ने एक सारांश (summary) जारी किया है। यह तब पूरा होता है जब इन्वेंट्री रिकॉर्ड सटीक हो, अपॉइंटमेंट कन्फर्म हो, और ग्राहक को एक वैध ट्रैकिंग नंबर प्राप्त हो जाए।

म्यूटेबल स्टेट (Mutable state)। ठीक से जानें कि एजेंट को क्या बदलने की अनुमति है। कौन सी टेबल्स, कौन से स्टेटस, कौन से अकाउंट फ्लैग्स? यदि एजेंट रिफंड जारी कर सकता है, जॉब रीशेड्यूल कर सकता है, या बिलिंग एड्रेस अपडेट कर सकता है, तो आपको उसके द्वारा छुए जाने वाले हर फ़ील्ड का इन्वेंट्री बनाना होगा।

टूल परमिशन्स (Tool permissions)। इस बारे में स्पष्ट रहें कि कौन से API एंडपॉइंट्स और फंक्शन्स स्कोप में हैं। एक एजेंट जिसके पास सर्च टूल, राइट टूल और नोटिफिकेशन टूल तक पहुंच है, वह उन्हें मिला देगा यदि सीमाएं धुंधली हैं। प्रत्येक अनुमति को एक विशिष्ट ऑपरेशनल आवश्यकता से मैप करें।

फेलियर रिकवरी (Failure recovery)। तय करें कि क्या होता है जब कैलेंडर API टाइम आउट हो जाता है, 500 एरर देता है, या खराब (malformed) JSON वापस करता है। एजेंट को घबराना नहीं चाहिए, सफलता का संदेश (success message) नहीं बनाना चाहिए, या अनंत काल तक रीट्राई नहीं करना चाहिए। इसे एक स्पष्ट फॉलबैक पाथ (fallback path) की आवश्यकता होती है।

ह्यूमन रिव्यू गेट्स (Human review gates)। उन क्षणों की पहचान करें जहाँ एजेंट के आगे बढ़ने से पहले किसी व्यक्ति का साइन-ऑफ आवश्यक है। यह ऑटोमेशन में कमजोरी का संकेत नहीं है। यह उच्च-प्रभाव वाले परिवर्तनों के लिए एक सेफ्टी वाल्व है और आपके रूब्रिक्स (rubrics) के लिए ग्राउंड-ट्रुथ लेबल का एक स्रोत है।

एक वास्तविक मूल्यांकन योजना कैसी दिखती है

एक बार निर्भरताएँ मैप हो जाने के बाद, आपको एक ऐसी मूल्यांकन योजना की आवश्यकता होती है जो प्रोडक्शन की अव्यवस्था (messiness) से मेल खाती हो। स्लाइड-डेक मेट्रिक्स यहाँ आपकी मदद नहीं करेंगे।

वास्तविक प्रोडक्शन विफलताओं से टेस्ट सेट बनाएं, न कि सिंथेटिक प्रश्न बैंकों से। यदि आपका एजेंट पिछले मंगलवार को दो समान SKUs में भ्रमित होकर विफल रहा था, तो वही भ्रम एक स्थायी टेस्ट केस होना चाहिए। आपका मूल्यांकन सूट हर बार बढ़ना चाहिए जब कोई घटना (incident) आपको कुछ नया सिखाती है।

ऐसे रूब्रिक्स लिखें जो ऑपरेशनल शब्दों में सफल समापन को परिभाषित करें। "सहायक" या "सटीक" जैसे अस्पष्ट मानदंड बेकार हैं। एक उपयोगी रूब्रिक बताता है कि रिफंड कार्य तभी सफल है जब मूल भुगतान आईडी (payment ID) का संदर्भ दिया गया हो, राशि अनुरोध से मेल खाती हो, एक पुष्टिकरण ईमेल कतार (queued) में हो, और ट्रांजेक्शन आईडी लॉग की गई हो।

टूल कॉल्स और रीट्राई के लिए ट्रेस स्पेक्स (trace specs) परिभाषित करें। आपको इस बात की ऑब्जर्वेबिलिटी (observability) की आवश्यकता है कि एजेंट ने क्या योजना बनाई, उसने वास्तव में क्या कॉल किया, उसने कितनी बार रीट्राई किया, और क्या रीट्राई रणनीति उचित थी। टूल-लेवल ग्रैनुलैरिटी (granularity) के बिना एक ट्रेस केवल एक सुंदर कहानी है।

कब इंसान को अलर्ट करना है, इसके लिए नीतियां (policies) निर्धारित करें। एजेंट को अपनी सीमाओं का पता होना चाहिए। यदि कोई अनुरोध डॉलर की सीमा से अधिक है, किसी VIP अकाउंट का संदर्भ देता है, या ऐसी स्थिति (state) का सामना करता है जिसे उसने पहले कभी नहीं देखा है, तो उसे अनुमान लगाने के बजाय मामला आगे बढ़ाना (escalate) चाहिए।

खराब मॉडल अपग्रेड्स को रोकने के लिए release gates इंस्टॉल करें। एक नया मॉडल केवल तभी अपग्रेड माना जाता है जब वह आपके विशिष्ट परिणामों में सुधार करता है। यदि यह टूल आर्गुमेंट्स (tool arguments) को अधिक बार गलत तरीके से प्रस्तुत (hallucinate) करता है, लेटेंसी (latency) बढ़ाता है, या नए सुरक्षा जोखिम पैदा करता है, तो उसे शिप नहीं किया जाना चाहिए। यह गेट प्रोडक्शन को स्थिर रखता है, भले ही बेस मॉडल वेंडर एक नया वर्ज़न जारी कर दे।

Runtime Grading: एजेंट के काम पर नज़र रखना

Anthropic उद्योग को ऑफलाइन टेस्ट से आगे बढ़कर runtime grading की ओर बढ़ने के लिए प्रेरित कर रहा है। किसी ट्रांसक्रिप्ट का बाद में मूल्यांकन करने के बजाय, runtime grading सिस्टम को कार्य के दौरान ही एजेंट के काम का मूल्यांकन करने की अनुमति देती है। इससे त्रुटियों को वास्तविक समस्याओं में बदलने से पहले ही पकड़ने का मौका मिलता है।

एक grader जोड़ने से टोकन और लेटेंसी का खर्च बढ़ता है। आप हर छोटे कदम का मूल्यांकन नहीं कर सकते। प्रत्येक grader का स्थान एक डिज़ाइन संबंधी निर्णय है। उन्हें वहां रखें जहां गलतियां महंगी साबित हो सकती हैं। सबसे मूल्यवान चेकपॉइंट्स डेटाबेस में स्टेट चेंज (state change) करने से ठीक पहले, पेमेंट लेने से ठीक पहले, और ग्राहक को संदेश भेजने से ठीक पहले होते हैं। ये वे क्षण हैं जहां एक गलत निर्णय अपरिवर्तनीय (irreversible) कार्रवाई बन जाता है।

एक विशेष ब्लाइंड स्पॉट (blind spot) का ध्यान रखें। यदि वही मॉडल काम भी करता है और उसका मूल्यांकन भी करता है, तो वह उन्हीं गलतियों को नज़रअंदाज़ कर सकता है। जिस तर्क (reasoning) ने त्रुटि पैदा की है, वह समीक्षा के दौरान आसानी से उस त्रुटि को सही ठहरा सकता है। उच्च-प्रभाव वाले कार्यों के लिए, 'human review' को प्रक्रिया का हिस्सा बनाए रखें। लोगों को grader के निर्णय को सत्यापित करने दें, खासकर तब जब पैसा या ग्राहक का भरोसा दांव पर हो।

यहाँ लक्ष्य परिचालन नियंत्रण (operational control) है। अपने इंसिडेंट डेटा, टास्क रूब्रिक्स (task rubrics) और रनटाइम ट्रेसेस (runtime traces) को एक फीडबैक चक्र में जोड़ें। पूरे पथ का मूल्यांकन करें: योजना, टूल का उपयोग, रिकवरी व्यवहार और अंतिम परिणाम। रिलीज़ से पहले ज्ञात और दोहराने योग्य त्रुटियों को पकड़ने के लिए ऑफलाइन टेस्ट का उपयोग करें। उन नई विफलताओं को खोजने के लिए रनटाइम ट्रेसेस का उपयोग करें जिनकी आपने अपेक्षा नहीं की थी। यह पता लगाने के लिए कि आपके रूब्रिक्स कहाँ सरल हैं और उन्हें और सख्त करने की आवश्यकता है, मानव समीक्षा (human review) का उपयोग करें।

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

एक महंगी गलती से शुरुआत करें

परिचालन मूल्यांकन (Operational evaluation) कोई शोध अभ्यास नहीं है। यह एजेंट के लाइव होने के बाद चैन की नींद सोने का एक तरीका है। आपको पहले दिन एक परफेक्ट फ्रेमवर्क की आवश्यकता नहीं है। आपको केवल एक स्पष्ट रूप से परिभाषित वर्कफ़्लो, सरल व्यावसायिक शब्दों में लिखा गया एक रूब्रिक, और उस सटीक क्षण पर रखा गया एक grader चाहिए जहां त्रुटि महंगी हो जाती है। इसे सही कर लें, और आपके पास एक ऐसा आधार होगा जिस पर आप वास्तव में भरोसा कर सकते हैं।

यदि आप विशेषज्ञों के समुदाय के साथ एजेंट मूल्यांकन और रनटाइम ग्रेडिंग के बारे में गहराई से जानना चाहते हैं, तो आप GyaanSetu लर्निंग कम्युनिटी को https://t.me/GyaanSetuAi पर पा सकते हैं।