Agentic AI ROI का मूक हत्यारा
आपके Kubernetes pods हरे (green) हैं। आपकी API latency कम है। आपका LLM provider 99.9% uptime दिखाता है।
फिर भी, आपके ऑटोमेटेड लोन सिस्टम ने तीन घंटों में अपना पूरा मासिक API बजट जला दिया। दो एजेंट एक लूप में फंस गए।
यह "स्वस्थ लेकिन भ्रमित" (Healthy but Hallucinating) विरोधाभास है।
पारंपरिक सॉफ्टवेयर में, एक सिस्टम या तो चालू (up) होता है या बंद (down)। एक एजेंटिक मेश (agentic mesh) में, एक सिस्टम स्वस्थ दिख सकता है लेकिन पूरी तरह से विफल हो सकता है। यदि आप एजेंटों के लिए मानक Site Reliability Engineering (SRE) का उपयोग करते हैं, तो आप गलत संकेतों की निगरानी कर रहे हैं। आप उस मरीज की धड़कन माप रहे हैं जो कार्यात्मक रूप से ब्रेन-डेड (brain-dead) है।
मानक इंफ्रास्ट्रक्चर एजेंटिक पतन (agentic collapse) को रोकने में विफल क्यों रहता है?
पारंपरिक SRE नियतात्मक (deterministic) प्रणालियों के लिए बनाया गया है। जब कोई सेवा विफल होती है, तो वह एक त्रुटि (error) देती है। यह बाइनरी है। एजेंट की विफलताएं अलग होती हैं। एक एजेंट क्रैश नहीं होता। वह भटक (drift) जाता है। वह टाइम आउट नहीं होता। वह एक ऐसा पैरामीटर हैलुसिनेट (hallucinate) करता है जो कुछ चरणों बाद एक मूक विफलता (silent failure) का कारण बनता है।
हम एकल बॉट्स से एंटरप्राइज एजेंट फैब्रिक्स (enterprise agent fabrics) की ओर बढ़ते समय इस अंतर को देखते हैं। एक टीम बेंचमार्क पर 95% सटीकता की रिपोर्ट करती है, लेकिन सिस्टम प्रोडक्शन में विफल हो जाता है। बेंचमार्क यह मापते हैं कि क्या कोई मॉडल किसी प्रश्न का उत्तर दे सकता है। वे यह नहीं मापते कि क्या कोई सिस्टम चार एजेंटों वाले 12-चरणीय वर्कफ़्लो में स्टेट (state) बनाए रख सकता है।
आपको Agent Reliability Engineering (ARE) की आवश्यकता है।
पारंपरिक SRE बाइनरी स्टेट्स को मैनेज करता है। ARE प्रोबेबिलिटी डिस्ट्रीब्यूशन (probability distributions) को मैनेज करता है। यदि आप केवल CPU और मेमोरी को ट्रैक करते हैं, तो आप एजेंट की विफलताओं के प्रति अंधे हैं।
मल्टी-एजेंट सिस्टम में त्रुटियां केवल जुड़ती नहीं हैं। वे गुणा (multiply) होती हैं। क्योंकि एजेंट अन्य एजेंटों के आउटपुट को सत्य के रूप में उपयोग करते हैं, इसलिए पहले चरण में एक छोटी सी त्रुटि पांचवें चरण तक आपदा बन जाती है।
सामान्य विफलता मोड में शामिल हैं:
- Agentic infinite loops (एजेंटिक अनंत लूप)
- State drift (स्टेट ड्रिफ्ट)
- Prompt injection cascades (प्रॉम्प्ट इंजेक्शन कैस्केड)
- Tool-call hallucinations (टूल-कॉल हैलुसिनेशन)
एक खतरनाक उदाहरण: एक एजेंट एक अपडेट टूल को कॉल करता है। वह एक ऐसा पैरामीटर बना देता है जो मौजूद नहीं है। API अतिरिक्त पैरामीटर को अनदेखा कर देता है और 200 OK लौटाता है। एजेंट को लगता है कि वह सफल रहा, लेकिन बिजनेस लॉजिक चुपचाप विफल हो गया।
ARE "इरादा-कार्रवाई-परिणाम" (intent-action-outcome) लूप पर ध्यान केंद्रित करता है। आप केवल यह निगरानी नहीं करते कि क्या एजेंट ने किसी टूल को कॉल किया। आप यह निगरानी करते हैं कि क्या वह कॉल मूल इरादे (intent) से मेल खाती थी और क्या परिणाम लक्ष्य तक पहुँचा।
एजेंट रिलायबिलिटी इंजीनियर (ARE) की भूमिका निम्नलिखित को संभालती है:
- Intent Analysis: यह पता लगाना कि कब एक एजेंट लक्ष्य से भटक जाता है।
- Guardrail Tuning: लूप को रोकने के लिए बाधाओं (constraints) को समायोजित करना।
- Dependability Mapping: यह तय करना कि कब एक एजेंट को मानव को काम सौंपना चाहिए।
- Audit Architecture: आंतरिक तर्क (reasoning) और स्टेट परिवर्तनों को कैप्चर करना।
सटीकता (accuracy) के बारे में बात करना बंद करें। सिस्टम डिपेंडेबिलिटी (System Dependability) के बारे में बात करना शुरू करें।
आप मानवीय हस्तक्षेप की लागत को मापकर इसे CFO को उचित ठहरा सकते हैं। हर बार जब कोई इंसान एजेंट की गलती सुधारता है, तो वह एक रिलायबिलिटी विफलता है। उन घंटों को अपने विशेषज्ञों के वेतन से गुणा करें। अविश्वसनीयता की लागत स्पष्ट हो जाती है।
एजेंटिक एरर बजट (Agentic Error Budgets) का उपयोग करें। एक साधारण ईमेल समराइज़र के लिए, आपका एरर बजट अधिक है। $10M ट्रांसफर करने वाले सिस्टम के लिए, आपका एरर बजट शून्य है।
AI को एक सॉफ्टवेयर फीचर के रूप में न मानें। इसे एक सिस्टमैटिक जोखिम (systemic risk) के रूप में मानें। इस युग के विजेता वे नहीं होंगे जिनके पास सबसे स्मार्ट मॉडल होंगे। उनके पास सबसे भरोसेमंद (dependable) सिस्टम होंगे।
Optional learning community: https://t.me/GyaanSetuAi