12 ലാർജ്-ലാംഗ്വേജ്-മോഡൽ (LLM) API-കളെക്കുറിച്ചുള്ള പുതിയ ബെഞ്ച്മാർക്ക് പഠനം വ്യക്തമാക്കുന്നത്, മിക്കവാറും എല്ലാ സേവനങ്ങളും ആവശ്യപ്പെട്ട സ്കീമയ്ക്ക് അനുസൃതമായ JSON നൽകുന്നുണ്ടെങ്കിലും, വലിയൊരു വിഭാഗം തെറ്റായ വിവരങ്ങളാണ് നൽകുന്നത് എന്നാണ്. ഒരേ സ്കീമയ്ക്ക് തന്നെ ടോക്കൺ ചിലവ് ഏതാനും ഡസൻ ടോക്കണുകൾ മുതൽ ഏകദേശം അയ്യായിരം ടോക്കണുകൾ വരെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു. എക്സ്ട്രാക്ഷൻ പൈപ്പ്‌ലൈനുകളോ ഡാറ്റാ-ഡ്രിവൺ ഏജന്റുകളോ നിർമ്മിക്കുന്ന ഡെവലപ്പർമാർക്ക് ഇനി മുതൽ "സ്കീമ-വാലിഡ്" (schema-valid) എന്നത് "കൃത്യതയുടെ" (correct) അടയാളമായി കണക്കാക്കാൻ കഴിയില്ല.

ഈ പരിശോധനയുടെ പ്രാധാന്യം

പാഴ്സിംഗ് പിശകുകൾ ഒഴിവാക്കാൻ "സ്ട്രക്ചേർഡ് ഔട്ട്‌പുട്ട്" (structured output) ഒരു പരിഹാരമായി API പ്രൊവൈഡർമാർ വാഗ്ദാനം ചെയ്യുന്നുണ്ട്. മോഡലിന് ഒരു JSON സ്കീമ നൽകിയാൽ, സങ്കീർണ്ണമായ പോസ്റ്റ്-പ്രോസസ്സിംഗ് കോഡുകൾ എഴുതാതെ തന്നെ അത് ഫീൽഡുകൾ പൂരിപ്പിക്കും എന്നതാണ് ഇതിന്റെ ലളിതമായ വാഗ്ദാനം. പ്രായോഗികമായി, പല പ്രൊഡക്ഷൻ സിസ്റ്റങ്ങളും ക്രാഷുകൾ ഒഴിവാക്കാനും ഡാറ്റാ അനലിറ്റിക്സ് പൈപ്പ്‌ലൈനുകൾ കൃത്യമായി നിലനിർത്താനും ഈ ഉറപ്പിനെയാണ് ആശ്രയിക്കുന്നത്. എന്നാൽ ഈ ഉറപ്പ് പകുതി മാത്രം ശരിയായിരിക്കുമ്പോൾ, സിസ്റ്റത്തിൽ നിശബ്ദമായി ബഗുകൾ കടന്നുകൂടുകയും ടോക്കൺ ഉപയോഗത്തെ അടിസ്ഥാനമാക്കിയുള്ള ചിലവ് കണക്കുകൂട്ടലുകൾ വൻതോതിൽ തെറ്റുകയും ചെയ്യുന്നു.

ശുഭവാർത്ത: സ്കീമകൾ ഇപ്പോൾ മിക്കവാറും നടപ്പിലാക്കപ്പെടുന്നു

  • പരീക്ഷണത്തിൽ ഉൾപ്പെട്ട മിക്ക മോഡലുകളും കർശനമായ വാലിഡേറ്റർ പാസായ JSON ആണ് ഉൽപ്പാദിപ്പിച്ചത്.
  • കൺസ്ട്രെയിൻഡ് ഡീകോഡിംഗ് (Constrained decoding) – ഡീകോഡറിനെ സ്കീമയുമായി ബന്ധിപ്പിക്കുന്ന മോഡലുകൾക്ക് തെറ്റായ ക്യാരക്ടറുകൾ നൽകാൻ കഴിയില്ല, അതിനാൽ തെറ്റായ ഫോർമാറ്റിലുള്ള ഡാറ്റകൾ (malformed payloads) ഇപ്പോൾ ഏതാണ്ട് ഇല്ലാതായിരിക്കുന്നു.
  • പാഴ്സിംഗ് പിശകുകൾ (Parse-error rates) – JSON സിന്റാക്സ് പിശകുകൾ സംഭവിക്കുമോ എന്ന പേടിയിൽ ഡെവലപ്പർമാർ ഇനി ഓരോ കോളിനും try-catch ബ്ലോക്കുകൾ ഉപയോഗിക്കേണ്ടതില്ല.

ചീത്തവാർത്ത: വാലിഡിറ്റി $\neq$ അക്യുറസി (Validity $\neq$ Accuracy)

ഒരു ശരിയായ രൂപം (valid shape) കൃത്യമായ മൂല്യം (valid value) ഉറപ്പുനൽകുന്നില്ല. പന്ത്രണ്ട് മോഡലുകളിൽ നാലെണ്ണം—DeepSeek V4, Qwen, GLM-5.2 (റിപ്പോർട്ടിൽ ഇവ രണ്ടും രണ്ട് വ്യത്യസ്ത പേരുകളിലാണ് കാണപ്പെടുന്നത്)—"ചിന്താ പ്രക്രിയ" (chain-of-thought) മോഡ് ഓൺ ചെയ്യുമ്പോൾ തെറ്റായ നമ്പറുകൾ അടങ്ങിയ കൃത്യമായ JSON ആണ് നൽകിയത്.

  • Qwen മോഡലിൽ, റീസണിംഗ് (reasoning) ഉപയോഗിക്കുമ്പോൾ 16-ൽ 1 ശരിയായ ഉത്തരം മാത്രമാണ് ലഭിച്ചതെങ്കിൽ, റീസണിംഗ് ഒഴിവാക്കിയപ്പോൾ 8-ൽ 8 ശരിയായ ഉത്തരങ്ങളും ലഭിച്ചു.
  • DeepSeek V4 Pro-യിലും സമാനമായ മാറ്റം കാണപ്പെട്ടു: മോഡൽ അതിന്റെ ഘട്ടങ്ങൾ വിശദീകരിക്കാൻ ശ്രമിക്കുന്നത് നിർത്തിയപ്പോൾ എക്സ്ട്രാക്ഷൻ കൃത്യത 1/8-ൽ നിന്ന് 7/8 ആയി ഉയർന്നു.

കൂടുതൽ റീസണിംഗ് ഘട്ടങ്ങൾ കൺസ്ട്രെയിൻഡ് ഡീകോഡറിനെ തടസ്സപ്പെടുത്തുകയും, പുറമെയുള്ള ബ്രാക്കറ്റുകൾ കൃത്യമായി പാലിക്കുമ്പോഴും മോഡൽ ഹാലൂസിനേഷനിലേക്ക് (hallucination) വഴുതി വീഴാൻ കാരണമാവുകയും ചെയ്യുന്നു.

മോശം വശങ്ങൾ: ടോക്കൺ ചിലവിലെ അപ്രതീക്ഷിത മാറ്റങ്ങളും അവഗണിക്കപ്പെട്ട പാരാമീറ്ററുകളും

  • Claude-ന്റെ റെസ്പോൺസ് ഫോർമാറ്റ് – OpenAI-യുമായി പൊരുത്തപ്പെടുന്ന എൻഡ്‌പോയിന്റുകൾ വഴി ഉപയോഗിക്കുമ്പോൾ, Claude response_format ഫ്ലാഗ് പൂർണ്ണമായും അവഗണിക്കുകയും സ്കീമയ്ക്ക് അനുസൃതമല്ലാത്ത (0%) ഔട്ട്‌പുട്ട് നൽകുകയും ചെയ്യുന്നു. മോഡൽ സ്ട്രക്ചേർഡ് കോളുകൾ പിന്തുണയ്ക്കുന്നുണ്ടെങ്കിലും, അത് Anthropic-ന്റെ സ്വന്തം ടൂൾ-കോൾ ഇന്റർഫേസ് (tool-call interface) വഴി മാത്രമാണ്.
  • സ്കീമ ടോക്കൺ ഇൻഫ്ലേഷൻ (Schema token inflation) – വെറും 12 KB സ്കീമയ്ക്ക് DeepSeek-ൽ 30 ടോക്കണുകൾ മാത്രമേ ചിലവാകുന്നുള്ളൂ എങ്കിൽ, അതേ ഡാറ്റ Claude-ൽ 4,959 ടോക്കണുകൾ വരെ ഉപയോഗിക്കുന്നു.
  • ബില്ലിംഗ് വൈരുദ്ധ്യങ്ങൾ – ചില പ്രൊവൈഡർമാർ സ്കീമയെ പ്രോംപ്റ്റിന്റെ ഭാഗമായി കണക്കാക്കുകയും ഓരോ ടോക്കണിനും ചാർജ് ചെയ്യുകയും ചെയ്യുന്നു; എന്നാൽ മറ്റുചിലർ ഇതിനെ സൗജന്യമായി കണക്കാക്കുന്നു. വലിയ തോതിലുള്ള ഉപയോഗത്തിൽ, സ്കീമയ്ക്കുള്ള ചിലവ് മോഡൽ ഉൽപ്പാദിപ്പിക്കുന്ന ഉള്ളടക്കത്തിന്റെ ചിലവിനേക്കാൾ കൂടുതലാകാം.

ഡെവലപ്പർമാർ ഇപ്പോൾ എന്തുചെയ്യണം

  1. രൂപം മാത്രമല്ല, മൂല്യങ്ങളും പരിശോധിക്കുക (Validate values, not just shapes) – ഒരു സ്കീമ വാലിഡേറ്ററിന് തെറ്റായ ഒരു സംഖ്യ കണ്ടെത്താൻ കഴിയില്ല, കാരണം അത് പ്രതീക്ഷിച്ച ടൈപ്പിൽ തന്നെയായിരിക്കും. അതിനാൽ ഡൊമെയ്ൻ-സ്പെസിഫിക് പരിശോധനകൾ (പരിധി, യൂണിറ്റ്, ഫീൽഡുകൾ തമ്മിലുള്ള പൊരുത്തം) കൂടി ഉൾപ്പെടുത്തുക.
  2. എക്സ്ട്രാക്ഷനായി ചെയിൻ-ഓഫ്-തോട്ട് ഓഫ് ചെയ്യുക – DeepSeek, Qwen, GLM എന്നിവയിൽ കൃത്യമായ ഫീൽഡുകൾ ലഭിക്കാൻ റീസണിംഗ് ഒഴിവാക്കുക. കൃത്യതയ്ക്ക് റീസണിംഗ് നിർബന്ധമല്ല.
  3. ടോക്കൺ ഉപയോഗം പരിശോധിക്കുക – ഓരോ റിക്വസ്റ്റിലും സ്കീമ ഉൾപ്പെടെ എത്ര ടോക്കണുകൾ ഉപയോഗിക്കുന്നുണ്ടെന്ന് രേഖപ്പെടുത്തുക. വലിയ പ്രോജക്റ്റുകൾ തുടങ്ങുന്നതിന് മുമ്പ് വിവിധ വെണ്ടർമാരുടെ ബില്ലുകൾ താരതമ്യം ചെയ്യുക.
  4. പോർട്ടബിലിറ്റി പരിശോധിക്കുക – OpenAI-യിൽ പ്രവർത്തിക്കുന്ന ഒരു സ്കീമ Gemini അല്ലെങ്കിൽ Claude-ൽ പ്രവർത്തിക്കണമെന്നില്ല. കോഡ് വിതരണം ചെയ്യുന്നതിന് മുമ്പ് ഓരോ പ്ലാറ്റ്‌ഫോമിലും ഇത് കൃത്യമാണോ എന്ന് പരിശോധിക്കുക.

വെണ്ടർമാരുടെ മറുപടി

ചില പ്രൊവൈഡർമാർ വാദിക്കുന്നത് "ചിന്താ പ്രക്രിയ" (thinking mode) എന്നത് വിശദീകരണം ആവശ്യമായ ജോലികൾക്കായി ഡെവലപ്പർമാർ തിരഞ്ഞെടുക്കുന്ന ഒന്നാണ് എന്നാണ്. Claude response_format ഫ്ലാഗ് അവഗണിക്കുന്നത് ചൂണ്ടിക്കാട്ടുകയും പകരം Anthropic-ന്റെ ടൂൾ കോളുകൾ ഉപയോഗിക്കാൻ നിർദ്ദേശിക്കുകയും ചെയ്യുന്നു. ഇവ സാങ്കേതികമായി ശരിയാണെങ്കിലും, ഏത് മോഡ് തിരഞ്ഞെടുക്കണം, ഒളിഞ്ഞിരിക്കുന്ന ടോക്കൺ ഫീസുകൾ എങ്ങനെ കണക്കാക്കണം എന്നതിൻ്റെ ഉത്തരവാദിത്തം ഡെവലപ്പർമാരുടെ മേൽ ചുമത്തുകയാണ് ഇത് ചെയ്യുന്നത്.

ചുരുക്കത്തിൽ

JSON സ്കീമ എന്നത് ഇനി ഒരു സുരക്ഷാ വലയമല്ല; അതൊരു രൂപം (shape) മാത്രമാണ്. ഉള്ളിലെ ഡാറ്റ യാഥാർത്ഥ്യത്തോട് യോജിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക, ടോക്കൺ ചിലവുകൾ ശ്രദ്ധിക്കുക, മോഡലിന്റെ "ചിന്താ പ്രക്രിയ" ഏറ്റവും വൃത്തിയുള്ള ഔട്ട്‌പുട്ടിനെപ്പോലും തെറ്റായതാക്കാൻ സാധ്യതയുണ്ടെന്ന് ഓർക്കുക.