सिमैंटिक 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 को छह चरणों में हल करता है — सबसे सस्ता पहले। एम्बेडिंग से पहले के चार चरण केवल टेक्स्ट तुलना हैं, इसलिए वहीं तय हो जाने वाली पहचान पर कोई लागत नहीं आती:

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

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

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

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

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

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

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

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

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

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

जज से पूछें

सबसे नज़दीकी कुछ कॉन्सेप्ट एक छोटे लैंग्वेज मॉडल को दिए जाते हैं, जो सिर्फ़ एक सवाल का जवाब देता है: क्या इनमें से कोई वास्तविक दुनिया की उसी चीज़ का नाम है? वह हर नाम को लेबल किए गए हिस्सों के रूप में देखता है — कभी समानता स्कोर नहीं, जो उसे सिर्फ़ ज्यामिति पर भरोसा करने के लिए उकसाता। अगर वह हाँ कहता है, तो वही ID दोबारा उपयोग होती है और नया शब्द उसी कॉन्सेप्ट की एक और वर्तनी के रूप में याद रख लिया जाता है, जिससे अगली बार वह मुफ़्त पड़ता है। अगर वह ना कहता है, या बता नहीं पाता, तो बिलकुल नई ID बनाई जाती है — इसका उल्टा कभी नहीं, क्योंकि दो पंक्तियों को बाद में मर्ज करना आसान है, पर गलती से जोड़ दी गई एक पंक्ति को अलग करना नहीं।

नंबर नहीं, मॉडल क्यों: अकेली समानता दोनों दिशाओं में गलत होती है। एक ही शिपयार्ड की दो वर्तनियों का स्कोर बहुत दूर हो सकता है, जबकि एक स्थिति और उसका विपरीत (“तीव्र” बनाम “दीर्घकालिक”) लगभग एक जैसा स्कोर पाते हैं। कोई थ्रेशोल्ड इन्हें अलग नहीं कर सकता; यह सिर्फ़ शब्दों के अर्थ की समझ से होता है। जज फ्लोर (डिफ़ॉल्ट 0.5, हर प्रॉपर्टी के लिए समायोज्य) सिर्फ़ यह तय करता है कि पूछने लायक कैंडिडेट कितनी दूर तक खोजे जाएँ — यह कभी पहचान तय नहीं करता।

इनपुट 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 बनाएं।
•अलग-अलग दिनों या अलग-अलग भाषाओं में दिखी एक ही एंटिटी का सामंजस्य स्थापित करें।

अपने सरफ़ेस फ़ॉर्म पर विस्तारित एक कॉन्सेप्ट पंक्ति: कैननिकल टेक्स्ट तारांकित, उसके नीचे एक समाहित वर्तनी — vocabulary की ओर से हल किया गया ID ऐसा दिखता है: कई वर्तनियाँ, एक कॉन्सेप्ट, एक कुल उपयोग — और *auto* टैग उस रूप को चिह्नित करता है जिसे identity judge ने इसमें समाहित किया।

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

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

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

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

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

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

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

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

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

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

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

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