ऐसी स्कीमा प्रॉपर्टीज़ खोजें जो एक से ज़्यादा सवाल पूछ रही हो सकती हैं — प्रतिस्पर्धी अर्थ साथ-साथ देखें, और डेटा एकत्र होने से पहले हर प्रॉपर्टी को एक ही अर्थ पर टिका दें।
Entity Enricher, LLM को ऐसे ज्ञान-भंडार की तरह मानता है जिनसे क्वेरी की जा सके, और प्रॉपर्टी का नाम ही वह सवाल है जो आप पूछ रहे हैं। जब नाम से कई अर्थ निकल सकते हैं, तो हर मॉडल चुपचाप एक चुन लेता है — तो किसी कंपनी की size एक मॉडल से कर्मचारी-संख्या, दूसरे से राजस्व का आँकड़ा और तीसरे से फ़र्श क्षेत्रफल बनकर लौटती है। मॉडलों में किसी तथ्य पर मतभेद नहीं था। उन्होंने अलग-अलग सवालों के जवाब दिए, और अब आपके कॉलम में जवाबों का ऐसा मिश्रण है जिसे आगे कोई भी उपभोक्ता अलग नहीं कर सकता।
अर्थ को पक्का करना ही एनरिचमेंट को अलग-अलग मॉडलों के बीच तुलनीय और समय के साथ स्थिर बनाता है। इससे आगे की हर चीज़ भी साफ़ हो जाती है: मल्टी-मॉडल फ्यूजन उन टकरावों को देखना बंद कर देता है जो दरअसल दो अलग सवाल हैं, और बेंचमार्क तुलनाएँ मॉडलों को इसलिए दंडित करना बंद कर देती हैं कि उन्होंने आपके स्कीमा को रेफ़रेंस से अलग तरह पढ़ा।
समय के साथ बदलने वाला तथ्य अपने आप में अस्पष्टता नहीं है। स्कीमा एक टिकाऊ अनुबंध है, इसलिए सीधे-सादे नाम वाली ceo प्रॉपर्टी का अर्थ है “एनरिचमेंट के समय का CEO”, और अगले साल वही स्कीमा दोबारा चलाने पर नया नाम लौटना चाहिए। यह जाँच कभी नाम में कोई तारीख़ जमा देने का सुझाव नहीं देती — इससे हर भावी रन टूट जाएगा।
पूरी जाँच एक ही सवाल है, जो हर प्रॉपर्टी से पूछा जाता है: उसका नाम उसके पैरेंट ऑब्जेक्ट के संदर्भ में पढ़ने पर, यह कितनी अलग-अलग चीज़ें माँग सकता है? यही गिनती फ़ैसला है।
| व्याख्याएँ | निर्णय | इसका क्या मतलब है |
|---|---|---|
| ठीक एक | साफ़ करें | हर मॉडल एक ही चीज़ खोजता है। कोई चिप नहीं, ठीक करने को कुछ नहीं। |
| दो या अधिक | अस्पष्ट | हर मॉडल अपना-अपना अर्थ तय कर लेता है, इसलिए कॉलम में चुपचाप अलग-अलग सवालों के जवाब मिल जाते हैं। यह जाँच प्रतिस्पर्धी अर्थों को नाम देती है और ऐसा शब्द-चयन सुझाती है जो केवल एक अर्थ रखे। |
| कोई नहीं | मैप न किया जा सकने वाला | यह नाम पैरेंट ऑब्जेक्ट की ऐसी किसी चीज़ का नाम नहीं है जो उसके पास हो, इसलिए मॉडल कोई मान खोज ही नहीं सकता — वह गढ़ लेता है। सूचीबद्ध व्याख्याएँ वही हैं जिन पर एनालाइज़र ने विचार किया और उन्हें ख़ारिज कर दिया, और उपाय है नाम बदलना या हटा देना: कोई भी विवरण किसी एंटिटी को वह प्रॉपर्टी नहीं दे सकता जो उसके पास है ही नहीं। |
जो प्रॉपर्टी ठीक एक ही चीज़ बताती है, वह भी तब फ़्लैग हो सकती है जब मान को कोई ढाँचा न मिला हो — पढ़ने वाला जानता है कि क्या पूछा जा रहा है, पर यह नहीं कि उत्तर किन शब्दों या इकाइयों में आएगा। ये रूप बार-बार दिखते हैं:
| उप-मामला | उदाहरण | क्या खुला है |
|---|---|---|
| संदर्भित वस्तु अस्पष्ट | Companysize | यह नाम कई अलग-अलग तथ्यों की ओर इशारा करता है जो पैरेंट के पास सचमुच हैं — कर्मचारी संख्या, राजस्व, फ़्लोर एरिया। नाम में ऐसा कुछ नहीं जो इनमें से किसी एक को चुने। |
| माप या इकाई अस्पष्ट | Companyannual_revenue | एक ही तथ्य, पर न मुद्रा, न अवधि और न सकल/शुद्ध का ढाँचा — एक विश्वसनीय लगने वाला उत्तर परिमाण के तीन क्रम तक ग़लत हो सकता है और फिर भी "सही" कहलाएगा। |
| स्केल या दिशा अस्पष्ट | Supplierrisk_score | न कोई रेंज बताई गई है और न ध्रुवता: 0–10 या 0–100, और क्या बड़ा नंबर ज़्यादा सुरक्षित है या ज़्यादा जोखिम भरा? दो मॉडल एक-दूसरे से बिलकुल उल्टा नतीजा दे सकते हैं। |
| अस्पष्ट दायरा या सीमा | Companyemployees | कौन-सा उपसमूह, समुच्चयन का कौन-सा स्तर, किसका दृष्टिकोण — पूरा समूह या यह साइट, कर्मचारी संख्या या पूर्णकालिक समकक्ष, ठेका कर्मी शामिल या बाहर। |
| मैप न किया जा सकने वाला | Authorrelease_year | किसी लेखक का कोई रिलीज़ वर्ष नहीं होता — उनकी किताबों का होता है। मॉडल इसे कहीं देख नहीं सकता, इसलिए वह गढ़ लेता है। इसे ऐसा नाम दें जो मूल (parent) के पास वाक़ई हो, या इसे उस ऑब्जेक्ट में ले जाएँ जिसके पास यह है। |
गद्य वाली प्रॉपर्टीज़ — description, summary, notes, bio — कभी फ़्लैग नहीं होतीं। इनकी शब्दावली एक मॉडल से दूसरे मॉडल में ज़ाहिर तौर पर अलग होती है, पर पूछा जा रहा सवाल पूरी तरह साफ़ है, और यह जाँच सिर्फ़ इतना ही आँकती है। अस्पष्टता सवाल से जुड़ी होती है, कभी इससे नहीं कि उत्तर आपस में कितने मिलते-जुलते हैं।
अकेला फ़ैसला (“यह अस्पष्ट है”) आपको अंदाज़ा लगाने पर छोड़ देता है कि एनालाइज़र के मन में क्या था। इसलिए हर निष्कर्ष अपने साथ interpretations लाता है: दो से चार छोटे, अलग-अलग अर्थ जो उस प्रॉपर्टी से निकल सकते हैं, सबसे संभावित पहले। यही सूची ही निष्कर्ष है — अगर एनालाइज़र दो अर्थ नहीं बता पाता, तो निष्कर्ष आपको दिखाने के बजाय शोर मानकर हटा दिया जाता है।
annual_revenue किसी कंपनी परउनके साथ एक सुझाया गया विवरण आता है जो ठीक एक अर्थ बनाए रखता है — यहाँ, “सबसे हालिया पूर्ण वित्तीय वर्ष का कुल समूह राजस्व, USD में, रिटर्न घटाए बिना”। इसे लागू करने की कोई क़ीमत नहीं: विवरण एनरिच करने वाले मॉडल तक ठीक वैसे ही पहुँचता है जैसे नाम, पर प्रॉपर्टी का नाम वही रहता है, इसलिए कोई डेटा अनुबंध नहीं हिलता। जब गुमराह करने वाली चीज़ नाम ख़ुद हो, तब निष्कर्ष के साथ सुझाए गए नाम भी आते हैं।
व्याख्याओं को साफ़-साफ़ लिखा हुआ देखना आमतौर पर किसी भी स्पष्टीकरण से जल्दी प्रॉपर्टी का मामला सुलझा देता है: जो आपका आशय था उसे आप पहचान लेते हैं, और बाकी वही हैं जो आपको चुपचाप मिलते आ रहे हैं।
नमूना तैयार होने के बाद एनालाइज़र उसके प्रॉपर्टी नामों की समीक्षा करता है और एक अस्पष्टता रिपोर्ट लौटाता है। स्पष्ट रीनेम अपने आप AI द्वारा गढ़ी गई कीज़ पर लागू हो जाते हैं (आपके ख़ुद रखे गए फ़ील्ड नामों पर कभी नहीं), इसलिए जो नमूना आप देखते हैं वह पहले से बेहतर पढ़ा जाता है। यह अति-विशिष्ट प्रॉपर्टीज़ को भी फ़्लैग करता है — वे विशेषताएँ जो उदाहरण इंस्टेंस से रिस आईं और केवल किसी उप-प्रकार पर लागू होती हैं (सामान्य Person पर किसी खिलाड़ी के मेडल) — और एक अधिक संकरा एंटिटी प्रकार सुझाता है। पहचान-दायरे की जाँच यहीं, ठीक इसके बाद, अपने अलग कॉल के रूप में चलती है: नमूना देखने से पहले ही यह संबंधित आइटम्स का स्वरूप तय कर देती है। संलग्न दस्तावेज़ों पर आधारित नमूने छोड़ दिए जाते हैं — उनके मान स्रोत दस्तावेज़ से आते हैं, मॉडल की स्मृति से नहीं।
जनरेट किया गया स्कीमा सहेजे जाने के बाद, एक पोस्ट-पास हर प्रॉपर्टी को उसके अस्पष्टता फ़ैसले के साथ एनोटेट करता है और जो अब भी खुली हैं उनके लिए नए नाम सुझाता है। रिलेशनशिप साइटें तब तक एनोटेट हो चुकी होती हैं — जनरेशन अपने ही एक चरण के रूप में उनकी स्कोपिंग का आकलन कर लेता है — इसलिए पोस्ट-पास सिर्फ़ प्रॉपर्टी नामों को कवर करता है। यह चरण बेस्ट-एफ़र्ट है: अगर यह विफल हो जाए, तो जनरेशन स्वयं अप्रभावित रहता है।
Re-check बटन दोनों जाँचें — प्रॉपर्टी नाम और रिलेशनशिप साइटें — दो समानांतर कॉल के रूप में चलाता है। यही एकमात्र जगह है जहाँ नाम बदलने के बजाय दोबारा लिखा गया विवरण सुझाया जाता है। यह सिर्फ़ उसी का विश्लेषण करता है जिस पर अभी कोई एनोटेशन नहीं है, और सब कुछ एनोटेट हो जाने पर पूरे नए विश्लेषण पर स्विच कर जाता है।
स्कीमा बनाने के लिए आप जो सैंपल JSON पेस्ट करते हैं, उसका विश्लेषण स्टेटलेस तरीके से किया जा सकता है — आपको अस्पष्ट और मैप न हो सकने वाले प्रॉपर्टी नामों की, और ऐसे संबंधित आइटम्स की रिपोर्ट मिलती है जो एंटिटी तथ्यों को पेयरिंग तथ्यों के साथ मिला देते हैं, बिना किसी चीज़ में बदलाव किए।
एक ही निष्कर्ष कहीं नाम बदलने का सुझाव देता है और कहीं विवरण का, और इसकी वजह जानने लायक है। जनरेशन के समय विवरण स्वतंत्र रूप से मौजूद ही नहीं होता — वह नाम से ही लिखा जाता है, इसलिए वह उसी अस्पष्टता को दोहरा भर सकता है। नाम ही एकमात्र चीज़ है जिसे ठीक किया जा सकता है, और अभी उस पर कुछ भी निर्भर नहीं है। यही वजह है कि सैंपल जनरेशन और स्कीमा-जनरेशन का पोस्ट-पास, दोनों नाम बदलने का प्रस्ताव देते हैं।
स्कीमा लाइव हो जाने के बाद किसी प्रॉपर्टी का नाम बदलने से कॉलम खिसकते हैं, क्वेरीज़ टूटती हैं और सिंक की गई टेबलों की कीज़ बदल जाती हैं, जबकि एक स्पष्ट विवरण मॉडल तक उतनी ही सीधे पहुँचता है और बाकी कुछ नहीं बदलता। इसलिए नियम सरल है: जब तक स्कीमा पर कुछ भी निर्भर न हो, नाम बदलें; लाइव हो जाने के बाद विवरण को पक्का करें — और नाम बदलने का विकल्प उन मामलों के लिए बचाकर रखें जहाँ समस्या नाम में ही हो।
यह जाँच सिर्फ़ सलाहकारी है। पृष्ठभूमि में आपके सहेजे गए स्कीमा का कोई विश्लेषण नहीं होता: यह जनरेशन के समय चलती है, और तब जब आप Re-check दबाते हैं। यह न कभी जनरेशन रोकती है, न किसी एनरिचमेंट को अस्वीकार करती है, और एनरिच करने वाले मॉडलों को भेजे जाने वाले हर प्रॉम्प्ट से इसकी एनोटेशन हटा दी जाती हैं — यह आपको सूचित करती है, AI को नहीं।
फ़्लैग की गई प्रॉपर्टीज़ “ambiguous” चिप दिखाती हैं, Workflow Editor में: अंबर तब जब अर्थ अधिकतर आपस में मेल खाते हों और सिर्फ़ किनारे के मामले अलग हों, लाल तब जब प्रतिस्पर्धी अर्थ काफ़ी अलग डेटा देंगे। स्पष्ट मानी गई प्रॉपर्टीज़ पर कोई चिप नहीं होती। चिप पर होवर करने से एनालाइज़र का नोट, उसे मिले प्रतिस्पर्धी अर्थ, और सुझाया गया विवरण या नाम दिखते हैं — यानी फ़ैसला और सुधार, दोनों एक ही टूलटिप में।
फ़ैसला प्रॉपर्टी के नाम और विवरण, दोनों को मिलाकर दिया जाता है — इसलिए प्रॉपर्टी का नाम बदलने या उसका विवरण संपादित करने पर उसका एनोटेशन हट जाता है। एडिटर ऐसी प्रॉपर्टीज़ को पुरानी (stale) के रूप में हाइलाइट करता है और दोबारा जाँच का विकल्प देता है, जो केवल छूटे हुए हिस्से का विश्लेषण करती है। सुझाया गया सुधार लागू करने के बाद आपको यही चाहिए: दोबारा जाँच पुष्टि करती है कि नया शब्द-चयन वाक़ई एक ही अर्थ पर टिकता है या नहीं।
आइडेंटिटी स्कोपिंग एक दूसरी जाँच है, जो अस्पष्टता पास के साथ-साथ अपने अलग मॉडल कॉल के रूप में चलती है और उसी के साथ रिपोर्ट होती है। यह हर रिलेशनशिप जगह की समीक्षा करती है — किसी संबंधित ऐरे के आइटम, और नेस्टेड ऑब्जेक्ट: जब कोई आइटम संबंधित एंटिटी से जुड़े तथ्यों (उसका नाम, उसका देश) को जोड़ी से जुड़े तथ्यों (इस पैरेंट के लिए निभाई गई भूमिका, प्रति-पैरेंट पदनाम) के साथ मिला देता है, तो दोनों की पहचान एक ही हो जाती है — और दोबारा एनरिचमेंट करने पर जोड़ी वाले तथ्य सभी पैरेंट में ओवरराइट हो जाते हैं। ऐसी जगहों पर एम्बर रंग की “मिश्रित तथ्य” चिप लगती है, जिसके टूलटिप में सुझाया गया ढाँचा दिखता है: एंटिटी के अपने फ़ील्ड एक सब-ऑब्जेक्ट में नेस्ट किए हुए, और जोड़ी वाले फ़ील्ड आइटम पर ही रखे हुए। अगर आइटम में ऐसा सब-ऑब्जेक्ट पहले से मौजूद है, तो सुधार छोटा है — गलत जगह रखे फ़ील्ड उसी मौजूदा सब-ऑब्जेक्ट में चले जाते हैं।
स्प्लिट सैंपल जनरेशन के दौरान, आपके सैंपल को मंज़ूरी देने से पहले लागू होता है: आकार पहले सैंपल पर ही तय हो जाता है, हर पुनर्संरचित साइट जनरेशन चेतावनियों में सूचीबद्ध होती है, और बैच के बाक़ी सैंपल उसी तय आकार के अनुसार जनरेट होते हैं। इसलिए नए सैंपल से जनरेट किए गए स्कीमा आम तौर पर साफ़ निकलते हैं। अटैच किए गए दस्तावेज़ों पर आधारित सैंपल वैसे ही छोड़ दिए जाते हैं जैसा उनके सोर्स से निकलता है, और उन्हें इसके बदले चिप मिलती है।
स्कीमा जनरेशन स्वयं आपके स्वीकृत सैंपल की संरचना कभी नहीं बदलता — यह उन्हीं साइट्स का मूल्यांकन करता है और जो मिलता है उसकी रिपोर्ट देता है। इसलिए किसी मौजूदा या हाथ से लिखे स्कीमा में सुधार चिप में ही मिलता है: यह वन-क्लिक स्प्लिट देता है, जो एंटिटी के अपने फ़ील्ड को सीधे स्कीमा में उनके अलग सबऑब्जेक्ट में ले जाता है — एक डिटरमिनिस्टिक बदलाव, कोई LLM कॉल नहीं, और स्वीकृत सैंपल को कभी नहीं छुआ जाता। केवल एंटिटी के फ़ील्ड ही जाते हैं; पेयरिंग फ़ील्ड अपने पाथ बनाए रखते हैं, और जो बदलता है वह है पहचान: एंटिटी को अपनी एक पहचान मिल जाती है, जिसे उसे रेफ़र करने वाला हर रिकॉर्ड साझा करता है। जिस साइट को आप स्प्लिट न करना चुनें, वह काम करती रहती है — बस उसकी एक ही साझा पहचान बनी रहती है, और चिप भी। आइटम का फ़ील्ड सेट बदलने पर चिप अपने आप गायब हो जाती है।
इस जाँच को हर स्कीमा के लिए Workflow Editor के ओवरफ़्लो मेन्यू से बंद किया जा सकता है। बंद होने पर, जनरेशन के बाद वाला पास छोड़ दिया जाता है, चिप्स, Re-check बटन और पुराने पड़ चुके चेतावनी संदेश छिप जाते हैं, और विश्लेषण एंडपॉइंट ambiguity_check_disabled एरर देते हैं। मौजूदा एनोटेशन बनी रहती हैं (बस छिप जाती हैं), और जिस स्कीमा का कभी विश्लेषण नहीं हुआ, उस पर जाँच दोबारा चालू करने पर यह अपने आप चल जाती है।
हर जनरेट किया गया स्कीमा इस जाँच के चालू रहते शुरू होता है, जिसमें अटैच किए गए दस्तावेज़ों से जनरेट हुए स्कीमा भी शामिल हैं। अस्पष्टता इस बात का गुण है कि स्कीमा किन शब्दों में लिखा गया है, न कि इस बात का कि किसी एक रन की वैल्यू कहाँ से आईं: दस्तावेज़ ने उन वैल्यू को एक बार तय कर दिया, और स्कीमा आगे ऐसी एंटिटी पर दोबारा इस्तेमाल होता रहता है जिन्हें उसने कभी कवर नहीं किया। दस्तावेज़ जो चीज़ बदलता है वह है सैंपल चरण — उसके प्रॉपर्टी नाम स्रोत दस्तावेज़ की अपनी शब्दावली से आते हैं, इसलिए उन्हें कोड में कभी नहीं बदला जाता, और उनसे बना स्कीमा इसके बजाय यह जाँच लेकर चलता है।
“कंपनी का वार्षिक राजस्व” ऐसी कोई जानकारी नहीं जोड़ता जो नाम में पहले से न हो, इसलिए एनालाइज़र ऐसे विवरण को अनुपस्थित मानकर केवल नाम के आधार पर आकलन करता है। विवरण अपनी जगह तभी बनाता है जब वह इकाई, अवधि, पैमाना या सीमा बताए।
एनालाइज़र के नोट और व्याख्याएँ आपकी इंटरफ़ेस भाषा में लिखी जाती हैं — फ़्रेंच उपयोगकर्ता को फ़्रेंच में अर्थ दिखते हैं, जापानी उपयोगकर्ता को जापानी में। सुझाए गए प्रॉपर्टी नाम अंग्रेज़ी में ही रहते हैं, ताकि स्कीमा नामकरण परंपराओं से मेल खाएँ।
हर विश्लेषण एक असली (सस्ता) मॉडल कॉल है — और जब दायरा तय करने के लिए संबंध-स्थल भी हों, तो समानांतर चलने वाले दो कॉल। हर कॉल रिकॉर्ड पर अपने अलग प्रॉम्प्ट के रूप में ambiguity_analysis प्रकार के अंतर्गत दर्ज होता है, और किसी भी अन्य AI उपयोग की तरह क्रेडिट से घटाया जाता है। इंक्रीमेंटल पुनः-जाँच में केवल उन्हीं प्रॉपर्टीज़ और स्थलों का शुल्क लगता है जिनका सचमुच विश्लेषण हुआ।
सैंपल और स्कीमा जनरेशन को खुद ही यह निर्देश दिया गया है कि हर प्रॉपर्टी में एक ही चीज़ का नाम दें और ऐसे विवरण लिखें जो इकाई, स्केल और सीमा बताएँ — और विवादास्पद सूचियों के लिए, नाम में ज़बरदस्ती गिनती डालने के बजाय विवरण में एक ऊपरी सीमा दें। इसलिए ज़्यादातर स्कीमा साफ़-सुथरे बनते हैं और एनालाइज़र को सिर्फ़ छूटे हुए मामले पकड़ने होते हैं।
यह चेक प्रोग्रामेटिक रूप से उपलब्ध है:
| सतही | विवरण |
|---|---|
POST /api/schema/analyze-sample | पेस्ट किए गए सैंपल JSON का विश्लेषण करें — एक ही रिक्वेस्ट के पीछे दोनों जाँचें समानांतर, स्टेटलेस रिपोर्ट, कुछ भी संशोधित नहीं होता |
POST /api/schema/saved/{id}/analyze | सेव किए गए स्कीमा का विश्लेषण करें और दोनों जाँचों के एनोटेशन लिखें — डिफ़ॉल्ट रूप से इंक्रीमेंटल, force=true सभी का दोबारा विश्लेषण करता है |
analyze_sample | MCP टूल — वही स्टेटलेस सैंपल रिपोर्ट, दोनों जाँचें, Claude या किसी भी MCP क्लाइंट से |
analyze_schema | MCP टूल — सहेजे गए स्कीमा को एनोटेट करें; सुझाया गया विवरण या रीनेम लागू करने के लिए update_schema के साथ इस्तेमाल करें |
निष्कर्ष एक kind (ambiguous या unmappable), एक level, एक नोट, interpretations सूची और सुझाए गए सुधार के साथ लौटते हैं। सहेजी गई स्कीमा में ये हर प्रॉपर्टी पर ambiguity के रूप में संग्रहित होते हैं; नमूना निर्माण इन्हें ambiguity_report के अंतर्गत लौटाता है।
प्रमाणीकरण और पूर्ण टूल कैटलॉग के लिए API रेफरेंस और MCP सर्वर गाइड देखें।