ऐसी स्कीमा प्रॉपर्टीज़ का पता लगाएँ जिनके मान मॉडलों के बीच या रन के बीच बदलते हैं, और उन्हें आपके डेटा को दूषित करने से पहले ठीक करें — ऐसे एनरिचमेंट के लिए जो दोहराए जाने योग्य, तुलनीय और सटीक हों।
Entity Enricher LLM को क्वेरी किए जा सकने वाले नॉलेज बेस की तरह मानता है। यह तभी काम करता है जब कोई प्रॉपर्टी नाम एक ही दोहराए जाने योग्य उत्तर को निर्धारित करता हो। annual_revenue जैसी प्रॉपर्टी ऐसा नहीं करती: कौन-सा वित्तीय वर्ष? कौन-सी मुद्रा? मिलियन में या इकाइयों में? हर मॉडल — और उसी मॉडल का हर पुनः-रन — एक अलग फ्रेम चुनने के लिए स्वतंत्र है, इसलिए मान असहमत होते हैं भले ही कोई भी मॉडल गलत न हो।
अस्थिर प्रॉपर्टीज़ डाउनस्ट्रीम हर चीज़ को नुकसान पहुँचाती हैं: मल्टी-मॉडल फ्यूजन ऐसे टकराव देखता है जो वास्तव में फ़्रेमिंग के अंतर होते हैं, और बेंचमार्क निरंतरता स्प्रेड उन कारणों से चौड़े हो जाते हैं जिनका मॉडल की गुणवत्ता से कोई लेना-देना नहीं। नॉन-डिटरमिनिज़्म चेक इन प्रॉपर्टीज़ को ढूँढता है और आपको बताता है कि उन्हें कैसे स्थिर करें।
हर फ्लैग की गई प्रॉपर्टी को चार कारणों में से एक में वर्गीकृत किया जाता है, प्रत्येक का अपना उपाय होता है:
| कारण | उदाहरण | उपाय |
|---|---|---|
| कालिक | ceo, stock_priceceo_2025 | बिना किसी एंकर तारीख वाला बदलता तथ्य — अवधि निर्धारित करें, या अवधि के आधार पर की-वाली array में पुनर्संरचित करें। |
| अस्पष्ट | annual_revenuerevenue_fy2024_usd_millions | नाम इकाई, मुद्रा, अवधि, या दायरे को निर्धारित नहीं करता — गुम फ़्रेम को नाम या विवरण में शामिल करें। |
| व्यक्तिपरक | reputationesg_risk_rating_sustainalytics | कोई वस्तुनिष्ठ ग्राउंड ट्रुथ नहीं — किसी मापने योग्य प्रॉक्सी या निश्चित स्केल से बदलें; अन्यथा यह सलाहकारी के रूप में फ्लैग रहती है। |
| बहु-मान वाला | top_competitorstop_3_competitors_by_revenue | कई समान रूप से सही उत्तर, आमतौर पर एक असीमित सूची — इसे सीमित करें और क्रम मापदंड बताएँ। |
रीनेम ही एकमात्र समाधान नहीं है: स्कीमा प्रॉपर्टीज़ के लिए एनालाइज़र एक description फिक्स भी सुझाता है जो गायब फ्रेम को निर्धारित कर देता है। एक स्पष्ट description एनरिच करने वाले AI तक बिल्कुल वैसे ही पहुँचता है जैसे name पहुँचता है, लेकिन आपके डेटा कॉन्ट्रैक्ट को कभी नहीं तोड़ता — इसलिए पहले से उपयोग में आ रहे स्कीमा के लिए यह पसंदीदा उपाय है।
सैंपल जनरेट होने के बाद, एनालाइज़र उसकी समीक्षा करता है। स्पष्ट रीनेम AI द्वारा गढ़ी गई keys पर अपने-आप लागू हो जाते हैं (उन फील्ड्स पर कभी नहीं जिन्हें आपने खुद नाम दिया हो), और स्ट्रक्चरल फिक्स दो सुधार राउंड तक जनरेटर को वापस भेजे जाते हैं। अटैच किए गए दस्तावेज़ों पर आधारित सैंपल छोड़ दिए जाते हैं — उनके मान स्रोत दस्तावेज़ से आते हैं, मॉडल की याददाश्त से नहीं।
जनरेट किया गया स्कीमा सेव हो जाने के बाद, एक पोस्ट-पास हर प्रॉपर्टी को उसके नॉन-डिटरमिनिज़्म स्तर के साथ एनोटेट करता है। यह चरण बेस्ट-एफर्ट है: अगर यह विफल होता है, तो जनरेशन स्वयं प्रभावित नहीं होता।
री-चेक बटन केवल उन प्रॉपर्टीज़ का विश्लेषण करता है जिनकी अभी तक कोई एनोटेशन नहीं है, और एक बार हर प्रॉपर्टी एनोटेट हो जाने पर पूर्ण पुनः विश्लेषण पर स्विच कर जाता है।
स्कीमा निर्माण के लिए आपके द्वारा पेस्ट किया गया सैंपल JSON स्टेटलेस रूप से विश्लेषित किया जा सकता है — आपको बिना किसी चीज़ में बदलाव के जोखिमपूर्ण प्रॉपर्टी नामों की एक रिपोर्ट मिलती है।
यह चेक केवल सलाहकारी है। यह कभी जनरेशन को नहीं रोकता, कभी किसी संवर्धन को अस्वीकार नहीं करता, और इसकी एनोटेशन संवर्धन करने वाले मॉडलों को भेजे गए हर प्रॉम्प्ट से हटा दी जाती हैं — यह आपको सूचित करता है, AI को नहीं।
फ्लैग की गई प्रॉपर्टीज़ स्कीमा एडिटर में “varies” बैज दिखाती हैं: मध्यम जोखिम के लिए एम्बर, उच्च जोखिम के लिए लाल। बैज पर होवर करने से एनालाइज़र का नोट दिखता है जो बताता है कि क्या और क्यों बदलता है। डिटरमिनिस्टिक मानी गई प्रॉपर्टीज़ पर कोई बैज नहीं होता।
किसी प्रॉपर्टी के name और description दोनों पर मिलाकर फैसला दिया जाता है — इसलिए किसी प्रॉपर्टी को रीनेम करने, या उसका description एडिट करने से उसका एनोटेशन हट जाता है। एडिटर ऐसी प्रॉपर्टीज़ को पुराना (stale) दिखाता है और री-चेक का विकल्प देता है, जो केवल गायब हिस्से का विश्लेषण करता है। सुझाए गए रीनेम को लागू करने के बाद आपको यही चाहिए होता है: री-चेक यह पुष्टि करता है कि नया name डिटरमिनिस्टिक है या नहीं।
चेक को स्कीमा एडिटर के ओवरफ़्लो मेन्यू से प्रति स्कीमा बंद किया जा सकता है। अक्षम होने पर, पोस्ट-जनरेशन पास छोड़ दिया जाता है और बैज, री-चेक बटन, तथा बासी चेतावनियाँ छिपा दी जाती हैं। मौजूदा एनोटेशन रखी जाती हैं (बस छिपी होती हैं), और ऐसे स्कीमा पर चेक को फिर से सक्षम करना जिसका कभी विश्लेषण नहीं हुआ, इसे स्वचालित रूप से चलाता है।
अटैच किए गए दस्तावेज़ों से जनरेट किए गए स्कीमा चेक अक्षम के साथ शुरू होते हैं: उनके मान स्रोत दस्तावेज़ से लिप्यंतरित होते हैं, इसलिए मॉडल ज्ञान में रन-दर-रन विचरण लागू नहीं होता।
एनालाइज़र के नोट्स आपकी इंटरफ़ेस भाषा में लिखे जाते हैं — एक फ़्रेंच उपयोगकर्ता को फ़्रेंच में और एक जापानी उपयोगकर्ता को जापानी में स्पष्टीकरण दिखते हैं। सुझाए गए प्रॉपर्टी नाम अंग्रेज़ी में ही रहते हैं, जो स्कीमा नामकरण परंपराओं के अनुरूप है।
हर विश्लेषण एक वास्तविक (सस्ता) मॉडल कॉल है, जो रिकॉर्ड पर अपने अलग प्रॉम्प्ट के रूप में दर्ज होता है और किसी भी अन्य AI उपयोग की तरह क्रेडिट से काटा जाता है। इंक्रीमेंटल री-चेक केवल वास्तव में विश्लेषित की गई प्रॉपर्टीज़ के लिए ही भुगतान लेते हैं।
स्कीमा जनरेशन को स्वयं डिटरमिनिस्टिक नाम और विवरण (निर्धारित अवधि, इकाइयाँ, क्रम मापदंड) बनाने का निर्देश दिया जाता है, इसलिए अधिकांश स्कीमा साफ़ निकलते हैं और एनालाइज़र को केवल पीछे रह गए मामलों को पकड़ना पड़ता है।
यह चेक प्रोग्रामेटिक रूप से उपलब्ध है:
| सतही | विवरण |
|---|---|
POST /api/schema/analyze-sample | पेस्ट किए गए सैंपल JSON का विश्लेषण करें — स्टेटलेस रिपोर्ट, कुछ भी बदला नहीं जाता |
POST /api/schema/saved/{id}/analyze | किसी सेव किए गए स्कीमा का विश्लेषण करें और एनोटेशन लिखें — डिफ़ॉल्ट रूप से इंक्रीमेंटल, force=true सब कुछ फिर से विश्लेषित करता है |
analyze_sample_determinism | MCP टूल — Claude या किसी भी MCP क्लाइंट से वही स्टेटलेस सैंपल रिपोर्ट |
analyze_schema_determinism | MCP टूल — किसी सेव किए गए स्कीमा को एनोटेट करें; सुझाए गए रीनेम को लागू करने के लिए edit_schema के साथ मिलाएँ |
प्रमाणीकरण और पूर्ण टूल कैटलॉग के लिए API रेफरेंस और MCP सर्वर गाइड देखें।