𝗕𝗼𝘂𝗻𝗱𝗲𝗱 𝗥𝗲𝘁𝗿𝗶𝗲𝘀 𝗙𝗼𝗿 𝗔𝗴𝗲𝗻𝘁 𝗧𝗼𝗼𝗹 𝗖𝗮𝗹𝗹𝘀

ഞങ്ങളുടെ ഏജന്റ് ഉണ്ടാക്കിയ ഏറ്റവും മോശമായ സംഭവം ഒരു തെറ്റായ ഉത്തരമായിരുന്നില്ല. അതൊരു ലൂപ്പ് (loop) ആയിരുന്നു.

ഒരു ടൂൾ കോൾ പരാജയപ്പെട്ടു. ഏജന്റ് അത് വീണ്ടും ശ്രമിച്ചു (retry). ആ ശ്രമവും പരാജയപ്പെട്ടു. ഏജന്റ് അത് തുടർന്നുകൊണ്ടേയിരുന്നു. ഇത് ടോക്കണുകൾ പാഴാക്കുകയും ഒരു മിനിറ്റിനുള്ളിൽ ഞങ്ങളുടെ API നൂറുകണക്കിന് തവണ ഉപയോഗിക്കുകയും ചെയ്തു.

ഞങ്ങൾ പറഞ്ഞതനുസരിച്ചാണ് ഏജന്റ് പ്രവർത്തിച്ചത്. ഒരു ടൂൾ പരാജയപ്പെട്ടാൽ വീണ്ടും ശ്രമിക്കാൻ ഞങ്ങൾ അതിനോട് പറഞ്ഞു. എന്നാൽ എപ്പോൾ നിർത്തണം എന്ന് പറയാൻ ഞങ്ങൾ മറന്നുപോയി.

താൽക്കാലിക പിശകുകൾക്ക് (temporary errors) റീട്രൈകൾ നല്ലതാണ്. എന്നാൽ ഏജന്റുകൾക്ക് ഒരു താൽക്കാലിക പിശകിനെ സ്ഥിരമായ പിശകിൽ നിന്ന് തിരിച്ചറിയാൻ കഴിയില്ല എന്നതാണ് പ്രശ്നം. പരിധികളില്ലെങ്കിൽ, എന്തെങ്കിലും തടയുന്നത് വരെ ഒരു പരാജയപ്പെട്ട കോൾ ഏജന്റ് വീണ്ടും വീണ്ടും ശ്രമിച്ചുകൊണ്ടേയിരിക്കും.

പരമ്പരാഗത കോഡുകളിൽ റീട്രൈ പരിധികൾ (retry limits) ഉപയോഗിക്കാറുണ്ട്. എന്നാൽ ഏജന്റ് ടൂൾ കോളുകളിൽ ഈ തീരുമാനം മോഡലിന്റെ റീസണിംഗിലേക്ക് (reasoning) മാറി. ഇത് ലൂപ്പിനെ അദൃശ്യവും പരിധിയില്ലാത്തതുമാക്കി മാറ്റി.

മോഡലിന് പുറത്ത് രണ്ട് ബജറ്റുകൾ (budgets) ചേർത്ത് ഞങ്ങൾ ഇത് പരിഹരിച്ചു:

• Per-call cap: ഒരു പ്രത്യേക ടൂളിന് നിശ്ചിത എണ്ണം ശ്രമങ്ങൾ മാത്രമേ അനുവദിക്കൂ. അത് പരാജയപ്പെട്ടാൽ, ഏജന്റ് മറ്റൊരു വഴി പരീക്ഷിക്കണം. • Per-session budget: മൊത്തം ടൂൾ കോളുകൾക്ക് ഒരു പരിധിയുണ്ട്. ഏജന്റ് ഈ പരിധിയിൽ എത്തിയാൽ, അത് പ്രവർത്തനം നിർത്തി സഹായം തേടും.

പരിധി നിശ്ചയിക്കുന്നത് കൊണ്ട് മാത്രം പ്രശ്നം പരിഹരിക്കപ്പെടില്ല. ആ പരിധി കഴിഞ്ഞാൽ എന്ത് സംഭവിക്കുന്നു എന്നതാണ് പ്രധാനം.

നിങ്ങൾ വെറുതെ പ്രവർത്തനം നിർത്തിയാൽ, ഏജന്റ് കുടുങ്ങിപ്പോകും. അതിനുപകരം, ഞങ്ങൾ ഏജന്റിന് വ്യക്തമായ ഒരു സന്ദേശം നൽകുന്നു. കോൾ പരാജയപ്പെട്ടുവെന്നും ഇനി അത് വീണ്ടും ശ്രമിക്കരുതെന്നും ഞങ്ങൾ അതിനോട് പറയുന്നു. ഇത് ഒരു ലൂപ്പിനെ ഒരു തീരുമാനമാക്കി മാറ്റുന്നു. സാധാരണയായി, ഏജന്റ് പിന്നീട് ഒരു പുതിയ രീതി തിരഞ്ഞെടുക്കും.

ഇത് നടപ്പിലാക്കിയതിന് ശേഷം, ടൂൾ ദുരുപയോഗം മൂലമുള്ള ലൂപ്പുകൾ ഏതാണ്ട് ഇല്ലാതായി. അവ സംഭവിക്കുമ്പോൾ പോലും, വലിയ API ബില്ലുകൾ ഉണ്ടാക്കുന്നതിന് പകരം അവ കൃത്യമായ രീതിയിൽ അവസാനിക്കുന്നു.

ശരിയായ പരിധി കണ്ടെത്തുക എന്നത് പ്രയാസകരമാണ്. വളരെ കുറഞ്ഞ പരിധി ദൈർഘ്യമേറിയ ജോലികളെ തടസ്സപ്പെടുത്തും. കൂടുതൽ പരിധി നൽകിയാൽ ചിലവേറിയ ലൂപ്പുകൾ ഉണ്ടാകാൻ സാധ്യതയുണ്ട്. ഞങ്ങൾ ഞങ്ങളുടെ പരിധികൾ 95th percentile ടാസ്ക് ദൈർഘ്യത്തിന്റെ അടിസ്ഥാനത്തിലാണ് നിശ്ചയിക്കുന്നത്.

ഈ ബജറ്റുകൾ നിശ്ചയിക്കാൻ നിങ്ങൾക്ക് ഇതിലും നല്ലൊരു മാർഗ്ഗമുണ്ടോ? കമന്റുകളിൽ അറിയിക്കുക.

Source: https://dev.to/james_oconnor_dev/bounded-retries-for-agent-tool-calls-the-budget-that-stopped-our-infinite-loop-incidents-4354

Optional learning community: https://t.me/GyaanSetuAi