एक ही तरह की एंटिटी को बार-बार संवर्धित करें और आप बार-बार वही वास्तविक-दुनिया की चीज़ें फिर से खोजते रहते हैं — वही कंपनी, वही दवा का साइड-इफ़ेक्ट, वही व्यक्ति — हर बार थोड़े अलग शब्दों में वर्णित। एक सिमेंटिक ID एक स्थिर, संगठन-स्कोप्ड पहचानकर्ता है जिसे Entity Enricher किसी ऑब्जेक्ट को उसके प्रमुख फ़ील्ड्स से असाइन करता है, ताकि वे निकट-डुप्लिकेट्स एक पहचान में सिमट जाएँ जिस पर आप समूह बना सकते हैं, डिडुप्लिकेट कर सकते हैं, और जॉइन कर सकते हैं।
किसी object की पहचान उसके key फ़ील्ड से बनती है — और ये एक या कई हो सकते हैं। दो उदाहरण:
name द्वारा कीड किया गया एक साइड-इफ़ेक्टयह विभिन्न runs और भाषाओं में Headache, Céphalée, और Cephalalgia के रूप में दिखता है। एक key फ़ील्ड, तीन वर्तनियाँ, एक वास्तविक concept।
name + country द्वारा keyed एक कंपनीAcme Inc. · United States और Acme Incorporated · United States एक ही कंपनी हैं — जबकि Acme Inc. · Germany एक अलग कंपनी है। दूसरी की अस्पष्टता दूर करती है; इसीलिए एक ऑब्जेक्ट एक से अधिक की रख सकता है।
साधारण स्ट्रिंग मिलान इन सभी पर विफल हो जाता है; एक इंसान जानता है कि कौन-से समान हैं। Semantic ID उस निर्णय को स्वतः एनकोड कर देते हैं।
string प्रॉपर्टी (डिफ़ॉल्ट रूप से id नामित), जो एक अपारदर्शी, स्थिर पहचानकर्ता रखती है।preserve) फ़ील्ड है: हमेशा एक स्ट्रिंग, कभी की नहीं, कभी बहुभाषी नहीं, प्रति ऑब्जेक्ट अधिकतम एक।manufacturer), या किसी array में प्रत्येक आइटम (जैसे प्रत्येक side_effect)।मॉडल द्वारा अपना परिणाम लौटाने के बाद, Entity Enricher प्रत्येक सिमेंटिक ID को चार चरणों में हल करता है — सबसे सस्ता पहले:
“Acme Inc.” और “Acme Incorporated” एक-दूसरे के पास आ जाते हैं।0.92, प्रति property ट्यून करने योग्य) से ऊपर स्कोर करता है, तो उस concept का ID पुनः उपयोग किया जाता है। अन्यथा एक बिल्कुल नया ID तैयार किया जाता है और अगली बार के लिए संग्रहीत कर लिया जाता है।थ्रेशोल्ड ट्रेड-ऑफ: उच्च थ्रेशोल्ड अधिक सख्त होता है (कम आकस्मिक मर्ज); निम्न थ्रेशोल्ड अधिक ढीला होता है (अधिक आक्रामक डीडुप्लीकेशन)। जब डिफ़ॉल्ट 0.92 अधिक या कम मर्ज करे तो इसे प्रति प्रॉपर्टी ट्यून करें।
कोई ID जनरेट होगी या नहीं, यह इस पर निर्भर करता है कि उस ऑब्जेक्ट के लिए इनपुट में पहले से कोई मौजूद है या नहीं। यही आपको राउंड-ट्रिप की सुविधा देता है: IDs पाने के लिए एक बार संवर्धन करें, फिर बाद के रन में किसी ज्ञात ID को वापस पास करके उसी पहचान से नए तथ्य जोड़ें — सस्ता और स्पष्ट।
यदि आपके द्वारा भेजा गया ऑब्जेक्ट पहले से एक सिमेंटिक ID रखता है, तो उसे एक lookup के रूप में माना जाता है: ID अक्षरशः रखा जाता है, रिकॉर्ड को उस मौजूदा concept से जोड़ा जाता है, और कोई embedding नहीं — कोई लागत नहीं, कोई match-or-mint नहीं। आप प्लेटफ़ॉर्म को बता रहे हैं “यह ऑब्जेक्ट हमारे डेटाबेस में पहले से पहचाना हुआ है।”
यदि ऑब्जेक्ट के पास कोई सिमेंटिक ID नहीं है, तो प्लेटफ़ॉर्म ऊपर दिए गए चार चरणों से एक बनाता है। वह ID उसके बाद से आपके संगठन के डेटाबेस में ऑब्जेक्ट का स्थिर पहचानकर्ता बन जाता है।
मौजूद लेकिन अपहचान योग्य मान (असली concept ID नहीं) को अनदेखा कर दिया जाता है, और इसके बजाय एक ID जनरेट किया जाता है।
रिज़ॉल्यूशन में प्रति एनरिचमेंट थोड़ी एम्बेडिंग उपयोग लागत लगती है (किसी भी मॉडल कॉल की तरह मीटर की जाती है)। एग्ज़ैक्ट-मैच कैश दोहरावों को मुफ़्त बना देता है, और इनपुट में दिए गए ID की कोई लागत नहीं होती।
रिज़ॉल्व किए गए ID एनरिचमेंट आउटपुट JSON में (प्रत्येक ऑब्जेक्ट पर id फ़ील्ड) और रिकॉर्ड विवरण के सिमेंटिक कॉन्सेप्ट्स में दिखते हैं। इन्हें इसके लिए उपयोग करें:
फ्यूज़न एक ही रन के भीतर मॉडल के बीच असहमतियों का मेल कराता है; सिमेंटिक ID एक ही एंटिटी का रन और समय के आर-पार मेल कराते हैं। दोनों साथ मिलकर काम करते हैं।