हैलुसिनेशन रोकथाम - Entity Enricher डॉक्युमेंटेशन

हैलुसिनेशन रोकथाम

जब LLM संरचित डेटा उत्पन्न करते हैं, तो वे प्रशंसनीय दिखने वाले तथ्य गढ़ सकते हैं। Entity Enricher 8 डिफ़ेंस लेयर का उपयोग करता है ताकि आपको सटीक डेटा मिले या कोई डेटा न मिले — कभी भी विश्वसनीय-लगने वाली कल्पना नहीं।

संरचित हैलुसिनेशन की समस्या

मुक्त पाठ में, एक मनगढ़ंत वाक्य स्पष्ट रूप से अस्पष्ट होता है। संरचित आउटपुट में, "founded_year": 1987 जैसा एक मनगढ़ंत field आधिकारिक दिखता है और इसे सही मान से अलग कर पाना लगभग असंभव है। तीन कारक इसे विशेष रूप से खतरनाक बनाते हैं:

गलत परिशुद्धता

एक hallucinated JSON मान बिल्कुल एक वास्तविक मान जैसा दिखता है। कोई हिचकिचाहट नहीं, कोई “लगभग” नहीं — बस एक साफ, आत्मविश्वासपूर्ण data बिंदु जो संयोगवश गलत है।

स्कीमा प्रेशर

आवश्यक फ़ील्ड LLM को मान उत्पन्न करने के लिए बाध्य करते हैं, भले ही उसके पास कोई जानकारी न हो। model संरचना में अंतर छोड़ने के बजाय डेटा गढ़ लेता है।

साइलेंट प्रोपेगेशन

संरचित डेटा सीधे डेटाबेस, एनालिटिक्स और ऑटोमेशन में जाता है। एक गलत मान बिना मानवीय समीक्षा के पाइपलाइनों में फैल जाता है।

सामान्य Hallucination पैटर्न

पैटर्नउदाहरणकारण
आत्मविश्वास के साथ गढ़ी गई जानकारी"ceo": "John Smith"LLM आवश्यक फ़ील्ड को किसी संभावित नाम से भर देता है
कालिक भ्रम"revenue": "$2.3B"ट्रेनिंग डेटा कटऑफ़ या अवधियों का घालमेल
Entity कॉन्फ़्लेशनCompany A से एट्रिब्यूट्स Company B परओवरलैपिंग ट्रेनिंग डेटा में मिलते-जुलते नाम
उचित डिफ़ॉल्ट"employees": 500LLM अज्ञानता स्वीकारने के बजाय कोई “उचित” संख्या चुन लेता है
मनगढ़ंत संबंध"subsidiary_of": "Alphabet"LLM एक ऐसे संबंध का अनुमान लगाता है जो मौजूद ही नहीं है

बचाव की 8 परतें

Entity Enricher किसी एकल तकनीक पर निर्भर नहीं करता। यह 8 स्वतंत्र रक्षा परतों को एक-दूसरे पर स्टैक करता है, प्रत्येक एक अलग विफलता मोड को लक्षित करती है। यदि एक परत किसी हैलुसिनेशन को चूक जाती है, तो अगली उसे पकड़ लेती है।

1
प्री-फ्लाइट क्लासिफिकेशन

एनरिचमेंट शुरू होने से पहले, एक तेज़ LLM यह क्लासिफाई करता है कि एंटिटी स्कीमा टाइप से मेल खाती है या नहीं। यह स्रोत पर ही पूरी-एंटिटी हैलुसिनेशन को रोकता है।

उदाहरण: “Planet” स्कीमा के विरुद्ध “Titan” को एक चंद्रमा के रूप में चिह्नित किया जाता है — संवर्धन मॉडल यह संदर्भ प्राप्त करते हैं और ग्रह-विशिष्ट फ़ील्ड के लिए null का उपयोग करते हैं।

2
Nullable फ़ील्ड और कंज़र्वेटिव Prompting

सभी रणनीतियाँ LLM को निर्देश देती हैं: "सटीक और सतर्क रहें — अनुमान लगाने के बजाय null को प्राथमिकता दें।" Nullable स्कीमा फ़ील्ड मॉडल को स्पष्ट रूप से "मुझे नहीं पता" कहने की अनुमति देते हैं।

यह सीधे स्कीमा प्रेशर को संबोधित करता है — जो संरचित हैलुसिनेशन का #1 कारण है।

3
Expert Domain स्कोपिंग

स्कीमा प्रॉपर्टीज़ विशेषज्ञता क्षेत्र के अनुसार समूहीकृत होती हैं। प्रत्येक LLM कॉल केवल अपने क्षेत्र के फ़ील्ड देखती है, और केवल उसी क्षेत्र पर ध्यान केंद्रित करने के निर्देश के साथ।

संकीर्ण दायरा मतलब मतिभ्रम का कम अवसर। एक वित्तीय विशेषज्ञ नियामक डेटा के बारे में कभी अनुमान नहीं लगाता।

4
सर्च की फ़ोकसिंग

कुंजी गुण (is_key: true के रूप में चिह्नित) को प्रॉम्प्ट में हाइलाइट किया जाता है ताकि अन्य फ़ील्ड भरने से पहले LLM को पहचान संबंधी जानकारी पर केंद्रित किया जा सके।

यह मॉडल को ज्ञात तथ्यों पर आधारित करता है, जिससे गढ़े हुए विवरणों की ओर ड्रिफ़्ट कम होती है।

5
स्कीमा सत्यापन और स्व-सुधार

8 validation नियम LLM output में type बेमेल, अमान्य reference और संरचनात्मक errors की जाँच करते हैं। असफल validation ModelRetry को ट्रिगर करता है — errors सुधार के लिए वापस LLM को भेजे जाते हैं।

एक ही agent run में अधिकतम 6 स्वचालित सुधार प्रयास। LLM अपनी ही गलतियाँ ठीक करता है।

6
लॉजिक सुरक्षित रखें

preserve: true के रूप में चिह्नित फ़ील्ड (IDs, SKUs, टाइमस्टैम्प) संवर्धन के बाद अपने मूल इनपुट मानों पर बहाल कर दिए जाते हैं। LLM ग्राउंड ट्रुथ डेटा को ओवरराइट नहीं कर सकता।

सुरक्षित फ़ील्ड: एंटिटी ID, सिस्टम कोड (EAN, SKU), इम्पोर्ट पहचानकर्ता, निर्माण टाइमस्टैम्प।

7
मल्टी-मॉडल सहमति

एक ही एंटिटी को 2+ स्वतंत्र मॉडल के माध्यम से चलाना और आउटपुट की फ़ील्ड-दर-फ़ील्ड तुलना करना। असहमतियों को संभावित हैलुसिनेशन के रूप में चिह्नित किया जाता है।

यदि Claude कहता है कि राजस्व $2.3B है और GPT-4 कहता है $1.8B — तो वह टकराव पहचाना जाता है और सामने लाया जाता है।

8
कॉन्फ्लिक्ट समाधान और आर्बिट्रेशन

पहचाने गए विरोध नियम-आधारित मतदान (बहुमत, माध्यिका, संघ) द्वारा या एक समर्पित LLM arbitrator द्वारा हल किए जाते हैं जो सटीकता, पूर्णता और संगति का मूल्यांकन करता है।

हर arbitration निर्णय में तर्क और कॉन्फ़िडेंस स्तर शामिल होता है — यह पूरी पारदर्शिता देता है कि टकराव कैसे हल किए गए।

डिफेंस पाइपलाइन

1प्री-फ्लाइट क्लासिफिकेशनगलत एंटिटी प्रकारों को ब्लॉक करें
2Nullable + कंज़र्वेटिव Promptsस्कीमा दबाव कम करें
3Expert Domain स्कोपिंगसीमित करें कि LLM को क्या उत्तर देना है
4सर्च की फ़ोकसपहचानकर्ताओं पर आधार रखें
5सत्यापन और स्व-सुधारसंरचनात्मक त्रुटियाँ ठीक करें
6लॉजिक सुरक्षित रखेंग्राउंड ट्रुथ की सुरक्षा करें
7मल्टी-मॉडल सहमतिअसहमतियाँ पहचानें
8कॉन्फ्लिक्ट आर्बिट्रेशनरीज़निंग के साथ रिज़ॉल्व करें
एनरिचमेंट से पहले
एनरिचमेंट के दौरान
एनरिचमेंट के बाद

डिज़ाइन दर्शन

मुख्य सिद्धांत

गलत डेटा की तुलना में अनुपस्थित डेटा हमेशा बेहतर होता है। हर परत इस सिद्धांत को मज़बूत करती है — सिस्टम को इस तरह डिज़ाइन किया गया है कि वह किसी प्रशंसनीय-प्रतीत होने वाली मनगढ़ंत जानकारी के बजाय null लौटाए।

Entity Enricher क्या करता है
  • LLM को null लौटाने की स्पष्ट अनुमति देता है
  • एकाधिक स्वतंत्र models के साथ क्रॉस-वैलिडेट करता है
  • ज्ञात-सही डेटा को ओवरराइट होने से बचाता है
  • कॉन्फ्लिक्ट रिज़ॉल्यूशन में पूरी पारदर्शिता दिखाता है
सामान्य टूल्स क्या करते हैं
  • LLM को हर फ़ील्ड भरने के लिए बाध्य करें, चाहे कुछ भी हो
  • बिना क्रॉस-वैलिडेशन के किसी एक ही model पर निर्भर रहें
  • LLM को इनपुट डेटा को स्वतंत्र रूप से ओवरराइट करने दें
  • बिना किसी ऑडिट ट्रेल के परिणाम एक ब्लैक बॉक्स के रूप में लौटाएँ