LLM-കൾ നിങ്ങളുടെ കോഡിലേക്ക് നേരിട്ട് പ്രവേശിക്കുന്നില്ല – അവ നിങ്ങൾക്ക് ഒരു അഭ്യർത്ഥന (request) നൽകുന്നു, നിങ്ങൾ ആ ഫംഗ്ഷൻ പ്രവർത്തിപ്പിക്കുന്നു. "മോഡൽ മാന്ത്രികമായി എന്റെ പൈത്തൺ റൂട്ടീൻ വിളിക്കുന്നു" എന്ന തെറ്റായ ധാരണയെ ഈ ലളിതമായ വസ്തുത തിരുത്തുന്നു, കൂടാതെ ഡെബഗ്ഗിംഗും സുരക്ഷയും (security) സംബന്ധിച്ച് പുനർചിന്തനം നടത്താൻ ഡെവലപ്പർമാരെ പ്രേരിപ്പിക്കുന്നു.
ഡിസ്പാച്ച് ലൂപ്പ് (dispatch loop), ഘട്ടം ഘട്ടമായി
ഒരു ലാംഗ്വേജ് മോഡലിന് (LLM) ഒരു ടൂൾ ആവശ്യമായി വരുമ്പോൾ, അത് ഒരു നിശ്ചിത ക്രമം (deterministic sequence) പിന്തുടരുന്നു:
- പ്ലാനിംഗ് (Planning) – ഒരു നടപടി ആവശ്യമാണെന്ന് മോഡൽ തീരുമാനിക്കുന്നു (ഉദാഹരണത്തിന്, "ഒരു പേയ്മെന്റ് റീഫണ്ട് ചെയ്യുക").
- ഒരു അഭ്യർത്ഥന തയ്യാറാക്കുന്നു (Generating a request) – അത് ടൂളിന്റെ പേരും ആർഗ്യുമെന്റുകളും (arguments) ഉൾക്കൊള്ളുന്ന സ്ട്രക്ചർഡ് ടെക്സ്റ്റ്—സാധാരണയായി JSON—ഔട്ട്പുട്ട് ആയി നൽകുന്നു.
- പാഴ്സിംഗ് (Parsing) – നിങ്ങളുടെ ആപ്പോ അല്ലെങ്കിൽ ഒരു സപ്പോർട്ടിംഗ് ഫ്രെയിംവർക്കോ ആ ടെക്സ്റ്റ് വായിക്കുന്നു.
- മാച്ചിംഗ് (Matching) – നിങ്ങൾ ലഭ്യമാക്കിയിട്ടുള്ള യഥാർത്ഥ ഫംഗ്ഷനുകളുടെ രജിസ്ട്രിയിൽ നിന്ന് ഫ്രെയിംവർക്ക് ആ പേര് കണ്ടെത്തുന്നു.
- വാലിഡേറ്റിംഗ് (Validating) – ആർഗ്യുമെന്റുകൾ ഫംഗ്ഷന്റെ സ്കീമയുമായി (schema) പൊരുത്തപ്പെടുന്നുണ്ടെന്നും വിളിക്കുന്നയാൾക്ക് (caller) അനുമതിയുണ്ടെന്നും ഇത് പരിശോധിക്കുന്നു.
- എക്സിക്യൂട്ടിംഗ് (Executing) – പൊരുത്തപ്പെട്ട ഫംഗ്ഷൻ നിങ്ങളുടെ എൻവയോൺമെന്റിൽ പ്രവർത്തിക്കുകയും ജോലി പൂർത്തിയാക്കുകയും ചെയ്യുന്നു.
- റിട്ടേണിംഗ് (Returning) – ഫലം പാക്കേജ് ചെയ്ത് കൂടുതൽ വിശകലനത്തിനായി (reasoning) മോഡലിലേക്ക് തിരികെ അയക്കുന്നു.
LLM-നെ ഒരു പ്ലാനർ ആയും, ഫ്രെയിംവർക്കിനെ ഒരു ഡിസ്പാച്ചർ ആയും, ഡാറ്റയോ പണമോ കൈമാറുന്ന യഥാർത്ഥ തൊഴിലാളിയായി ഫംഗ്ഷനെയും സങ്കൽപ്പിക്കുക.
എന്തുകൊണ്ടാണ് ഈ "മാന്ത്രികത" എന്ന മിത്ത് നിലനിൽക്കുന്നത്?
മിക്ക ഡെവലപ്പർമാരും ഒരു ഫംഗ്ഷൻ കോൾ പോലെ തോന്നിക്കുന്ന മോഡൽ ഔട്ട്പുട്ടിന്റെ ഒരു വരി മാത്രം കണ്ട്, മോഡൽ തന്നെ ആ പ്രവർത്തനം ചെയ്തതായി തെറ്റിദ്ധരിക്കുന്നു. പ്രൊവൈഡർ ഡോക്യുമെന്റുകളിലെ "tool calling" എന്ന പദം മോഡൽ നേരിട്ട് കോഡ് വിളിക്കുന്നു എന്ന രീതിയിൽ തോന്നിപ്പിക്കുന്നു.
വാസ്തവത്തിൽ, ഒരു കോളിനെ വിവരിക്കുന്ന ടെക്സ്റ്റ് മാത്രമാണ് മോഡൽ ഉണ്ടാക്കുന്നത്. ലുക്കപ്പ് (lookup), ടൈപ്പ് ചെക്കിംഗ് (type checking), പെർമിഷൻ എൻഫോഴ്സ്മെന്റ് (permission enforcement), എറർ ഹാൻഡ്ലിംഗ് (error handling) തുടങ്ങിയ കഠിനമായ ജോലികളെല്ലാം നിങ്ങളുടെ പ്രോസസ്സ് ആണ് ചെയ്യുന്നത്.
പ്രവർത്തനങ്ങളെ മറച്ചുവെക്കുന്ന ഫ്രെയിംവർക്കുകൾ
PydanticAI, LangChain തുടങ്ങിയ ലൈബ്രറികൾ ഈ ലൂപ്പിനെ ലളിതമാക്കുന്നു (abstract), അങ്ങനെ നിങ്ങൾക്ക് ബിസിനസ് ലോജിക്കിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ കഴിയും. അവ സ്വയമേവ ഇവ ചെയ്യുന്നു:
- ഒരു സ്കീമയ്ക്കെതിരെ (ഉദാഹരണത്തിന്, ഒരു Pydantic model) ആർഗ്യുമെന്റുകൾ പരിശോധിക്കുന്നു (Validate arguments).
- അനുമതികൾ ഉറപ്പാക്കുന്നു (Enforce permissions), ഉപയോക്താവിന് ടൂൾ ഉപയോഗിക്കാൻ അധികാരമുണ്ടെന്ന് ഉറപ്പാക്കുന്നു.
- പരാജയപ്പെട്ടാൽ വീണ്ടും ശ്രമിക്കുന്നു (Retry on failure), ഒരു ടൂൾ എറർ നൽകിയാൽ മോഡലിലേക്ക് തിരികെ പോകുന്നു.
- അനിയന്ത്രിതമായ ലൂപ്പുകളിൽ നിന്ന് സംരക്ഷിക്കുന്നു (Guard against runaway loops), തുടർച്ചയായ ടൂൾ കോളുകളുടെ എണ്ണം പരിമിതപ്പെടുത്തുന്നു.
- സംഭാഷണത്തിന്റെ അവസ്ഥ നിലനിർത്തുന്നു (Maintain conversation state), ടൂൾ ഫലങ്ങളെ സംഭാഷണത്തിന്റെ ഭാഗമാക്കുന്നു.
ഈ സഹായങ്ങൾ ഉണ്ടെങ്കിൽ പോലും, രീതി മാറുന്നില്ല: മോഡൽ ഒരിക്കലും കോഡ് പ്രവർത്തിപ്പിക്കുന്നില്ല.
പ്രൊവൈഡർമാരുടെ നേറ്റീവ് ടൂൾ-കോളിംഗ് സപ്പോർട്ട്
ചില പ്രൊവൈഡർമാർ ടൂൾ നിർവചനങ്ങളും റിക്വസ്റ്റ് ഫോർമാറ്റുകളും ഏകീകരിക്കുന്ന ഒരു "നേറ്റീവ്" ടൂൾ-കോളിംഗ് ഇന്റർഫേസ് നൽകുന്നുണ്ട്. ഇത് സംയോജനം (integration) എളുപ്പമാക്കുന്നുണ്ടെങ്കിലും ഡിസ്പാച്ച് ഘട്ടത്തെ ഒഴിവാക്കുന്നില്ല. അഭ്യർത്ഥിക്കപ്പെട്ട പ്രവർത്തനം യഥാർത്ഥത്തിൽ നടപ്പിലാക്കുന്ന കോഡ് നിങ്ങൾ തന്നെ എഴുതുകയോ (അല്ലെങ്കിൽ ഇംപോർട്ട് ചെയ്യുകയോ) ചെയ്യേണ്ടതുണ്ട്.
പ്രശ്നത്തിന് പുതിയ പേര് നൽകിയാൽ ഡെബഗ്ഗിംഗ് എളുപ്പമാകും
"കൺഫ്യൂസ്ഡ് ഏജന്റ്" (confused agent) എന്ന് കുറ്റപ്പെടുത്തുന്നതിന് പകരം, "മോഡൽ റെസ്പോൺസിൽ ടൂൾ കോളുകൾ ഉണ്ടായില്ല" എന്ന് പറയുക. ഈ വ്യത്യാസം പ്രധാനമാണ്:
- ടൂൾ കോൾ ഇല്ല (No tool call) – മോഡൽ നേരിട്ട് മറുപടി നൽകി അല്ലെങ്കിൽ ശരിയായ ഫോർമാറ്റിലുള്ള റിക്വസ്റ്റ് തയ്യാറാക്കുന്നതിൽ പരാജയപ്പെട്ടു.
- തെറ്റായ റിക്വസ്റ്റ് (Malformed request) – JSON സിന്റാക്സൽ ആയി തെറ്റോ അല്ലെങ്കിൽ ആവശ്യമായ ഫീൽഡുകൾ ഇല്ലാത്തതോ ആണ്, അതിനാൽ ഡിസ്പാച്ചർ അത് നിരസിക്കുന്നു.
- വാലിഡേഷൻ പരാജയം (Validation failure) – ആർഗ്യുമെന്റുകൾ സ്കീമയുമായി പൊരുത്തപ്പെടുന്നില്ല, ഇത് എക്സിക്യൂഷന് മുമ്പ് ഒരു എറർ ഉണ്ടാക്കുന്നു.
പരാജയങ്ങളെ തരംതിരിക്കുന്നത് ലൂപ്പിന്റെ ഓരോ ഘട്ടവും ലോഗ് ചെയ്യാനും എവിടെയാണ് പിശക് സംഭവിച്ചതെന്ന് കൃത്യമായി കണ്ടെത്താനും നിങ്ങളെ സഹായിക്കുന്നു.
വിശ്വസനീയമായ ഒരു പൈപ്പ്ലൈനിനായി പ്രായോഗിക നിർദ്ദേശങ്ങൾ
- മോഡൽ ഔട്ട്പുട്ടിനെ വിശ്വസിക്കാൻ കൊള്ളാത്ത ഇൻപുട്ട് ആയി പരിഗണിക്കുക. സൈഡ്-ഇഫക്റ്റ് ഉണ്ടാക്കുന്ന കോഡുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന് മുമ്പ് ഓരോ റിക്വസ്റ്റും നിശ്ചിത വാലിഡേഷനിലൂടെ കടത്തിവിടുക.
- റ (raw request) ലോഗ് ചെയ്യുക കൂടാതെ ഓരോ വാലിഡേഷൻ ഘട്ടത്തിന്റെയും ഫലം രേഖപ്പെടുത്തുക. ഇത് എന്തെങ്കിലും പിശക് സംഭവിക്കുമ്പോൾ പരിശോധിക്കാൻ സഹായിക്കുന്നു.
- തുടർച്ചയായ ടൂൾ കോളുകൾക്ക് വ്യക്തമായ പരിധികൾ നിശ്ചയിക്കുക; അനിയന്ത്രിതമായ ലൂപ്പുകൾ റിസോഴ്സുകൾ തീർക്കുകയോ റേറ്റ് ലിമിറ്റുകളിൽ (rate limits) എത്തിക്കുകയോ ചെയ്തേക്കാം.
- ഓരോ ഫംഗ്ഷനും ഒരു try/except ബ്ലോക്കിനുള്ളിൽ ഉൾപ്പെടുത്തുക. ഇത് മോഡലിന് മനസ്സിലാക്കാൻ കഴിയുന്ന ഒരു സ്ട്രക്ചർഡ് എറർ ഒബ്ജക്റ്റ് നൽകുകയും, വീണ്ടും ശ്രമിക്കാനോ (retry) അല്ലെങ്കിൽ പരാജയപ്പെട്ടാൽ മറ്റൊരു വഴി സ്വീകരിക്കാനോ (graceful fallback) സഹായിക്കുകയും ചെയ്യുന്നു.
- പെർമിഷൻ ചെക്കുകളെ ബിസിനസ് ലോജിക്കിൽ നിന്ന് വേർതിരിക്കുക. ഫംഗ്ഷൻ പ്രവർത്തിക്കുന്നതിന് മുമ്പ് വിളിക്കുന്നയാളുടെ അവകാശങ്ങൾ പരിശോധിക്കുക, പ്രത്യേകിച്ച് "ഡിലീറ്റ് യൂസർ" (delete user) പോലുള്ള പ്രധാനപ്പെട്ട കാര്യങ്ങളിൽ.
- സ്കീമ അധിഷ്ഠിത നിർവചനങ്ങൾ ഉപയോഗിക്കുക (ഉദാഹരണത്തിന്, Pydantic models), അങ്ങനെ മോഡൽ പിന്തുടരേണ്ട JSON സ്കീം ഫ്രെയിംവർക്കിന് സ്വയമേവ നിർമ്മിക്കാൻ കഴിയും.
ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
പ്രൊവൈഡർമാർ അവരുടെ നേറ്റീവ് ടൂൾ-കോളിംഗ് API-കൾ പരിഷ്കരിക്കുമ്പോൾ, റിക്വസ്റ്റ് ഫോർമാറ്റുകളിൽ കൂടുതൽ കൃത്യതയും കൂടുതൽ വിവരങ്ങൾ നൽകുന്ന എറർ കോഡുകളും പ്രതീക്ഷിക്കാം. ഈ മാറ്റങ്ങൾ വാലിഡേഷൻ എളുപ്പമാക്കുകയും ഡെവലപ്പർമാർക്ക് കൂടുതൽ ശക്തമായ സുരക്ഷാ സംവിധാനങ്ങൾ നിർമ്മിക്കാൻ സഹായിക്കുകയും ചെയ്യും. ലൈബ്രറി അപ്ഡേറ്റുകൾ ശ്രദ്ധിക്കുക—പലതും പുതിയ പ്രൊവൈഡർ ഫീച്ചറുകൾക്കായി ഇൻ-ബിൽറ്റ് സപ്പോർട്ട് നൽകുന്നുണ്ട്.
ചുരുക്കം (Takeaway)
LLM എന്നത് ഒരു അത്യാധുനിക ടെക്സ്റ്റ് ജനറേറ്റർ മാത്രമാണ്, ഒരു എക്സിക്യൂട്ടർ അല്ല. പ്രവൃത്തികൾ നടപ്പിലാക്കുന്ന ഏക അധികാരം നിങ്ങളുടെ കോഡ് തന്നെയാണ്; നിങ്ങൾ നിർമ്മിക്കുന്നതോ (അല്ലെങ്കിൽ ഇംപോർട്ട് ചെയ്യുന്നതോ ആയ) ഡിസ്പാച്ചർ എന്നത് ആ പ്രവൃത്തികളെ സാധൂകരിക്കുകയും (validate), അനുമതി നൽകുകയും (authorize), പ്രവർത്തിപ്പിക്കുകയും ചെയ്യുന്ന ഒരു ഗേറ്റ് കീപ്പർ ആണ്. വർക്ക്ഫ്ലോയെ ഇത്തരത്തിൽ പുനർനിർവചിക്കുന്നത് "മാജിക്" എന്ന മിഥ്യാധാരണ ഇല്ലാതാക്കുന്നു, ഡീബഗ്ഗിംഗ് കൂടുതൽ കൃത്യമാക്കുന്നു, കൂടാതെ ഓരോ പ്രൊഡക്ഷൻ സിസ്റ്റത്തിനും ആവശ്യമായ സുരക്ഷാ അച്ചടക്കം (security discipline) ഉറപ്പുവരുത്തുകയും ചെയ്യുന്നു.