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

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

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

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

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

1) स्रोत उद्धरण: मॉडल हर उत्तर को स्रोत दस्तावेज़ के id या पंक्ति संख्या के साथ लौटाता है। स्रोत न हो तो "मुझे नहीं पता" कहता है। हैल्यूसिनेशन लगभग 80% कम होते हैं।

2) नियम पूर्व-जाँच: डोमेन नियमों के विरुद्ध आउटपुट को आने से पहले मान्य करें — क्या ऑर्डर नंबर 8 अंकों का है? क्या इनवॉइस श्रेणी अनुमत सूची में है? क्या तारीख का प्रारूप मान्य है? ये सस्ती Python जाँचें अधिकांश को पकड़ती हैं।

3) मानवीय पूर्व-अनुमोदन: उच्च जोखिम वाली क्रियाएँ (रिफंड, अनुबंध पर हस्ताक्षर) AI द्वारा प्रस्तावित और मानव द्वारा अनुमोदित। AI लगभग 95% स्वयं संभालता है; 5% अपवाद समीक्षा के लिए आपके पास आते हैं।

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

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

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

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

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

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

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

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

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

यह तय करने के लिए इस क्रम (gradient) का उपयोग करें कि गार्डरेल पर मेहनत कहाँ लगानी है। कम-जोखिम, बंद-स्कीमा वाले कार्य अक्सर हल्के वैलिडेशन और स्पॉट चेक के साथ चल सकते हैं। उच्च-जोखिम, ओपन-एंडेड या संख्यात्मक/क़ानूनी कार्य, ऑटोमेशन को किसी ग्राहक या लेजर को छूने देने से पहले, पिछले खंड की पूरी व्यवस्था के हक़दार हैं — स्रोत उद्धरण, नियम-जाँच, और ह्यूमन-इन-द-लूप।