ഏജന്റ് സെഷൻ മെമ്മറി എന്നത് ഒരു ഫീച്ചറല്ല. അത് നിങ്ങളുടെ കൺട്രോൾ പ്ലാനാണ്.
ഏജന്റ് മെമ്മറി എന്നാൽ വെക്റ്റർ ഡാറ്റാബേസുകളെ (vector databases) കുറിച്ചാണെന്ന് മിക്ക ടീമുകളും കരുതുന്നു. അവർക്ക് തെറ്റിയിരിക്കുന്നു.
യഥാർത്ഥ പ്രശ്നം സംഭാഷണത്തിന്റെ അവസ്ഥയാണ് (conversation state). നിങ്ങളുടെ ഏജന്റ് റീസ്റ്റാർട്ട് ചെയ്യുമ്പോൾ, ആ കോൺടെക്സ്റ്റ് (context) കൈകാര്യം ചെയ്യുന്നത് ആരാണ്?
ഇതൊരു യൂസർ എക്സ്പീരിയൻസ് പ്രശ്നമല്ല. ഇതൊരു ഇൻഫ്രാസ്ട്രക്ചർ പ്രശ്നമാണ്.
പാഴാകുന്ന സമയത്തിന്റെ കണക്ക് ഇതാ: നിങ്ങൾ ഒരു കോഡിംഗ് ഏജന്റ് തുടങ്ങുന്നു. നിങ്ങളുടെ റിപ്പോസിറ്ററി (repository) വായിച്ച് ഒരു മെന്റൽ മോഡൽ നിർമ്മിക്കാൻ അത് 45 സെക്കൻഡ് എടുക്കുന്നു. തുടർന്ന്, ഒരു പോഡ് (pod) റീസ്റ്റാർട്ട് ആകുകയോ, ഒരു കണ്ടെയ്നർ ക്രാഷ് ആകുകയോ, അല്ലെങ്കിൽ നിങ്ങൾ ടൂളുകൾ മാറ്റുകയോ ചെയ്യുന്നു. നിങ്ങളുടെ അടുത്ത സെഷനിൽ അതേ മോഡൽ വീണ്ടും നിർമ്മിക്കാൻ മറ്റൊരു 45 സെക്കൻഡ് കൂടി പാഴാകുന്നു.
10 ഡെവലപ്പർമാർ ദിവസം 3 തവണ ഇങ്ങനെ ചെയ്താൽ, ഒരാൾക്ക് പ്രതിദിനം 225 സെക്കൻഡ് നഷ്ടപ്പെടുന്നു. വലിയ തോതിൽ നോക്കിയാൽ, stateless amnesia കാരണം നൂറുകണക്കിന് എഞ്ചിനീയറിംഗ് മണിക്കൂറുകൾ നിങ്ങൾക്ക് നഷ്ടമാകുന്നു.
മെമ്മറിയെ ഒരു സിംഗിൾ ഫ്രെയിംവർക്കിനുള്ളിലെ ഒരു ഫീച്ചറായി കാണുന്നതാണ് തെറ്റ്. അത് അങ്ങനെയല്ല. സെഷൻ മെമ്മറി എന്നത് നിങ്ങളുടെ റൺടൈമുകൾക്ക് (runtimes) മുകളിലുള്ള ഇൻഫ്രാസ്ട്രക്ചർ ലെയറിൽ ആയിരിക്കണം.
LangGraph അല്ലെങ്കിൽ AutoGen പോലുള്ള ഫ്രെയിംവർക്കുകൾ അവയുടെ പരിധിക്കുള്ളിൽ നിങ്ങൾക്ക് മെമ്മറി നൽകുന്നു. എന്നാൽ താഴെ പറയുന്ന സാഹചര്യങ്ങളിൽ അവ പരാജയപ്പെടുന്നു:
- Claude, Cursor തുടങ്ങിയ വ്യത്യസ്ത റൺടൈമുകളിൽ ഏജന്റുകളെ പ്രവർത്തിപ്പിക്കുമ്പോൾ.
- ടീം അംഗങ്ങൾക്കിടയിൽ സ്റ്റേറ്റ് (state) പങ്കിടേണ്ടി വരുമ്പോൾ.
- കോൺടെക്സ്റ്റ് നഷ്ടപ്പെടാതെ റീസ്റ്റാർട്ടുകളെ അതിജീവിക്കേണ്ടി വരുമ്പോൾ.
- ഒരു പ്രോജക്റ്റിലുടനീളം ഏജന്റിന്റെ പ്രവർത്തനങ്ങൾ ഓഡിറ്റ് ചെയ്യേണ്ടി വരുമ്പോൾ.
മെമ്മറിയുടെ മൂന്ന് തരങ്ങളെക്കുറിച്ച് നിങ്ങൾ അറിഞ്ഞിരിക്കണം:
- സെഷൻ മെമ്മറി (Session Memory): ഒരു ഇന്ററാക്ഷന്റെ ചരിത്രം.
- എപ്പിസോഡിക് മെമ്മറി (Episodic Memory): ആഴ്ചകളോ മാസങ്ങളോ ആയി സൂക്ഷിച്ചിരിക്കുന്ന സംഭവങ്ങൾ.
- സെമാന്റിക് മെമ്മറി (Semantic Memory): ഡാറ്റാബേസുകളിൽ സൂക്ഷിച്ചിരിക്കുന്ന വസ്തുതകളും പാറ്റേണുകളും.
ഏജന്റ് ബ്രെയിനിനെ (agent brain) റൺടൈമിൽ നിന്ന് വേർതിരിച്ചുകൊണ്ട് പ്രൊഡക്ഷൻ ടീമുകൾ ഇത് പരിഹരിക്കുന്നു. ബ്രെയിൻ ഒരു പെർസിസ്റ്റന്റ് പോഡിൽ (persistent pod) റീസണിംഗ് കൈകാര്യം ചെയ്യുന്നു. സാൻഡ്ബോക്സ് (sandbox) ഒരു എഫെമറൽ എൻവയോൺമെന്റിൽ (ephemeral environment) എക്സിക്യൂഷൻ കൈകാര്യം ചെയ്യുന്നു.
2026-ൽ, ടീമുകൾ ഒരു പ്ലാറ്റ്ഫോം മാത്രമല്ല ഉപയോഗിക്കുന്നത്. അവർ പലതാണ് ഉപയോഗിക്കുന്നത്. ഇത് ഫ്രാഗ്മെന്റേഷൻ (fragmentation) ഉണ്ടാക്കുന്നു. ഒരു സെഷൻ Claude-ൽ ആയിരിക്കും. മറ്റൊന്ന് ഒരു ലോക്കൽ ഫയലിലും. വേറൊന്ന് ഒരു ഡാറ്റാബേസിലും. ഇതിനാൽ സെർച്ച് ചെയ്യാനോ ജോലി കൈമാറാനോ ഉള്ള കഴിവ് നിങ്ങൾക്ക് നഷ്ടപ്പെടുന്നു.
വലിയൊരു മോഡൽ ഉപയോഗിച്ച് ഇത് പരിഹരിക്കാൻ ശ്രമിക്കുന്നത് നിർത്തുക. മികച്ച ഇൻഫ്രാസ്ട്രക്ചറിലൂടെ ഇത് പരിഹരിക്കുക.
സ്വയം ഈ മൂന്ന് ചോദ്യങ്ങൾ ചോദിക്കുക:
- എന്റെ ഏജന്റിന് ഒരു റീസ്റ്റാർട്ടിനെ അതിജീവിക്കാൻ കഴിയുമോ?
- എന്റെ ടീമിന് ഏജന്റ് സെഷനുകൾ പങ്കിടാൻ കഴിയുമോ?
- എന്റെ ഏജന്റുകൾ വ്യത്യസ്ത റൺടൈമുകളിൽ കോൺടെക്സ്റ്റ് പങ്കിടുന്നുണ്ടോ?
നിങ്ങൾക്ക് 'അതെ' എന്ന് ഉത്തരം നൽകാൻ കഴിയില്ലെങ്കിൽ, നിങ്ങൾ ഉൽപ്പാദനക്ഷമത (productivity) പാഴാക്കുകയാണ്.
സെഷൻ സ്റ്റേറ്റിനെ ഡ്യൂറബിൾ (durable), സെർച്ചബിൾ (searchable), ഷെയറബിൾ (shareable) ആക്കുന്ന ഒരു കൺട്രോൾ പ്ലാൻ നിർമ്മിക്കുക.
Source: https://dev.to/paultwist/agent-session-memory-isnt-a-feature-its-your-control-plane-1c2p
ഓപ്ഷണൽ ലേണിംഗ് കമ്മ്യൂണിറ്റി: https://t.me/GyaanSetuAi