१२ लार्ज-लँग्वेज-मॉडेल (LLM) API च्या एका नवीन बेंचमार्कमध्ये असे दिसून आले आहे की, जवळजवळ प्रत्येक सेवा विनंती केलेल्या स्कीमाशी (schema) जुळणारा JSON परत करते, परंतु मोठ्या प्रमाणात मॉडेल्स तथ्यात्मकदृष्ट्या चुकीची मूल्ये देतात. त्याच स्कीमासाठी टोकन खर्च काही डझन टोकन्सपासून ते जवळपास पाच हजार टोकन्सपर्यंत बदलतो. एक्सट्रॅक्शन पाइपलाइन्स (extraction pipelines) किंवा डेटा-ड्रिव्हन एजंट्स (data-driven agents) तयार करणारे डेव्हलपर्स आता "स्कीमा-व्हॅलिड" (schema-valid) म्हणजे "बरोबर" (correct) असा समज करून घेऊ शकत नाहीत.
ही चाचणी का महत्त्वाची आहे
API प्रदाते पार्सिंग त्रुटी (parsing errors) दूर करण्यासाठी "स्ट्रक्चर्ड आउटपुट" (structured output) चा प्रचार करत आहेत. याचे आश्वासन सोपे आहे: मॉडेलला JSON स्कीमा द्या, आणि ते तुमच्यासाठी नाजूक पोस्ट-प्रोसेसिंग कोड न लिहिता फील्ड्स भरून देईल. प्रत्यक्षात, अनेक प्रोडक्शन सिस्टम्स क्रॅश टाळण्यासाठी आणि डाउनस्ट्रीम ॲनालिटिक्स पाइपलाइन्स स्वच्छ ठेवण्यासाठी आधीच या हमीवर अवलंबून आहेत. जेव्हा ही हमी अर्धवट सत्य ठरते, तेव्हा सिस्टिममध्ये शांतपणे बग्स (bugs) शिरतात आणि टोकन वापराच्या आधारावर केलेले खर्चाचे गणित पूर्णपणे कोलमडते.
चांगली बातमी: स्कीमा आता बहुतेक वेळा लागू केले जातात
- टेस्ट सुईटमधील बहुतेक मॉडेल्सनी असा JSON तयार केला जो कडक व्हॅलिडेटरमधून (validator) यशस्वीरित्या पार झाला.
- Constrained decoding – जे मॉडेल्स डिकोडरला स्कीमाशी बांधून ठेवतात, ते विस्कळीत वर्ण (stray characters) देऊ शकत नाहीत, त्यामुळे चुकीच्या स्वरूपाचे पेलोड्स (malformed payloads) आता जवळजवळ नष्ट झाले आहेत.
- Parse-error rates – JSON सिंटॅक्स फेल्युअरसाठी डेव्हलपर्सना आता प्रत्येक कॉल 'try-catch' ब्लॉक्समध्ये गुंडाळण्याची गरज नाही.
वाईट बातमी: वैधता ≠ अचूकता (validity ≠ accuracy)
वैध आकार (valid shape) म्हणजे वैध मूल्य (valid value) याची खात्री मिळत नाही. बारा पैकी चार मॉडेल्स—DeepSeek V4, Qwen, आणि GLM-5.2 (यातील शेवटची दोन मॉडेल्स रिपोर्टमध्ये दोन वेगवेगळ्या नावांनी दिसत आहेत)—जेव्हा "thinking" (किंवा chain-of-thought) मोड चालू होता, तेव्हा त्यांनी अचूक स्वरूपाचा JSON तयार केला परंतु त्यामध्ये चुकीचे अंक होते.
- Qwen मॉडेलवर, 'reasoning' सक्षम असताना १६ पैकी फक्त १ बरोबर उत्तर मिळाले, तर 'reasoning' अक्षम केल्यावर ८ पैकी ८ बरोबर उत्तरे मिळाली.
- DeepSeek V4 Pro मध्येही असाच बदल दिसून आला: मॉडेलने स्वतःच्या पायऱ्या स्पष्ट करण्याचा प्रयत्न करणे थांबवल्यानंतर एक्सट्रॅक्शन अचूकता १/८ वरून ७/८ पर्यंत वाढली.
अतिरिक्त 'reasoning' स्टेप 'constrained decoder' मध्ये अडथळा आणते, ज्यामुळे मॉडेल बाहेरील कंबांचे (brackets) पालन करत असतानाही 'hallucination' कडे वळू शकते.
भयंकर बाजू: टोकन-खर्चातील आश्चर्याचा धक्का आणि दुर्लक्षित पॅरामीटर्स
- Claude चा response format – जेव्हा OpenAI-सुसंगत एंडपॉइंट्सद्वारे प्रवेश केला जातो, तेव्हा Claude ने
response_formatफ्लॅग पूर्णपणे दुर्लक्षित केला आणि ०% स्कीमा-सुसंगत आउटपुट दिले. हे मॉडेल स्ट्रक्चर्ड कॉल्सना सपोर्ट करते, परंतु केवळ Anthropic च्या नेटिव्ह 'tool-call' इंटरफेसद्वारे. - Schema token inflation – DeepSeek वर १२ KB च्या साध्या स्कीमासाठी ३० टोकन्स लागतात, परंतु Claude वर त्याच पेलोडसाठी ४,९५९ टोकन्स खर्च झाले.
- Billing inconsistencies – काही प्रदाते स्कीमाला प्रॉम्प्टचा भाग मानतात आणि त्यातील प्रत्येक टोकनसाठी शुल्क आकारतात; इतर त्याला मोफत 'overlay' मानतात. मोठ्या प्रमाणावर वापर करताना, स्कीमाचे बिल मॉडेलने तयार केलेल्या मजकुराच्या खर्चापेक्षाही जास्त असू शकते.
डेव्हलपर्सनी आता काय करावे
- केवळ आकार नाही, तर मूल्ये तपासा (Validate values, not just shapes) – एखादे मूल्य अपेक्षित प्रकाराशी (type) जुळत असले तरी स्कीमा व्हॅलिडेटर चुकीचे संख्यात्मक उत्तर पकडू शकणार नाही. डोमेन-विशिष्ट तपासणी (range, unit, cross-field consistency) जोडा.
- DeepSeek, Qwen, आणि GLM वर एक्सट्रॅक्शनसाठी chain-of-thought बंद करा – जेव्हा तुम्हाला विश्वसनीय फील्ड फिलिंगची गरज असते, तेव्हा हे करा. अतिरिक्त 'reasoning' स्टेप ऐच्छिक आहे, अचूकतेसाठी ती आवश्यक नाही.
- टोकन वापराचे ऑडिट करा – प्रत्येक विनंतीमध्ये स्कीमासह किती टोकन्स खर्च होतात याची नोंद ठेवा आणि मोठ्या प्रमाणावर उपयोजन (deployment) करण्यापूर्वी विविध विक्रेत्यांच्या बिलांची तुलना करा.
- पोर्टेबिलिटी तपासा (Test portability) – OpenAI वर काम करणारा स्कीमा Gemini किंवा Claude वर दुर्लक्षित केला जाऊ शकतो. कोड शिप करण्यापूर्वी प्रत्येक टार्गेट प्लॅटफॉर्मवर त्वरित 'sanity check' करा.
प्रदात्यांचा प्रतिवाद
काही प्रदात्यांचे असे म्हणणे आहे की "thinking" मोड हा डेव्हलपरचा पर्याय आहे, जो अशा कामांसाठी आहे जिथे स्पष्टीकरण हे केवळ एक्सट्रॅक्शन अचूकतेपेक्षा जास्त महत्त्वाचे असते. Claude response_format फ्लॅग दुर्लक्षित करतो आणि त्याऐवजी Anthropic च्या नेटिव्ह 'tool calls' वापरण्याचा सल्ला देतो. ही स्पष्टीकरणे तांत्रिकदृष्ट्या बरोबर आहेत, परंतु ती डेव्हलपर्सवर हे ओझे टाकतात की कोणता मोड निवडावा आणि लपलेल्या टोकन शुल्कासाठी बजेट कसे ठरवावे.
सारांश
JSON स्कीमा आता सुरक्षिततेचे जाळे (safety net) राहिलेले नाही; तो फक्त एक आकार आहे. आतील डेटा वास्तवाशी जुळतो याची खात्री करा, लपलेल्या टोकन खर्चावर लक्ष ठेवा आणि लक्षात ठेवा की मॉडेलचे "thinking" अगदी स्वच्छ दिसणाऱ्या आउटपुटलाही खराब करू शकते.