മോഡൽ എന്നത് ഉൽപ്പന്നമല്ല. യഥാർത്ഥത്തിൽ എന്താണെന്ന് നോക്കാം.
AI വികസിപ്പിക്കുന്നവരുമായി സംസാരിക്കാനും അവരെ സഹായിക്കാനുമാണ് ഞാൻ സമയം ചെലവഴിക്കുന്നത്. ഡെമോകളും യഥാർത്ഥ പ്രൊഡക്ഷൻ സിസ്റ്റങ്ങളും തമ്മിൽ വലിയൊരു വ്യത്യാസമുണ്ട്. പലരും ഈ വ്യത്യാസത്തെക്കുറിച്ച് തുറന്നു പറയുന്നില്ല.
എല്ലാവരും എല്ലാറ്റിനെയും ഏജന്റ് (agent) എന്ന് വിളിക്കുന്നു. ഒരു ലൂപ്പ് ഉള്ള സ്ക്രിപ്റ്റ് ഒരു ഏജന്റാണ്. മെമ്മറിയുള്ള ഒരു ചാറ്റ്ബോട്ട് ഒരു ഏജന്റാണ്. ഇത് എഞ്ചിനീയറിംഗിൽ തെറ്റുകൾക്ക് കാരണമാകുന്നു. ലളിതമായ ജോലികൾക്ക് നിങ്ങൾ അമിതമായി എഞ്ചിനീയറിംഗ് നടത്തുകയും സങ്കീർണ്ണമായവയിൽ മതിയായ ശ്രദ്ധ നൽകാതിരിക്കുകയും ചെയ്യുന്നു.
ഒരു ഏജന്റിന് ഒരു ലക്ഷ്യം (objective) ആവശ്യമാണ്. അത് വെറുതെ ഒരു നിർദ്ദേശം മാത്രം അനുസരിക്കുകയല്ല ചെയ്യുന്നത്. അടുത്തതായി എന്ത് ചെയ്യണമെന്ന് ഒരു ഏജന്റ് സ്വയം തീരുമാനിക്കുന്നു. പരാജയങ്ങളെ അത് കൈകാര്യം ചെയ്യുന്നു. അതിന്റെ ജോലി എപ്പോൾ അവസാനിക്കുന്നുവെന്നും അതിന് അറിയാം.
- ഒരു മനുഷ്യൻ നിങ്ങളുടെ സിസ്റ്റത്തിന് ഓരോ ഘട്ടവും പറഞ്ഞുതരികയാണെങ്കിൽ, അത് ഒരു ചാറ്റ് ഇന്റർഫേസ് മാത്രമാണ്.
- ഒരു ടൂൾ കോൾ (tool call) പരാജയപ്പെട്ടാൽ നിങ്ങളുടെ സിസ്റ്റം അതിൽ നിന്ന് തിരിച്ചു വരുന്നുണ്ടെങ്കിൽ, നിങ്ങൾ ഒരു ഏജന്റ് നിർമ്മിക്കുകയാണ്.
- നിങ്ങളുടെ സിസ്റ്റം ഒരു ലക്ഷ്യത്തെ ഉപദൗത്യങ്ങളായി (subtasks) വിഭജിക്കുന്നുണ്ടെങ്കിൽ, അത് യഥാർത്ഥ ഏജന്റാണ്.
യഥാർത്ഥ ഏജന്റ് വിന്യാസങ്ങൾ (deployments) വളരെ കൃത്യമായ ലക്ഷ്യങ്ങളുള്ളവയാണ്. ഡോക്യുമെന്റ് എക്സ്ട്രാക്ഷൻ (document extraction) അല്ലെങ്കിൽ കോഡ് റിവ്യൂ പോലെ ഒരു കാര്യം മാത്രം മികച്ച രീതിയിൽ അവ ചെയ്യുന്നു. വിജയിക്കുന്ന ടീമുകൾ പുതിയ മോഡലുകൾക്ക് പിന്നാലെ പോകാറില്ല. അവർ ഈ മൂന്ന് കാര്യങ്ങളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു:
- ടൂൾ ഡിസൈൻ (Tool design): ഇന്റർഫേസ് എത്രത്തോളം വ്യക്തമാണ്?
- ഫെയിലർ ഹാൻഡ്ലിംഗ് (Failure handling): ഒരു ടൂൾ ഒന്നും തിരികെ നൽകാതിരുന്നാൽ എന്ത് സംഭവിക്കും?
- ഒബ്സർവബിലിറ്റി (Observability): ഏജന്റ് എന്തുകൊണ്ട് ഒരു തീരുമാനം എടുത്തു എന്ന് നിങ്ങൾക്ക് കണ്ടെത്താൻ കഴിയുമോ?
LangChain അല്ലെങ്കിൽ CrewAI പോലുള്ള ഫ്രെയിംവർക്കുകളേക്കാൾ പ്രാധാന്യം പാറ്റേണുകൾക്കാണ് (patterns). ഫ്രെയിംവർക്ക് എന്നത് ഒരു നിർമ്മാണ താൽക്കാലിക ഘടന (scaffolding) മാത്രമാണ്. ആർക്കിടെക്ചർ ആണ് യഥാർത്ഥ കെട്ടിടം.
ഈ പാറ്റേണുകൾ ഉപയോഗിക്കുക:
- പ്ലാൻ ചെയ്ത ശേഷം നടപ്പിലാക്കുക (Plan then execute). പ്ലാനിംഗിനായി ഒരു ഘട്ടവും നടപ്പിലാക്കുന്നതിനായി (execution) മറ്റൊരു ഘട്ടവും ഉപയോഗിക്കുക.
- റിട്രീവലും (retrieval) റീസണിംഗും (reasoning) വേർതിരിക്കുക. കോൺടെക്സ്റ്റ് ശേഖരിക്കുന്നതും അത് ഉപയോഗിക്കുന്നതും രണ്ട് വ്യത്യസ്ത ജോലികളാണ്.
- വ്യക്തമായ കൈമാറ്റങ്ങൾ (Explicit handoffs). ഒരു ഏജന്റ് മറ്റൊരു ഏജന്റിലേക്ക് ജോലി കൈമാറുമ്പോൾ അത് കൃത്യമായി ക്രമീകരിക്കുക.
RAG എന്നത് ഒരു സ്റ്റാൻഡേർഡ് രീതിയാണ്, എന്നാൽ ചങ്കിംഗ് (chunking) പലപ്പോഴും തെറ്റാകുന്നു. ഡോക്യുമെന്റുകൾ മോശമായി വിഭജിച്ചാൽ, മോഡലിന് കോൺടെക്സ്റ്റ് നഷ്ടപ്പെടുകയും അത് തെറ്റായ വിവരങ്ങൾ നൽകുകയും (hallucinate) ചെയ്യുന്നു. നിങ്ങളുടെ RAG ഫലങ്ങൾ ഉപയോഗശൂന്യമാണെങ്കിൽ, ചങ്കിംഗും മെറ്റാഡേറ്റയും (metadata) ശരിയാക്കുക. എംബെഡിംഗ് മോഡലിനെ (embedding model) കുറ്റപ്പെടുത്തരുത്.
മോഡലുകൾ മെച്ചപ്പെട്ടുകൊണ്ടിരിക്കും. കോൺടെക്സ്റ്റ് വിൻഡോകൾ (context windows) വർദ്ധിക്കും. ചിലവ് കുറയും. എന്നാൽ ഇത് എഞ്ചിനീയറിംഗ് വെല്ലുവിളികളെ മാറ്റുന്നില്ല. നിങ്ങൾ ശ്രദ്ധിക്കാത്ത സമയത്തും വിശ്വസിക്കാൻ കഴിയുന്ന സിസ്റ്റങ്ങൾ നിങ്ങൾ നിർമ്മിക്കണം.
ഗവേണൻസ് (governance), ഒബ്സർവബിലിറ്റി (observability), ടൂൾ ഉപയോഗം എന്നിവയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുക. പ്രോംപ്റ്റ് എഞ്ചിനീയറിംഗിൽ മാത്രം ഒതുങ്ങാതെ, സിസ്റ്റം ഡിസൈനിൽ (systems design) വൈദഗ്ധ്യം നേടുന്ന എഞ്ചിനീയർമാരായിരിക്കും ഭാവിയിൽ പ്രസക്തരാകുക.
Source: https://dev.to/aibughunter/the-model-is-not-the-product-heres-what-actually-is-52b5