Agentic AI च्या ROI चा मूक भक्षक
तुमचे Kubernetes pods हिरवे (green) आहेत. तुमची API latency कमी आहे. तुमचा LLM प्रदाता 99.9% uptime दाखवत आहे.
तरीही, तुमच्या स्वयंचलित कर्ज प्रणालीने (automated loan system) अवघ्या तीन तासांत आपला संपूर्ण मासिक API बजेट खर्च केले आहे. दोन एजंट्स एका लूपमध्ये अडकले होते.
हा "Healthy but Hallucinating" विरोधाभास आहे.
पारंपारिक सॉफ्टवेअरमध्ये, प्रणाली एकतर सुरू असते किंवा बंद असते. 'एजेंटिक मेश'मध्ये (agentic mesh), प्रणाली निरोगी दिसू शकते परंतु पूर्णपणे अपयशी ठरू शकते. जर तुम्ही एजंट्ससाठी मानक Site Reliability Engineering (SRE) वापरत असाल, तर तुम्ही चुकीच्या संकेतांचे (signals) निरीक्षण करत आहात. तुम्ही अशा रुग्णाच्या हृदयाचे ठोके मोजत आहात जो कार्यात्मकदृष्ट्या मेंदू मृत (brain-dead) झाला आहे.
मानक पायाभूत सुविधा (standard infrastructure) एजेंटिक कोसळण्यापासून (agentic collapse) रोखण्यात का अपयशी ठरतात?
पारंपारिक SRE हे 'डिटरमिनिस्टिक' (deterministic) प्रणालींसाठी बनवले आहे. जेव्हा एखादी सेवा निकामी होते, तेव्हा ती एरर (error) देते. ते बायनरी (binary) असते. एजंटचे अपयश वेगळे असते. एजंट क्रॅश होत नाही. तो भरकटतो (drifts). तो 'टाइम आउट' होत नाही. तो असा एखादा पॅरामीटर 'हॅलुसिनेट' (hallucinate) करतो ज्यामुळे काही स्टेप्सनंतर शांतपणे (silently) बिघाड होतो.
सिंगल बॉट्सकडून एंटरप्राइझ एजंट फॅब्रिक्सकडे (enterprise agent fabrics) वळताना आपल्याला ही तफावत दिसून येते. एखादी टीम बेंचमार्कवर 95% अचूकता (accuracy) नोंदवते, परंतु उत्पादन प्रणालीमध्ये (production) ती अपयशी ठरते. बेंचमार्क हे मॉडेल प्रश्नाचे उत्तर देऊ शकते की नाही हे मोजतात. परंतु चार एजंट्सना समाविष्ट करणाऱ्या 12-स्टेप वर्कफ्लोमध्ये प्रणाली 'स्टेट' (state) राखू शकते की नाही, हे ते मोजत नाहीत.
तुम्हाला Agent Reliability Engineering (ARE) ची गरज आहे.
पारंपारिक SRE बायनरी स्टेट्सचे व्यवस्थापन करते. ARE संभाव्यता वितरणाचे (probability distributions) व्यवस्थापन करते. जर तुम्ही फक्त CPU आणि मेमरी ट्रॅक करत असाल, तर तुम्ही एजंटच्या अपयशांकडे दुर्लक्ष करत आहात.
मल्टी-एजंट सिस्टममधील त्रुटी केवळ वाढत नाहीत, तर त्या गुणाकारात वाढतात. कारण एजंट्स इतर एजंट्सच्या आउटपुटला सत्य मानतात, त्यामुळे पहिल्या स्टेपमधील छोटी चूक पाचव्या स्टेपपर्यंत आपत्ती बनू शकते.
सामान्य अपयशाचे प्रकार (failure modes) खालीलप्रमाणे आहेत:
- एजेंटिक अनंत लूप्स (Agentic infinite loops)
- स्टेट ड्रिफ्ट (State drift)
- प्रॉम्प्ट इंजेक्शन कॅस्केड्स (Prompt injection cascades)
- टूल-कॉल हॅलुसिनेशन्स (Tool-call hallucinations)
एक धोकादायक उदाहरण: एक एजंट 'अपडेट टूल' कॉल करतो. तो असा एखादा पॅरामीटर तयार करतो जो अस्तित्वात नाही. API त्या अतिरिक्त पॅरामीटरकडे दुर्लक्ष करते आणि '200 OK' परत करते. एजंटला वाटते की तो यशस्वी झाला आहे, परंतु बिझनेस लॉजिक शांतपणे (silently) निकामी झाले असते.
ARE "intent-action-outcome" लूपवर लक्ष केंद्रित करते. तुम्ही फक्त एजंटने टूल कॉल केले की नाही याचे निरीक्षण करत नाही. तुम्ही त्या कॉलमुळे मूळ हेतू (intent) पूर्ण झाला का आणि त्याचे परिणाम (outcome) ध्येयापर्यंत पोहोचले का, याचे निरीक्षण करता.
Agent Reliability Engineer (ARE) ची भूमिका खालील गोष्टी हाताळते:
- हेतू विश्लेषण (Intent Analysis): एजंट ध्येयापासून कधी भरकटतो हे शोधणे.
- गार्डरेल ट्यूनिंग (Guardrail Tuning): लूप्स थांबवण्यासाठी मर्यादा (constraints) समायोजित करणे.
- डिपेंडेबिलिटी मॅपिंग (Dependability Mapping): एजंटने मानवाला काम कधी सोपवावे (hand off) हे ठरवणे.
- ऑडिट आर्किटेक्चर (Audit Architecture): अंतर्गत तर्क (reasoning) आणि स्टेटमधील बदल टिपणे.
अचूकतेबद्दल (accuracy) बोलणे थांबवा. सिस्टम डिपेंडेबिलिटीबद्दल (System Dependability) बोलायला सुरुवात करा.
मानवी हस्तक्षेपाचा खर्च मोजून तुम्ही हे CFO ला पटवून देऊ शकता. जेव्हा जेव्हा एखादा माणूस एजंटची चूक सुधारतो, तेव्हा ती एक 'रिलेयबिलिटी फेल्युअर' (reliability failure) असते. त्या तासांचा तुमच्या तज्ज्ञांच्या पगाराने गुणाकार करा. अविश्वासार्हतेचा (unreliability) खर्च स्पष्ट होईल.
'एजेंटिक एरर बजेट्स' (Agentic Error Budgets) वापरा. साध्या ईमेल समरायझरसाठी तुमचे एरर बजेट जास्त असू शकते. परंतु $10M हस्तांतरित करणाऱ्या प्रणालीसाठी तुमचे एरर बजेट शून्य आहे.
AI ला केवळ सॉफ्टवेअर फीचर म्हणून पाहू नका. त्याला एक 'सिस्टेमिक रिस्क' (systemic risk) म्हणून पहा. या युगातील विजेत्यांकडे सर्वात स्मार्ट मॉडेल्स नसतील, तर त्यांच्याकडे सर्वात विश्वसनीय (dependable) सिस्टम्स असतील.
Optional learning community: https://t.me/GyaanSetuAi