स्वचालित सेल्फ-करेक्शन और इंटेलिजेंट पोस्ट-प्रोसेसिंग के साथ AI का उपयोग करके सैंपल डेटा से स्ट्रक्चर्ड JSON schema जेनरेट करें।
स्कीमा जनरेशन कच्चे एंटिटी डेटा को एक टाइप्ड, एनोटेटेड JSON स्कीमा में बदल देता है, जो ठीक-ठीक परिभाषित करता है कि संवर्धन के दौरान कौन-सी जानकारी निकालनी है। स्कीमा मैन्युअल रूप से लिखने के बजाय, आप सैंपल JSON पेस्ट करते हैं और AI को संरचना का विश्लेषण करने, टाइप अनुमानित करने, विशेषज्ञता क्षेत्र असाइन करने और सुधार सुझाने देते हैं।
जनरेशन कोई एक बड़ा प्रॉम्प्ट नहीं है। यह छोटे, एक-एक काम वाले कॉल्स का क्रम है, जिनमें से ज़्यादातर साथ-साथ चलते हैं — इसी वजह से छोटे और सस्ते मॉडल भी काम लायक स्कीमा बना पाते हैं, क्योंकि हर कॉल ऐसी सामग्री पर एक सीमित सवाल का जवाब देता है जिसे वह एक साथ नज़र में रख सकता है।
"8.275 h" बन जाता है half_life_seconds: 29790), और जिस तारीख़ को कोई नेटिव टाइप संभाल न सके वह पूर्णांक वर्ष बन जाती है। हर देखे गए मान को यह दावा साबित करना होता है, वरना प्रॉपर्टी टेक्स्ट ही रहती है। सेव वही सैंपल होता है जो दोबारा लिखा गया है।manufacturer_name जैसा कोई स्केलर, या therapeutic_classes[] जैसे स्केलर ऐरे का हर आइटम, किसी पुन: प्रयोज्य एंटिटी का नाम हो सकता है। जनरेशन के दौरान स्वीकृत सैंपल का आकार अपरिवर्तित रहता है; लॉजिकल एंटिटी मैप इस अलगाव को दर्ज करता है। एडिटर में, इसका एंटिटी बैज हर बार आने वाली प्रविष्टि को एक साझा ऑब्जेक्ट टाइप के रेफरेंस के रूप में मूर्त कर देता है।{"en": "...", "fr": "..."}) एक ही बहुभाषी वैल्यू में सिमट जाते हैं।हर स्टेप अपने स्तर पर रीट्राई करता है (3 प्रयास) और उसके उत्तर प्रयासों के दौरान जुड़ते जाते हैं, इसलिए टुकड़ों में जवाब देने वाला मॉडल भी पूरे उत्तर तक पहुँच जाता है। उसके बाद स्टेप जो मिला उसे स्वीकार कर लेता है और बची हुई खाली जगहें डिटर्मिनिस्टिक तरीके से भरी जाती हैं — कमज़ोर मॉडल जनरेशन को फ़ेल करने के बजाय विवरणों की गुणवत्ता घटाता है। सिर्फ़ आइडेंटिटी और डोमेन रूटिंग को ही पूरे रन को फ़ेल करने की अनुमति है। हर कॉल अपने अलग प्रॉम्प्ट के रूप में बिल और लॉग होती है, इसलिए रिकॉर्ड में ठीक-ठीक दिखता है कि कहाँ कितना खर्च हुआ।
आप एक ही एंटिटी टाइप के एक के बजाय कई सैंपल्स पास कर सकते हैं — तब स्कीमा उनके फ़ील्ड्स के यूनियन को कवर करती है, किसी सैंपल से गायब कोई भी चीज़ nullable बन जाती है, और उनमें दिखने वाली वैल्यूज़ असली उदाहरण बन जाती हैं। फ़ील्ड नाम मेल खाने चाहिए: अलग-अलग एंटिटी टाइप वर्णित करने वाले सैंपल्स अस्वीकृत किए जाते हैं, और ऐसे ही किसी array के अंदर के वे ऑब्जेक्ट्स भी जिनमें कोई भी फ़ील्ड साझा नहीं है, क्योंकि तब उनकी rows को पहचानने के लिए कुछ नहीं बचेगा। सैंपल एडिटर किसी भी ऐसे अंतर को आपके किसी जनरेशन खर्च करने से पहले फ़्लैग कर देता है।
स्प्रेडशीट भी चलेगी: Excel या Google Sheets से सीधे, या किसी .csv फ़ाइल से CSV पंक्तियाँ पेस्ट करें जिनकी पहली पंक्ति हेडर हो। प्रत्येक पंक्ति एक सैंपल बनती है, हेडर प्रॉपर्टी नाम बन जाते हैं (Author Name → author_name), और प्रत्येक कॉलम को एक टाइप मिलता है — integer, number, boolean या text; खाली सेल null मानी जाती हैं और सेमीकोलन- या टैब-सेपरेटेड टेक्स्ट में दशमलव कॉमा संख्या के रूप में पढ़े जाते हैं। पंक्तियाँ एडिटर में JSON के रूप में दिखती हैं ताकि जेनरेट करने से पहले आप उन्हें जाँच सकें; 20 से अधिक पंक्तियाँ होने पर 20 रखी जाती हैं, ताकि हर कॉलम में कोई मान दिखे। यदि पहली पंक्ति में हेडर के बजाय डेटा हो, तो अनुमान लगाने के बजाय उसे अस्वीकार कर दिया जाता है।
जो values अपनी इकाई खुद साथ रखते हैं, उन्हें schema derive होने से पहले संख्याओं में बदल दिया जाता है, क्योंकि "8.275 h" और "85 ms" वाले column को न तो sort किया जा सकता है, न range से filter किया जा सकता है और न ही aggregate किया जा सकता है। इकाई property नाम में चली जाती है (half_life_seconds), "stable" जैसा गैर-संख्यात्मक विकल्प null बन जाता है, और वर्ष 1 से पहले तक पहुँचने वाली तारीखें एक पूर्णांक वर्ष बन जाती हैं (BCE के लिए ऋणात्मक), जिसे कोई भी date type स्टोर नहीं कर सकता और text गलत तरीके से sort होता है। आपका sample पैनल इसके अनुरूप अपडेट हो जाता है, ताकि वह हमेशा वही sample दिखाए जिसे schema वर्णित करता है। जो कुछ भी conversion निश्चितता के साथ नहीं पढ़ पाता, उसे ठीक वैसे ही छोड़ दिया जाता है जैसा आपने लिखा था।
चूँकि हर चरण एक ही सीमित सवाल का जवाब देता है, इसलिए सुधार भी सीमित रह सकता है: चरण का वैलिडेटर जो कुछ उपयोगी लौटा है उसे रखता है और केवल छूटी हुई चीज़ों के लिए दोबारा पूछता है। कुछ भी शून्य से दोबारा नहीं बनाया जाता, इसलिए आंशिक रूप से सही जवाब बर्बाद कोशिश नहीं, बल्कि प्रगति है।
आठों वैलिडेशन नियम अब भी अंतिम जाँच के रूप में तैयार स्कीमा पर चलते हैं — टाइप की शुद्धता, विशेषज्ञता क्षेत्र का असाइनमेंट, रेफ़रेंस की अखंडता, पूर्णता। उस चरण तक वे सुधार का तंत्र नहीं, बल्कि एक सुरक्षा जाल होते हैं। हर नियम के बारे में Validation Rules गाइड में और पढ़ें।
एक जनरेट किया गया schema एक साधारण type परिभाषा से अधिक है। प्रत्येक property में metadata शामिल होता है जो enrichment प्रक्रिया का मार्गदर्शन करता है:
JSON Schema प्रकार (string, number, integer, boolean, array, object)
संदर्भात्मक विवरण जो AI को बताता है कि कौन-सी जानकारी खोजनी है
कौन-सा विशेषज्ञ क्षेत्र (वित्तीय, नियामक, आदि) यह मान प्रदान करता है
क्या यह फ़ील्ड इंस्टेंस की पहचान का हिस्सा है। पहचानकर्ता प्रॉपर्टीज़ दो काम एक साथ करती हैं: वे एनरिचमेंट प्रॉम्प्ट को सही एंटिटी पर केंद्रित करती हैं, और फ़्यूज़न इन्हीं के आधार पर ऐरे आइटम्स का मिलान करता है। कोई प्रॉपर्टी फिर भी nullable हो सकती है — एक जैसे दिखने वाले सिबलिंग्स को अलग करने वाला क्वालिफ़ायर तब भी पहचानकर्ता रहता है, जब पूरे समूहों में वह वाक़ई मौजूद न हो
जहाँ किसी string के मान एक छोटे, पारंपरिक सेट से आते हैं (स्टेटस, ग्रेड, वर्गीकरण कोड), वहाँ जनरेशन सदस्यों का सुझाव देता है — उसी वर्तनी में जैसी आपके सैंपल में है — एक खुली शब्दावली के रूप में जिस पर संवर्धन अभिसरित होता है। सूची से बाहर दिखने वाले मान एडिटर में उम्मीदवारों के रूप में सामने आते हैं, और सेट बढ़ना बंद होते ही आप उसे बंद कर देते हैं; बंद सेट एक सख़्त अनुबंध बन जाता है जिससे संवर्धन बाहर नहीं भटक सकता
क्या फ़ील्ड null हो सकता है — database प्रवेश के लिए non-nullable फ़ील्ड्स आवश्यक हैं
क्या फ़ील्ड को कई भाषाओं में संवर्धित किया जाना चाहिए
क्या संवर्धन के दौरान मूल मान को अपरिवर्तित रखना है
यथार्थवादी उदाहरण मान जो AI को सही प्रारूप की ओर मार्गदर्शन करते हैं
स्ट्रिंग मानों के लिए मशीन-जाँच योग्य आकार: गलत ढंग से बने उत्तर अस्वीकार कर दोबारा माँगे जाते हैं, और संग्रहीत मान कैनोनिकल रूप में रहते हैं। जनरेशन केवल वही नामित format (date, time, date-time, uuid, email, uri, ipv4, ipv6) बताता है जिसे उसके सैंपल सिद्ध करते हैं — regex pattern तो उन मानों के बारे में एक भविष्यवाणी है जिन्हें अभी किसी ने देखा ही नहीं, और गलत pattern उस फ़ील्ड की हर एनरिचमेंट को विफल कर देता है, इसलिए वह आप स्वयं एडिटर में जोड़ें
AI स्कीमा प्रॉपर्टीज़ को उनके सिमेंटिक अर्थ के आधार पर एक्सपर्टीज़ डोमेन में समूहित करता है। उदाहरण के लिए, किसी फार्मास्युटिकल कंपनी के स्कीमा में “Financial Analyst,” “Regulatory Expert,” और “Corporate Information” जैसे डोमेन हो सकते हैं। इन डोमेन का उपयोग मल्टी-एक्सपर्टीज़ स्ट्रैटेजी द्वारा गहरे परिणामों के लिए समानांतर, विशेषीकृत LLM कॉल चलाने में किया जाता है।
ओवर-फ़्रैगमेंटेशन रोकने के लिए एक्सपर्टीज़ डोमेन की संख्या आपके डेटा की प्रॉपर्टी काउंट के आधार पर अपने-आप सीमित हो जाती है:
फ़्रैगमेंट जुड़ जाने के बाद, नियतात्मक चरण वह सब तय कर देते हैं जो किसी मॉडल पर नहीं छोड़ा जाना चाहिए — प्रमाण के रूप में आपके वास्तविक इनपुट डेटा का उपयोग करते हुए:
किसी भी सैंपल में अनुपस्थित या null फ़ील्ड nullable बन जाती है, चाहे मॉडल ने कुछ भी उत्तर दिया हो — यानी अज्ञात मान डेटा-गुणवत्ता की विफलता नहीं, बल्कि एक स्वीकृत उत्तर है। सैंपल केवल दायरा चौड़ा कर सकते हैं: कुछ गिने-चुने सैंपल उन्हीं इंस्टेंस के लिए मौजूदगी सिद्ध करते हैं, उस टाइप के हर इंस्टेंस के लिए कभी नहीं — इसीलिए मॉडल को भी एक वोट मिलता है, और दोनों को OR किया जाता है।
जो एट्रिब्यूट साथ नहीं रह सकते, उन्हें दोबारा पूछने के बजाय नियम से सुलझाया जाता है: preserve, multilingual और nullable पर भारी पड़ता है, बची हुई क्लोज़्ड वोकैबुलरी multilingual को हटा देती है, और कोई की-प्रॉपर्टी कभी enum नहीं रखती।
किसी ऐरे के अंदर हर ऑब्जेक्ट में कम से कम एक की प्रॉपर्टी होना तय है — यही वह इकाई है जिस पर फ्यूजन डीडुप्लिकेशन करता है, इसलिए बिना की वाले ऐरे आइटम से दो मॉडलों के उत्तरों को मर्ज करना असंभव हो जाएगा।
मेट्रिक्स और रणनीति कॉन्फ़िगरेशन के लिए स्कीमा से सभी अद्वितीय विशेषज्ञता डोमेन एकत्र किए जाते हैं।
स्कीमा स्वयं को किसी भाषा में वर्णित करता है — उसके टाइप नाम, प्रॉपर्टी विवरण, विशेषज्ञता लेबल और सुझाव। यह उन भाषाओं से अलग बात है जिनमें आप एनरिचमेंट करते हैं। जनरेट करते समय कोई एक भाषा चुनें, या उसे छोड़ दें और तब आपके सैंपल के अपने प्रॉपर्टी नामों की भाषा तय करती है: फ़्रेंच सैंपल अब अंग्रेज़ी स्कीमा बनाना बंद कर देता है। यह चुनाव सहेजा जाता है, ताकि बाद के AI संपादन भी उसी भाषा में लिखें और वापस अंग्रेज़ी की ओर न खिसकें।
शुरू करने के लिए आपको नमूना डेटा की ज़रूरत नहीं है। आप जो नमूना चाहते हैं उसका सरल शब्दों में वर्णन करें — एंटिटी का प्रकार, उसमें कौन-सी प्रॉपर्टीज़ होनी चाहिए, कितना बड़ा या कितना गहरा — चाहें तो उसे आधार देने के लिए दस्तावेज़ जोड़ें, या वास्तविकता से मिलान के लिए वेब सर्च — और प्लेटफ़ॉर्म आपके लिए नमूने लिख देता है। कई माँगिए और आपको कई अलग-अलग इंस्टेंस मिलेंगे, एक ही इंस्टेंस दोहराया हुआ नहीं।
पहला सैंपल उसी कॉल में यह भी तय करता है कि बाकी सैंपल किनके बारे में होंगे। “एक उदाहरण” के लिए N बार अलग-अलग पूछने पर हर बार वही प्रसिद्ध उदाहरण N बार लौटता है; शुरुआत में ही सबके नाम तय कर देना ही उन्हें एक-दूसरे से अलग बनाता है।
बाकी सैंपल समानांतर रूप से, सैंपल 1 की संरचना के विरुद्ध एक अनुबंध के रूप में बनाए जाते हैं — उनसे केवल उससे मेल खाने को नहीं कहा जाता, इसलिए कोई वेरिएंट किसी फ़ील्ड का नाम नहीं बदल सकता, न कोई फ़ील्ड जोड़ सकता है, न हटा सकता है। फिर भी जो डुप्लिकेट या खराब बनकर लौटते हैं, उन्हें एक सीमित रीट्राई राउंड में दोबारा माँगा जाता है, और यदि पूरी संख्या नहीं मिलती तो चुपचाप कम देने के बजाय आपको बता दिया जाता है।
आपकी रिक्वेस्ट की हर बात का पालन होता है — साइज़ बजट जेनरेटर की सब कुछ शामिल कर देने की प्रवृत्ति पर भारी पड़ता है, और आपका माँगा हुआ स्ट्रक्चर उसके डिफ़ॉल्ट पर — या फिर रिस्पॉन्स आपको बताता है कि किस बात का पालन नहीं हो सका और क्यों; कुछ भी चुपचाप नहीं छोड़ा जाता। एक चीज़ रिक्वेस्ट नहीं है: आपको कितने सैंपल मिलेंगे यह सैंपल काउंट तय करता है, और हर सैंपल ठीक एक इंस्टेंस होता है — टेक्स्ट में “तीन सैंपल” माँगने से कभी भी एक ऑब्जेक्ट में लिपटी हुई लिस्ट नहीं मिलती। जब रिक्वेस्ट सचमुच अस्पष्ट हो (ऐसी एंटिटी जिसके कई अर्थ निकलते हों, या दो परस्पर विरोधी स्कोप), तो जेनरेटर अनुमान लगाने के बजाय जेनरेशन खर्च करने से पहले आपसे पूछता है। भाषा डिफ़ॉल्ट रूप से auto रहती है, जिसका अनुमान पहले आपकी अपनी रिक्वेस्ट के शब्दों से, फिर किसी अटैच किए गए डॉक्यूमेंट से लगाया जाता है।
किसी प्रॉपर्टी नाम को उसके पैरेंट ऑब्जेक्ट के संदर्भ में पढ़ें और गिनें कि वह कितनी अलग-अलग चीज़ें पूछ सकता है। एक हो तो नाम स्पष्ट है। दो या उससे ज़्यादा हों तो हर मॉडल किसी एक अलग अर्थ पर टिक जाता है, और कॉलम में अलग-अलग सवालों के जवाब मिल-जुल जाते हैं — किसी कंपनी पर annual_revenue ग्रुप का हो सकता है या एंटिटी का, सकल हो सकता है या शुद्ध, और कई मुद्राओं में से किसी एक में। और अगर कोई अर्थ ही न निकले — यानी ऐसा नाम जिसके लिए इस पैरेंट के पास कुछ है ही नहीं — तो बात और बिगड़ती है: देखने को कुछ न मिलने पर मॉडल वैल्यू गढ़ लेता है।
जनरेशन इससे दो बार लड़ता है: प्रॉम्प्ट खुद ऐसे नामों की माँग करता है जिनका एक ही अर्थ निकले, और तैयार स्कीमा पर चलने वाला एक पोस्ट-पास उन नामों को चिह्नित करता है जो अब भी ऐसे नहीं हैं। इस चरण पर उपाय है नाम बदलना — विवरण नामों से ही बनाए गए थे, इसलिए कोई विवरण उस नाम की अस्पष्टता दूर नहीं कर सकता जिससे वह खुद निकला है, और अभी स्कीमा पर कुछ निर्भर भी नहीं करता। सैंपल जनरेशन यही जाँच सैंपल पर चलाता है और आपके देखने से पहले ही नाम बदल देता है। मुक्त-पाठ गद्य — कोई विवरण, सारांश, नोट्स — कभी चिह्नित नहीं होता: शब्द अलग-अलग हो सकते हैं, पर पूछा गया सवाल स्पष्ट रहता है।
चिह्नित प्रॉपर्टीज़ Workflow Editor में “अस्पष्ट” बैज दिखाती हैं, जिसमें वे सभी अर्थ सूचीबद्ध होते हैं जो उस नाम से निकल सकते हैं। स्कीमा लाइव हो जाने के बाद उपाय बदलकर नया लिखा गया विवरण हो जाता है, जो डेटा कॉन्ट्रैक्ट तोड़े बिना एक अर्थ तय कर देता है। पूरी कसौटी और उसके उपायों के लिए Ambiguity Check गाइड देखें।
किसी विवरण से sample entity जनरेट करते समय, आप “Use web search” सक्षम कर सकते हैं ताकि model केवल अपने ट्रेनिंग डेटा पर निर्भर रहने के बजाय वेब पर मौजूदा तथ्य खोज सके। इससे अधिक ताज़ा और सटीक sample मान मिलते हैं — खासकर तेज़ी से बदलते तथ्यों के लिए, जैसे क़ीमतें, कर्मचारियों की संख्या या हाल के रिलीज़। यह विकल्प केवल उन models के लिए उपलब्ध है जिनका provider अंतर्निहित वेब सर्च का समर्थन करता है, और सर्च कॉल्स को provider किसी भी अन्य model उपयोग की तरह बिल करता है।
जनरेशन के बाद, आप प्राकृतिक भाषा निर्देशों का उपयोग करके स्कीमा संशोधित कर सकते हैं। एक कमांड टाइप करें और AI आपके मौजूदा स्कीमा संरचना को संरक्षित करते हुए परिवर्तन लागू करता है। प्रत्येक एडिट आगे के सुधारों के लिए 5 सुझाव भी उत्पन्न करता है।
एक employee_count इंटीजर फ़ील्ड जोड़ेंशहर और देश के साथ एक नेस्टेड पता ऑब्जेक्ट बनाएँसभी टेक्स्ट फ़ील्ड में फ़्रेंच विवरण जोड़ें$defs का उपयोग करके एक पैरेंट कंपनी रेफरेंस परिभाषित करेंwebsite field को nullable के रूप में चिह्नित करेंAI एडिट को जनरेशन नियमों के एक उपसमूह (टाइप चेकिंग, रेफरेंस इंटीग्रिटी, एक्सपर्टीज़ डोमेन संगति) का उपयोग करके वैलिडेट किया जाता है, इनपुट डेटा से तुलना किए बिना, क्योंकि आप जानबूझकर फ़ील्ड जोड़ या हटा सकते हैं।
स्कीमा जनरेशन और AI एडिटिंग दोनों 5 लक्षित सुझाव उत्पन्न करते हैं जो विभिन्न सुधार श्रेणियों को कवर करते हैं:
सुझाव Workflow Editor में क्लिक करने योग्य चिप्स के रूप में दिखाई देते हैं — किसी एक पर क्लिक करके AI एडिट इनपुट को अपने-आप भरें और उसे लागू करें।