AI ऐप को संरचित आउटपुट की ज़रूरत क्यों होती है?
AI ऐप को तय ढाँचे में आउटपुट चाहिए, क्योंकि सॉफ़्टवेयर बातचीत के अंदाज़ में लिखे पैराग्राफ़ को भरोसेमंद ढंग से नहीं पढ़ सकता; उसे हर बार वही फ़ील्ड, उन्हीं नामों और डेटा प्रकारों के साथ चाहिए। एक अतिरिक्त वाक्य या एक गायब फ़ील्ड आपके ऐप के अगले चरण को रोक सकता है।
12 लोगों वाले एक काल्पनिक लॉजिस्टिक्स स्टार्टअप, पार्सलवाइज़, की कल्पना करें। इसकी डेवलपर, सना, एक ऐसा टूल बना रही है जो ग्राहकों के ईमेल पढ़कर डिलीवरी में बदलाव का फ़ॉर्म भरता है: ऑर्डर का संदर्भ नंबर, माँगी गई तारीख, नया पता और क्या ग्राहक पैसे वापस माँग रहा है। एक सामान्य ईमेल कुछ ऐसा है: 'नमस्ते, ऑर्डर PW-88213, मैं गुरुवार को घर पर नहीं रहूँगा, क्या उसकी जगह शनिवार को पहुँचा सकते हैं? या फिर नं. 14 पर छोड़ दें। अगर यह भी न हो सके तो कृपया रद्द करके पैसे वापस कर दें।' उसका पहला संस्करण मॉडल से कहता है कि 'JSON में जवाब दो'। ज़्यादातर जवाब मशीन पढ़ लेती है, लेकिन कुछ की शुरुआत 'ज़रूर, यह रहा JSON' से होती है, कुछ में फ़ील्ड का नाम 'requested_date' के बजाय 'date' होता है, और एक में तारीख की जगह 'शनिवार' लिखा होता है।
JSON स्कीमा क्या है और यह कैसे मदद करता है?
JSON स्कीमा उस डेटा का औपचारिक विवरण है जिसकी आपको अपेक्षा है: कौन-से फ़ील्ड मौजूद हैं, कौन-से अनिवार्य हैं, हर फ़ील्ड का प्रकार क्या है और कौन-से मान स्वीकार्य हैं। मॉडल को स्कीमा देने से 'कृपया JSON में जवाब दें' एक ऐसे अनुबंध में बदल जाता है जिसकी जाँच आपका कोड कर सकता है।
सना के लिए स्कीमा यह कहता है: order_reference एक अनिवार्य स्ट्रिंग है; requested_date तारीख के प्रारूप में एक अनिवार्य स्ट्रिंग है, या कोई तारीख न दी गई हो तो null; new_address एक स्ट्रिंग या null है; refund_requested एक अनिवार्य बूलियन है; और किसी अन्य फ़ील्ड की अनुमति नहीं है। आखिरी नियम मॉडल को टिप्पणी वाले फ़ील्ड जोड़ने से रोकता है।
मॉडल के API तय संरचना में आउटपुट देने में कैसे मदद करते हैं?
प्रमुख मॉडलों के API आपको अनुरोध के साथ JSON स्कीमा भेजने देते हैं, और मॉडल के आउटपुट को उसी के अनुरूप रखा जाता है।
OpenAI
OpenAI की संरचित आउटपुट सुविधा, सख्त मोड चालू होने पर, जवाबों को दिए गए JSON स्कीमा के अनुरूप रखती है। इसके दस्तावेज़ इसे पुराने JSON मोड से अलग बताते हैं। पुराना मोड केवल मान्य JSON सुनिश्चित करता है, आपके स्कीमा का पालन नहीं। जहाँ उपलब्ध हो, वहाँ दस्तावेज़ संरचित आउटपुट इस्तेमाल करने की सलाह देते हैं।
Anthropic
Claude का API आपके दिए गए स्कीमा के अनुरूप JSON आउटपुट देता है। साथ ही, टूल की परिभाषाओं में एक सख़्त विकल्प भी मिलता है, जिससे टूल के इनपुट को उसके स्कीमा से मिलाकर जाँचा जाता है। इसके दस्तावेज़ों में बताया गया है कि स्कीमा की कौन-सी विशेषताएँ समर्थित हैं और किनसे त्रुटि मिलती है।
Gemini API उत्तरों के लिए JSON स्कीमा स्वीकार करता है और स्कीमा के कीवर्ड के एक निर्धारित हिस्से का समर्थन करता है। इसके दस्तावेज़ के अनुसार, भले ही आउटपुट का JSON प्रारूप सही हो, फिर भी आपको अपने अनुप्रयोग में उसके मानों की जाँच करनी चाहिए।
आपको फिर भी सत्यापन और दोबारा कोशिश करने की ज़रूरत क्यों होती है?
आपको फिर भी सत्यापन करना होगा, क्योंकि स्कीमा डेटा की संरचना तय करता है, यह नहीं कि उसमें दी गई जानकारी सही है या नहीं। बिल्कुल सही संरचना वाले उत्तर में भी गलत तारीख, गढ़ा हुआ ऑर्डर संदर्भ या रिफ़ंड का ऐसा संकेत हो सकता है जिसकी ग्राहक ने कभी माँग नहीं की।
दो स्तरों पर सत्यापन करें। पहले, स्कीमा लाइब्रेरी से संरचना जाँचें, जैसे Python में Pydantic या JavaScript में Zod। OpenAI, Anthropic और Google, तीनों के दस्तावेज़ों में इनके उदाहरण दिए गए हैं। दूसरे, व्यावसायिक नियम जाँचें: क्या ऑर्डर का संदर्भ तय पैटर्न से मेल खाता है और सिस्टम में मौजूद है, क्या तारीख भविष्य की है और उस दिन डिलीवरी होती है, और क्या पता डिलीवरी क्षेत्र में है? सेवा प्रदाताओं के दस्तावेज़ों में बताए गए इन मामलों को भी सँभालें: जवाब देने से इनकार, जो आपके स्कीमा के अनुसार न हो सकता है, और अधिकतम टोकन सीमा के कारण बीच में कट गया जवाब, जिससे JSON अधूरा रह जाता है।
दोबारा प्रयास करते समय सावधानी बरतें। यदि कोई जाँच विफल हो, तो एक बार फिर अनुरोध भेजें और उसमें सटीक त्रुटि बताएँ, जैसे 'requested_date में तारीख होनी चाहिए; ईमेल में शनिवार लिखा है और ऑर्डर की तारीख 14 October है'। दोबारा प्रयासों की सीमा एक या दो रखें, फिर ईमेल किसी व्यक्ति को भेज दें।
कमजोर और मजबूत संरचित आउटपुट कैसा होता है?
कमज़ोर तरीका: प्रॉम्प्ट कहता है 'विवरण निकालें और JSON में जवाब दें।' ऐप जो भी जवाब आता है, उसे पढ़ लेता है। ऊपर दिए गए ईमेल के लिए उसे order और date नाम के फ़ील्ड मिलते हैं, तारीख की जगह 'शनिवार' मिलता है और refund का मान true मिलता है, क्योंकि मॉडल ने 'नहीं तो बस रद्द कर दें' को पक्का अनुरोध मान लिया। फ़ॉर्म गलत भर जाता है और ग्राहक को ऐसा रिफ़ंड मिल जाता है जो वह चाहता ही नहीं था।
मज़बूत संस्करण: अनुरोध में सना का स्कीमा सख्त मोड के साथ शामिल है और प्रॉम्प्ट में हर फ़ील्ड समझाया गया है, जिसमें यह भी है कि 'refund_requested केवल तभी true होगा जब ग्राहक बिना किसी शर्त के पैसे वापस माँगे'। मॉडल order_reference में PW-88213, requested_date में अगले शनिवार की तारीख, new_address में null और refund_requested में false लौटाता है। साथ ही conditional_request में 'यदि शनिवार को या पड़ोसी को डिलीवरी संभव न हो तो पैसे वापस करें' दर्ज करता है। सना ने ठीक इसी स्थिति के लिए यह फ़ील्ड स्कीमा में जोड़ा था। सत्यापन से पुष्टि होती है कि ऑर्डर मौजूद है और शनिवार को डिलीवरी होती है। चूँकि ईमेल में शर्त वाला अनुरोध है, इसलिए नियमों के अनुसार अंतिम निर्णय के लिए इसे किसी व्यक्ति को भेजा जाता है।
तय संरचना वाले आउटपुट में आम तौर पर कौन-सी गलतियाँ होती हैं?
सबसे आम गलती वैध JSON को सही डेटा मान लेना है। अन्य गलतियाँ हैं: API में स्कीमा लागू कराने की सुविधा होने पर भी केवल निर्देशों पर निर्भर रहना, विवरण दिए बिना अस्पष्ट फ़ील्ड नाम इस्तेमाल करना, जहाँ ईमानदार उत्तर null हो वहाँ कोई मान देना अनिवार्य बनाना, जवाब देने से इनकार और अधूरे कटे जवाबों को नज़रअंदाज़ करना, और मॉडल को यह बताए बिना दोबारा कोशिश करना कि गलत क्या था।
Tosheo.ai की पाठ्यसूची में संरचित आउटपुट कहाँ शामिल है?
संरचित आउटपुट, AI ऐप बनाना श्रेणी के AI ऐप बनाने के पाठ्यक्रम में कोड का एक पाठ है। कोड के साथ इसका पूरा व्यावहारिक संस्करण साइन-अप के बाद कोड वाले पाठ्यक्रम में मिलता है। इसमें आप डेटा की संरचना तय करते हैं, API कॉल करते हैं, जवाबों की वैधता जाँचते हैं और दोबारा कोशिश करने की व्यवस्था जोड़ते हैं। हर चरण पर तय मूल्यांकन मानदंडों के अनुसार प्रतिक्रिया मिलती है।
स्रोत और दायरा
Google Gemini एपीआई दस्तावेज़, संरचित आउटपुट और सत्यापन संबंधी सलाह (19 October 2026 को जाँचा गया) ↗