एआई हैल्यूसिनेशन पकड़ना: B2B टीमों के लिए 3 गार्डरेल

वास्तविक B2B वर्कफ़्लो में AI हैल्यूसिनेशन कैसे दिखते हैं

हैल्यूसिनेशन तब होता है जब मॉडल आत्मविश्वासी सी सुनाई देने वाली लेकिन ग़लत प्रतिक्रिया देता है। B2B में यह तीन शास्त्रीय रूपों में दिखता है: (1) सपोर्ट क्वेरी के लिए न मौजूद ऑर्डर नंबर गढ़ना, (2) अनुबंध का सारांश देते समय वहाँ न मौजूद तारीख का "उद्धरण" देना, (3) इनवॉइस वर्गीकरण में परिभाषित सेट के बाहर एक नई श्रेणी आविष्कार करना।

तीनों एक ही पैटर्न साझा करते हैं: जब मॉडल वास्तविक एंकर नहीं पाता, वह ख़ालीपन भर देता है। समस्या यह है कि आउटपुट आत्मविश्वासी दिखता है — भले ही ग़लत हो। "AI ग़लत है" क्रियाशील नहीं है; कहाँ और क्यों ग़लत है यह पकड़ना ज़रूरी है। नीचे की तीन गार्डरेल यही करती हैं।

तीन गार्डरेल: स्रोत, नियम, मानव

स्रोत जाँच: उत्तर के साथ सहायक दस्तावेज़ और अंश दिखाएँ; केवल संदर्भ की मौजूदगी नहीं, दावे से उसका संबंध जाँचें। अधूरे या विरोधी प्रमाण समीक्षा के लिए भेजें।

नियम जाँच: एप्लिकेशन में ऑर्डर का अस्तित्व, उपयोगकर्ता का अधिकार, राशि और अनुमत श्रेणी सत्यापित करें। सही प्रारूप तथ्य की सच्चाई साबित नहीं करता।

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

शिप करने से पहले एक मूल्यांकन (eval) प्रक्रिया बनाना

आप आउटपुट को यूँ ही देखकर हैल्यूसिनेशन दर नहीं पकड़ सकते; आपको एक टेस्ट सेट चाहिए। ज्ञात सही उत्तरों वाले 50-200 वास्तविक उदाहरणों का एक "गोल्डन सेट" बनाएँ, और सुनिश्चित करें कि यह एज केस को कवर करे — गुम डेटा, अस्पष्ट प्रश्न, दायरे से बाहर के अनुरोध। इस पर मॉडल को केवल लॉन्च के समय नहीं, बल्कि हर प्रॉम्प्ट या मॉडल परिवर्तन से पहले चलाएँ।

दो अलग-अलग आँकड़ों पर नज़र रखें: सटीकता (क्या इसने सही उत्तर दिया) और परहेज़ दर (abstention rate) (क्या इसने सही ढंग से "मुझे नहीं पता" कहा जब उसे कहना चाहिए था)। एक ऐसा मॉडल जो कभी परहेज़ नहीं करता, आत्मविश्वासी लगता है लेकिन ज़्यादा जोखिम भरा है; एक ऐसा मॉडल जो बहुत ज़्यादा परहेज़ करता है, कष्टप्रद है लेकिन ज़्यादा सुरक्षित है। सही सीमा इस पर निर्भर करती है कि एक ग़लत उत्तर की तुलना में टाले गए उत्तर की लागत कितनी है।

एडवर्सेरियल टेस्टिंग सामान्य-मामले की टेस्टिंग जितनी ही मायने रखती है — जान-बूझकर मॉडल को ऐसे प्रश्न दें जो हैल्यूसिनेशन को ट्रिगर करने के लिए बनाए गए हों: ऐसी संस्थाओं (entities) के बारे में सवाल जो मौजूद ही नहीं हैं, ऐसे अनुरोध जो दो रिकॉर्ड्स को आपस में मिला देते हैं, ऐसे प्रॉम्प्ट जो इससे स्रोत दस्तावेज़ से आगे अनुमान लगाने के लिए कहते हैं। अगर यह एक नियंत्रित परीक्षण में सहजता से विफल नहीं हो सकता, तो यह प्रोडक्शन में भी सहजता से विफल नहीं होगा।

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

किन कार्यों में हैल्यूसिनेशन का सबसे ज़्यादा जोखिम है

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