12 લાર્જ-લેંગ્વેજ-મોડેલ (LLM) API ના એક નવા બેન્ચમાર્કથી જાણવા મળ્યું છે કે લગભગ દરેક સર્વિસ વિનંતી કરેલા સ્કીમા (schema) મુજબ JSON રિટર્ન કરે છે, પરંતુ નોંધપાત્ર સંખ્યામાં સર્વિસ તથ્યપૂર્ણ રીતે ખોટી કિંમતો (values) આપે છે. સમાન સ્કીમા માટે ટોકન ખર્ચ થોડા ડઝન ટોકનથી લઈને લગભગ પાંચ હજાર સુધી બદલાઈ શકે છે. એક્સટ્રેક્શન પાઇપલાઇન્સ અથવા ડેટા-ડ્રિવન એજન્ટ્સ બનાવતા ડેવલપર્સ હવે "schema-valid" (સ્કીમા-માન્ય) ને "correct" (સાચા) હોવાના પ્રમાણ તરીકે ગણી શકતા નથી.

આ ટેસ્ટ શા માટે મહત્વનો છે

API પ્રદાતાઓ પાર્સિંગ ભૂલોને દૂર કરવા માટે "structured output" (સ્ટ્રક્ચર્ડ આઉટપુટ) નો પ્રચાર કરી રહ્યા છે. આ વચન સરળ છે: મોડેલને JSON સ્કીમા આપો, અને તે તમારા દ્વારા કોઈ નાજુક પોસ્ટ-પ્રોસેસિંગ કોડ લખ્યા વિના ફિલ્ડ્સ ભરી દેશે. વ્યવહારમાં, ઘણા પ્રોડક્શન સિસ્ટમ્સ ક્રેસ (crash) ટાળવા અને ડાઉનસ્ટ્રીમ એનાલિટિક્સ પાઇપલાઇન્સને સ્વચ્છ રાખવા માટે પહેલેથી જ આ ગેરંટી પર આધાર રાખે છે. જ્યારે આ ગેરંટી અડધી સાચી સાબિત થાય છે, ત્યારે બગ્સ (bugs) શાંતિથી ઘૂસી જાય છે, અને ટોકન વપરાશ પર આધારિત ખર્ચની ગણતરીઓ ખોટી રીતે વધી જાય છે.

સારા સમાચાર: સ્કીમા હવે મોટાભાગે લાગુ કરવામાં આવે છે

  • ટેસ્ટ સ્યુટના મોટાભાગના મોડેલ્સે એવું JSON બનાવ્યું જે સ્ટ્રિક્ટ વેલિડેટર (strict validator) માં પાસ થયું.
  • Constrained decoding – જે મોડેલ્સ ડિકોડરને સ્કીમા સાથે લોક કરે છે તે વધારાના કેરેક્ટર્સ (stray characters) બહાર કાઢી શકતા નથી, તેથી મેલફોર્મ્ડ પેલોડ્સ (malformed payloads) હવે લગભગ અસ્તિત્વમાં નથી.
  • Parse-error rates – ડેવલપર્સને હવે JSON સિન્ટેક્સ નિષ્ફળતા માટે દરેક કોલને try-catch બ્લોક્સમાં રાખવાની જરૂર નથી.

ખરાબ સમાચાર: validity ≠ accuracy

યોગ્ય આકાર (shape) યોગ્ય કિંમત (value) ની ગેરંટી આપતો નથી. બારમાંથી ચાર મોડેલ્સ—DeepSeek V4, Qwen, અને GLM-5.2 (રિપોર્ટમાં છેલ્લા બે અલગ-અલગ નામો હેઠળ દેખાય છે)—જ્યારે "thinking" (અથવા chain-of-thought) મોડ ચાલુ હોય ત્યારે સંપૂર્ણ રીતે ફોર્મેટ કરેલું JSON બનાવતા હતા, પરંતુ તેમાં ખોટા આંકડાઓ હતા.

  • Qwen મોડેલ પર, રીઝનિંગ (reasoning) ચાલુ હોવા પર 16 માંથી માત્ર 1 સાચો જવાબ હતો, જ્યારે રીઝનિંગ બંધ કરવા પર તે 8 માંથી 8 સાચા જવાબો સુધી પહોંચી ગયો.
  • DeepSeek V4 Pro માં પણ આવો જ ફેરફાર જોવા મળ્યો: એકવાર મોડેલે તેના સ્ટેપ્સ સમજાવવાનો પ્રયાસ કરવાનું બંધ કર્યું એટલે એક્સટ્રેક્શન ચોકસાઈ (extraction accuracy) 1/8 થી વધીને 7/8 થઈ ગઈ.

વધારાનું રીઝનિંગ સ્ટેપ કન્સ્ટ્રેઇન્ડ ડિકોડર (constrained decoder) માં દખલ કરે છે, જેના કારણે મોડેલ બહારના બ્રેકેટ્સનું પાલન તો કરે છે, પરંતુ હલ્યુસિનેશન (hallucination) તરફ વળી જાય છે.

કડવું સત્ય: ટોકન-ખર્ચના આશ્ચર્યો અને અવગળાયેલા પેરામીટર્સ

  • Claude’s response format – જ્યારે OpenAI-સુસંગત એન્ડપોઇન્ટ્સ દ્વારા એક્સેસ કરવામાં આવે છે, ત્યારે Claude response_format ફ્લેગને સંપૂર્ણપણે અવગણે છે, અને 0% સ્કીમા-સુસંગત આઉટપુટ આપે છે. મોડેલ સ્ટ્રક્ચર્ડ કોલ્સને સપોર્ટ કરે છે, પરંતુ તે ફક્ત Anthropic ના નેટિવ ટૂલ-કોલ ઇન્ટરફેસ દ્વારા જ શક્ય છે.
  • Schema token inflation – DeepSeek પર માત્ર 12 KB ની સ્કીમા માટે 30 ટોકનનો ખર્ચ થાય છે, જ્યારે Claude પર આ જ પેલોડ 4,959 ટોકન ખાઈ જાય છે.
  • Billing inconsistencies – કેટલાક પ્રદાતાઓ સ્કીમાને પ્રોમ્પ્ટના ભાગ તરીકે ગણે છે અને તેના દ્વારા વપરાતા દરેક ટોકન માટે ચાર્જ કરે છે; અન્ય તેને મફત ઓવરલે તરીકે ગણે છે. મોટા પાયે ઉપયોગ કરતી વખતે, સ્કીમાનું બિલ મોડેલ દ્વારા જનરેટ કરાયેલ કન્ટેન્ટના ખર્ચ કરતા પણ વધી શકે છે.

ડેવલપર્સ અત્યારે શું કરવું જોઈએ

  1. માત્ર આકાર જ નહીં, પણ કિંમતોનું પણ વેરિફિકેશન કરો – સ્કીમા વેલિડેટર ખોટા સંખ્યાત્મક જવાબને પકડી શકશે નહીં, ભલે તે અપેક્ષિત પ્રકાર (type) મુજબ હોય. ડોમેન-સ્પેસિફિક ચેક્સ (રેન્જ, યુનિટ, ક્રોસ-ફિલ્ડ ક consistencey) ઉમેરો.
  2. DeepSeek, Qwen, અને GLM પર એક્સટ્રેક્શન માટે chain-of-thought બંધ કરો જ્યારે તમારે વિશ્વસનીય ફિલ્ડ ફિલિંગની જરૂર હોય. વધારાનું રીઝનિંગ સ્ટેપ વૈકલ્પિક છે, ચોકસાઈ માટે તે જરૂરી નથી.
  3. ટોકન વપરાશનું ઓડિટ કરો – સ્કીમાના ભાગ સહિત દરેક રિક્વેસ્ટ કેટલા ટોકન વાપરે છે તેનો લોગ રાખો, અને મોટા પાયે ડિપ્લોયમેન્ટ કરતા પહેલા વિવિધ વેન્ડર્સના બિલની સરખામણી કરો.
  4. પોર્ટેબિલિટી ટેસ્ટ કરો – OpenAI પર કામ કરતી સ્કીમા Gemini અથવા Claude પર કામ ન પણ કરે. કોડ શિપ કરતા પહેલા દરેક ટાર્ગેટ પ્લેટફોર્મ પર ઝડપી સેનિટી ચેક (sanity check) કરો.

વેન્ડર્સનો પક્ષ

કેટલાક પ્રદાતાઓ દલીલ કરે છે કે "thinking" મોડ એ ડેવલપરની પસંદગી છે, જે એવા કાર્યો માટે છે જ્યાં સમજૂતી (explanation) એક્સટ્રેક્શનની ચોકસાઈ કરતા વધુ મહત્વની હોય છે. Claude response_format ફ્લેગને અવગણે છે અને તેના બદલે Anthropic ના નેટિવ ટૂલ કોલ્સનો ઉપયોગ કરવાનું સૂચવે છે. આ સ્પષ્ટતાઓ ટેકનિકલ રીતે સાચી છે, પરંતુ તે ડેવલપર્સ પર બોજ નાખે છે કે કયો મોડ પસંદ કરવો અને છુપાયેલા ટોકન ફી માટે બજેટ કેવી રીતે બનાવવું.

નિષ્કર્ષ

JSON સ્કીમા હવે કોઈ સેફ્ટી નેટ નથી; તે માત્ર એક આકાર છે. ખાતરી કરો કે અંદરનો ડેટા વાસ્તવિકતા સાથે મેળ ખાય છે, છુપાયેલા ટોકન ખર્ચ પર નજર રાખો, અને યાદ રાખો કે મોડેલનું "thinking" સૌથી સ્વચ્છ દેખાતા આઉટપુટને પણ બગાડી શકે છે.