AI एजेंट्स बनानामध्यमपाठ 1986 मिनट का पाठ

Structured outputs और function calling

मॉडल से खुले टेक्स्ट (free text) के बजाय मशीन द्वारा पढ़ा जा सकने वाला JSON पाएँ, कोड में schema के अनुसार उसकी जाँच करें, और गलत होने पर साफ़-सुथरे तरीके से दोबारा कोशिश (retry) करें।

✦ ट्यूटर से पूछें 🧪 लैब · 30 min 📝 पाठ का टेस्ट

स्पीड

पाठ वीडियो में

60 सेकंड में

Structured outputs और function calling

मॉडल से खुले टेक्स्ट (free text) के बजाय मशीन द्वारा पढ़ा जा सकने वाला JSON पाएँ, कोड में schema के अनुसार उसकी जाँच करें, और गलत होने पर साफ़-सुथरे तरीके से दोबारा कोशिश (retry)…

1/5

आसान शब्दों में

जब आप रेलवे रिज़र्वेशन का फ़ॉर्म भरते हैं, तो हर डिब्बे का एक काम होता है: यहाँ नाम, वहाँ उम्र, उम्र वाले डिब्बे में सिर्फ़ नंबर। क्लर्क फिर इसे तेज़ी से प्रोसेस कर सकता है। Structured output मॉडल से ऐसा ही एक फ़ॉर्म भरने को कहता है, और आपका कोड इस्तेमाल करने से पहले हर डिब्बे की जाँच करता है।

Agents को सिर्फ़ लोगों तक ही नहीं, बल्कि कोड तक भी डेटा पहुँचाना होता है। कोड "ज़रूर! शायद ऑर्डर आईडी ORD-123456 है।" जैसी बात नहीं पढ़ सकता। उसे {"order_id": "ORD-123456"} चाहिए। इसे पाने के दो आम तरीके हैं:

तरीका	इसका क्या मतलब है	आम तौर पर इस्तेमाल
Function (tool) calling	API मॉडल को एक tool का नाम और आपके schema का पालन करने वाले JSON arguments वापस करने की सुविधा देती है।	Agent लूप: tools चुनना और उन्हें कॉल करना।
Structured output (JSON mode)	आप पूरा जवाब schema से मेल खाते JSON के रूप में मांगते हैं। कई APIs इसे सख्ती से लागू कर सकती हैं या इसका पालन करने के लिए कड़ा निर्देश दे सकती हैं।	फ़ील्ड्स निकालना, वर्गीकरण (classifying) करना, डेटा के रूप में कोई प्लान बनाना।

दोनों JSON Schema का इस्तेमाल करते हैं: JSON डेटा के आकार और बनावट को समझाने का एक मानक तरीका, जैसे कि कौन-सी फ़ील्ड्स ज़रूरी हैं, उनके प्रकार (types) और कौन-से मान (values) मान्य हैं। कुछ प्रदाता मॉडल को इस तरह सीमित कर सकते हैं कि उसका आउटपुट हमेशा पार्स हो और schema का पालन करे; दूसरे सिर्फ़ दिशा-निर्देश देते हैं। सुविधाएँ अक्सर बदलती रहती हैं, इसलिए अपने प्रदाता के मौजूदा दस्तावेज़ (docs) देखें। चाहे जो भी हो, अपने खुद के कोड में जाँच (validate) ज़रूर करें।

अगर API पहले से ही schema का इस्तेमाल करती है, तो फिर वैलिडेट क्यों करें?

पार्स होने का मतलब यह नहीं कि डेटा सही भी है। किसी रेस्टोरेंट बुकिंग के लिए {"people": 4000} एक मान्य (valid) JSON तो है, लेकिन गलत है।
Schemas हर बिज़नेस नियम को नहीं समझा सकते: जैसे "तारीख भविष्य की होनी चाहिए", "सिर्फ़ यूज़र के अपने ऑर्डर्स"।
मॉडल आउटपुट एक untrusted input है। इसे किसी वेब फ़ॉर्म से आए डेटा की तरह समझें (देखें मॉडल आउटपुट को untrusted input मानें)।
अगर आप बाद में प्रदाता या मॉडल बदलते हैं, तो भी आपकी जाँच काम करती रहेगी।

वैलिडेट करें, फिर गड़बड़ी (error) के साथ दोबारा कोशिश करें

1
पूछें
प्रॉम्प्ट और schema भेजें। सिर्फ़ JSON मांगें।
2
पार्स करें
JSON को पढ़ने की कोशिश करें। अगर यह फ़ेल हो जाए, तो गड़बड़ी का मैसेज (error message) संभाल कर रखें।
3
जाँचें
ज़रूरी फ़ील्ड्स, types, ranges और अपने बिज़नेस नियमों की जाँच करें।
4
फ़ीडबैक के साथ दोबारा कोशिश करें
अगर कुछ गलत है, तो मॉडल को उसका आउटपुट और सटीक गड़बड़ी (error) भेजें, और दोबारा पूछें।
5
साफ़-सुथरे तरीके से रुक जाएँ
2 या 3 कोशिशों के बाद रुक जाएँ और साफ़ तौर पर बताएँ कि यह फ़ेल हो गया है। अंदाज़ा न लगाएँ।

structured.py: validate model JSON and retry with the errorpython

import json

def call_model(prompt: str) -> str:
    # Placeholder. Plug in your provider here. For this demo we fake two replies:
    # the first is wrong, the second is right.
    call_model.n = getattr(call_model, "n", 0) + 1
    if call_model.n == 1:
        return '{"name": "Asha", "people": "four"}'
    return '{"name": "Asha", "people": 4, "date": "2026-10-02"}'

FIELDS = {"name": str, "people": int, "date": str}

def check(raw: str):
    try:
        data = json.loads(raw)
    except json.JSONDecodeError as err:
        return None, "Not valid JSON: " + str(err)
    if not isinstance(data, dict):
        return None, "Expected one JSON object."
    for key, kind in FIELDS.items():
        value = data.get(key)
        if value is None:
            return None, "Missing field: " + key
        if not isinstance(value, kind) or isinstance(value, bool):
            return None, key + " must be of type " + kind.__name__
    if not 1 <= data["people"] <= 20:
        return None, "people must be between 1 and 20"
    return data, None

def get_booking(text: str, tries: int = 3):
    prompt = "Extract name, people (integer), date (YYYY-MM-DD) as JSON only: " + text
    for _ in range(tries):
        raw = call_model(prompt)
        data, error = check(raw)
        if data:
            return data
        prompt += "\nYour last answer: " + raw + "\nProblem: " + error + "\nTry again."
    raise ValueError("Model could not produce valid booking data")

print(get_booking("Table for four on 2 October for Asha, please."))

नोट

असली प्रोजेक्ट्स में आप खुद से एक-एक जाँच लिखने के बजाय schemas को वैलिडेट करने के लिए किसी लाइब्रेरी का इस्तेमाल कर सकते हैं, जैसे कि jsonschema या pydantic Python पैकेज। चाहे जो भी तरीका अपनाएँ, अपने बिज़नेस नियम कोड में ज़रूर रखें।

अच्छी आदतें

Schemas को छोटा और सीधा (flat) रखें। बहुत ज़्यादा अंदर-अंदर उलझे हुए (nested) schemas को भरना मॉडल के लिए मुश्किल होता है।
तयशुदा विकल्पों के लिए enum का इस्तेमाल करें, जैसे "priority": ["low", "medium", "high"]।
ईमानदारी से "मुझे नहीं पता" कहने की गुंजाइश रखें: मनगढ़ंत मान (value) देने से बेहतर है "found": false जैसी कोई फ़ील्ड होना।
additionalProperties: false सेट करें ताकि अतिरिक्त, अनपेक्षित फ़ील्ड्स को खारिज किया जा सके।
हर नाकाम वैलिडेशन को लॉग करें। नाकामियों में अचानक उछाल का अक्सर मतलब होता है कि प्रॉम्प्ट या मॉडल में हुए किसी बदलाव ने कुछ बिगाड़ दिया है।

आउटपुट पर भरोसा करना

json.loads का इस्तेमाल करें और परिणाम सीधे डेटाबेस में भेज दें
वही प्रॉम्प्ट दोबारा भेजकर फिर से कोशिश करें
जब तक काम न बने, तब तक लगातार कोशिश करते रहें

आउटपुट की जाँच करना

पार्स करें, types और बिज़नेस नियमों की जाँच करें, फिर इसका इस्तेमाल करें
सटीक गड़बड़ी (error) के साथ दोबारा कोशिश करें, ताकि मॉडल इसे सुधार सके
कुछ कोशिशों के बाद रुक जाएँ और नाकामी की रिपोर्ट दें

इसे आज़माएँ। ऊपर दिया गया कोड चलाएँ। फिर दूसरे नकली जवाब (fake reply) को बदलकर {"name": "Asha", "people": 400, "date": "2026-10-02"} कर दें। क्या होता है, और क्या आप यही व्यवहार चाहते हैं?

और देखें और पढ़ें

JSON Schemajson-schema.org · reading

लैब

मॉडल द्वारा निकाली गई शिकायत टिकटों के लिए एक वैलिडेटर, retry लूप और साफ़-सुथरी नाकामी (clean failure) की व्यवस्था के साथ।

~30 min

समस्या

नगर निगम की हेल्पलाइन पर WhatsApp जैसी शिकायतें आती हैं जैसे "बस स्टॉप के पास स्ट्रीटलाइट काम नहीं कर रही, अन्ना नगर, 3 दिनों से"। आप चाहते हैं कि मॉडल हर शिकायत को एक टिकट में बदल दे।

एक JSON schema लिखें जिसमें हो: category (enum: water, road, streetlight, garbage, other), area (string), days_open (integer 0 से 365), urgent (boolean)।
Python में एक check() फ़ंक्शन लिखें जो इन नियमों को खुद से जाँचे, या फिर jsonschema पैकेज से पार्स और चेक करे।
एक retry लूप जोड़ें (अधिकतम 3) जो सटीक गड़बड़ी (error) वापस भेजे। एक नकली call_model() का इस्तेमाल करें जो एक गलत और एक सही जवाब लौटाए।
पाँच खराब आउटपुट्स के साथ टेस्ट करें: जो JSON न हो, गायब फ़ील्ड, गलत enum मान, -2 का days_open, और एक अतिरिक्त अज्ञात फ़ील्ड।

आपका काम तब पूरा होगा जब

Schema में category के लिए enum और days_open के लिए सीमाएँ (limits) इस्तेमाल की गई हैं
पाँचों खराब आउटपुट्स को एक स्पष्ट, सटीक मैसेज के साथ खारिज किया जाता है
Retry प्रॉम्प्ट में पिछला जवाब और सटीक समस्या शामिल होती है
आखिरी कोशिश के बाद कोड खराब डेटा वापस करने के बजाय साफ़ तौर पर फ़ेल हो जाता है

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1आपकी schema जाँच पास हो जाती है, लेकिन मॉडल कभी-कभी शिकायत का पूरा टेक्स्ट <code>area</code> में डाल देता है। आप इसे कैसे पकड़ेंगे?दिखाएं

ऐसे नियम जोड़ें जिन्हें schema ठीक से नहीं दर्शा सकता: area के लिए अधिकतम लंबाई, जाने-पहचाने इलाकों या वार्डों की सूची से मिलान, या एक सरल जाँच कि area कहीं पूरे मैसेज जैसा ही तो नहीं है। इस तरह की नाकामी के उदाहरण भी इकट्ठा करें और उन्हें अपने टेस्ट सेट में जोड़ें ताकि आपको पता चल सके कि क्या किसी प्रॉम्प्ट बदलाव से यह समस्या और बढ़ तो नहीं गई।

Q2यूज़र की मूल शिकायत (raw complaint) को बार-बार retry प्रॉम्प्ट में डालना जोखिम भरा क्यों हो सकता है?दिखाएं

हर retry के साथ टेक्स्ट दोबारा भेजा जाता है, जिससे tokens खर्च होते हैं, और अगर शिकायत में मॉडल को भटकाने वाले निर्देश (injection) शामिल हैं, तो इसे दोहराने से उनके असर करने का मौका बढ़ जाता है। यूज़र के टेक्स्ट को साफ़ तौर पर चिन्हित डेटा सेक्शन में रखें, retries की संख्या कम रखें, और सिर्फ़ अपना छोटा गड़बड़ी का मैसेज (error message) तथा मॉडल का पिछला आउटपुट वापस भेजें।

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

अगर API मान्य (valid) JSON की गारंटी देती है, तो क्या मैं वैलिडेशन छोड़ सकता हूँ?

आप पार्सिंग से जुड़ी कुछ जाँचें छोड़ सकते हैं, लेकिन बिज़नेस की जाँचें नहीं। एक मान्य ऑब्जेक्ट में भी गलत तारीख, नामुमकिन रकम या किसी दूसरे यूज़र की आईडी हो सकती है। कोई भी कदम उठाने से पहले हमेशा ज़रूरी बातों की जाँच करें।

सिर्फ़ दोबारा पूछने के बजाय गड़बड़ी (error) वापस क्यों भेजें?

जब तक आप मॉडल को नहीं बताते, उसे पता नहीं चलता कि क्या गलत हुआ। "people must be an integer" उसे सुधारने का साफ़ रास्ता देता है। वही प्रॉम्प्ट दोबारा भेजने पर अक्सर वही गलती दोबारा होती है।

कितनी बार दोबारा कोशिश (retries) करना समझदारी है?

आम तौर पर दो या तीन बार। अगर मॉडल एक ही इनपुट पर इतनी बार फ़ेल होता है, तो शायद प्रॉम्प्ट, schema या काम (task) में बदलाव की ज़रूरत है। ज़्यादा बार कोशिश करने से बिना किसी खास फ़ायदे के लागत और समय दोनों बढ़ जाते हैं।

क्या JSON मांगने से मॉडल की सटीकता कम हो जाती है?

कुछ मामलों में इससे मॉडल का व्यवहार बदल सकता है, उदाहरण के लिए जब मॉडल के पास जवाब देने से पहले सोचने-समझने (reasoning) की गुंजाइश नहीं होती। एक आम तरीका यह है कि आखिरी फ़ील्ड्स से पहले एक छोटी reason फ़ील्ड शामिल कर दी जाए, या फिर तर्क करने और फ़ॉर्मैटिंग का काम अलग-अलग चरणों में किया जाए। अपने डेटा पर दोनों को आज़माकर देखें।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें

Structured outputs और function calling

Structured outputs और function calling

अगर API पहले से ही schema का इस्तेमाल करती है, तो फिर वैलिडेट क्यों करें?

वैलिडेट करें, फिर गड़बड़ी (error) के साथ दोबारा कोशिश करें

पूछें

पार्स करें

जाँचें

फ़ीडबैक के साथ दोबारा कोशिश करें

साफ़-सुथरे तरीके से रुक जाएँ

अच्छी आदतें

और देखें और पढ़ें

समस्या

आपका काम तब पूरा होगा जब

कठिन सवाल

अक्सर पूछे जाने वाले सवाल