जब आप एक ही एनरिचमेंट को कई AI मॉडलों पर चलाते हैं, तो Entity Enricher परिणामों को एक एकल, उच्च-कॉन्फ़िडेंस आउटपुट में फ्यूज़ कर सकता है। फ्यूज़न मॉडल आउटपुट के बीच टकरावों का पता लगाता है और उन्हें नियतात्मक नियमों या LLM-संचालित आर्बिट्रेशन का उपयोग करके हल करता है।
कॉन्फ्लिक्ट डिटेक्टर सभी मॉडल आउटपुट में हर फ़ील्ड की तुलना करता है। जिन फ़ील्ड पर सभी मॉडल सहमत होते हैं वे अपरिवर्तित पास हो जाती हैं। जिन फ़ील्ड पर मॉडल असहमत होते हैं उन्हें ऐसे विरोध के रूप में चिह्नित किया जाता है जिन्हें हल करने की आवश्यकता होती है।
| प्रकार | तुलना कैसे की गई | सहमति का अर्थ |
|---|---|---|
| स्केलर | सामान्यीकृत सटीक मिलान (ट्रिम किया गया, लोअरकेस, राउंड किया गया) | सामान्यीकरण के बाद सभी मान समान हैं |
| बहुभाषी | रन की प्राथमिक भाषा तय करती है; अनुवाद के अंतर केवल प्रति-भाषा मर्ज को ट्रिगर करते हैं | प्राथमिक भाषा में वही टेक्स्ट — किसी अनुवाद के शब्दावली रूप असहमति नहीं हैं |
| Array | आइटम के प्राथमिक-भाषा दृश्य पर सेट तुलना (क्रम-निरपेक्ष) | क्रम या अनुवाद की शब्दावली चाहे जो हो, वही आइटम |
| Object | जब तक identity फ़ील्ड यह साबित करती हैं कि दोनों मॉडल एक ही चीज़ का वर्णन कर रहे हैं, तब तक प्रति-प्रॉपर्टी — अन्यथा पूरा ऑब्जेक्ट एक ही कॉन्फ़्लिक्ट है | सभी नेस्टेड प्रॉपर्टीज़ मेल खाती हैं |
| null / खाली | null, खाली-स्ट्रिंग, या खाली-ऐरे मान एक परहेज़ है, दावा नहीं | भरा हुआ मान किसी टकराव को गिने बिना जीत जाता है |
डिटर्मिनिस्टिक नियम हर फ्यूज़न पर चलते हैं और वह सब कुछ तय कर देते हैं जिसे मॉडलों के अपने मान सिद्ध कर सकते हैं। जिन मामलों में वे किसी उत्तर को केवल वरीयता दे सकते हैं — कोई विरोधाभासी मान, कोई नेस्टेड ऑब्जेक्ट जिसे मॉडल अलग-अलग तरह से बताते हैं, कोई ऐसा आइटम जिसे केवल एक ही मॉडल ने बनाया — उन्हें एक रिज़ॉल्वर के पास भेजा जाता है। साइडबार में आर्बिट्रेशन मॉडल चुनना यह तय करता है कि वह रिज़ॉल्वर कौन होगा: स्वयं नियम, या कोई LLM।
प्रत्येक फ़ील्ड के डेटा टाइप के आधार पर डिटर्मिनिस्टिक नियम लागू किए जाते हैं। लगभग हमेशा इसके लिए किसी LLM कॉल की ज़रूरत ही नहीं पड़ती — समाधान तुरंत और मुफ़्त होता है। एकमात्र अपवाद वे संख्याएँ हैं जिन पर मॉडलों में भारी असहमति होती है और जिन्हें कोई नियम ईमानदारी से तय नहीं कर सकता; नीचे देखें।
| फ़ील्ड टाइप | नियम | औचित्य |
|---|---|---|
| स्ट्रिंग | बहुमत मत; बराबरी होने पर सबसे लंबा मान चुना जाता है | आमतौर पर ज़्यादा विवरण बेहतर होता है |
| Number | मीडियन के सबसे नज़दीक मॉडल मान | आउटलायर्स के प्रति सुदृढ़, कभी कोई मनगढ़ंत औसत नहीं |
| बूलियन | बहुमत; बराबरी में true जीतता है | रूढ़िवादी डिफ़ॉल्ट |
| बहुभाषी | प्रति-भाषा बहुमत मत, भाषाओं का यूनियन | हर भाषा स्वतंत्र रूप से हल की जाती है |
| Array | की-अवेयर यूनियन: आइटम अपने की फ़ील्ड पर समूहित होते हैं, वर्तनी के रूप एक साथ मिल जाते हैं, मेल खाते आइटम प्रति-फ़ील्ड मर्ज होते हैं | प्रति लॉजिकल एंटिटी एक पंक्ति, कुछ भी नहीं खोता |
| Object | जब identity मेल खाती है तो प्रति-फ़ील्ड; अन्यथा किसी एक मॉडल का ऑब्जेक्ट पूरा का पूरा लिया जाता है | अलग-अलग एंटिटी बताने वाले दो ऑब्जेक्ट को मिलाने से एक तीसरी एंटिटी गढ़ जाएगी, जो किसी भी मॉडल ने नहीं लौटाई |
| Null बनाम मान | भरे हुए मान को प्राथमिकता दें | अनुपस्थित डेटा किसी भी मान से बदतर है |
टाई-ब्रेकर: जब वोट बराबर हों, तो अधिक क़ीमत वाले मॉडल का मान जीतता है (क्षमता के संकेतक के रूप में), उसके बाद मॉडल नाम का वर्णक्रमानुसार क्रम। परमाणु रूप से लिए गए पूरे ऑब्जेक्ट के लिए, इन दोनों के बीच पूर्णता आती है — यानी भरी हुई लीव्स की संख्या: जब यह साबित करने को कुछ न हो कि कौन-सी एंटिटी असली है, तो पहले मज़बूत मॉडल को प्राथमिकता दें, फिर उस उत्तर को जो अधिक जानकारी रखता है।
किसी नेस्टेड ऑब्जेक्ट को फ़ील्ड-दर-फ़ील्ड मर्ज करना तभी सुरक्षित है जब दोनों मॉडल एक ही चीज़ का वर्णन कर रहे हों। जब पहचान फ़ील्ड यह साबित न करें — अलग-अलग कीज़, या कोई की ही नहीं और नीचे वास्तविक असहमति — तब पूरा ऑब्जेक्ट एक ही टकराव बन जाता है और किसी एक मॉडल का संस्करण ज्यों का त्यों ले लिया जाता है। अन्यथा फ़्यूज़न एक काइमेरा गढ़ देगा: इस मॉडल का पता उस मॉडल की कंपनी पर। इसका एक परिणाम जानबूझकर रखा गया है पर जानने योग्य है: विजेता को उसकी रिक्तियों सहित लिया जाता है, इसलिए विजेता ने जो फ़ील्ड खाली छोड़ा वह खाली ही रहता है — जो एंटिटी को डेटाबेस प्रवेश द्वार पर रोक सकता है। इसका कारण रन की वैलिडेशन चेतावनियों में साथ चलता है।
“माध्यिका के सबसे निकट” उन मॉडलों के लिए सही है जो अलग-अलग तरह से राउंड करते हैं, और उन मॉडलों के लिए ग़लत है जो एक-दूसरे का खंडन करते हैं — 0 बनाम 1854 राउंडिंग का अंतर नहीं है। जब मानों का सापेक्ष फैलाव 20% तक पहुँच जाता है, तो वह फ़ील्ड आपके संगठन के सामान्य मॉडल चयन के ज़रिए स्वतः चुने गए एक LLM आर्बिटर को सौंप दी जाती है, और उस कॉल का बिल किसी भी अन्य कॉल की तरह बनता है। ऐसी फ़ील्ड्स फ्यूजन ऑडिट ट्रेल में ऑटो-एस्केलेटेड के रूप में चिह्नित होती हैं, ताकि जिस मर्ज में टोकन खर्च हुए हों वह हमेशा बताए कि किन फ़ील्ड्स की वजह से ऐसा हुआ।
जब आप साइडबार में कोई आर्बिट्रेशन मॉडल चुनते हैं, तो जिन प्रश्नों को नियम तय नहीं कर सके, वे उसी LLM के सामने रखे जाते हैं। वह एंटिटी की पहचान, हर फ़ील्ड का विवरण, और हर मॉडल का मान आपकी प्राथमिक एनरिचमेंट भाषा में देखता है — और वह इशारा करके उत्तर देता है, कभी अपना कोई मान लिखकर नहीं।
प्रश्न स्तर-दर-स्तर पूछे जाते हैं: पहले स्वयं एंटिटी, फिर हर मिलान किया गया ऐरे आइटम अपने अलग कॉल में, अपनी पहचान को संदर्भ के रूप में लेकर (“इस ओपेरा का अंक I”) — और जिस आइटम को आर्बिटर ने हटा दिया, उसके बारे में दोबारा कभी नहीं पूछा जाता। प्रॉम्प्ट का साझा हिस्सा पहले कॉल द्वारा कैश कर लिया जाता है, इसलिए गहरे स्तर के कॉल लागत के एक अंश पर समानांतर रूप से चलते हैं।
फ़ॉलबैक: यदि आर्बिट्रेशन मॉडल विफल हो जाता है (टाइमआउट, त्रुटि), तो नियम-आधारित निर्णय ही लागू रहते हैं, इसलिए आपको परिणाम हमेशा मिलता है — और रिकॉर्ड बताता है कि कौन-सी विधि लागू हुई।
कॉन्फ्लिक्ट समाधान के बाद, सिस्टम एक एकल मर्ज किया गया परिणाम बनाता है और उसे डेटाबेस में “आर्बिट्रेशन” रिकॉर्ड के रूप में संग्रहीत करता है। प्रत्येक मर्ज किए गए परिणाम में एक ऑडिट ट्रेल शामिल होता है ताकि आप ट्रेस कर सकें कि प्रत्येक कॉन्फ्लिक्ट कैसे हल हुआ।
हर मर्ज किया गया परिणाम मेटाडेटा शामिल करता है जो फ्यूज़न प्रक्रिया को प्रलेखित करता है:
यही ऑडिट ट्रेल इतिहास पेज पर किसी भी मर्ज किए गए रिकॉर्ड के लिए, उसके अवलोकन टैब में दिखाया जाता है। ऐरे के भीतर लिए गए निर्णय — किसी मिलान किए गए आइटम का फ़ील्ड, कोई आइटम रखा गया या हटाया गया — भी सूचीबद्ध होते हैं, ताकि जो छोड़ा गया वह उतना ही स्पष्ट दिखे जितना जो रखा गया। LLM द्वारा आर्बिट्रेट किए गए रिकॉर्ड में उसके आर्बिटर को ही उसका मॉडल बताया जाता है; वहीं नियम-आधारित मर्ज में उन मॉडलों की सूची होती है जिन्हें मर्ज किया गया, क्योंकि उसमें कोई LLM कॉल हुई ही नहीं और उसका कोई प्रॉम्प्ट, कोई टोकन और कोई लागत नहीं होती।
फ्यूज़न पूरा होने के बाद, परिणाम पैनल में “Merged” टैब दिखाता है:
बैच एनरिचमेंट में, जब आप दो या ज़्यादा मॉडल चुनते हैं तो फ्यूजन अपने-आप होता है। आपको “Merge Results” पर मैन्युअली क्लिक करने की ज़रूरत नहीं — किसी एंटिटी के लिए जैसे ही हर मॉडल सफल हो जाता है, फ्यूजन चल पड़ता है और मर्ज किया गया नतीजा अलग-अलग मॉडल आउटपुट के साथ दिखने लगता है। जिस रन में कोई एक मॉडल फ़ेल हुआ हो, उसे जान-बूझकर फ्यूज़ नहीं किया जाता: बचे हुए हिस्से को मर्ज करना चुपचाप एक अधूरे जवाब को सहमत जवाब की तरह प्रकाशित कर देता। पहले छूटे हुए मॉडल को रिकवर करें — उसकी फ़ेल हुई एक्सपर्टीज़ को दोबारा चलाने पर रन पूरा होते ही अपने-आप फ्यूज़ हो जाता है।
fusion_started, conflicts_detected, और fusion_completed इवेंट देखते हैं।