AI ആപ്പുകൾക്ക് ഘടനാബദ്ധമായ ഔട്ട്‌പുട്ട് ആവശ്യമായിരിക്കുന്നത് എന്തുകൊണ്ട്?

AI ആപ്പുകൾക്ക് ഘടനാബദ്ധമായ ഔട്ട്‌പുട്ട് വേണം. കാരണം, സ്വാഭാവികമായ ഒരു ഖണ്ഡിക സോഫ്‌റ്റ്‌വെയറിന് വിശ്വസനീയമായി വായിച്ചെടുക്കാനാവില്ല; ഓരോ തവണയും ഒരേ പേരുകളും തരങ്ങളുമുള്ള ഒരേ ഫീൽഡുകളാണ് അതിന് വേണ്ടത്. അധികമായ ഒരു വാക്യമോ ഇല്ലാത്ത ഒരു ഫീൽഡോ നിങ്ങളുടെ ആപ്പിന്റെ അടുത്ത ഘട്ടം തടസ്സപ്പെടുത്താം.

12 പേരുള്ള പാർസൽവൈസ് എന്ന സാങ്കൽപ്പിക ലോജിസ്റ്റിക്സ് സ്റ്റാർട്ടപ്പിനെ സങ്കൽപ്പിക്കുക. അതിലെ ഡെവലപ്പറായ സന, ഉപഭോക്താക്കളുടെ ഇമെയിലുകൾ വായിച്ച് ഡെലിവറി മാറ്റാനുള്ള ഫോമിൽ വിവരങ്ങൾ പൂരിപ്പിക്കുന്ന ഒരു ഉപകരണം നിർമ്മിക്കുകയാണ്: ഓർഡർ റഫറൻസ്, ആവശ്യപ്പെട്ട തീയതി, പുതിയ വിലാസം, ഉപഭോക്താവ് പണം തിരികെ ചോദിക്കുന്നുണ്ടോ എന്നിവ. ഒരു സാധാരണ ഇമെയിൽ ഇങ്ങനെയാണ്: 'ഹായ്, ഓർഡർ PW-88213, വ്യാഴാഴ്ച ഞാൻ സ്ഥലത്തുണ്ടാകില്ല, പകരം ശനിയാഴ്ച കൊണ്ടുവരാമോ? അല്ലെങ്കിൽ 14-ാം നമ്പറിൽ ഏൽപ്പിച്ചാൽ മതി. പറ്റില്ലെങ്കിൽ റദ്ദാക്കി പണം തിരികെ തരൂ.' ആദ്യ പതിപ്പിൽ മോഡലിനോട് 'JSON രൂപത്തിൽ മറുപടി നൽകുക' എന്നാണ് അവൾ ആവശ്യപ്പെടുന്നത്. മിക്ക മറുപടികളും പാർസ് ചെയ്യാനാകുന്നവയാണ്. എന്നാൽ ചിലത് 'തീർച്ചയായും, ഇതാ JSON' എന്ന് തുടങ്ങുന്നു, ചിലത് 'requested_date' എന്നതിനുപകരം ഫീൽഡിന് 'date' എന്ന് പേരിടുന്നു, ഒരെണ്ണം തീയതിയായി 'ശനിയാഴ്ച' എന്ന് നൽകുന്നു.

JSON ഘടനാനിർവചനം എന്താണ്, അത് എങ്ങനെ സഹായിക്കുന്നു?

നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന ഡാറ്റയുടെ ഔപചാരിക വിവരണമാണ് JSON സ്കീമ: ഏതെല്ലാം ഫീൽഡുകളുണ്ട്, ഏതെല്ലാം നിർബന്ധമാണ്, ഓരോന്നിന്റെയും തരം എന്താണ്, ഏതൊക്കെ മൂല്യങ്ങൾ അനുവദനീയമാണ് എന്നിവ. മോഡലിന് ഒരു സ്കീമ നൽകുമ്പോൾ 'ദയവായി JSON രൂപത്തിൽ മറുപടി നൽകുക' എന്ന അഭ്യർഥന നിങ്ങളുടെ കോഡിന് പരിശോധിക്കാവുന്ന ഒരു കരാറായി മാറുന്നു.

സനയുടെ കാര്യത്തിൽ സ്കീമ പറയുന്നത് ഇതാണ്: order_reference നിർബന്ധമായും ഉണ്ടായിരിക്കേണ്ട ഒരു സ്ട്രിങ് ആണ്; requested_date തീയതി രൂപത്തിലുള്ള നിർബന്ധിത സ്ട്രിങ് ആണ്, തീയതി നൽകിയിട്ടില്ലെങ്കിൽ null ആയിരിക്കണം; new_address ഒരു സ്ട്രിങ് അല്ലെങ്കിൽ null ആണ്; refund_requested നിർബന്ധമായും ഉണ്ടായിരിക്കേണ്ട ഒരു ബൂളിയൻ ആണ്; മറ്റൊരു ഫീൽഡും അനുവദനീയമല്ല. അവസാനത്തെ നിയമം മോഡൽ വിശദീകരണ ഫീൽഡുകൾ ചേർക്കുന്നത് തടയുന്നു.

ഘടനാബദ്ധമായ ഔട്ട്പുട്ട് നൽകാൻ മോഡൽ API-കൾ എങ്ങനെ സഹായിക്കുന്നു?

പ്രമുഖ മോഡലുകളുടെ API-കൾ അഭ്യർഥനയ്‌ക്കൊപ്പം ഒരു JSON സ്കീമ നൽകാൻ അനുവദിക്കുന്നു. അതിനോട് പൊരുത്തപ്പെടുന്ന രീതിയിൽ മാത്രമേ മോഡലിന് ഔട്ട്പുട്ട് നൽകാനാകൂ.

OpenAI

കർശന മോഡ് പ്രവർത്തനക്ഷമമാകുമ്പോൾ, OpenAI-യുടെ ഘടനാബദ്ധമായ ഔട്ട്പുട്ടുകൾ എന്ന സവിശേഷത നൽകിയ JSON സ്കീമയ്ക്ക് അനുസൃതമായി മറുപടികളെ പരിമിതപ്പെടുത്തുന്നു. പഴയ JSON മോഡിൽ നിന്ന് ഇതിനെ അതിന്റെ രേഖകൾ വേർതിരിച്ചു വിശദീകരിക്കുന്നു: പഴയ മോഡ് സാധുവായ JSON മാത്രമേ ഉറപ്പാക്കുന്നുള്ളൂ, നിങ്ങളുടെ സ്കീമ പാലിക്കുമെന്ന് ഉറപ്പാക്കുന്നില്ല. ലഭ്യമായിടത്ത് ഘടനാബദ്ധമായ ഔട്ട്പുട്ടുകൾ ഉപയോഗിക്കാനാണ് ശുപാർശ.

Anthropic

നിങ്ങൾ നൽകുന്ന സ്കീമയുമായി പൊരുത്തപ്പെടുന്ന JSON ഫലങ്ങൾ Claude-ന്റെ API നൽകുന്നു. കൂടാതെ, ടൂളുകളുടെ നിർവചനങ്ങളിൽ കർശനമായ പരിശോധനയ്ക്കുള്ള ഒരു ഓപ്ഷനുമുണ്ട്; ഇതിലൂടെ ടൂളിനുള്ള ഇൻപുട്ടുകൾ അതിന്റെ സ്കീമയുമായി പൊരുത്തപ്പെടുന്നുണ്ടെന്ന് പരിശോധിക്കുന്നു. ഏത് സ്കീമ സവിശേഷതകളെയാണ് പിന്തുണയ്ക്കുന്നതെന്നും ഏതൊക്കെയാണ് പിശക് നൽകുന്നതെന്നും അതിന്റെ രേഖകളിൽ പട്ടികപ്പെടുത്തിയിട്ടുണ്ട്.

Google

പ്രതികരണങ്ങൾക്കായി Gemini API ഒരു JSON സ്കീമ സ്വീകരിക്കുകയും നിർവചിച്ചിട്ടുള്ള ചില സ്കീമ കീവേഡുകളെ പിന്തുണയ്ക്കുകയും ചെയ്യുന്നു. ഔട്ട്‌പുട്ട് വ്യാകരണഘടനാപരമായി ശരിയായ JSON ആയിരിക്കുമെങ്കിലും, നിങ്ങളുടെ ആപ്ലിക്കേഷനിൽ മൂല്യങ്ങൾ പരിശോധിക്കണമെന്ന് അതിന്റെ രേഖകൾ പറയുന്നു.

പരിശോധിച്ച് ഉറപ്പാക്കലും വീണ്ടും ശ്രമിക്കലും ഇപ്പോഴും ആവശ്യമായിരിക്കുന്നത് എന്തുകൊണ്ട്?

ഡാറ്റയുടെ ഘടനയാണ് സ്കീമ നിയന്ത്രിക്കുന്നത്, മൂല്യങ്ങൾ ശരിയാണോ എന്നല്ല. അതിനാൽ സാധുത പരിശോധിക്കേണ്ടത് അപ്പോഴും ആവശ്യമാണ്. തികച്ചും ശരിയായ ഘടനയുള്ള മറുപടിയിലും തെറ്റായ തീയതിയോ കെട്ടിച്ചമച്ച ഓർഡർ റഫറൻസോ ഉപഭോക്താവ് ആവശ്യപ്പെടാത്ത പണംതിരിച്ചുനൽകൽ സൂചനയോ ഉണ്ടാകാം.

രണ്ട് തലങ്ങളിൽ സാധുത പരിശോധിക്കുക. ആദ്യം, Python-ലെ Pydantic അല്ലെങ്കിൽ JavaScript-ലെ Zod പോലുള്ള ഒരു സ്കീമ ലൈബ്രറി ഉപയോഗിച്ച് ഘടന പരിശോധിക്കുക. OpenAI, Anthropic, Google എന്നിവയുടെ രേഖകളിലെ ഉദാഹരണങ്ങളിൽ ഇവ കാണാം. രണ്ടാമതായി, ബിസിനസ് നിയമങ്ങൾ പരിശോധിക്കുക: ഓർഡർ റഫറൻസ് നിർദിഷ്ട മാതൃകയുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ, അത് സിസ്റ്റത്തിൽ നിലവിലുണ്ടോ, തീയതി ഭാവിയിലേതും ഡെലിവറി നടത്തുന്ന ദിവസവുമാണോ, വിലാസം ഡെലിവറി മേഖലയിലാണോ? സേവനദാതാക്കൾ രേഖപ്പെടുത്തിയിട്ടുള്ള സാഹചര്യങ്ങളും കൈകാര്യം ചെയ്യുക: നിങ്ങളുടെ സ്കീമ പാലിക്കണമെന്നില്ലാത്ത നിരസിക്കൽ മറുപടി, പരമാവധി ടോക്കൺ പരിധിയെത്തിയതിനാൽ മുറിഞ്ഞുപോയി അപൂർണമായ JSON നൽകുന്ന മറുപടി എന്നിവ.

ശ്രദ്ധയോടെ വീണ്ടും ശ്രമിക്കുക. ഒരു പരിശോധന പരാജയപ്പെട്ടാൽ, കൃത്യമായ പിശക് ഉൾപ്പെടുത്തി ഒരിക്കൽ കൂടി ശ്രമിക്കാൻ നിർദേശം അയയ്ക്കുക. ഉദാഹരണത്തിന്, 'requested_date ഒരു തീയതി ആയിരിക്കണം; ഇമെയിലിൽ ശനിയാഴ്ച എന്നാണ് പറയുന്നത്, ഓർഡർ തീയതി 14 ഒക്ടോബർ ആണ്'. വീണ്ടും ശ്രമിക്കുന്നത് ഒന്നോ രണ്ടോ തവണയായി പരിമിതപ്പെടുത്തുക, തുടർന്ന് ഇമെയിൽ ഒരു വ്യക്തിക്ക് കൈമാറുക.

ദുർബലമായ ഘടനാബദ്ധ ഫലവും വിശ്വസനീയമായ ഘടനാബദ്ധ ഫലവും എങ്ങനെയായിരിക്കും?

ദുർബലമായ പതിപ്പ്: 'വിശദാംശങ്ങൾ വേർതിരിച്ചെടുത്ത് JSON രൂപത്തിൽ മറുപടി നൽകുക.' എന്നാണ് പ്രോംപ്റ്റിൽ പറയുന്നത്. തിരികെ ലഭിക്കുന്നതെന്തും ആപ്പ് വായിക്കുന്നു. മുകളിലെ ഇമെയിലിന്, order എന്നും date എന്നും പേരുള്ള ഫീൽഡുകളും, തീയതിയായി 'ശനിയാഴ്ച' എന്ന മൂല്യവും, റീഫണ്ട് മൂല്യമായി true എന്നതും ലഭിക്കുന്നു. കാരണം, 'അല്ലെങ്കിൽ റദ്ദാക്കിയാൽ മതി' എന്നത് മോഡൽ ഉറച്ച അഭ്യർത്ഥനയായി കണക്കാക്കി. ഫോം തെറ്റായി പൂരിപ്പിക്കപ്പെടുകയും ഉപഭോക്താവിന് ആവശ്യമില്ലാത്ത റീഫണ്ട് ലഭിക്കുകയും ചെയ്യുന്നു.

കൂടുതൽ വിശ്വസനീയമായ പതിപ്പ്: അഭ്യർത്ഥനയിൽ കർശന മോഡ് ഉപയോഗിച്ചുള്ള സനയുടെ സ്കീമ ഉൾപ്പെടുന്നു. 'ഉപഭോക്താവ് ഉപാധികളൊന്നുമില്ലാതെ പണം തിരികെ ആവശ്യപ്പെട്ടാൽ മാത്രം refund_requested ശരിയായിരിക്കും' എന്നതടക്കം ഓരോ ഫീൽഡും പ്രോംപ്റ്റ് വിശദീകരിക്കുന്നു. മോഡൽ order_reference ആയി PW-88213, requested_date ആയി അടുത്ത ശനിയാഴ്ചയുടെ തീയതി, new_address ആയി null, refund_requested ആയി false എന്നിവ നൽകുന്നു. ഈ സാഹചര്യത്തിനായി സന സ്കീമയിൽ ചേർത്ത conditional_request എന്ന ഫീൽഡിന് 'ശനിയാഴ്ചയോ അയൽക്കാരന് കൈമാറുന്നതോ സാധ്യമല്ലെങ്കിൽ പണം തിരികെ നൽകുക' എന്ന മൂല്യം നൽകുന്നു. ഓർഡർ നിലവിലുണ്ടെന്നും ശനിയാഴ്ച ഡെലിവറി നടത്തുന്ന ദിവസമാണെന്നും സാധുതാ പരിശോധന സ്ഥിരീകരിക്കുന്നു. ഇമെയിലിൽ ഉപാധിയുള്ള അഭ്യർത്ഥന അടങ്ങിയിരിക്കുന്നതിനാൽ, അന്തിമ തീരുമാനത്തിനായി നിയമങ്ങൾ അത് ഒരു വ്യക്തിക്ക് കൈമാറുന്നു.

നിശ്ചിത ഘടനയിലുള്ള ഔട്ട്‌പുട്ടിൽ സാധാരണ സംഭവിക്കുന്ന പിഴവുകൾ എന്തൊക്കെയാണ്?

സാധുവായ JSON ശരിയായ ഡാറ്റയാണെന്ന് വിശ്വസിക്കുന്നതാണ് ഏറ്റവും സാധാരണമായ തെറ്റ്. മറ്റ് തെറ്റുകൾ: API ഘടന നിർബന്ധമായി പാലിപ്പിക്കാനുള്ള സൗകര്യം നൽകുമ്പോഴും നിർദേശങ്ങളെ മാത്രം ആശ്രയിക്കുക, വിവരണങ്ങളില്ലാതെ അവ്യക്തമായ ഫീൽഡ് പേരുകൾ ഉപയോഗിക്കുക, സത്യസന്ധമായ ഉത്തരം null ആയിരിക്കുമ്പോൾ ഒരു മൂല്യം നിർബന്ധിച്ച് നൽകിക്കുക, നിരസിക്കലുകളും മുറിഞ്ഞ മറുപടികളും അവഗണിക്കുക, എന്താണ് തെറ്റിയതെന്ന് മോഡലിനെ അറിയിക്കാതെ വീണ്ടും ശ്രമിക്കുക.

Tosheo.ai പാഠപ്പട്ടികയിൽ നിശ്ചിത ഘടനയിലുള്ള ഫലം എവിടെയാണ് ഉൾപ്പെടുന്നത്?

AI ആപ്പുകൾ നിർമ്മിക്കൽ എന്ന വിഭാഗത്തിലെ AI ആപ്പുകൾ നിർമ്മിക്കാനുള്ള കോഴ്‌സിൽ കോഡുമായി ബന്ധപ്പെട്ട ഒരു പാഠമാണ് ഘടനാബദ്ധമായ ഔട്ട്പുട്ട്. ഒരു സ്കീമ നിർവചിക്കുക, API വിളിക്കുക, മറുപടികൾ സാധുതയുള്ളതാണെന്ന് പരിശോധിക്കുക, വീണ്ടും ശ്രമിക്കാനുള്ള സംവിധാനം ചേർക്കുക എന്നിവ കോഡ് ഉപയോഗിച്ച് നേരിട്ട് പരിശീലിക്കുന്ന പൂർണ്ണ പതിപ്പ്, സൈൻ അപ്പ് ചെയ്ത ശേഷം കോഡ് പഠനപാതയിൽ ലഭിക്കും. ഓരോ ഘട്ടത്തിലും വ്യക്തമായ മൂല്യനിർണയ മാനദണ്ഡങ്ങൾ അനുസരിച്ചുള്ള പ്രതികരണവും ലഭിക്കും.

ഉറവിടങ്ങളും പരിധിയും

OpenAI API രേഖകൾ, ഘടനാബദ്ധമായ ഔട്ട്പുട്ടുകൾക്കുള്ള മാർഗദർശി, JSON മോഡ് താരതമ്യം, നിരസിക്കലുകൾ (പരിശോധിച്ചത് 19 October 2026) ↗

Anthropic Claude രേഖകൾ, ഘടനാപരമായ ഫലങ്ങളും കർശനമായ ഉപകരണ ഉപയോഗവും (പരിശോധിച്ചത് 19 ഒക്ടോബർ 2026) ↗

Google Gemini API രേഖകൾ, ഘടനാബദ്ധമായ ഔട്ട്‌പുട്ടും സാധുത പരിശോധിക്കുന്നതിനുള്ള നിർദേശങ്ങളും (പരിശോധിച്ചത് 19 October 2026) ↗