सपोर्ट एजेंट ने टू-फैक्टर ऑथेंटिकेशन (two-factor authentication) रीसेट करने के यूजर के अनुरोध का उत्तर ऐसे चरणों के साथ दिया जो वास्तव में मौजूद ही नहीं थे। प्रतिक्रिया आत्मविश्वास से भरी लग रही थी, HTTP अनुरोध ने 200 OK लौटाया, लेटेंसी (latency) सामान्य थी और हर मॉनिटरिंग चार्ट हरा (green) बना हुआ था।
एक AI-संचालित सपोर्ट एजेंट ने एक गलत उत्तर (hallucinated answer) दे दिया क्योंकि वे आंतरिक चेक, जिन्हें इस त्रुटि को पकड़ना चाहिए था, कभी चले ही नहीं। डैशबोर्ड, जिन पर इंजीनियर भरोसा करते हैं, उन्होंने एक सफल रन की रिपोर्ट दी, जबकि एजेंट चुपचाप एक समाधान गढ़ रहा था।
पारंपरिक डैशबोर्ड AI हैलुसिनेशन (hallucinations) को क्यों नहीं पकड़ पाते
अधिकांश ऑब्जर्वेबिलिटी स्टैक (observability stacks) एक AI एजेंट को किसी अन्य माइक्रोसर्विस की तरह मानते हैं: एक सिंगल इनबाउंड अनुरोध और एक सिंगल आउटबाउंड प्रतिक्रिया। वे HTTP स्टेटस, रिस्पॉन्स टाइम और एरर काउंट को लॉग करते हैं। वे अनुरोध के भीतर के छिपे हुए चरणों को लॉग नहीं करते हैं – जैसे बाहरी दस्तावेजों की प्राप्ति (retrieval), लार्ज लैंग्वेज मॉडल्स (LLMs) को कॉल करना, सहायक टूल्स का उपयोग, और कोई भी गार्ड-रेल लॉजिक (guard-rail logic) जो आउटपुट को सत्यापित करता है।
जब कोई रिट्रीवल स्टेप (retrieval step) खाली परिणाम लौटाता है, तो मॉडल अक्सर "अंतराल को भरने" के लिए विश्वसनीय लगने वाले टेक्स्ट का उपयोग करता है। मॉनिटरिंग सिस्टम के दृष्टिकोण से कॉल सफल रही, क्योंकि कुछ भी क्रैश नहीं हुआ और स्टेटस कोड 200 ही रहा। हैलुसिनेशन अदृश्य बना रहता है, और एकमात्र लक्षण यूजर तक पहुँचने वाला गलत उत्तर होता है।
एक ब्लैक बॉक्स को पठनीय ट्री (tree) में बदलना
विश्वसनीय डिबगिंग का पहला कदम एजेंट को एक मोनोलिथिक कॉल (monolithic call) के रूप में मानना बंद करना और प्रत्येक आंतरिक ऑपरेशन को ट्रेस टेबल (trace table) में अपनी एक अलग पंक्ति के रूप में विज़ुअलाइज़ करना शुरू करना है। एक सामान्य रन इन चरणों में विभाजित होता है:
- टॉप-लेवल एजेंट इनवोकेशन (agent invocation)
- रिट्रीवल स्टेप जो प्रासंगिक दस्तावेज़ निकालता है
- प्रत्येक लैंग्वेज-मॉडल इन्फरेंस (inference) जो प्राप्त डेटा को प्रोसेस करता है
- प्रत्येक टूल कॉल (जैसे, डेटाबेस लुकअप, API अनुरोध)
- गार्ड-रेल चेक जो तथ्यात्मकता या पॉलिसी अनुपालन को लागू करते हैं
प्रत्येक पंक्ति टाइमस्टैम्प, सक्सेस फ्लैग और उस पेलोड को रिकॉर्ड करती है जो उस चरण से गुजरा। इस संरचना के साथ, निष्पादन (execution) एक ट्री बन जाता है जिसका अंतिम आउटपुट से अनुमान लगाने के बजाय लाइन-दर-लाइन निरीक्षण किया जा सकता है।
वह बग जो निकल गया
दोषपूर्ण सपोर्ट इंटरैक्शन में ट्रेस कुछ इस तरह था:
- Retrieval चला लेकिन कोई दस्तावेज़ नहीं लौटाया।
- अगला चरण फिर भी आगे बढ़ गया, मॉडल को एक खाली कॉन्टेक्स्ट (context) पास कर दिया।
- मॉडल ने एक ऐसा उत्तर तैयार किया जिसने गायब जानकारी को मनगढ़ंत चरणों से भर दिया।
- सिस्टम ने 200 लौटाया क्योंकि पाइपलाइन में कोई अपवाद (exception) नहीं आया।
हैलुसिनेशन लैंग्वेज मॉडल की अपनी खामी नहीं थी; यह रिट्रीवल और जनरेशन चरणों के बीच एक गायब गार्ड-रेल थी। एजेंट ने तब भी उत्तर दिया जब उसके पास अपने उत्तर को पुख्ता करने के लिए कुछ भी नहीं था।
सरल गार्ड-रेल्स जो हैलुसिनेशन को रोकते हैं
दो ठोस बदलावों ने समस्या को समाप्त कर दिया:
- खाली रिट्रीवल पर रोकें (Abort on empty retrieval) – यदि डॉक्यूमेंट स्टोर कुछ भी नहीं लौटाता है, तो एजेंट को जनरेशन की ओर बढ़ने के बजाय "मुझे वह जानकारी नहीं मिली जिसकी आपको आवश्यकता है" के साथ उत्तर देना चाहिए।
- ग्राउंडिंग चेक (Grounding check) – मॉडल द्वारा प्रतिक्रिया देने के बाद, सत्यापित करें कि प्रत्येक तथ्यात्मक दावा प्राप्त सामग्री में मौजूद है। यदि चेक विफल हो जाता है, तो उत्तर को अस्वीकार कर दें और "उत्तर नहीं दे सकते" वाली प्रतिक्रिया पर वापस जाएँ।
तेज़ डिबगिंग के लिए एक व्यावहारिक वर्कफ़्लो
- प्रत्येक आंतरिक कॉल को ट्रेस करें – एजेंट को इस तरह इंस्ट्रूमेंट (instrument) करें कि प्रत्येक रिट्रीवल, मॉडल इन्फरेंस और टूल का उपयोग एक स्थायी लॉग (persistent log) में एक पंक्ति लिखे।
- विफल रन को सुरक्षित रखें – किसी भी ऐसे इंटरैक्शन का पूरा ट्रेस स्टोर करें जिसे यूजर ने गलत बताया हो। स्टोरेज बचाने के लिए उन्हें हटाना, रिग्रेशन (regressions) खोजने के लिए आवश्यक डेटा को छिपा देता है।
- वर्जन जानकारी के साथ रन को टैग करें – प्रत्येक ट्रेस पंक्ति में रिलीज़ आइडेंटिफायर और किसी भी फीचर-फ्लैग (feature-flag) की स्थिति शामिल करें। यह आपको एक नए बग को हाल ही में किए गए कोड परिवर्तन के साथ जोड़ने में मदद करता है।
- केवल गति नहीं, गुणवत्ता को स्कोर करें – ऐसे मेट्रिक्स जोड़ें जो यह मापें कि उत्तर निर्देशों का कितनी अच्छी तरह पालन करता है और प्राप्त सामग्री में कितना सटीक (grounded) रहता है। यदि उत्तर गलत हैं, तो उच्च थ्रूपुट (throughput) का बहुत कम महत्व है।
- दैनिक विफलताओं (failures) की समीक्षा करें – स्टोर की गई विफलताओं की संक्षिप्त, नियमित समीक्षा अक्सर पैटर्न (जैसे, एक विशेष प्रकार का क्वेरी लगातार खाली रिट्रीवल लौटाता है) को तब प्रकट कर देती है जब वे कई उपयोगकर्ताओं को प्रभावित करने लगते हैं।
"ग्रीन" को "वेरिफाइड" (verified) में बदलकर, टीमें हैलुसिनेशन को जल्दी पकड़ सकती हैं और यूजर अनुभव को भरोसेमंद बनाए रख सकती हैं।
आंतरिक विफलताओं को नज़रअंदाज़ करने की कीमत
जब डैशबोर्ड केवल HTTP लेयर पर सफलता की रिपोर्ट करते हैं, तो संगठन ऐसे एजेंट तैनात करते हैं जो विश्वसनीय प्रतीत होते हैं लेकिन नियमित रूप से गलत मार्गदर्शन प्रदान करते हैं।
आगे क्या देखें
जब तक वे आम नहीं हो जाते, सबसे सुरक्षित दृष्टिकोण यह है कि प्रत्येक आंतरिक ऑपरेशन को ऑब्जर्वेबल (observable) माना जाए और प्रमाण की कमी होने पर तुरंत विफल (fail fast) हो जाया जाए।
मुख्य बात: एक हरा डैशबोर्ड आपको बताता है कि प्लंबिंग (प्रणाली) काम कर रही है; यह इस बात की गारंटी नहीं देता कि उत्तर सही है। प्रत्येक रिट्रीवल, मॉडल कॉल और गार्ड-रेल चेक को ट्रेस करके, आप छिपे हुए मतिभ्रम (hallucinations) को ऐसी दृश्य विफलताओं में बदल देते हैं जिन्हें उपयोगकर्ता तक पहुँचने से पहले ठीक किया जा सकता है।