നീണ്ട ഏജന്റ് ടേണുകൾ കോൺടെക്സ്റ്റ് വിൻഡോയ്ക്കുള്ളിൽ നിർത്തുന്നു

ഒരു മോഡലിന് ഒരേസമയം വായിക്കാവുന്നത് പരിമിതമാണ്: അതിന്റെ കോൺടെക്സ്റ്റ് വിൻഡോ. Mythex-ന്റെ ഏജന്റ് നീണ്ട ജോലി ചെയ്യുന്നു: നിരവധി ഫയലുകൾ വായിക്കുന്നു, കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കുന്നു, പരിമിതമായ ജോലികൾ സബ്-ഏജന്റുകൾക്ക് കൈമാറുന്നു. നീണ്ട ജോലി തകരാറിലാകുന്ന മൂന്ന് വഴികൾ ഞങ്ങൾ കണ്ടെത്തി: സബ്-ഏജന്റുകൾ മോഡൽ എല്ലാ അഭ്യർത്ഥനകളും നിരസിക്കുന്നതുവരെ വളർന്നു, മുറിയില്ലെന്ന് കരുതി ഒരു സബ്-ഏജന്റ് നേരത്തെ നിർത്തി, ഞങ്ങളുടെ ടോക്കൺ എണ്ണം റഷ്യൻ, ചൈനീസ്, ജാപ്പനീസ് ടെക്സ്റ്റിന് വളരെ തെറ്റായിരുന്നു. ഞങ്ങൾ മാറ്റിയത് ഇതാണ്.

ആദ്യം ചില പദങ്ങൾ

• ടോക്കണുകൾ മോഡൽ വായിക്കുന്ന കഷണങ്ങളാണ്. പരിധികളും ചെലവുകളും കണക്കാക്കുന്നത് അക്ഷരങ്ങളിലോ വാക്കുകളിലോ അല്ല, ടോക്കണുകളിലാണ്.
• കോൺടെക്സ്റ്റ് വിൻഡോ ഒരു അഭ്യർത്ഥനയിൽ മോഡലിന് വായിക്കാവുന്ന പരമാവധി അളവാണ്. ചെലവും വേഗതയും ന്യായമായി നിലനിർത്താൻ ഓരോ അഭ്യർത്ഥനയ്ക്കും ഞങ്ങൾ സ്വന്തമായി കുറഞ്ഞ ബജറ്റും നിശ്ചയിക്കുന്നു.
• ടൂൾ ഫലങ്ങൾ ഏജന്റിന് ഏജന്റിന്റെ ടൂളുകളിൽ നിന്ന് തിരികെ കിട്ടുന്നതാണ്: ഒരു ഫയലിന്റെ ഉള്ളടക്കം, ഒരു കമാൻഡിന്റെ ഔട്ട്പുട്ട്. നീണ്ട ജോലിയിൽ അവയാണ് അയക്കുന്നതിന്റെ മിക്ക ഭാഗവും.
• സബ്-ഏജന്റ് എന്നത് ഒരു സ്വതന്ത്ര ജോലിക്കായി മെയിൻ ഏജന്റ് തുടങ്ങുന്ന സഹായിയാണ്, ഉദാഹരണത്തിന് "ഈ അധ്യായങ്ങൾ നോട്ടുകളുമായി ഒത്തുനോക്കുക". അതിന് ഒരൊറ്റ നിർദ്ദേശം കിട്ടുന്നു, പിന്നെ സ്വന്തമായി നിരവധി ടൂൾ കോളുകളിലൂടെ പ്രവർത്തിക്കുന്നു.

പ്രശ്നം 1: സബ്-ഏജന്റുകൾ മോഡൽ നിരസിക്കുന്നതുവരെ വളർന്നു

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

ഒരു സബ്-ഏജന്റിന് ഒരേയൊരു ഉപയോക്തൃ സന്ദേശമേയുള്ളൂ: അതിന്റെ നിർദ്ദേശം. വെട്ടാൻ ഒരിടവുമില്ലായിരുന്നു. അതിനാൽ അത് ഓരോ ഘട്ടത്തിലും അതിന്റെ മുഴുവൻ ചരിത്രവും അയച്ചു, ഓരോ തവണയും വളർന്ന്, അഭ്യർത്ഥന മോഡൽ സ്വീകരിക്കുന്നതിനേക്കാൾ വലുതാകുന്നതുവരെ, ഏകദേശം ഒരു ദശലക്ഷം ടോക്കണുകൾ. അത്തരം 8 സബ്-ഏജന്റുകളുള്ള ഒരു ടെസ്റ്റിൽ, 8-ഉം നിരസിക്കപ്പെട്ടു.

പരിഹാരം: ആദ്യം പഴയ ടൂൾ ഫലങ്ങൾ മായ്ക്കുക

ഇപ്പോൾ അഭ്യർത്ഥനകൾ മൂന്ന് ഘട്ടങ്ങളിലായി ബജറ്റിൽ ഒതുക്കുന്നു, മുമ്പത്തെ ഘട്ടം മതിയായില്ലെങ്കിൽ മാത്രം അടുത്തത്:

1. ഏറ്റവും പഴയ ടൂൾ ഫലങ്ങൾ മായ്ക്കുക. അവയുടെ ഉള്ളടക്കം ഒരു ചെറിയ കുറിപ്പ് കൊണ്ട് മാറ്റിസ്ഥാപിക്കുന്നു: മോഡലിന്റെ കോൺടെക്സ്റ്റിൽ ഒതുങ്ങാൻ ഫലം മായ്ച്ചു, ആവശ്യമെങ്കിൽ ഏജന്റിന് ആ ടൂൾ വീണ്ടും പ്രവർത്തിപ്പിക്കാം. ഒരു മണിക്കൂർ മുമ്പ് വായിച്ച ഫയൽ സാധാരണയായി അഭ്യർത്ഥനയിലെ ഏറ്റവും വലുതും ഏറ്റവും കുറഞ്ഞ ഉപയോഗമുള്ളതുമായ കാര്യമാണ്, ഫയൽ വീണ്ടും വായിക്കാൻ ഇപ്പോഴും ലഭ്യമാണ്. ഏറ്റവും പുതിയ ഫലങ്ങൾ പൂർണ്ണമായി നിൽക്കുന്നു.
2. മുഴുവൻ ഉപയോക്തൃ ടേണുകൾ നിലനിർത്തുക. മുമ്പത്തെപ്പോലെ: ആദ്യ സന്ദേശം, ഒരു കുറിപ്പ്, യോജിക്കുന്ന ഏറ്റവും പുതിയ മുഴുവൻ ടേണുകൾ.
3. മുഴുവൻ ടൂൾ റൗണ്ടുകൾ നിലനിർത്തുക. ഒരു നീണ്ട ടേണിനുള്ളിൽ, അതായത് സബ്-ഏജന്റിന് ഉള്ള ഒരേയൊരു തരത്തിൽ, ആദ്യ സന്ദേശം, ഒരു കുറിപ്പ്, "ഒരു ടൂൾ വിളിക്കുക, അതിന്റെ ഫലം കിട്ടുക" എന്നതിന്റെ ഏറ്റവും പുതിയ മുഴുവൻ റൗണ്ടുകളും നിലനിർത്തുക.

ഇത് അയക്കുന്നതിന്റെ ആകൃതി മാത്രമേ മാറ്റുന്നുള്ളൂ. ഏജന്റിന്റെ സേവ് ചെയ്ത ചരിത്രത്തിൽ എല്ലാം തുടരുന്നു. അതേ ടെസ്റ്റിൽ, 8-ൽ 0 നിരസിക്കപ്പെട്ടു, 8-ഉം പൂർത്തിയായി.

ബാച്ചുകളായി മായ്ക്കുക, അങ്ങനെ കാഷിംഗ് പ്രവർത്തിക്കുന്നു

മോഡൽ പ്രൊവൈഡർമാർക്ക് ഒരു അഭ്യർത്ഥനയുടെ തുടക്കം, മുമ്പത്തേതുമായി സമാനമാണെങ്കിൽ, വീണ്ടും ഉപയോഗിക്കാം: ഇതിനെ prefix cache എന്ന് വിളിക്കുന്നു. ഓരോ കോളിലും ഒരു ഫലം കൂടി മായ്ച്ചാൽ, അഭ്യർത്ഥനയുടെ തുടക്കം ഓരോ കോളിലും മാറും, കാഷെ ഒരിക്കലും സഹായിക്കില്ല.

അതിനാൽ ഏറ്റവും പഴയ ഫലങ്ങൾ ഒന്നല്ല, നാലെണ്ണം ഒരുമിച്ചാണ് മായ്ക്കുന്നത്. മായ്ച്ച ഭാഗം പിന്നീട് നിരവധി കോളുകളിലുടനീളം അതേപടി തുടരുന്നു. കുറിപ്പിനേക്കാൾ വലുതല്ലാത്ത ഫലം തൊടാതെ വിടുന്നു: അത് മായ്ച്ചാൽ ലാഭം കുറവായിരിക്കും, എന്നാൽ അഭ്യർത്ഥനയുടെ തുടക്കം മാറും. എത്ര ഭാഗം മുഴുവനായി നിലനിൽക്കുന്നു എന്നത് എണ്ണം കൊണ്ടല്ല, വലുപ്പം കൊണ്ടാണ് തീരുമാനിക്കുന്നത്: ബജറ്റിന്റെ കാൽഭാഗത്തിൽ ഒതുങ്ങുന്ന ഏറ്റവും പുതിയ ഫലങ്ങൾ നിലനിൽക്കുന്നു, എപ്പോഴും കുറഞ്ഞത് ഒന്നെങ്കിലും. മുമ്പ് ഞങ്ങൾ സ്ഥിരമായി ആറ് മുഴുവനായി നിലനിർത്തിയിരുന്നു; അത് ചെറിയ കമാൻഡ് ഔട്ട്പുട്ടിന് ശരിയായിരുന്നു, പക്ഷേ നീണ്ട ഫയൽ വായനകളോടെ ബജറ്റിന്റെ മിക്കതും പഴയ ഫലങ്ങൾക്ക് വിട്ടുകൊടുത്തു.

പരിധി മോഡൽ നിരസിച്ചാൽ അത് പറയുന്നു

മോഡൽ അസാധുവെന്ന് നിരസിക്കുന്ന ഒരു അഭ്യർത്ഥന ഇനി വീണ്ടും ശ്രമിക്കില്ല; അതേ അഭ്യർത്ഥന വീണ്ടും അയച്ചാൽ അതേ ഉത്തരമേ കിട്ടൂ. സംഭാഷണം മോഡലിന് വളരെ നീണ്ടതാണെങ്കിൽ, ആളുകൾ കാണുന്നത്: "ഈ സംഭാഷണം ഒറ്റയടിക്ക് വായിക്കാൻ മോഡലിന് വളരെ നീണ്ടുപോയി. അടുത്ത ഘട്ടത്തിന് ഒരു പുതിയ ചാറ്റ് തുടങ്ങുക — ഇതുവരെ നിർമ്മിച്ചതെല്ലാം നിലനിൽക്കും." ഇത് ആളുകൾ നടപടിയെടുക്കേണ്ട കാര്യമാണ്, ഒരു outage അല്ല, അതിനാൽ ഞങ്ങളെ വിളിച്ചുണർത്തുന്നില്ല.

പ്രശ്നം 2: "മുറി ലാഭിക്കാൻ" ഏജന്റ് നിർത്തി

40 നീണ്ട അധ്യായങ്ങൾ വായിക്കാൻ ആവശ്യപ്പെട്ട ഒരു സബ്-ഏജന്റ് 2 എണ്ണം വായിച്ച ശേഷം മുറി ലാഭിക്കാൻ നിർത്തി. 400,000 ടോക്കൺ ബജറ്റിൽ അത് ഏകദേശം 100,000 ടോക്കൺ ഉപയോഗിച്ചിരുന്നു.

പഴയ ഫലങ്ങൾ അതിനായി മായ്ക്കപ്പെടുമെന്ന് അതിന് അറിയില്ലായിരുന്നു. അതിനാൽ ഞങ്ങൾ അത് പറഞ്ഞു. സംഭാഷണം മോഡലിന് സ്വീകരിക്കാവുന്നതിനേക്കാൾ വളരുമ്പോൾ പഴയ ടൂൾ ഫലങ്ങൾ മായ്ക്കപ്പെടുകയും ഏറ്റവും പുതിയവ പൂർണ്ണമായി നിൽക്കുകയും ചെയ്യുമെന്ന് ഇപ്പോൾ ഏജന്റിന്റെ നിർദ്ദേശങ്ങൾ പറയുന്നു. അതിനാൽ മുറി ലാഭിക്കാൻ നീണ്ട ജോലി നിർത്തരുത്; തുടരുക, മായ്ച്ചത് ആവശ്യമെങ്കിൽ ഫയൽ വീണ്ടും വായിക്കുക.

മോഡലിന് കാണാൻ കഴിയാത്ത ഒരു പരിഹാരം മോഡലിന്റെ കാഴ്ചപ്പാടിൽ പരിഹാരമല്ല. സംവിധാനം ഏജന്റ് അതിൽ വിശ്വസിച്ചാൽ മാത്രമേ സഹായിക്കൂ.

പ്രശ്നം 3: എല്ലാം ഇംഗ്ലീഷ് പോലെ ടോക്കണുകൾ എണ്ണുന്നു

ടോക്കണിംഗ് ടൂൾ പ്രവർത്തിപ്പിക്കാതെ, അക്ഷരങ്ങളെ നാല് കൊണ്ട് ഹരിച്ചാണ് ഞങ്ങൾ ടോക്കണുകൾ കണക്കാക്കിയിരുന്നത്. ഇംഗ്ലീഷിന് ഇത് ന്യായമായ ഒരു നിയമമാണ്. മറ്റ് ലിപികൾക്ക് അങ്ങനെയല്ല: റഷ്യൻ ഏകദേശം 2.2 അക്ഷരം ഒരു ടോക്കണിന്, ചൈനീസ് അല്ലെങ്കിൽ ജാപ്പനീസ് ഏകദേശം ഒന്ന്.

അതിനാൽ റഷ്യൻ അധ്യായങ്ങൾ വായിക്കുന്ന ഒരു സബ്-ഏജന്റ് ഏകദേശം 640,000 ടോക്കണുള്ള ഒരു അഭ്യർത്ഥന അയച്ചു, അതേസമയം ഞങ്ങളുടെ കണക്ക് 400,000 ബജറ്റിന് താഴെയാണെന്ന് പറഞ്ഞു. ആ കണക്ക് മോഡലിന്റെ കഠിന പരിധിക്ക് മുകളിൽ ഒരു അഭ്യർത്ഥനയെ തള്ളിവിടാനും സാധ്യതയുണ്ടായിരുന്നു.

ഇപ്പോൾ കണക്ക് ലിപി അനുസരിച്ച് എണ്ണുന്നു: സാധാരണ ASCII നാല് അക്ഷരം ഒരു ടോക്കണിന്, ചൈനീസ്, ജാപ്പനീസ്, കൊറിയൻ ഒന്ന് വീതം, മറ്റെല്ലാം — സിറിലിക്, ഗ്രീക്ക്, അറബിക്, ഉച്ചാരണ അക്ഷരങ്ങൾ, ഇമോജി — രണ്ട് വീതം. ഉയർന്ന ഭാഗത്ത് തെറ്റാനാണ് ഉദ്ദേശ്യം. ഒരു റഷ്യൻ അധ്യായത്തിൽ ഇപ്പോൾ 43,423 ടോക്കൺ എന്ന് കണക്കാക്കുന്നു, അളന്നപ്പോൾ ഏകദേശം 44,600; മുമ്പ് അത് 25,023 എന്നായിരുന്നു. ഒരു സന്ദേശം എഴുതിക്കഴിഞ്ഞാൽ അത് ഒരിക്കലും മാറാത്തതിനാൽ, അതിന്റെ കണക്ക് ഒരിക്കൽ കണക്കാക്കി ഓർത്തുവെക്കുന്നു, ഓരോ ഘട്ടത്തിലും വീണ്ടും കണക്കാക്കുന്നില്ല.

ഞങ്ങൾ പഠിച്ചത്

• വലുപ്പം യഥാർത്ഥത്തിൽ ഉള്ളിടത്ത് വെട്ടിച്ചുരുക്കുക. ഏജന്റ് ജോലിയിൽ അത് ടൂൾ ഫലങ്ങളാണ്, ഉപയോക്തൃ സന്ദേശങ്ങളല്ല.
• ഏജന്റിനോട് അതിന്റെ സുരക്ഷാ വലകളെക്കുറിച്ച് പറയുക. അല്ലെങ്കിൽ ഇനി ബാധകമല്ലാത്ത പരിധികൾ മുൻകൂട്ടി കണ്ട് അത് ആസൂത്രണം ചെയ്യും.
• "അക്ഷരങ്ങൾ ÷ 4" ഒരു ഇംഗ്ലീഷ് അനുമാനമാണ്. ബഹുഭാഷാ ഉപയോക്താക്കൾക്ക് ടോക്കണുകൾ എണ്ണുന്ന എന്തും ലിപി അനുസരിച്ച് എണ്ണണം, അല്ലെങ്കിൽ യഥാർത്ഥ ടോക്കണൈസർ ഉപയോഗിക്കണം.
• കാഷെയെക്കുറിച്ച് ശ്രദ്ധിക്കുക. ഓരോ കോളിലും തുടക്കം മാറുന്ന അഭ്യർത്ഥന കൂടുതൽ ചെലവാകുകയും സാവധാനം പ്രവർത്തിക്കുകയും ചെയ്യുന്നു.

നിങ്ങൾ AI ഫീച്ചറുകൾ സ്വന്തം ആപ്പിൽ ചേർക്കുകയാണെങ്കിൽ, LLM എന്താണ്, LLM API-കൾ എങ്ങനെ ഉപയോഗിക്കാം എന്നീ ഗൈഡുകൾ കോൺടെക്സ്റ്റ് വിൻഡോകളും ടോക്കണുകളും ആദ്യം മുതൽ വിശദീകരിക്കുന്നു. Mythex-ൽ സബ്-ഏജന്റുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ച് കൂടുതൽ സബ്-ഏജന്റ് ഡോക്സിൽ ഉണ്ട്.