Skip to main content
जब ऐप्लिकेशन को सख्त JSON चाहिए और मॉडल कभी-कभी लगभग सही आउटपुट लौटाते हैं जो फिर भी parser को विफल कर देता है, तब यह तरीका अपनाएँ।

​
1. स्ट्रक्चर्ड रिस्पॉन्स कॉन्ट्रैक्ट से शुरू करें

रिस्पॉन्स सुधार तभी उपयोगी है जब अनुरोध पहले से ही स्ट्रक्चर्ड आउटपुट माँगता हो। उपयुक्त स्थितियाँ:
  • response_format.type = "json_object"
  • JSON Schema शैली का आउटपुट
  • कई कॉलर द्वारा इस्तेमाल की जाने वाली एक स्थिर object संरचना
खुले रूप वाले टेक्स्ट अनुरोधों के लिए सुधार चालू न करें।

​
2. सही स्तर पर प्लगइन चालू करें

आप response-healing को तीन जगह चालू कर सकते हैं:
  1. workspace की डिफ़ॉल्ट प्लगइन नीति
  2. प्रीसेट प्लगइन कॉन्फ़िगरेशन
  3. अनुरोध में plugins
प्राथमिकता का क्रम:
  1. workspace
  2. प्रीसेट
  3. अनुरोध
जब किसी workflow को हमेशा स्ट्रक्चर्ड JSON चाहिए, तब प्रीसेट डिफ़ॉल्ट इस्तेमाल करें।

​
3. मॉडल के आउटपुट को सीमित रखें

माँगा गया आउटपुट आकार जितना स्पष्ट होगा, सुधार उतना बेहतर काम करेगा। सुझाव:
  • कई असंबंधित ब्लॉब के बजाय एक object
  • अनिवार्य keys स्पष्ट रूप से तय करें
  • संभव हो तो temperature को नियत रखें
  • JSON payload के बाहर अतिरिक्त व्याख्या न माँगें

​
4. जानें कि रिस्पॉन्स सुधार क्या कर सकता है और क्या नहीं

मौजूदा सुधार प्रक्रिया नियतात्मक है और केवल बिना streaming वाली स्थिति में चलती है। Streaming अनुरोध इसे पूरी तरह छोड़ देते हैं। यह सुधार सकता है:
  • JSON के आसपास लगे Markdown code fences
  • अंत में लगी अतिरिक्त कॉमा
  • सुरक्षित रूप से जोड़े जा सकने वाले बंद करने के चिह्न
  • ऐसे object में बिना quotes वाली keys जिसे बाकी हिस्सों से सुधारा जा सकता है
अधिक सीमित नीति के लिए strict mode इस्तेमाल करें। यह केवल code fences या आसपास के टेक्स्ट में से पहले से वैध JSON निकालता है और बाकी व्यापक syntax सुधार नहीं करता। अगर अनुरोध JSON Schema शैली का आउटपुट माँगता है, तो सुधार प्रक्रिया दोबारा लिखने से पहले रिकवर किए गए payload की जाँच भी करती है। मौजूदा validator आम नियमों को कवर करता है, जैसे:
  • अनिवार्य keys
  • बुनियादी scalar और container प्रकार
  • enums और const वैल्यू
  • array सीमा और uniqueItems
  • string लंबाई, regex और email, uri, uuid, date-time जैसे आम प्रारूप
  • संख्या सीमा और multipleOf
  • object property सीमा और additionalProperties: false
यह नहीं कर सकता:
  • अर्थ की दृष्टि से ज़रूरी लेकिन गायब फ़ील्ड गढ़ना
  • व्यावसायिक वैल्यू का अनुमान लगाना
  • मनमाने prose को वैध डेटा में बदलना

​
5. पुष्टि करें कि प्लगइन सचमुच चला

सुधार चलने पर अनुरोध विवरण में प्लगइन रन की जानकारी दिखनी चाहिए। जाँचें:
  • प्लगइन ID
  • क्या उसने बदलाव करने की कोशिश की
  • क्या payload बदला
  • रिस्पॉन्स रिकवर न हो पाने पर विफलता का कारण
  • सुधार की अपेक्षा होने पर क्या अनुरोध बिना streaming के था
अगर प्लगइन दिखाई नहीं देता, तो जाँचें कि अनुरोध, प्रीसेट या workspace नीति में वह चालू था।

​
6. parser की समस्या और सामग्री की समस्या अलग करें

अगर सुधार मदद न करे, तो पता करें कि विफलता किस प्रकार की है:
  1. गलत JSON जो संरचना में अपेक्षित रूप के करीब हो
  2. स्कीमा के अनुसार वैध JSON जिसमें गलत फ़ील्ड हों
  3. JSON के बजाय prose
  4. बहुत कम token सीमा के कारण अधूरा आउटपुट
केवल पहली स्थिति रिस्पॉन्स सुधार के लिए उपयुक्त है।

​
7. धीरे-धीरे लागू करें

  1. स्थिर स्ट्रक्चर्ड आउटपुट वाले एक प्रीसेट में सुधार चालू करें
  2. लॉग में प्लगइन रन मेटाडेटा देखें
  3. पुष्टि करें कि रिकवर किए गए payload अपेक्षित स्कीमा से मेल खाते हैं
  4. लॉग साफ़ होने पर ही मिलते-जुलते प्रीसेट तक सेटिंग फैलाएँ

​
8. सही mode चुनें

  • अगर workflow को सीमित syntax सफ़ाई से लाभ हो, जैसे अतिरिक्त कॉमा हटाना या बिना quotes वाली keys को quote करना, तो safe इस्तेमाल करें।
  • अगर wrappers हटाने के बाद केवल पहले से वैध JSON स्वीकार करना हो, तो strict इस्तेमाल करें।
  • अनुरोध विवरण में जाँचें कि कौन-सा mode चला।

​
संबंधित गाइड

अंतिम संशोधन 2 अक्टूबर 2026