स्वचालित सेल्फ-करेक्शन और इंटेलिजेंट पोस्ट-प्रोसेसिंग के साथ AI का उपयोग करके सैंपल डेटा से स्ट्रक्चर्ड JSON schema जेनरेट करें।
स्कीमा जनरेशन कच्चे एंटिटी डेटा को एक टाइप्ड, एनोटेटेड JSON स्कीमा में बदल देता है, जो ठीक-ठीक परिभाषित करता है कि संवर्धन के दौरान कौन-सी जानकारी निकालनी है। स्कीमा मैन्युअल रूप से लिखने के बजाय, आप सैंपल JSON पेस्ट करते हैं और AI को संरचना का विश्लेषण करने, टाइप अनुमानित करने, विशेषज्ञता क्षेत्र असाइन करने और सुधार सुझाने देते हैं।
जनरेशन कोई एक बड़ा प्रॉम्प्ट नहीं है। यह छोटे, एक-एक काम वाले कॉल्स का क्रम है, जिनमें से ज़्यादातर साथ-साथ चलते हैं — इसी वजह से छोटे और सस्ते मॉडल भी काम लायक स्कीमा बना पाते हैं, क्योंकि हर कॉल ऐसी सामग्री पर एक सीमित सवाल का जवाब देता है जिसे वह एक साथ नज़र में रख सकता है।
"8.275 h" बन जाता है half_life_seconds: 29790), और जिस तारीख़ को कोई नेटिव टाइप संभाल न सके वह पूर्णांक वर्ष बन जाती है। हर देखे गए मान को यह दावा साबित करना होता है, वरना प्रॉपर्टी टेक्स्ट ही रहती है। सेव वही सैंपल होता है जो दोबारा लिखा गया है।{"en": "...", "fr": "..."}) सिमटकर एक ही बहुभाषी मान बन जाते हैं।हर स्टेप अपने स्तर पर रीट्राई करता है (3 प्रयास) और उसके उत्तर प्रयासों के दौरान जुड़ते जाते हैं, इसलिए टुकड़ों में जवाब देने वाला मॉडल भी पूरे उत्तर तक पहुँच जाता है। उसके बाद स्टेप जो मिला उसे स्वीकार कर लेता है और बची हुई खाली जगहें डिटर्मिनिस्टिक तरीके से भरी जाती हैं — कमज़ोर मॉडल जनरेशन को फ़ेल करने के बजाय विवरणों की गुणवत्ता घटाता है। सिर्फ़ आइडेंटिटी और डोमेन रूटिंग को ही पूरे रन को फ़ेल करने की अनुमति है। हर कॉल अपने अलग प्रॉम्प्ट के रूप में बिल और लॉग होती है, इसलिए रिकॉर्ड में ठीक-ठीक दिखता है कि कहाँ कितना खर्च हुआ।
आप एक ही एंटिटी टाइप के एक के बजाय कई सैंपल्स पास कर सकते हैं — तब स्कीमा उनके फ़ील्ड्स के यूनियन को कवर करती है, किसी सैंपल से गायब कोई भी चीज़ nullable बन जाती है, और उनमें दिखने वाली वैल्यूज़ असली उदाहरण बन जाती हैं। फ़ील्ड नाम मेल खाने चाहिए: अलग-अलग एंटिटी टाइप वर्णित करने वाले सैंपल्स अस्वीकृत किए जाते हैं, और ऐसे ही किसी array के अंदर के वे ऑब्जेक्ट्स भी जिनमें कोई भी फ़ील्ड साझा नहीं है, क्योंकि तब उनकी rows को पहचानने के लिए कुछ नहीं बचेगा। सैंपल एडिटर किसी भी ऐसे अंतर को आपके किसी जनरेशन खर्च करने से पहले फ़्लैग कर देता है।
जो 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 हो सकती है — एक जैसे दिखने वाले सिबलिंग्स को अलग करने वाला क्वालिफ़ायर तब भी पहचानकर्ता बना रहता है जब पूरे-के-पूरे परिवारों में वह सचमुच मौजूद न हो
जहाँ किसी स्ट्रिंग के मान एक छोटे, पूरी तरह गिनाए जा सकने वाले सेट से आते हैं (स्टेटस, ग्रेड, क्लासिफिकेशन कोड), वहाँ जनरेशन उसके सदस्य प्रस्तावित करता है — ठीक उसी वर्तनी में जैसी आपके सैंपल में है — ताकि एनरिचमेंट खिसककर किसी पर्यायवाची पर न चला जाए
क्या फ़ील्ड 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 गाइड देखें।
किसी विवरण से सैंपल एंटिटी जनरेट करते समय, आप “वेब सर्च का उपयोग करें” सक्षम कर सकते हैं ताकि मॉडल केवल अपने ट्रेनिंग डेटा पर निर्भर रहने के बजाय वेब पर वर्तमान तथ्य खोज सके। इससे ताज़ा, अधिक सटीक सैंपल मान बनते हैं — विशेष रूप से कीमतों, स्टाफ संख्या, या हाल के रिलीज़ जैसे तेज़ी से बदलने वाले तथ्यों के लिए। यह विकल्प केवल उन मॉडलों के लिए दिखता है जिनका प्रोवाइडर बिल्ट-इन वेब सर्च का समर्थन करता है, और सर्च कॉल किसी अन्य मॉडल उपयोग की तरह प्रोवाइडर द्वारा बिल किए जाते हैं।
जनरेशन के बाद, आप प्राकृतिक भाषा निर्देशों का उपयोग करके स्कीमा संशोधित कर सकते हैं। एक कमांड टाइप करें और AI आपके मौजूदा स्कीमा संरचना को संरक्षित करते हुए परिवर्तन लागू करता है। प्रत्येक एडिट आगे के सुधारों के लिए 5 सुझाव भी उत्पन्न करता है।
एक employee_count इंटीजर फ़ील्ड जोड़ेंशहर और देश के साथ एक नेस्टेड पता ऑब्जेक्ट बनाएँसभी टेक्स्ट फ़ील्ड में फ़्रेंच विवरण जोड़ें$defs का उपयोग करके एक पैरेंट कंपनी रेफरेंस परिभाषित करेंwebsite field को nullable के रूप में चिह्नित करेंAI एडिट को जनरेशन नियमों के एक उपसमूह (टाइप चेकिंग, रेफरेंस इंटीग्रिटी, एक्सपर्टीज़ डोमेन संगति) का उपयोग करके वैलिडेट किया जाता है, इनपुट डेटा से तुलना किए बिना, क्योंकि आप जानबूझकर फ़ील्ड जोड़ या हटा सकते हैं।
स्कीमा जनरेशन और AI एडिटिंग दोनों 5 लक्षित सुझाव उत्पन्न करते हैं जो विभिन्न सुधार श्रेणियों को कवर करते हैं:
सुझाव Workflow Editor में क्लिक करने योग्य चिप्स के रूप में दिखाई देते हैं — किसी एक पर क्लिक करके AI एडिट इनपुट को अपने-आप भरें और उसे लागू करें।