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