एआई एजेंट शायद ही कभी क्रैश होते हैं। वे चुपचाप विफल होते हैं—और शोध बताता है कि ऐसा क्यों होता है

बड़े भाषा मॉडल पर आधारित एजेंट अब सहायता अनुरोधों का जवाब देते हैं, डेटाबेस से जानकारी लेते हैं और यात्राओं की योजना बनाते हैं। जब वे गड़बड़ी करते हैं, तो आम तौर पर आत्मविश्वास से भरा जवाब और सफलता कोड लौटाते हैं। शोध का एक बढ़ता हुआ भंडार बताता है कि इन विफलताओं का पता लगाना कठिन क्यों है और इंजीनियरिंग टीमें इन्हें मापना कैसे सीख रही हैं।

ऐसी विफलता जो सफलता जैसी दिखती है

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

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

मॉडल प्रदाता अपने दस्तावेज़ों में इसी कमी का ज़िक्र करते हैं। Google की Gemini API मार्गदर्शिका बताती है कि मॉडल “फ़ंक्शन को स्वयं निष्पादित नहीं करता”। वह केवल फ़ंक्शन का नाम और तर्क सुझाता है; कॉल डेवलपर का ऐप्लिकेशन चलाता है। इसलिए सिस्टम का सिर्फ़ ऐप्लिकेशन वाला हिस्सा ही असली नतीजा देखता है। एजेंट बनाने के बारे में Anthropic की इंजीनियरिंग मार्गदर्शिका भी इससे जुड़ी बात कहती है: अपनी प्रगति का आकलन करने के लिए एजेंटों को हर चरण पर परिवेश से “वास्तविक स्थिति” की जानकारी चाहिए, जैसे टूल से मिले नतीजे। जब कोई टूल विफलता की सूचना सामान्य पाठ के रूप में देता है, तो वह जानकारी ग़लत होती है और एजेंट के पास इसका पता लगाने का कोई तरीका नहीं होता।

यह समस्या नई नहीं है, बल्कि पुरानी समस्या का और भी स्पष्ट रूप है। 2015 में D. Sculley के नेतृत्व में Google के इंजीनियरों ने मशीन लर्निंग प्रणालियों में “छिपे हुए तकनीकी ऋण” का वर्णन किया। उनका तर्क था कि उत्पादन में चल रही एमएल प्रणाली का अधिकांश जोखिम मॉडल कोड से बाहर—डेटा निर्भरताओं, कॉन्फ़िगरेशन और जोड़ने वाले कोड—में होता है। एजेंट इस सूची में एक नई परत जोड़ते हैं। प्रॉम्प्ट और टूल के विवरण ऐसे कॉन्फ़िगरेशन हैं जो कोड में कोई बदलाव किए बिना सिस्टम का व्यवहार बदल सकते हैं।

छोटे बदलाव, बड़े असर

प्रॉम्प्ट में छोटा-सा बदलाव कितना असर डाल सकता है? ICLR 2024 में प्रस्तुत एक शोधपत्र में University of Washington की Melanie Sclar और उनके सहकर्मियों ने कुछ उदाहरणों वाले प्रॉम्प्ट के केवल फ़ॉर्मैट में बदलाव किया: विभाजक, रिक्त स्थान और बड़े-छोटे अक्षरों का इस्तेमाल। अर्थ वही रहा। फिर भी LLaMA-2-13B पर उसी कार्य में प्रदर्शन का अंतर 76 सटीकता-अंक तक रहा। बड़े मॉडल, अधिक उदाहरणों या निर्देश-आधारित फ़ाइन-ट्यूनिंग से भी यह संवेदनशीलता दूर नहीं हुई।

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

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

एक बार की सफलता बहुत कम बताती है

शोध की एक दूसरी दिशा निरंतरता पर ध्यान देती है। Shunyu Yao और Sierra के सहकर्मियों द्वारा प्रकाशित और ICLR 2025 में प्रस्तुत τ-bench बेंचमार्क ग्राहक सेवा से जुड़ी ऐसी बातचीत का अनुकरण करता है, जिसमें एजेंट को टूल इस्तेमाल करने और कारोबारी नियमों का पालन करने होते हैं। लेखकों ने pass^k नाम का एक माप प्रस्तुत किया: इसकी संभावना कि एजेंट एक ही कार्य को k प्रयासों में हर बार सही ढंग से पूरा करे।

नतीजे चिंताजनक थे। GPT-4o एजेंट ने एक ही प्रयास में खुदरा क्षेत्र के लगभग 61% कार्य हल किए। जब उसे उसी कार्य में लगातार आठ बार सफल होना पड़ा, तो यह दर घटकर लगभग 25% रह गई। एक बार काम करने वाला डेमो यह बताने के लिए पर्याप्त नहीं है कि हज़ारवीं बार चलाने पर सिस्टम कैसा व्यवहार करेगा।

बहु-एजेंट प्रणालियाँ कहाँ विफल होती हैं

अब कई टीमें कई एजेंटों को एक साथ जोड़ती हैं—एक योजना बनाता है, दूसरा उसे लागू करता है और तीसरा काम की जाँच करता है। UC Berkeley के 2025 के एक अध्ययन, “बहु-एजेंट एलएलएम प्रणालियाँ विफल क्यों होती हैं?”, ने सात लोकप्रिय बहु-एजेंट ढाँचों के 1,600 से अधिक टिप्पणी-सहित निष्पादन रिकॉर्ड का विश्लेषण किया। Mert Cemri के नेतृत्व में लेखकों ने MAST नाम का एक वर्गीकरण तैयार किया, जिसमें तीन समूहों के 14 विफलता-प्रकार शामिल हैं: सिस्टम डिज़ाइन की समस्याएँ, एजेंटों के बीच तालमेल की कमी और कार्य का सत्यापन।

उनकी मुख्य खोज यह है कि कई विफलताएँ केवल मूल मॉडल की सीमाओं से नहीं, बल्कि सिस्टम के डिज़ाइन से पैदा होती हैं। एजेंट अपनी तय भूमिका की अनदेखी करते हैं, बातचीत का क्रम भूल जाते हैं या नतीजे की जाँच किए बिना कार्य पूरा होने की घोषणा कर देते हैं। इन विफलताओं का कोई त्रुटि-संदेश नहीं मिलता। वे तभी दिखाई देती हैं जब कोई यह देख सके कि हर एजेंट ने वास्तव में क्या किया। Unite.AI में बहु-एजेंट विरोधाभास पर प्रकाशित लेख वास्तुकला के संदर्भ में इससे जुड़ी बात कहता है: एजेंट जोड़ने से शुरुआती गड़बड़ी दूर होने के बजाय बढ़ सकती है।

अदृश्य को दृश्य बनाना

इंजीनियरिंग का यह समाधान वितरित प्रणालियों से प्रेरित है, जहाँ लंबे समय से ट्रेसिंग नामक तकनीक का उपयोग करके कई सेवाओं में अनुरोधों का पता लगाया जाता रहा है। एजेंटों पर लागू करने पर, उपयोगकर्ता का हर अनुरोध एक ट्रेस बन जाता है और मॉडल या टूल का हर कॉल उसके भीतर एक «स्पैन» बन जाता है। स्पैन में उसका इनपुट, आउटपुट, इस्तेमाल किए गए टोकन और उसे पूरा होने में लगा समय दर्ज होता है। इस काम के लिए उद्योग के मानक तय करने वाली संस्था OpenTelemetry, जनरेटिव एआई स्पैन के लिए साझा परंपराएँ तैयार कर रही है। 2026 तक, इन परंपराओं को अब भी विकासाधीन बताया गया है, इसलिए एट्रिब्यूट के नाम अभी बदल सकते हैं।

Langfuse, Arize Phoenix और AcruxCore जैसे कई ओपन-सोर्स प्रोजेक्ट पहले से ही इस विचार को लागू कर रहे हैं। इनका सोर्स कोड सार्वजनिक है, इसलिए टीमें देख सकती हैं कि ट्रेस किस तरह संग्रहीत किया जाता है और सॉफ़्टवेयर को अपने सर्वरों पर चला सकती हैं। ये एक ही ट्रेस के भीतर मॉडल और टूल कॉल को स्पैन के रूप में दर्ज करते हैं और टीमों को उन पर गुणवत्ता स्कोर जोड़ने देते हैं। टूल का चुनाव एक बात से कम अहम है: टूल स्पैन में यह दर्ज होना चाहिए कि टूल ने वास्तव में क्या लौटाया, न कि केवल यह कि नेटवर्क अनुरोध सफल हुआ या नहीं। इसके बिना, ऊपर बताई गई मौसम-टूल की विफलता अदृश्य बनी रहती है।

उद्योग के सर्वेक्षणों से पता चलता है कि ट्रेसिंग अब आम हो गई है, लेकिन परीक्षण अभी पीछे है। LangChain की एजेंट इंजीनियरिंग की स्थिति पर रिपोर्ट ने 2025 के उत्तरार्ध में 1,340 प्रैक्टिशनरों का सर्वेक्षण किया। एजेंटों को उत्पादन में लागू करने में सबसे बड़ी बताई गई बाधा गुणवत्ता थी; 32% उत्तरदाताओं ने इसका उल्लेख किया। 89% संगठनों ने अपने एजेंटों के लिए किसी न किसी प्रकार की ऑब्ज़र्वेबिलिटी की जानकारी दी, और 62% ने अलग-अलग चरणों और टूल कॉल की विस्तृत ट्रेसिंग की बात कही। केवल 52.4% ने परीक्षण डेटासेट पर ऑफ़लाइन मूल्यांकन किए, और 37.3% ने लाइव ट्रैफ़िक का मूल्यांकन किया। ज़्यादातर टीमें देख सकती हैं कि उनके एजेंटों ने क्या किया। लेकिन इससे कम टीमें यह जाँचती हैं कि वह सही था या नहीं।

बड़े पैमाने पर उत्तरों का मूल्यांकन

ट्रेस दिखाते हैं कि क्या हुआ। वे यह नहीं बताते कि उत्तर अच्छा था या नहीं। हर बातचीत को हाथ से पढ़ना बड़े पैमाने पर संभव नहीं है, इसलिए टीमें तेजी से दूसरे मॉडल का उपयोग मूल्यांकनकर्ता के रूप में कर रही हैं—इस तरीके को एलएलएम-आधारित निर्णयक कहा जाता है। Lianmin Zheng और उनके सहलेखकों के NeurIPS 2023 के एक शोधपत्र में पाया गया कि GPT-4 जैसे सक्षम मॉडल 80% से अधिक मामलों में मानवीय पसंद से सहमत थे—लगभग उतनी ही दर से, जितनी दर से मनुष्य एक-दूसरे से सहमत होते हैं।

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

व्यवहार से नीति तक

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

टीमें अभी क्या कर सकती हैं

यह उस तर्क को दोहराता है जो इस मंच पर दिया गया है कि एजेंटिक एआई की असली कसौटी विश्वसनीयता है। ऊपर दिया गया शोध उस तर्क के पीछे मापन से जुड़ी बारीकियाँ जोड़ता है: विश्वसनीयता ऐसी विशेषता नहीं है जिसे आप एक बार देखकर तय कर लें; यह एक दायरा है जिसे लगातार मापते रहना पड़ता है।

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

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

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