अधिकांश इंजीनियरिंग टीमें अभी भी AI एजेंटों का मूल्यांकन उसी तरह करती हैं जैसे वे गणित के होमवर्क को ग्रेड देती हैं। वे केवल अंतिम आउटपुट को देखते हैं। यदि उत्तर सही है, तो वे रिलीज़ को हरी झंडी दे देते हैं और आगे बढ़ जाते हैं। यह एक खतरनाक शॉर्टकट है। एक सही उत्तर एक गहराई से खराब सिस्टम को छिपा सकता है।
असली कहानी उस रास्ते में छिपी होती है जिससे होकर एजेंट वहां तक पहुँचा। उस रास्ते को 'एजेंट ट्रेजेक्टरी' (agent trajectory) कहा जाता है। इसमें हर टूल कॉल (tool call), हर रूटिंग निर्णय और हर वह ठहराव शामिल है जहाँ एजेंट पुनर्विचार करने के लिए रुकता है। आप इसे एजेंट के 'ब्रेडक्रंब ट्रेल' (trail of breadcrumbs) के रूप में सोच सकते हैं। और यदि आप केवल गंतव्य का निरीक्षण करते हैं, तो आप रास्ते में बिखरे हुए सभी चेतावनी संकेतों को नज़रअंदाज़ कर देते हैं।
अव्यवस्थित रास्तों की समस्या
एक एजेंट एक नशे में धुत ड्राइवर की तरह व्यवहार करते हुए भी सही उत्तर तक पहुँच सकता है। वह गलत टूल्स के बीच डगमगाता है, राउटर की ओर वापस मुड़ता है, और अंततः कुछ सही चीज़ तक पहुँचने से पहले अनावश्यक तर्क (redundant reasoning) के चक्र में फँस जाता है। उपयोगकर्ता को एक साफ परिणाम दिखाई देता है। लेकिन पर्दे के पीछे, सिस्टम संसाधनों को बर्बाद कर रहा होता है और जोखिम बढ़ा रहा होता है।
व्यवहार में यह अव्यवस्था वास्तव में कैसी दिखती है?
सबसे पहले, 'रिडंडेंट टूल कॉल' (redundant tool call) की समस्या होती है। एजेंट आपके कस्टमर डेटाबेस को क्वेरी करता है, परिणाम प्राप्त करता है, पाँच सेकंड बाद उसे भूल जाता है, और फिर से समान मापदंडों (parameters) के साथ उसी रिकॉर्ड को क्वेरी करता है। यह डेटा की समस्या नहीं है। यह ट्रेजेक्टरी की समस्या है। एजेंट 'स्टेट' (state) बनाए रखने में विफल रहा, इसलिए वह काम को दोहराता है।
फिर 'wrong-tool-first' पैटर्न आता है। एक कोडिंग एजेंट उस फंक्शन डेफिनेशन को वेब पर खोजने की कोशिश कर सकता है जो पहले से ही लोकल रिपॉजिटरी में मौजूद है। या एक सपोर्ट एजेंट बिलिंग API का उपयोग कर सकता है जबकि उपयोगकर्ता का प्रश्न स्पष्ट रूप से अकाउंट सेटिंग्स टूल की मांग करता है। प्रत्येक गलत चुनाव टोकन खर्च करता है, लेटेंसी (latency) बढ़ाता है, और इस बात की संभावना बढ़ा देता है कि वास्तविक काम शुरू होने से पहले ही कॉन्टेक्स्ट लिमिट (context limits) खत्म हो जाए।
'राउटर लूप्स' (Router loops) एक और रेड फ्लैग हैं। निर्णय नोड (decision node) प्रतिबद्ध नहीं हो पाता। वह कार्य को ब्रांच A पर भेजता है, फिर अपना विचार बदलता है, उसे वापस खींचता है, ब्रांच B पर भेजता है, और फिर बिना किसी कारण के उसे एक सामान्य-उद्देश्य वाले फॉलबैक नोड (fallback node) के माध्यम से रूट करता है। प्रत्येक लूप एक नेटवर्क हॉप (network hop) जोड़ता है और अंततः डिबग लॉग (debug log) में भ्रम की एक और परत जोड़ देता है।
अंत में, 'रिपीटेड एनालिसिस' (repeated analysis) की समस्या होती है। एजेंट किसी निष्कर्ष को तय मानने के बजाय हर कदम पर उसी निष्कर्ष को बार-बार निकालने की कोशिश करता रहता है। यह एक ऐसे बढ़ई की तरह है जो हर कट से पहले बोर्ड को दस बार मापता है। पहला माप ठीक था। अगले नौ माप केवल समय की बर्बादी हैं।
इन अतिरिक्त कदमों के वास्तविक परिणाम होते हैं। लेटेंसी (latency) बढ़ती जाती है। एक सिंक्रोनस चैट इंटरफ़ेस में, अतिरिक्त तीन सेकंड एक युग की तरह महसूस होते हैं। बड़े पैमाने पर, वे सेकंड कंप्यूटिंग लागत के रूप में हजारों डॉलर में बदल जाते हैं। विफलता का जोखिम भी बढ़ता है। प्रत्येक अनावश्यक हॉप (hop) एक बाहरी API के टाइम आउट होने, कॉन्टेक्स्ट विंडो के ओवरफ्लो होने, या रेस कंडीशन (race condition) के सामने आने का एक और अवसर है। और जब कुछ टूटता है, तो ऐसे ट्रेस (trace) को डिबग करने के लिए शुभकामनाएँ जो स्पैगेटी (spaghetti) जैसा दिखता हो। आप यह समझने में घंटों बिता देंगे कि एजेंट ने सातवां कदम क्यों उठाया, केवल यह महसूस करने के लिए कि सातवां कदम कभी होना ही नहीं चाहिए था।
कन्वर्जेंस (Convergence) का वास्तव में क्या अर्थ है
यदि ट्रेजेक्टरी रास्ता है, तो कन्वर्जेंस उसकी दक्षता (efficiency) का माप है। कन्वर्जेंस आपको बताता है कि एजेंट उपयोगकर्ता के अनुरोध और सही समाधान के बीच सबसे छोटे व्यवहार्य मार्ग (shortest viable route) का कितनी बारीकी से पालन करता है।
यह सटीकता (accuracy) के समान नहीं है। सटीकता एक मोटा पैमाना है। यह पूछता है कि क्या अंतिम स्थिति सही है। कन्वर्जेंस पूछता है कि क्या यात्रा तर्कसंगत थी। उच्च सटीकता और कम कन्वर्जेंस वाला एजेंट सफलता का मुखौटा पहने हुए एक देनदारी (liability) है। उच्च कन्वर्जेंस और औसत सटीकता वाला एजेंट आमतौर पर ठीक करना आसान होता है, क्योंकि उसका तर्क स्पष्ट होता है और उसकी गलतियाँ सीमित (localized) होती हैं।
आप उस टास्क क्लास के लिए आपके द्वारा परिभाषित सबसे छोटे पथ की तुलना में एजेंट द्वारा वास्तव में लिए गए कदमों की तुलना करके एक अनुमानित कन्वर्जेंस स्कोर की गणना कर सकते हैं। यदि एक मानक रिफंड क्वेरी के लिए ठीक तीन टूल कॉल की आवश्यकता होनी चाहिए और एजेंट ने नौ का उपयोग किया, तो आपका कन्वर्जेंस अनुपात गिर रहा है। आप विभिन्न प्रकार की बर्बादी को वेटेज (weighting) देकर इसे और बेहतर बना सकते हैं। टूल की लेटेंसी और कीमत के आधार पर, एक गलत टूल कॉल एक रिडंडेंट कॉल की तुलना में अधिक महंगा हो सकता है। एक राउटर लूप जो कोई मूल्य नहीं जोड़ता है, सबसे भारी दंड (penalty) दे सकता है, क्योंकि यह आर्किटेक्चरल