മെമ്മറി തരംതിരിച്ച് ക്രമീകരിക്കുന്നത് റിട്രീവ് ചെയ്യുന്ന ടോക്കണുകളുടെ എണ്ണം ഏകദേശം 40% കുറയ്ക്കുന്നു.

എന്തുകൊണ്ടാണ് ഒരു ഫ്ലാറ്റ് മെമ്മറി സ്റ്റോർ (flat memory store) പരാജയപ്പെടുന്നത്

മിക്ക തുടക്കക്കാരും കാണിക്കുന്ന ട്യൂട്ടോറിയലുകളിൽ, ഓരോ പുതിയ വിവരവും ഒരു സിംഗിൾ ലിസ്റ്റിലേക്ക് ചേർക്കുകയും (appending), ഓരോ തവണയും ആ ലിസ്റ്റ് തന്നെ മോഡലിന് നൽകുകയും ചെയ്താണ് ഒരു LLM ഏജന്റിനെ "ഓർമ്മിക്കാൻ" പഠിപ്പിക്കുന്നത്. ഇതിന്റെ കോഡ് വെറും മൂന്ന് വരികൾ മാത്രമാണ്, അത് ഒരു വർക്കിംഗ് ഡെമോ നൽകുന്നുമുണ്ട്. എന്നാൽ പ്രായോഗികമായി നോക്കുമ്പോൾ, ഈ ലിസ്റ്റ് നിയന്ത്രണമില്ലാതെ വളർന്നുകൊണ്ടിരിക്കും. ഇതിന്റെ രണ്ട് ലക്ഷണങ്ങൾ കാണാം:

  • ഏജന്റ് കാലഹരണപ്പെട്ട വിവരങ്ങളെ ഇപ്പോഴും ശരിയാണെന്ന് കരുതി നൽകുന്നു, ഉദാഹരണത്തിന് മണിക്കൂറുകൾക്ക് മുമ്പ് അവസാനിച്ച ഒരു ETA നൽകുന്നു.
  • ഉത്തരത്തെ ഒട്ടും സ്വാധീനിക്കാത്ത അനാവശ്യ വിവരങ്ങൾ കൊണ്ട് കോൺടെക്സ്റ്റ് വിൻഡോ (context window) നിറയുന്നു, ഇത് API ചിലവ് വർദ്ധിപ്പിക്കുകയും മറുപടി നൽകുന്ന സമയം വൈകിപ്പിക്കുകയും ചെയ്യുന്നു.

ഒരു സാധാരണ വെക്റ്റർ സ്റ്റോറിനോ (vector store) ലളിതമായ കീ-വാല്യൂ കാഷെയോ (key-value cache) ഉപയോക്താവിന്റെ ജോലിയും താൽക്കാലികമായ ഒരു പ്രോജക്റ്റ് സ്റ്റാറ്റസും തമ്മിൽ തിരിച്ചറിയാൻ കഴിയില്ല. ഏജന്റ് ഒരു സെമാന്റിക് സെർച്ച് (semantic search) നടത്തുമ്പോൾ, ക്വറിയിൽ ഒരേ വാക്കുകൾ ഉള്ളതുകൊണ്ട് മാത്രം സിമിലാരിറ്റി അൽഗോരിതം ഒരു പഴയ ETA പുറത്തുകൊണ്ടുവന്നേക്കാം, ആ വിവരം ഇപ്പോൾ പ്രസക്തമല്ലെങ്കിൽ പോലും.

സ്ട്രക്ചേർഡ് മെമ്മറി: നാല് വിഭാഗങ്ങൾ, ഒരു ലക്ഷ്യം

മെമ്മറിയെ ഒരു ഏകീകൃത വസ്തുവായി കാണുന്നത് അവസാനിപ്പിക്കുകയും ഓരോ എൻട്രിയെയും താഴെ പറയുന്ന നാല് വിഭാഗങ്ങളിലൊന്നായി തരംതിരിക്കുകയും ചെയ്യുക എന്നതാണ് ഇതിനുള്ള പരിഹാരം:

  • User facts – ഉപയോക്താവിന്റെ റോൾ, ഇഷ്ടപ്പെട്ട ഭാഷ, അല്ലെങ്കിൽ സെക്യൂരിറ്റി ക്ലിയറൻസ് തുടങ്ങിയ സ്ഥിരമായ കാര്യങ്ങൾ. ഇവ അപൂർവ്വമായി മാത്രമേ മാറുന്നുള്ളൂ, അതിനാൽ മുഴുവൻ സെഷനും ഇവ കാഷെ (cache) ചെയ്യാം.
  • Feedback – ഏജന്റ് പാലിക്കേണ്ട വ്യക്തമായ നിയമങ്ങൾ, ഉദാഹരണത്തിന്, "ഡാറ്റാബേസ് പാസ്‌വേഡുകൾ ഒരിക്കലും വെളിപ്പെടുത്തരുത്" അല്ലെങ്കിൽ "കംപ്ലയൻസ് ക്വറികളിൽ തമാശ ഒഴിവാക്കുക." ഇവ പെരുമാറ്റത്തെ നിയന്ത്രിക്കുന്നവയായതിനാൽ, സെർച്ച് ചെയ്യാവുന്ന ലിസ്റ്റിലല്ല, മറിച്ച് സിസ്റ്റം പ്രോംപ്റ്റിലാണ് (system prompt) ഇവ ഉൾപ്പെടുത്തേണ്ടത്.
  • Project state – നിലവിലെ ETAകൾ, ടാസ്ക് പ്രോഗ്രസ്സ്, അല്ലെങ്കിൽ താൽക്കാലിക ടോക്കണുകൾ തുടങ്ങിയ വേഗത്തിൽ മാറുന്ന വിവരങ്ങൾ. ഈ വിഭാഗത്തിന് ഒരു എക്സ്പയറി ചെക്ക് (expiry check) ആവശ്യമാണ്; ഒരു ടൈംസ്റ്റാമ്പ് നിശ്ചിത സമയപരിധിക്ക് പുറത്തുകഴിഞ്ഞാൽ ആ എൻട്രി നീക്കം ചെയ്യണം.
  • References – എക്സ്റ്റേണൽ സർവീസുകൾക്കായുള്ള പോയിന്ററുകൾ, ഡോക്യുമെന്റ് ഐഡികൾ, അല്ലെങ്കിൽ API എൻഡ്‌പോയിന്റുകൾ. ഇവ പ്രദർശിപ്പിക്കേണ്ട ഉള്ളടക്കമല്ല, മറിച്ച് ആവശ്യമുള്ളപ്പോൾ പുതിയ വിവരങ്ങൾ ശേഖരിക്കാനുള്ള വഴികളാണ്.

ഓരോ മെമ്മറി റെക്കോർഡിലും ഇഷ്ടാനുസൃതമായ മെറ്റാഡാറ്റ (metadata) ചേർക്കാൻ Mem0 ഡെവലപ്പർമാരെ അനുവദിക്കുന്നു. "kind" എന്ന ഫീൽഡ് ഉപയോഗിച്ച് ഇൻഡക്സ് ചെയ്യുന്നതിലൂടെ, LLM ഫലം എങ്ങനെ ഉപയോഗിക്കണമെന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് ഒരു ക്വറിക്ക് പ്രസക്തമായ വിഭാഗം (bucket) ഫിൽട്ടർ ചെയ്യാൻ സാധിക്കും.

Mem0 ഉപയോഗിച്ചുള്ള രണ്ട് ഘട്ടങ്ങളായുള്ള റിട്രീവൽ

  1. Pull memories by kind – ഒരു ചെറിയ ഫിൽട്ടർ ക്വറിയിലൂടെ "എല്ലാ ഫീഡ്‌ബാക്കും" അല്ലെങ്കിൽ "ഒരു ചെറിയ ഇടവേളയ്ക്ക് ശേഷമുള്ള പ്രോജക്റ്റ് സ്റ്റേറ്റ് എൻട്രികൾ" വേണമെന്ന് Mem0-യോട് ആവശ്യപ്പെടുന്നു. ഇതിലൂടെ ലഭിക്കുന്ന ഫലം കൃത്യമായ വിഭാഗത്തിലേക്ക് മാത്രമായി പരിമിതപ്പെടുത്തിയിരിക്കും.
  2. Let the LLM decide – ഫിൽട്ടർ ചെയ്ത വിവരങ്ങൾ ഉപയോക്താവിന്റെ നിലവിലെ ചോദ്യത്തോടൊപ്പം പ്രോംപ്റ്റിൽ ഉൾപ്പെടുത്തുന്നു. അനാവശ്യ വിവരങ്ങൾ പരിശോധിക്കാതെ തന്നെ മോഡലിന് അവയെക്കുറിച്ച് ചിന്തിക്കാൻ (reason) സാധിക്കുന്നു.

ഒരു ഉദാഹരണം: "ഡാറ്റാബേസിനെ പരിഹസിക്കരുത്" എന്ന നിയമം കണ്ടെത്താൻ ഒരു സെമാന്റിക് മാച്ചിനായി കാത്തുനിൽക്കുന്നതിന് പകരം, ഡെവലപ്പർ ആ നിയമം സെഷൻ തുടങ്ങുമ്പോൾ തന്നെ നേരിട്ട് സിസ്റ്റം പ്രോംപ്റ്റിൽ ഉൾപ്പെടുത്തുകയും മുഴുവൻ സംഭാഷണത്തിനും വേണ്ടി അത് കാഷെ ചെയ്യുകയും ചെയ്യുന്നു. ഉപയോക്താവിന്റെ ചോദ്യത്തിൽ ഡാറ്റാബേസിനെക്കുറിച്ച് നേരിട്ട് പരാമർശമില്ലെങ്കിൽ പോലും, ആ നിയന്ത്രണം മോഡലിന് നേരത്തെ തന്നെ അറിയാം.

ചിലവ് കുറയ്ക്കാൻ സഹായിക്കുന്ന പ്രായോഗിക വിദ്യകൾ

  • Cache feedback rules – ഓരോ തവണയും വീണ്ടും സെർച്ച് ചെയ്യുന്നതിന് പകരം, ഒരു സെഷനിൽ ഒരിക്കൽ മാത്രം നിയമങ്ങൾ ശേഖരിക്കുകയും അത് വീണ്ടും ഉപയോഗിക്കുകയും ചെയ്യുക. ഇത് ഓരോ റൗണ്ടിലും ടോക്കൺ ഉപയോഗം കുറയ്ക്കുന്നു.
  • Skip project-state searches when irrelevant – ഉപയോക്താവ് കേവലം ആശയപരമായ ഒരു ചോദ്യമാണ് ചോദിക്കുന്നതെങ്കിൽ (ഉദാഹരണത്തിന്, "supervised learning-ഉം reinforcement learning-ഉം തമ്മിലുള്ള വ്യത്യാസം എന്താണ്?"), ETA അല്ലെങ്കിൽ ടാസ്ക് പ്രോഗ്രസ്സ് വിവരങ്ങൾ ശേഖരിക്കേണ്ടതില്ല.

ഈ രണ്ട് രീതികളും പിന്തുടരുന്നതിലൂടെ, സാധാരണ ഫ്ലാറ്റ് മെമ്മറി രീതിയെ അപേക്ഷിച്ച് ടോക്കൺ ഉപയോഗം ഏകദേശം 40% കുറയ്ക്കാൻ സാധിക്കും. ഇത് നേരിട്ട് API ബില്ലുകൾ കുറയ്ക്കാനും വേഗത്തിലുള്ള മറുപടികൾ നൽകാനും സഹായിക്കുന്നു, പ്രത്യേകിച്ച് കൂടുതൽ സംഭാഷണങ്ങൾ നടത്തുന്ന ഏജന്റുകൾക്ക് ഇത് വളരെ ഗുണകരമാണ്.

ആർക്കാണ് ഗുണം ലഭിക്കുന്നത്, ആർക്കാണ് ആശങ്ക?

Winners – കസ്റ്റമർ സപ്പോർട്ട് ബോട്ടുകൾ, ഇന്റേണൽ വർക്ക്ഫ്ലോ അസിസ്റ്റന്റുകൾ, അല്ലെങ്കിൽ മൾട്ടി-ടേൺ LLM ഇന്റർഫേസുകൾ നിർമ്മിക്കുന്ന ടീമുകൾ. ഇവർക്ക് കൂടുതൽ വിശ്വസനീയമായ ഉത്തരങ്ങൾ ലഭിക്കുന്നു, കാലഹരണപ്പെട്ട വിവരങ്ങൾ മൂലമുണ്ടാകുന്ന തെറ്റുകൾ ഒഴിവാക്കാം, കൂടാതെ ബജറ്റും ലാഭിക്കാം.

ചുരുക്കത്തിൽ (Takeaway)

നീണ്ട സെഷനുകളിൽ കൃത്യത നിലനിർത്തുന്ന ഒരു LLM ഏജന്റ് ആണ് നിങ്ങൾ ആഗ്രഹിക്കുന്നതെങ്കിൽ, എല്ലാ വിവരങ്ങളും ഒരു സിംഗിൾ കോൺടെക്സ്റ്റ് വിൻഡോയിലേക്ക് കുത്തിനിറയ്ക്കുന്നത് നിർത്തുക. ഓരോ മെമ്മറിയും user fact, feedback, project state, അല്ലെങ്കിൽ reference എന്നിങ്ങനെ ടാഗ് ചെയ്യുക, ആവശ്യമുള്ള ഇടങ്ങളിൽ എക്സ്പയറി (expiry) നിശ്ചയിക്കുക, Mem0 പോലുള്ള ഒരു ടൂൾ ഉപയോഗിച്ച് കാര്യങ്ങൾ എളുപ്പമാക്കുക. ഇതിലൂടെ കൂടുതൽ കൃത്യമായ ഉത്തരങ്ങൾ ലഭിക്കുകയും, അനാവശ്യ ടോക്കണുകൾ കുറയുകയും, പ്രവർത്തനച്ചെലവ് ഗണ്യമായി കുറയുകയും ചെയ്യും.