Most engineering teams still evaluate AI agents the same way they grade math homework. They look at the final output. If

മിക്ക എഞ്ചിനീയറിംഗ് ടീമുകളും ഇപ്പോഴും AI ഏജന്റുകളെ വിലയിരുത്തുന്നത് ഗണിതശാസ്ത്ര ഹോംവർക്ക് പരിശോധിക്കുന്നതുപോലെയാണ്. അവർ അവസാന ഫലത്തെ (final output) മാത്രമാണ് നോക്കുന്നത്. ഉത്തരം ശരിയാണെങ്കിൽ, അവർ അത് റിലീസ് ചെയ്യാൻ അനുമതി നൽകുകയും മുന്നോട്ട് പോവുകയും ചെയ്യുന്നു. ഇതൊരു അപകടകരമായ രീതിയാണ്. ഒരു ശരിയായ ഉത്തരം ഒരു തകരാറിലായ സിസ്റ്റത്തെ മറച്ചുവെച്ചേക്കാം.

യഥാർത്ഥ കഥ നിലനിൽക്കുന്നത് ഏജന്റ് ആ ഉത്തരത്തിൽ എത്തുന്നതിനായി സ്വീകരിച്ച പാതയിലാണ്. ആ പാതയെ 'ഏജന്റ് ട്രാജക്റ്ററി' (agent trajectory) എന്ന് വിളിക്കുന്നു. ഇതിൽ ഓരോ ടൂൾ കോൾ (tool call), ഓരോ റൂട്ടിംഗ് തീരുമാനം (routing decision), ഏജന്റ് വീണ്ടും ചിന്തിക്കാൻ വേണ്ടി നിൽക്കുന്ന ഓരോ ഇടവേളകളും ഉൾപ്പെടുന്നു. ഇതിനെ ഏജന്റിന്റെ പാതയിലെ അടയാളങ്ങൾ (trail of breadcrumbs) എന്ന് നിങ്ങൾക്ക് കരുതാം. നിങ്ങൾ ലക്ഷ്യസ്ഥാനം മാത്രം പരിശോധിക്കുകയാണെങ്കിൽ, വഴിയിലുടനീളം ചിതറിക്കിടക്കുന്ന മുന്നറിയിപ്പ് സൂചനകൾ നിങ്ങൾക്ക് നഷ്ടമാകും.

കുഴഞ്ഞുമറിഞ്ഞ പാതകളിലെ പ്രശ്നങ്ങൾ

ഒരു മദ്യപിച്ച ഡ്രൈവറെപ്പോലെ പെരുമാറിക്കൊണ്ട് തന്നെ ഒരു ഏജന്റിന് ശരിയായ ഉത്തരത്തിൽ എത്തിച്ചേരാൻ സാധിച്ചേക്കാം. അത് തെറ്റായ ടൂളുകളിലൂടെ വളഞ്ഞുപുളഞ്ഞു പോകുന്നു, റൂട്ടറിലേക്ക് തിരിച്ചു വരുന്നു, ഒടുവിൽ ശരിയായ ഒന്നിലേക്ക് തട്ടി വീഴുന്നതിന് മുമ്പ് അനാവശ്യമായ ചിന്താ പ്രക്രിയകളിലൂടെ (redundant reasoning) കടന്നുപോകുന്നു. ഉപയോക്താവ് കാണുന്നത് വൃത്തിയുള്ള ഒരു ഫലമാണ്. എന്നാൽ ഇതിന് പിന്നിൽ, സിസ്റ്റം വിഭവങ്ങൾ (resources) പാഴാക്കുകയും അപകടസാധ്യതകൾ വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നു.

പ്രായോഗികമായി ഈ കുഴപ്പങ്ങൾ എങ്ങനെയിരിക്കും?

ഒന്നാമതായി, അനാവശ്യമായ ടൂൾ കോളുകൾ (redundant tool call). ഏജന്റ് നിങ്ങളുടെ കസ്റ്റമർ ഡാറ്റാബേസ് ക്വറി ചെയ്യുന്നു, ഫലം ലഭിക്കുന്നു, അഞ്ച് സെക്കൻഡിനുള്ളിൽ അത് മറന്നുപോകുന്നു, തുടർന്ന് അതേ പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് അതേ റെക്കോർഡ് തന്നെ വീണ്ടും ക്വറി ചെയ്യുന്നു. ഇതൊരു ഡാറ്റാ പ്രശ്നമല്ല, മറിച്ച് ഒരു ട്രാജക്റ്ററി പ്രശ്നമാണ്. ഏജന്റിന് സ്റ്റേറ്റ് (state) നിലനിർത്താൻ കഴിഞ്ഞില്ല, അതിനാൽ അത് ജോലി ആവർത്തിക്കുന്നു.

രണ്ടാമതായി, തെറ്റായ ടൂൾ ആദ്യം ഉപയോഗിക്കുന്ന രീതി (wrong-tool-first pattern). ലോക്കൽ റെപ്പോസിറ്ററിയിൽ (local repository) നിലവിലുള്ള ഒരു ഫംഗ്ഷൻ ഡെഫനിഷനായി ഒരു കോഡിംഗ് ഏജന്റ് വെബ് സെർച്ച് ചെയ്യാൻ ശ്രമിച്ചേക്കാം. അല്ലെങ്കിൽ, ഉപയോക്താവിന്റെ ചോദ്യത്തിന് അക്കൗണ്ട് സെറ്റിംഗ്സ് ടൂൾ ആവശ്യമാണെന്ന് വ്യക്തമായിരിക്കുമ്പോഴും ഒരു സപ്പോർട്ട് ഏജന്റ് ബില്ലിംഗ് API ഉപയോഗിച്ചേക്കാം. ഓരോ തെറ്റായ തിരഞ്ഞെടുപ്പും ടോക്കണുകൾ (tokens) പാഴാക്കുന്നു, ലേറ്റൻസി (latency) വർദ്ധിപ്പിക്കുന്നു, കൂടാതെ യഥാർത്ഥ ജോലി തുടങ്ങുന്നതിന് മുമ്പ് തന്നെ കോൺടെക്സ്റ്റ് ലിമിറ്റുകൾ (context limits) അവസാനിക്കാനുള്ള സാധ്യത വർദ്ധിപ്പിക്കുന്നു.

റൂട്ടർ ലൂപ്പുകൾ (Router loops) മറ്റൊരു ചുവന്ന അടയാളമാണ് (red flag). ഡിസിഷൻ നോഡിന് (decision node) ഒരു തീരുമാനത്തിൽ ഉറച്ചുനിൽക്കാൻ കഴിയുന്നില്ല. അത് ടാസ്ക് ബ്രാഞ്ച് A-ലേക്ക് അയക്കുന്നു, പിന്നീട് തീരുമാനം മാറ്റുന്നു, അത് തിരികെ എടുക്കുന്നു, ബ്രാഞ്ച് B-ലേക്ക് അയക്കുന്നു, എന്നിട്ട് യാതൊരു കാരണവുമില്ലാതെ ഒരു ജനറൽ പർപ്പസ് ഫോളബാക്ക് നോഡിലൂടെ (general-purpose fallback node) റൂട്ട് ചെയ്യുന്നു. ഓരോ ലൂപ്പും ഒരു നെറ്റ്‌വർക്ക് ഹോപ്പും (network hop) ഡീബഗ് ലോഗിൽ കൂടുതൽ ആശയക്കുഴപ്പവും ഉണ്ടാക്കുന്നു.

അവസാനമായി, ആവർത്തിച്ചുള്ള വിശകലനം (repeated analysis). ഏജന്റ് ഓരോ ഘട്ടത്തിലും ഒരു കാര്യം സ്ഥിരീകരിച്ചതായി കണക്കാക്കുന്നതിന് പകരം, ഒരേ നിഗമനത്തിൽ തന്നെ വീണ്ടും എത്തിച്ചേരാൻ ശ്രമിക്കുന്നു. ഇത് ഓരോ മുറി sebelum മുറിക്കുന്നതിന് മുമ്പ് പത്ത് തവണ മരപ്പലക അളക്കുന്ന ഒരു ആശാരിയെപ്പോലെയാണ്. ആദ്യത്തെ അളവ് ശരിയായിരുന്നു, അടുത്ത ഒൻപതും വെറുതെ പാഴായ പ്രയത്നമാണ്.

ഈ അധിക ഘട്ടങ്ങൾ യഥാർത്ഥ പ്രത്യാഘാതങ്ങൾ ഉണ്ടാക്കുന്നു. ലേറ്റൻസി (latency) വർദ്ധിക്കുന്നു. ഒരു സിൻക്രണസ് ചാറ്റ് ഇന്റർഫേസിൽ (synchronous chat interface), അധികമായ മൂന്ന് സെക്കൻഡ് എന്നത് ഒരു യുഗമായി തോന്നും. വലിയ തോതിലുള്ള ഉപയോഗത്തിൽ (at scale), ആ സെക്കൻഡുകൾ ആയിരക്കണക്കിന് ഡോളർ കമ്പ്യൂട്ട് ചിലവായി മാറുന്നു. പരാജയസാധ്യതയും വർദ്ധിക്കുന്നു. ഓരോ അനാവശ്യമായ നീക്കവും ഒരു എക്സ്റ്റേണൽ API ടൈം ഔട്ട് ആകാനോ, കോൺടെക്സ്റ്റ് വിൻഡോ ഓവർഫ്ലോ ആകാനോ, അല്ലെങ്കിൽ ഒരു റേസ് കണ്ടീഷൻ (race condition) ഉണ്ടാകാനോ ഉള്ള സാധ്യത വർദ്ധിപ്പിക്കുന്നു. എന്തെങ്കിലും തകരാർ സംഭവിച്ചാൽ, സ്പാഗെറ്റി പോലെ കുഴഞ്ഞുമറിഞ്ഞ ഒരു ട്രാസ് (trace) ഡീബഗ് ചെയ്യുന്നത് വളരെ പ്രയാസകരമായിരിക്കും. ഏജന്റ് ഏഴാമത്തെ ഘട്ടം എടുത്തത് എന്തുകൊണ്ടാണെന്ന് കണ്ടെത്താൻ നിങ്ങൾ മണിക്കൂറുകൾ ചെലവഴിക്കും, ഒടുവിൽ ഏഴാമത്തെ ഘട്ടം ഒരിക്കലും ആവശ്യമില്ലായിരുന്നു എന്ന് തിരിച്ചറിയുകയും ചെയ്യും.

കൺവെർജൻസ് (Convergence) എന്നാൽ യഥാർത്ഥത്തിൽ എന്താണ്?

ട്രാജക്റ്ററി എന്നത് പാതയാണെങ്കിൽ, കൺവെർജൻസ് എന്നത് അതിന്റെ കാര്യക്ഷമതയുടെ അളവാണ്. ഉപയോക്താവിന്റെ അഭ്യർത്ഥനയും ശരിയായ പരിഹാരവും തമ്മിലുള്ള ഏറ്റവും കുറഞ്ഞ പാതയിലൂടെ ഏജന്റ് എത്രത്തോളം കൃത്യമായി സഞ്ചരിക്കുന്നു എന്ന് കൺവെർജൻസ് പറഞ്ഞുതരുന്നു.

ഇത് കൃത്യതയുമായി (accuracy) തുല്യമല്ല. കൃത്യത എന്നത് ഒരു ലളിതമായ അളവുകോലാണ്; അത് അവസാന ഫലം ശരിയാണോ എന്ന് മാത്രം ചോദിക്കുന്നു. എന്നാൽ കൺവെർജൻസ് ആ യാത്ര യുക്തിസഹമായിരുന്നോ എന്ന് ചോദിക്കുന്നു. ഉയർന്ന കൃത്യതയും എന്നാൽ കുറഞ്ഞ കൺവെർജൻസും ഉള്ള ഒരു ഏജന്റ് വിജയത്തിന്റെ വേഷം ധരിച്ച ഒരു ബാധ്യതയാണ്. ഉയർന്ന കൺവെർജൻസും ഇടത്തരം കൃത്യതയുമുള്ള ഒരു ഏജന്റിനെ പരിഹരിക്കാൻ എളുപ്പമാണ്, കാരണം അതിന്റെ യുക്തി (reasoning) വ്യക്തമാണ് കൂടാതെ അതിന്റെ തെറ്റുകൾ പരിമിതവുമാണ്.

ആ ടാസ്ക് ക്ലാസ്സിനായി നിങ്ങൾ നിർവചിച്ച ഏറ്റവും കുറഞ്ഞ പാതയുമായി ഏജന്റ് യഥാർത്ഥത്തിൽ സ്വീകരിച്ച ഘട്ടങ്ങൾ താരതമ്യം ചെയ്തുകൊണ്ട് നിങ്ങൾക്ക് ഏകദേശ കൺവെർജൻസ് സ്കോർ കണക്കാക്കാം. ഒരു സാധാരണ റീഫണ്ട് ക്വറിക്ക് കൃത്യം മൂന്ന് ടൂൾ കോളുകൾ ആവശ്യമാണെങ്കിൽ ഏജന്റ് ഒൻപത് ഉപയോഗിച്ചാൽ, നിങ്ങളുടെ കൺവെർജൻസ് അനുപാതം കുറയുന്നു. വിവിധ തരത്തിലുള്ള പാഴായ പ്രയത്നങ്ങൾക്ക് (waste) വ്യത്യസ്ത മൂല്യം നൽകിക്കൊണ്ട് നിങ്ങൾക്ക് ഇത് കൂടുതൽ മെച്ചപ്പെടുത്താം. ടൂളിന്റെ ലേറ്റൻസിയും വിലയും അനുസരിച്ച്, ഒരു തെറ്റായ ടൂൾ കോൾ ഒരു അനാവശ്യമായ കോളിനേക്കാൾ കൂടുതൽ ചിലവ് വരുത്തിയേക്കാം. യാതൊരു മൂല്യവും കൂട്ടാത്ത ഒരു റൂട്ടർ ലൂപ്പിന് ഏറ്റവും വലിയ പിഴവ് (penalty) നൽകേണ്ടി വന്നേക്കാം, കാരണം അത് ആർക്കിടെക്ചറൽ...