सिमैंटिक ID - Entity Enricher दस्तावेज़

सिमैंटिक ID

एक ही तरह की एंटिटी को बार-बार संवर्धित करें और आप बार-बार वही वास्तविक-दुनिया की चीज़ें फिर से खोजते रहते हैं — वही कंपनी, वही दवा का साइड-इफ़ेक्ट, वही व्यक्ति — हर बार थोड़े अलग शब्दों में वर्णित। एक सिमेंटिक ID एक स्थिर, संगठन-स्कोप्ड पहचानकर्ता है जिसे Entity Enricher किसी ऑब्जेक्ट को उसके प्रमुख फ़ील्ड्स से असाइन करता है, ताकि वे निकट-डुप्लिकेट्स एक पहचान में सिमट जाएँ जिस पर आप समूह बना सकते हैं, डिडुप्लिकेट कर सकते हैं, और जॉइन कर सकते हैं।

समस्या: एक ही चीज़, अलग शब्द

किसी object की पहचान उसके key फ़ील्ड से बनती है — और ये एक या कई हो सकते हैं। दो उदाहरण:

एक key

`name` द्वारा कीड किया गया एक साइड-इफ़ेक्ट

यह विभिन्न runs और भाषाओं में Headache, Céphalée, और Cephalalgia के रूप में दिखता है। एक key फ़ील्ड, तीन वर्तनियाँ, एक वास्तविक concept।

दो keys

`name` + `country` द्वारा keyed एक कंपनी

Acme Inc. · United States और Acme Incorporated · United States एक ही कंपनी हैं — जबकि Acme Inc. · Germany एक अलग कंपनी है। दूसरी की अस्पष्टता दूर करती है; इसीलिए एक ऑब्जेक्ट एक से अधिक की रख सकता है।

साधारण स्ट्रिंग मिलान इन सभी पर विफल हो जाता है; एक इंसान जानता है कि कौन-से समान हैं। Semantic ID उस निर्णय को स्वतः एनकोड कर देते हैं।

सिमेंटिक ID क्या है

•किसी ऑब्जेक्ट पर एक अकेली string प्रॉपर्टी (डिफ़ॉल्ट रूप से id नामित), जो एक अपारदर्शी, स्थिर पहचानकर्ता रखती है।
•स्थिर और संगठन-स्कोप्ड — एक ही वास्तविक-दुनिया की चीज़ संवर्धनों, बैचों, और समय के दौरान एक ही ID में रिज़ॉल्व होती है, केवल आपके संगठन के भीतर।
•स्वचालित रूप से असाइन किया जाता है, कभी भी LLM द्वारा नहीं — यह enrichment के बाद के एक पास में गणना किया जाता है, इसलिए model इसे hallucinate नहीं कर सकता। यह एक पास-थ्रू फ़ील्ड है (इनपुट मान बिना बदले प्रवाहित होते हैं): हमेशा एक string, कभी key नहीं, कभी preserve नहीं, कभी multilingual नहीं, प्रति object अधिकतम एक।
•किसी भी object पर अनुमत — पूरी entity (root), एक 1-1 nested object (जैसे कोई manufacturer), या किसी array में प्रत्येक आइटम (जैसे प्रत्येक side_effect)।

यह कैसे काम करता है

मॉडल का परिणाम लौटाने के बाद, Entity Enricher हर सिमेंटिक ID को छह चरणों में हल करता है — सबसे सस्ता पहले। एम्बेडिंग से पहले के चार चरण केवल टेक्स्ट तुलना हैं, इसलिए वहीं तय हो जाने वाली पहचान पर कोई लागत नहीं आती:

पहचान टेक्स्ट लिखें

ऑब्जेक्ट को स्वयं पहचानने वाले की-फ़ील्ड को अपनी प्राथमिक भाषा में एक ही स्ट्रिंग में जोड़ें। ऐसा नेस्टेड ऑब्जेक्ट जो अपने आप में एक entity है, उसे छोड़ दिया जाता है: उसकी key उसी का नाम बताती है, उसका संदर्भ देने वाली चीज़ का नहीं, और उसी entity का संदर्भ देने वाले हर सिबलिंग में वही मान होगा — एक ही लॉन्च साइट साझा करने वाले दो मिशन लगभग एक जैसे पढ़े जाएँगे और एक में मिल जाने का जोखिम रहेगा। जो नेस्टेड ऑब्जेक्ट केवल फ़ील्ड्स को समूहित करते हैं, वे फिर भी योगदान देते हैं; और यदि आप स्वयं जोड़ें तो किसी संबंधित entity की key भी। ऐरे के भीतर के आइटम कभी शामिल नहीं किए जाते: हर ऐरे आइटम की अपनी पहचान होती है। schema एडिटर की identity participants सूची ठीक-ठीक दिखाती है कि कौन-से मान इस टेक्स्ट को बनाते हैं और आपको उन्हें पुनः क्रमित करने या बदलने देती है — जो schema एक ही क्रम में वही participants चुनते हैं, वे एक जैसे ID बनाते हैं। मामूली अंतर घटाने के लिए टेक्स्ट को सामान्यीकृत किया जाता है (लोअरकेस, कोष्ठक वाला हिस्सा हटाया गया, अतिरिक्त स्पेस संक्षिप्त)। यदि उन की-फ़ील्ड्स में से हर एक खाली लौटती है, तो ऑब्जेक्ट को पहचानने के लिए कुछ नहीं बचता और कोई ID नहीं दी जा सकती — इसलिए ऑब्जेक्ट को ऐसे अनाम रूप में रखने के बजाय हटा दिया जाता है जिस पर कुछ भी समूहित, जोड़ा या डीडुप्लिकेट नहीं किया जा सकता: नेस्टेड ऑब्जेक्ट अपने पैरेंट में null हो जाता है, और सूची के भीतर का आइटम सूची से हटा दिया जाता है। enrich की गई entity स्वयं कभी नहीं हटाई जाती; उसके पास बस कोई ID नहीं होती।

एक सटीक मिलान खोजें

यदि वह ठीक वही सामान्यीकृत टेक्स्ट आपके संगठन में पहले देखा जा चुका है, तो उसका मौजूदा ID तुरंत पुनः उपयोग किया जाता है — कोई मॉडल कॉल नहीं, कोई लागत नहीं।

कोड पर मिलान करें, यदि कोई हो

जब पहचान की कुंजियों में से एक code हो — यानी कोई पैटर्न-बाध्य फ़ील्ड, या ऐसा फ़ील्ड जिसके उदाहरण पहचानकर्ता जैसे दिखते हों — तो उसे पहले बनाया जाता है और अकेले ही तुलना की जाती है। कोड का सटीक मिलान पहचान को तुरंत तय कर देता है, आसपास की भाषा चाहे जैसी भी हो, इसलिए LC-39A बाकी टेक्स्ट के हर लिखावट-रूप को एक कर देता है। उतना ही अहम यह है कि यह उल्टा भी काम करता है: अलग कोड उस मर्ज को वीटो कर देता है जिसे एम्बेडिंग स्टेप वरना स्वीकार कर लेता, क्योंकि अलग पहचानकर्ता वाली दो चीज़ें दो ही होती हैं, चाहे पढ़ने में कितनी भी एक जैसी लगें।

किसी भी क्रम में समान शब्दों पर मिलान करें

एम्बेडिंग खर्च करने से पहले, शब्दों की ही एक सेट के रूप में तुलना की जाती है: यदि एक टेक्स्ट के शब्द दूसरे के शब्दों में समाहित हैं, तो वे अलग-अलग लंबाई में लिखी गई एक ही पहचान हैं — “Boeing” और “The Boeing Company”। यह ठीक उन्हीं शब्द-विस्तार के अंतरों को पकड़ लेता है जिन्हें एम्बेडिंग बहुत दूर मापती है, और इसकी कोई लागत नहीं: exact-text चरण की तरह, यहाँ मैच मिलने का मतलब है कोई एम्बेडिंग कॉल नहीं और कोई शुल्क नहीं।

एम्बेड करें और तुलना करें

अन्यथा टेक्स्ट को एम्बेड किया जाता है और वेक्टर समानता का उपयोग करके, अर्थ के आधार पर, उसी कॉन्सेप्ट टाइप (डिफ़ॉल्ट रूप से एंटिटी टाइप नाम — एडिटर में ओवरराइड करने योग्य ताकि अलग-अलग नाम वाले स्कीमा एक कॉन्सेप्ट स्पेस साझा करें) के मौजूदा कॉन्सेप्ट्स से तुलना की जाती है — ताकि “Acme Inc.” और“Acme Incorporated” एक-दूसरे के पास आएं।

पुनः उपयोग करें या नया बनाएँ

अगर सबसे नज़दीकी मैच समानता थ्रेशोल्ड (डिफ़ॉल्ट 0.92, हर प्रॉपर्टी के लिए ट्यून किया जा सकता है) से ऊपर स्कोर करता है, तो उस कॉन्सेप्ट का ID दोबारा इस्तेमाल होता है। अन्यथा एक बिल्कुल नया ID बनाकर अगली बार के लिए सहेज लिया जाता है। एक अपवाद ऊँचे स्कोर पर भी भारी पड़ता है: जब दोनों टेक्स्ट एक ही शब्द हों पर उनमें गिनती अलग हो — “दूसरा चरण” और“तीसरा चरण” — तो उन्हें अलग-अलग चीज़ें माना जाता है, क्योंकि गिनती ही उन्हें एक-दूसरे से अलग करती है। एक ही संख्या दो तरह से लिखी हो (2 औरII) तो भी मैच होती है।

थ्रेशोल्ड ट्रेड-ऑफ: उच्च थ्रेशोल्ड अधिक सख्त होता है (कम आकस्मिक मर्ज); निम्न थ्रेशोल्ड अधिक ढीला होता है (अधिक आक्रामक डीडुप्लीकेशन)। जब डिफ़ॉल्ट 0.92 अधिक या कम मर्ज करे तो इसे प्रति प्रॉपर्टी ट्यून करें।

इनपुट ID बनाम जनरेट किए गए ID

कोई ID जनरेट होगी या नहीं, यह इस पर निर्भर करता है कि उस ऑब्जेक्ट के लिए इनपुट में पहले से कोई मौजूद है या नहीं। यही आपको राउंड-ट्रिप की सुविधा देता है: IDs पाने के लिए एक बार संवर्धन करें, फिर बाद के रन में किसी ज्ञात ID को वापस पास करके उसी पहचान से नए तथ्य जोड़ें — सस्ता और स्पष्ट।

ID पहले से इनपुट में मौजूद → रखा गया (lookup)

यदि आपके द्वारा भेजा गया ऑब्जेक्ट पहले से एक सिमेंटिक ID रखता है, तो उसे एक lookup के रूप में माना जाता है: ID अक्षरशः रखा जाता है, रिकॉर्ड को उस मौजूदा concept से जोड़ा जाता है, और कोई embedding नहीं — कोई लागत नहीं, कोई match-or-mint नहीं। आप प्लेटफ़ॉर्म को बता रहे हैं “यह ऑब्जेक्ट हमारे डेटाबेस में पहले से पहचाना हुआ है।”

इनपुट में कोई ID नहीं → जनरेट किया गया

अगर ऑब्जेक्ट के पास कोई सिमैंटिक ID नहीं है, तो प्लेटफ़ॉर्म ऊपर बताए गए चरणों से एक बना देता है। उसके बाद वही ID आपके ऑर्गनाइज़ेशन के डेटाबेस में उस ऑब्जेक्ट का स्थायी पहचानकर्ता बन जाती है।

मौजूद लेकिन अपहचान योग्य मान (असली concept ID नहीं) को अनदेखा कर दिया जाता है, और इसके बजाय एक ID जनरेट किया जाता है।

इसे कैसे सक्षम करें

एक एम्बेडिंग model चुनें (प्रति organization एक बार)

कोई ओनर Settings → Organization → Defaults में एम्बेडिंग-सक्षम मॉडल को संगठन के डिफ़ॉल्ट एम्बेडिंग मॉडल के रूप में चुनता है (यह सेटिंग प्लान पर निर्भर है; कौन-से मॉडल एम्बेड कर सकते हैं, यह जानने के लिए Models & Pricing देखें)। संग्रहीत वेक्टर अलग-अलग मॉडलों के बीच तुलनीय नहीं होते, इसलिए कॉन्सेप्ट बन जाने के बाद इस सेटिंग को केवल हटाया जा सकता है — मॉडल बदलना Semantic IDs पेज से माइग्रेशन के रूप में चलता है, जो हर कॉन्सेप्ट को फिर से एम्बेड करता है और उनकी ID बनाए रखता है। मॉडल न होने पर सिमेंटिक ID को बस छोड़ दिया जाता है।

स्कीमा में सिमेंटिक ID जोड़ें

दो तरीके, दोनों Workflow Editor में:

जनरेशन के समय स्वचालित रूप से — “Generate semantic IDs for types” पर टिक करें; की वाला हर ऑब्जेक्ट (अपनी, या किसी 1-1 नेस्टेड ऑब्जेक्ट की) एक पाता है, जिसमें रूट एंटिटी भी शामिल है।
मैन्युअल रूप से — किसी भी ऑब्जेक्ट या एंटिटी फ़ुटर पर “+ सिमेंटिक ID जोड़ें” नियंत्रण का उपयोग करें।

रिज़ॉल्यूशन में प्रति एनरिचमेंट थोड़ी एम्बेडिंग उपयोग लागत लगती है (किसी भी मॉडल कॉल की तरह मीटर की जाती है)। एग्ज़ैक्ट-मैच कैश दोहरावों को मुफ़्त बना देता है, और इनपुट में दिए गए ID की कोई लागत नहीं होती।

ID कहां दिखते हैं और उनके साथ क्या करना है

रिज़ॉल्व की गई ID एनरिचमेंट आउटपुट JSON में दिखती हैं (हर ऑब्जेक्ट पर id फ़ील्ड), रिकॉर्ड विवरण के सिमेंटिक कॉन्सेप्ट में, और सब एक साथ सिमेंटिक ID पेज पर, जहाँ उनसे बनी शब्दावली को ब्राउज़ और क्यूरेट किया जाता है। इनका उपयोग करें:

•बैचों में और समय के साथ पंक्तियों का डीडुप्लिकेशन करें।
•अपने डेटा वेयरहाउस या CRM के लिए एक स्थिर जॉइन key बनाएं।
•अलग-अलग दिनों या अलग-अलग भाषाओं में दिखी एक ही एंटिटी का सामंजस्य स्थापित करें।

multi-model fusion को पूरक बनाता है

फ्यूज़न एक ही रन के भीतर मॉडल के बीच असहमतियों का मेल कराता है; सिमेंटिक ID एक ही एंटिटी का रन और समय के आर-पार मेल कराते हैं। दोनों साथ मिलकर काम करते हैं।

मुख्य अवधारणाएँ

सर्च और मर्ज कीज़ खोजें, जिन पर सिमेंटिक IDs आधारित होते हैं

बहुभाषी संवर्धन

अलग-अलग भाषाओं की वर्तनियों को एक पहचान में संक्षिप्त करें

मल्टी-मॉडल फ्यूज़न

एक ही रन के भीतर मॉडलों के बीच सामंजस्य स्थापित करें

वर्कफ़्लो एडिटर

किसी भी ऑब्जेक्ट में सिमेंटिक ID जोड़ें

सिमेंटिक ID पेज

परिणामी शब्दावली को ब्राउज़, क्यूरेट और डीडुप्लिकेट करें