12 लार्ज-लैंग्वेज-मॉडल (LLM) APIs के एक नए बेंचमार्क से पता चलता है कि लगभग हर सर्विस ऐसा JSON लौटाती है जो अनुरोधित स्कीमा (schema) से मेल खाता है, लेकिन एक बड़ी अल्पसंख्यक संख्या तथ्यात्मक रूप से गलत मान (values) देती है। उसी स्कीमा की टोकन लागत कुछ दर्जन टोकन से लेकर लगभग पाँच हज़ार टोकन तक बदलती रहती है। एक्सट्रैक्शन पाइपलाइन या डेटा-संचालित एजेंट बनाने वाले डेवलपर्स अब "स्कीमा-वैलिड" (schema-valid) को "सही" (correct) होने के प्रमाण के रूप में भरोसा नहीं कर सकते।

यह टेस्ट क्यों महत्वपूर्ण है

API प्रदाता पार्सिंग त्रुटियों (parsing errors) को समाप्त करने के तरीके के रूप में "स्ट्रक्चर्ड आउटपुट" (structured output) का प्रचार कर रहे हैं। वादा सरल है: मॉडल को एक JSON स्कीमा दें, और यह बिना किसी नाजुक पोस्ट-प्रोसेसिंग कोड के फ़ील्ड्स को भर देगा। व्यवहार में, कई प्रोडक्शन सिस्टम क्रैश से बचने और डाउनस्ट्रीम एनालिटिक्स पाइपलाइन को साफ रखने के लिए पहले से ही इस गारंटी पर भरोसा करते हैं। जब यह गारंटी केवल आधी सच होती है, तो बग्स चुपचाप आ जाते हैं, और टोकन उपयोग पर आधारित लागत गणनाएं पूरी तरह से गलत हो जाती हैं।

अच्छी खबर: स्कीमा अब ज्यादातर लागू किए जा रहे हैं

  • टेस्ट सूट के अधिकांश मॉडलों ने ऐसा JSON तैयार किया जो एक सख्त वैलिडेटर (validator) को पास कर गया।
  • Constrained decoding – जो मॉडल डिकोडर को स्कीमा के साथ लॉक कर देते हैं, वे अतिरिक्त (stray) कैरेक्टर नहीं निकाल सकते, इसलिए खराब तरीके से बने (malformed) पेलोड अब लगभग खत्म हो चुके हैं।
  • Parse-error rates – डेवलपर्स को अब JSON सिंटैक्स विफलताओं के लिए हर कॉल को try-catch ब्लॉक्स में लपेटने की आवश्यकता नहीं है।

बुरी खबर: वैधता ≠ सटीकता

एक वैध आकार (shape) वैध मान (value) की गारंटी नहीं देता है। बारह में से चार मॉडलों—DeepSeek V4, Qwen, और GLM-5.2 (रिपोर्ट में पिछले दो दो अलग-अलग नामों के तहत दिखाई देते हैं)—ने पूरी तरह से बने हुए JSON तैयार किए, लेकिन जब "thinking" (या chain-of-thought) मोड चालू था, तो उनमें गलत नंबर थे।

  • Qwen मॉडल पर, रीजनिंग सक्षम होने पर 16 में से 1 सही उत्तर से लेकर रीजनिंग अक्षम होने पर 8 में से 8 सही उत्तर तक का अंतर देखा गया।
  • DeepSeek V4 Pro ने भी इसी तरह का बदलाव दिखाया: जैसे ही मॉडल ने अपने चरणों को समझाने की कोशिश करना बंद कर दिया, एक्सट्रैक्शन सटीकता 1/8 से बढ़कर 7/8 हो गई।

अतिरिक्त रीजनिंग स्टेप कंस्ट्रेंड डिकोडर (constrained decoder) में हस्तक्षेप करता है, जिससे मॉडल बाहरी ब्रैकेट का सम्मान करते हुए भी मतिभ्रम (hallucination) की ओर बढ़ जाता है।

काला पक्ष: टोकन-लागत का आश्चर्य और अनदेखे पैरामीटर्स

  • Claude का रिस्पॉन्स फॉर्मेट – जब OpenAI-संगत एंडपॉइंट्स के माध्यम से एक्सेस किया जाता है, तो Claude ने response_format फ्लैग को पूरी तरह से अनदेखा कर दिया, और 0% स्कीमा-अनुपालन वाला आउटपुट लौटाया। मॉडल स्ट्रक्चर्ड कॉल्स का समर्थन करता है, लेकिन केवल Anthropic के नेटिव टूल-कॉल इंटरफेस के माध्यम से।
  • Schema token inflation – DeepSeek पर एक मामूली 12 KB स्कीमा की लागत 30 टोकन है, फिर भी वही पेलोड Claude पर 4,959 टोकन खा गया।
  • Billing inconsistencies – कुछ प्रदाता स्कीमा को प्रॉम्प्ट के हिस्से के रूप में गिनते हैं, और इसके द्वारा उपयोग किए जाने वाले प्रत्येक टोकन के लिए शुल्क लेते हैं; अन्य इसे एक मुफ्त ओवरले के रूप में मानते हैं। बड़े पैमाने पर, स्कीमा का बिल मॉडल द्वारा उत्पन्न सामग्री की लागत से भी अधिक हो सकता है।

डेवलपर्स को अब क्या करना चाहिए

  1. केवल आकार ही नहीं, मानों (values) को भी वैलिडेट करें – एक स्कीमा वैलिडेटर गलत संख्यात्मक उत्तर को नहीं पकड़ पाएगा, भले ही वह अपेक्षित प्रकार (type) का हो। डोमेन-विशिष्ट जाँच (रेंज, यूनिट, क्रॉस-फील्ड कंसिस्टेंसी) जोड़ें।
  2. DeepSeek, Qwen, और GLM पर एक्सट्रैक्शन के लिए chain-of-thought को बंद कर दें जब आपको विश्वसनीय फ़ील्ड फिलिंग की आवश्यकता हो। अतिरिक्त रीजनिंग स्टेप वैकल्पिक है, सटीकता के लिए आवश्यक नहीं है।
  3. टोकन उपयोग का ऑडिट करें – लॉग करें कि प्रत्येक अनुरोध में स्कीमा हिस्से सहित कितने टोकन खर्च होते हैं, और बड़े पैमाने पर तैनाती करने से पहले विभिन्न विक्रेताओं के बिलों की तुलना करें।
  4. पोर्टेबिलिटी का परीक्षण करें – एक स्कीमा जो OpenAI पर काम करता है, वह Gemini या Claude पर चुपचाप छोड़ दिया जा सकता है। कोड शिप करने से पहले प्रत्येक लक्षित प्लेटफॉर्म पर एक त्वरित सैनिटी चेक (sanity check) चलाएं।

विक्रेताओं का प्रतिवाद

कुछ प्रदाताओं का तर्क है कि "thinking" मोड डेवलपर का एक विकल्प है, जो उन कार्यों के लिए है जहाँ स्पष्टीकरण कच्चे एक्सट्रैक्शन की सटीकता से अधिक महत्वपूर्ण होता है। Claude response_format फ्लैग को अनदेखा करता है और इसके बजाय Anthropic के नेटिव टूल कॉल्स का उपयोग करने का सुझाव देता है। वे स्पष्टीकरण तकनीकी रूप से सही हैं, लेकिन वे यह जानने का बोझ डेवलपर्स पर डाल देते हैं कि कौन सा मोड चुनना है और छिपे हुए टोकन शुल्क के लिए बजट कैसे बनाना है।

निष्कर्ष

एक JSON स्कीमा अब कोई सुरक्षा जाल (safety net) नहीं है; यह केवल एक आकार है। सुनिश्चित करें कि इसके अंदर का डेटा वास्तविकता से मेल खाता है, छिपी हुई टोकन लागतों पर नज़र रखें, और याद रखें कि मॉडल की "thinking" सबसे साफ दिखने वाले आउटपुट को भी खराब कर सकती है।