നിങ്ങളുടെ LLM-അധിഷ്ഠിത ഏജന്റ് ഒരു ഡെമോയിൽ മികച്ച രീതിയിൽ പ്രവർത്തിച്ചേക്കാം, എന്നാൽ ഏതാനും തവണ ഉപയോഗിച്ചുകഴിഞ്ഞാൽ അതിന്റെ വേഗത കുറയുകയും ബില്ല് കുതിച്ചുയരുകയും ചെയ്തേക്കാം. ഇതിന് പിന്നിലെ യഥാർത്ഥ കാരണം മോഡലിന്റെ തകരാറല്ല—അത് 'ടോക്കൺ ഡ്രിഫ്റ്റ്' (token drift) ആണ്; അതായത്, ഓരോ തവണയും മോഡൽ പ്രോസസ്സ് ചെയ്യേണ്ട പ്രോംപ്റ്റിൽ (prompt) ക്രമേണ ഉണ്ടാകുന്ന വർദ്ധനവ്.

ഓരോ സംഭാഷണവും മോഡലിന്റെ ഇൻപുട്ട് കോൺടെക്സ്റ്റിലേക്ക് (input context) കൂടുതൽ ടെക്സ്റ്റ് ചേർക്കുമ്പോഴാണ് ടോക്കൺ ഡ്രിഫ്റ്റ് സംഭവിക്കുന്നത്. സംഭാഷണ ചരിത്രം (conversation history), ടൂൾ സ്കീമകൾ (tool schemas), API റെസ്‌പോൺസുകൾ, ലഭ്യമാക്കിയ ഡോക്യുമെന്റുകൾ എന്നിവയെല്ലാം കുന്നുകൂടുന്നു, അതിനാൽ ഓരോ അടുത്ത വിളിയും (call) വലിയൊരു ഡാറ്റാ പാക്കേജുമായി മാറുന്നു. ഇൻപുട്ട് ടോക്കണുകളുടെ എണ്ണത്തിനനുസരിച്ച് മോഡലിന്റെ പ്രോസസ്സിംഗ് സമയവും വിലയും കൂടുന്നതിനാൽ, ചിലവ് ലീനിയർ (linear) രീതിയിലല്ല, മറിച്ച് ക്വാഡ്രാറ്റിക് (quadratically) രീതിയിലാണ് വർദ്ധിക്കുന്നത്.

എന്തുകൊണ്ടാണ് ഈ പ്രശ്നം ഡെമോകളിൽ വരാത്തതും പ്രൊഡക്ഷനിൽ മാത്രം കാണുന്നതും

യഥാർത്ഥ ഉപയോഗങ്ങളിൽ (real deployments) എല്ലാം സൂക്ഷിച്ചുവെക്കപ്പെടുന്നു: ഓരോ ഉപയോക്താവിന്റെ വാക്കും, ഓരോ ടൂൾ ഔട്ട്‌പുട്ടും, ലഭ്യമാക്കിയ അറിവിന്റെ ഓരോ ഭാഗവും. ലേറ്റൻസി (latency) വർദ്ധിക്കുകയും ഇൻവോയ്സ് വരികയും ചെയ്യുന്നത് വരെ ഈ കുന്നുകൂടൽ ശ്രദ്ധിക്കപ്പെടാതെ പോയേക്കാം.

ടോക്കൺ ഡ്രിഫ്റ്റിന്റെ പ്രധാന കാരണങ്ങൾ

  • ആവർത്തിച്ചുള്ള ട്രാൻസ്ക്രിപ്റ്റുകൾ (Repeated transcripts) – പഴയ സന്ദേശങ്ങൾ സംഗ്രഹിക്കുന്നതിനോ ഒഴിവാക്കുന്നതിനോ പകരം പ്രോംപ്റ്റിൽ തന്നെ നിലനിർത്തുന്നത്.
  • ഭാരമേറിയ ടൂൾ സ്കീമകൾ (Heavy tool schemas) – ഓരോ തവണയും ടൂളുകളുടെ പ്രവർത്തനങ്ങളെക്കുറിച്ചുള്ള വലിയ JSON നിർവചനങ്ങൾ അയക്കുന്നത്.
  • അമിതമായ ടൂൾ റിസൾട്ടുകൾ (Bulky tool results) – ഏജന്റിന് ആവശ്യമുള്ളതിനേക്കാൾ കൂടുതൽ ഡാറ്റ അടങ്ങിയ പൂർണ്ണമായ API റെസ്‌പോൺസുകളോ ഡാറ്റാബേസ് വരികളോ ഉൾപ്പെടുത്തുന്നത്.
  • RAG ബ്ലോട്ട് (RAG bloat) – കാലഹരണപ്പെട്ടതോ പ്രസക്തമല്ലാത്തതോ ആയ നിരവധി ഡോക്യുമെന്റ് ഭാഗങ്ങൾ ചേർക്കുന്ന Retrieval-augmented generation (RAG) രീതി.
  • ആവർത്തിച്ചുള്ള മെമ്മറി (Duplicated memory) – ഒരു സംഗ്രഹം (summary), ഒരു സ്റ്റേറ്റ് ഒബ്‌ജക്റ്റ് (state object), ഒരു ട്രാൻസ്ക്രിപ്റ്റ് എന്നിവ ഒന്നിച്ച് ചേർക്കുന്നത് വഴി ഒരേ വിവരങ്ങൾ തന്നെ മൂന്ന് തവണ ആവർത്തിക്കുന്നത്.

ഇവയിൽ ഓരോന്നും പുതിയ യുക്തിപരമായ ചിന്താശേഷി (reasoning power) നൽകുന്നില്ലെങ്കിലും പ്രോംപ്റ്റിന്റെ വലിപ്പം വർദ്ധിപ്പിക്കുന്നു.

ടോക്കൺ ബജറ്റ് നിയന്ത്രിക്കേണ്ട രീതികൾ

1. ലെയറുകളായുള്ള കോൺടെക്സ്റ്റ് ഡിസൈൻ സ്വീകരിക്കുക

  • സ്ഥിരമായ നിർദ്ദേശങ്ങൾ (Stable instructions) – സിസ്റ്റം പ്രോംപ്റ്റുകളും സുരക്ഷാ നിയമങ്ങളും മുകളിൽ തന്നെ നിലനിർത്തുക; ഓരോ തവണയും അവ വീണ്ടും അയക്കുന്നതിന് പകരം അവയെ റഫർ (reference) ചെയ്യുക.
  • ക്രമീകരിച്ച സ്റ്റേറ്റ് (Structured state) – ലക്ഷ്യങ്ങൾ, തീരുമാനങ്ങൾ, ഐഡന്റിഫയറുകൾ എന്നിവയുടെ ലളിതമായ രൂപം സൂക്ഷിക്കുക, ഇത് ഏജന്റിന് വേഗത്തിൽ വായിക്കാൻ സാധിക്കും.
  • സമ്മർചിച്ച ചരിത്രം (Compressed history) – പഴയ സംഭാഷണങ്ങൾ ലളിതമായ ഒരു ഖണ്ഡികയായി സംഗ്രഹിക്കുക; ഒരു നിശ്ചിത പരിധി (threshold) കഴിഞ്ഞാൽ മാത്രം ഇത് പുതുക്കുക.
  • സമീപകാല സംഭാഷണങ്ങൾ (Recent turns) – സംഭാഷണത്തിന്റെ തുടർച്ച നിലനിർത്താൻ അവസാനത്തെ കുറച്ച് സന്ദേശങ്ങൾ അതേപടി ഉൾപ്പെടുത്തുക.

മാറ്റമില്ലാത്ത ടെക്സ്റ്റുകളെയും സംഗ്രഹിക്കാവുന്ന ഉള്ളടക്കങ്ങളെയും വേർതിരിക്കുന്നത് ഒരേ വാക്കുകൾ തന്നെ വീണ്ടും വീണ്ടും അയക്കുന്നത് ഒഴിവാക്കാൻ സഹായിക്കും.

2. ടൂൾ ഔട്ട്‌പുട്ടുകൾ കുറയ്ക്കുക

  • ഏജന്റിന് യഥാർത്ഥത്തിൽ ആവശ്യമുള്ള ഫീൽഡുകൾ മാത്രം എടുക്കുക; അനാവശ്യമായ വിവരണങ്ങൾ ഒഴിവാക്കുക.
  • വലിയ റിസൾട്ടുകൾക്ക് പകരം ഒരു സംഗ്രഹമോ റഫറൻസ് ഐഡിയോ നൽകുക; പൂർണ്ണമായ ഡാറ്റ ഒരു ഡാറ്റാബേസിലോ കാഷെയിലോ (cache) അല്ലെങ്കിൽ ബ്ലോബ് സ്റ്റോറിലോ സൂക്ഷിക്കുക.
  • ഒരു ടൂൾ ഒരു ലിസ്റ്റ് നൽകുന്നുണ്ടെങ്കിൽ, നിലവിലെ തീരുമാനത്തിന് ആവശ്യമുള്ള പ്രധാനപ്പെട്ട (top-N) കാര്യങ്ങൾ മാത്രം അയക്കുക.

3. സ്മാർട്ട് സംഗ്രഹനം ഉപയോഗിക്കുക

  • ഓരോ തവണയും സംഗ്രഹം ചെയ്യുന്നത് ഒഴിവാക്കുക; ഇത് അനാവശ്യമായ പ്രോസസ്സിംഗ് ഭാരം (overhead) വർദ്ധിപ്പിക്കും.
  • പഴയ സംഭാഷണങ്ങളുടെ ടോക്കൺ എണ്ണം നിശ്ചിത പരിധി കവിടുമ്പോൾ മാത്രം സംഗ്രഹം പുതുക്കുക.
  • ഐഡികൾ, തുകകൾ, ടൈംസ്റ്റാമ്പുകൾ തുടങ്ങിയ പ്രധാന വിവരങ്ങൾ വിവരണങ്ങളിൽ (prose) ഉൾപ്പെടുത്തുന്നതിന് പകരം ഒരു സ്ട്രക്ചർഡ് സ്റ്റോറിൽ സൂക്ഷിക്കുക, അതുവഴി സംഗ്രഹം ചെറുതായിരിക്കും.

4. ശരിയായ മെട്രിക്സുകൾ ട്രാക്ക് ചെയ്യുക

  • ടോക്കൺ ഉപയോഗം ഉപയോക്താവിന്റെ ഓരോ അഭ്യർത്ഥനയ്ക്കും പകരം ഓരോ മോഡൽ കോളിനും (per model call) രേഖപ്പെടുത്തുക. ഇത് ഇൻപുട്ട് ഭാഗത്തുണ്ടാകുന്ന രഹസ്യമായ വർദ്ധനവ് കണ്ടെത്താൻ സഹായിക്കും.
  • ഓരോ തവണയും ചേർക്കപ്പെടുന്ന ഇൻപുട്ട് ടോക്കണുകളുടെ എണ്ണം നിരീക്ഷിക്കുക; പെട്ടെന്നുള്ള വർദ്ധനവ് ടോക്കൺ ഡ്രിഫ്റ്റിന്റെ ഉറവിടത്തെ സൂചിപ്പിക്കുന്നു.
  • കാഷെ ചെയ്ത ടോക്കണുകളെയും (cached tokens) പുതുതായി നിർമ്മിച്ച ടോക്കണുകളെയും വേർതിരിക്കുക; കാഷെ ചെയ്തവയല്ല ടോക്കൺ ഡ്രിഫ്റ്റിന് കാരണമാകുന്നത്.

പ്രോംപ്റ്റിനെ ഒരു പരിധിയുള്ള വിഭവമായി കാണുക, അല്ലാതെ അനന്തമായ ഒരു ട്രാൻസ്ക്രിപ്റ്റായിട്ടല്ല. കൃത്യമായി അളക്കുന്നതിലൂടെയും സംഗ്രഹിക്കുന്നതിലൂടെയും അനാവശ്യ ഭാഗങ്ങൾ ഒഴിവാക്കുന്നതിലൂടെയും നിങ്ങളുടെ LLM ഏജന്റിനെ വേഗതയുള്ളതും ചെലവ് കുറഞ്ഞതും പ്രൊഡക്ഷൻ ആവശ്യങ്ങൾക്കായി തയ്യാറുള്ളതുമായി നിലനിർത്താം.

ചുരുക്കത്തിൽ (Takeaway): ടോക്കൺ ഡ്രിഫ്റ്റ് നിശബ്ദമായി ചിലവ് വർദ്ധിപ്പിക്കുകയും ഏജന്റുകളുടെ വേഗത കുറയ്ക്കുകയും ചെയ്യുന്നു. നിങ്ങളുടെ പ്രോംപ്റ്റിൽ വർദ്ധിച്ചുകൊണ്ടിരിക്കുന്ന ഭാഗങ്ങൾ തിരിച്ചറിയുക, അവ സംഗ്രഹിക്കുകയോ പുറത്തേക്ക് മാറ്റുകയോ ചെയ്യുക, ഓരോ കോളിനും ടോക്കൺ ഉപയോഗം ശ്രദ്ധിക്കുക. അച്ചടക്കമുള്ള ഒരു സമീപനം അപ്രതീക്ഷിതമായ ബില്ല് വർദ്ധനവിനെ നിയന്ത്രിക്കാവുന്നതും ബജറ്റിലൊതുങ്ങുന്നതുമായ പ്രവർത്തനമാക്കി മാറ്റുന്നു.