𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗪𝗶𝗻𝗱𝗼𝘄𝘀 𝗔𝗿𝗲 𝗚𝗲𝘁𝘁𝗶𝗻𝗴 𝗛𝘂𝗴𝗲

ആളുകൾ എല്ലാ കാര്യങ്ങൾക്കും 'ഏജന്റ്' (agent) എന്ന വാക്ക് ഉപയോഗിക്കുന്നു.

ഒരു ടൂൾ വിളിക്കുന്ന ഒരു ഫംഗ്ഷൻ ഒരു ഏജന്റാണ്. മെമ്മറിയുള്ള ഒരു ചാറ്റ്ബോട്ട് ഒരു ഏജന്റാണ്. ഒരു ലൂപ്പ് ഉള്ള ഒരു സ്ക്രിപ്റ്റ് ഒരു ഏജന്റാണ്.

ഈ തെറ്റ് മോശം എൻജിനീയറിംഗിലേക്ക് നയിക്കുന്നു. ടീമുകൾ ലളിതമായ ജോലികൾക്ക് അമിതമായി എൻജിനീയറിംഗ് നടത്തുകയും സങ്കീർണ്ണമായവയ്ക്ക് വേണ്ടത്ര എൻജിനീയറിംഗ് നടത്താതിരിക്കുകയും ചെയ്യുന്നു. ഒരു നല്ല പ്രോംപ്റ്റ് മാത്രം മതിയാകുന്ന വർക്ക്ഫ്ലോകൾക്കായി ഏജന്റ് ഓർക്കസ്ട്രേഷനിൽ (agent orchestration) ആഴ്ചകൾ ചിലവഴിക്കുന്നത് ഞാൻ കാണാറുണ്ട്.

ഒരു യഥാർത്ഥ ഏജന്റിനെക്കുറിച്ചുള്ള എന്റെ നിർവചനം ഇതാ.

ഒരു ഏജന്റിന് ഒരു ലക്ഷ്യമുണ്ട് (objective). അത് വെറുതെ നിർദ്ദേശങ്ങൾ മാത്രം പാലിക്കുന്നില്ല. അടുത്തതായി എന്തുചെയ്യണമെന്ന് അത് തീരുമാനിക്കുന്നു. പരാജയങ്ങളെ അത് കൈകാര്യം ചെയ്യുന്നു. എപ്പോൾ നിർത്തണമെന്ന് അതിന് അറിയാം.

ഈ മാനദണ്ഡങ്ങൾ ഉപയോഗിക്കുക:

  • ഓരോ ഘട്ടത്തിലും ഒരു മനുഷ്യൻ മാർഗ്ഗനിർദ്ദേശം നൽകണമെങ്കിൽ, അത് ഒരു ചാറ്റ് ഇന്റർഫേസ് ആണ്.
  • ഒരു ടൂൾ കോൾ പരാജയപ്പെട്ടാൽ സിസ്റ്റം അതിൽ നിന്ന് തിരിച്ചു വരുന്നുണ്ടെങ്കിൽ, അത് ഒരു ഏജന്റായി മാറിക്കൊണ്ടിരിക്കുകയാണ്.
  • സിസ്റ്റം ഒരു ലക്ഷ്യത്തെ ടാസ്ക്കുകളായി വിഭജിക്കുകയും അവ ഏൽപ്പിക്കുകയും ചെയ്യുന്നുണ്ടെങ്കിൽ, അത് ഒരു യഥാർത്ഥ ഏജന്റാണ്.

മിക്ക വിജയകരമായ ഏജന്റുകളും പരിമിതമാണ് (narrow). അവ ഒരു ജോലി നന്നായി ചെയ്യുന്നു. അവ കസ്റ്റമർ സപ്പോർട്ട് ട്രയാജേജ് (customer support triage) അല്ലെങ്കിൽ ഡോക്യുമെന്റ് എക്സ്ട്രാക്ഷൻ (document extraction) പോലുള്ളവ കൈകാര്യം ചെയ്യുന്നു. അവ പൊതുവായ റീസണിംഗ് എൻജിനുകൾ (general reasoning engines) അല്ല.

വിജയകരമായ ടീമുകൾ ഈ മൂന്ന് കാര്യങ്ങളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു:

  • ടൂൾ ഡിസൈൻ: ഇന്റർഫേസ് എത്രത്തോളം വ്യക്തമാണ്?
  • ഫെയിലർ ഹാൻഡ്‌ലിംഗ്: ഒരു ടൂൾ ഒന്നും തിരികെ നൽകാതിരുന്നാൽ എന്ത് സംഭവിക്കും?
  • ഒബ്സർവബിലിറ്റി (Observability): ഏജന്റ് എന്തുകൊണ്ട് ഒരു തീരുമാനം എടുത്തു എന്ന് നിങ്ങൾക്ക് കണ്ടെത്താൻ കഴിയുമോ?

പരാജയപ്പെടുന്ന ടീമുകൾ ഒരു മോഡലിന് പകരം പുതിയൊന്ന് ഉപയോഗിക്കുകയും മികച്ച ഫലങ്ങൾ പ്രതീക്ഷിക്കുകയും ചെയ്യുന്നു. അവർ സിസ്റ്റം ഡിസൈനിനെ അവഗണിക്കുന്നു.

LangChain അല്ലെങ്കിൽ CrewAI പോലുള്ള ഫ്രെയിംവർക്കുകൾ എല്ലാ മാസവും മാറിക്കൊണ്ടിരിക്കുന്നു. ഫ്രെയിംവർക്കിനേക്കാൾ പ്രാധാന്യം പാറ്റേണിനാണ് (pattern).

ഈ പാറ്റേണുകൾ ഉപയോഗിക്കുക:

  • പ്ലാൻ ചെയ്ത ശേഷം നടപ്പിലാക്കുക: റീസണിംഗ് ഘട്ടത്തെ എക്സിക്യൂഷൻ ഘട്ടത്തിൽ നിന്ന് വേർതിരിക്കുക.
  • റിട്രീവലിനെ റീസണിംഗിൽ നിന്ന് വേർതിരിക്കുക: കോൺടെക്സ്റ്റ് ശേഖരിക്കുന്നത് അത് ഉപയോഗിക്കുന്നതിൽ നിന്ന് വ്യത്യസ്തമായ ജോലിയാണ്.
  • എക്സ്പ്ലിസിറ്റ് ഹാൻഡ്‌ഓഫുകൾ (Explicit handoffs): ഒരു ഏജന്റ് മറ്റൊരു ഏജന്റിലേക്ക് ജോലി കൈമാറുമ്പോൾ സ്ട്രക്ചേർഡ് ലോഗുകൾ ഉപയോഗിക്കുക.

ഫ്രെയിംവർക്ക് എന്നത് വെറും സ്കാഫോൾഡിംഗ് (scaffolding) മാത്രമാണ്. ആർക്കിടെക്ചറാണ് യഥാർത്ഥ കെട്ടിടം.

RAG ഒരു സ്റ്റാൻഡേർഡ് ആണ്, എന്നാൽ ചങ്കിംഗ് (chunking) പലപ്പോഴും ശരിയായ രീതിയിലല്ല നടക്കുന്നത്. നിങ്ങൾ ഡോക്യുമെന്റുകൾ മോശമായി വിഭജിച്ചാൽ, മോഡലിന് കോൺടെക്സ്റ്റ് നഷ്ടപ്പെടും. ഇത് ഹാലുസിനേഷനുകളിലേക്ക് (hallucinations) നയിക്കുന്നു.

നിങ്ങളുടെ RAG ഫലങ്ങൾ ഉപയോഗശൂന്യമാണെങ്കിൽ, നിങ്ങളുടെ ചങ്കിംഗും മെറ്റാഡേറ്റയും പരിശോധിക്കുക. മോഡൽ അപൂർവ്വമായേ പ്രശ്നമാകാറുള്ളൂ.

മോഡലുകൾ മെച്ചപ്പെടും. കോൺടെക്സ്റ്റ് വിൻഡോകൾ വർദ്ധിക്കും. ടോക്കൺ ചിലവ് കുറയും.

ഇവയൊന്നും യഥാർത്ഥ എൻജിനീയറിംഗ് വെല്ലുവിളിയെ പരിഹരിക്കുന്നില്ല. നിങ്ങൾ ശ്രദ്ധിക്കാത്തപ്പോഴും ശരിയായി പ്രവർത്തിക്കുന്ന സിസ്റ്റങ്ങൾ നിങ്ങൾ നിർമ്മിക്കണം.

ഗവേണൻസ് (governance), ഒബ്സർവബിലിറ്റി (observability), വിശ്വസനീയമായ ടൂൾ ഉപയോഗം എന്നിവയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുക. മികച്ച എൻജിനീയർമാർ മോഡൽ ഗവേഷകരായിരിക്കില്ല. അവർ വിശ്വസനീയമായ AI നിർമ്മിക്കുന്ന സിസ്റ്റം ഡിസൈനർമാരായിരിക്കും.

Source: https://dev.to/aibughunter/context-windows-are-getting-huge-heres-why-that-changes-everything-2jlh