ഓരോ പ്രൊഡക്റ്റ് റോഡ്മാപ്പിലും "AI Agent" എന്നൊരു പോയിന്റ് ഉണ്ടാകും. ആ വാക്ക് പുരോഗതിയെ സൂചിപ്പിക്കുന്നു. നിങ്ങളുടെ ടീം വെറും നിലവിലുള്ള കാര്യങ്ങൾ പരിപാലിക്കുകയല്ല, മറിച്ച് ഭാവി നിർമ്മിക്കുകയാണ് എന്ന സന്ദേശമാണ് അത് നേതൃത്വത്തിന് നൽകുന്നത്. എന്നാൽ മിക്ക ഡെമോ വീഡിയോകളും കാണിക്കാത്ത അസ്വസ്ഥതയുണ്ടാക്കുന്ന ഒരു സത്യമുണ്ട്: ഒരു ജോലി പൂർത്തിയാക്കാൻ ഏറ്റവും ചിലവേറിയതും പ്രവചനാതീതവുമായ മാർഗമാണ് ഒരു ഏജന്റ്. ഭൂരിഭാഗം ബിസിനസ്സ് ജോലികൾക്കും ഇത് തികച്ചും തെറ്റായ ഉപകരണമാണ്. ഒരു ഏജന്റ് നിർമ്മിക്കാൻ ധൃതി കാണിക്കുന്നവരല്ല മികച്ച എഞ്ചിനീയർമാർ. എപ്പോൾ നിർത്തണമെന്ന് അറിയുന്നവരാണ് അവർ.
The Classification Trap
ഒരു ടീം അവരുടെ ആദ്യത്തെ ഏജന്റ് എങ്ങനെ രൂപകൽപ്പന ചെയ്യുന്നു എന്ന് ശ്രദ്ധിച്ചാൽ സാധാരണയായി ഇങ്ങനെയൊന്ന് കാണാം. ഒരു സപ്പോർട്ട് ഇമെയിൽ വരുന്നു. ഒരു ലാർജ് ലാംഗ്വേജ് മോഡൽ അതിന്റെ വിഷയം (subject) വായിക്കുന്നു, അത് ബില്ലിംഗ് സംബന്ധമായ ചോദ്യമാണോ അതോ സാങ്കേതിക തകരാറാണോ എന്ന് തീരുമാനിക്കുന്നു, എന്നിട്ട് അത് ശരിയായ ക്യൂവിലേക്ക് (queue) മാറ്റുന്നു. ടീം ഇതിനെ ഒരു ഏജന്റ് എന്ന് വിളിക്കുന്നു. പക്ഷേ അതല്ല.
അവർ നിർമ്മിച്ചിരിക്കുന്നത് ഒരു മോഡൽ കോൾ ഉൾപ്പെടുത്തിയുള്ള ഒരു ഡിറ്റർമിനിസ്റ്റിക് ഫ്ലോ (deterministic flow) മാത്രമാണ്. ഘട്ടങ്ങൾ നിശ്ചിതമാണ്: ഇമെയിൽ സ്വീകരിക്കുക, മോഡലിനെ വിളിക്കുക, ക്യൂവിലേക്ക് മാറ്റുക. ഇതിൽ ഒരു ലൂപ്പും ഇല്ല, ടൂൾ ഉപയോഗമില്ല, ആദ്യ ശ്രമം പരാജയപ്പെട്ടാൽ പ്ലാൻ പുനർചിന്തനം ചെയ്യാൻ സിസ്റ്റം നിൽക്കുന്ന നിമിഷവുമില്ല. ഇത് ഒരു നോളജ് ബേസ് (knowledge base) പരിശോധിക്കുകയോ, കോഡ് എഴുതുകയോ, അല്ലെങ്കിൽ ഇടയ്ക്ക് ഓർഡർ സ്റ്റാറ്റസ് പരിശോധിക്കുകയോ ചെയ്യുന്നില്ല. ഇത് ഒരു വിധി കൽപ്പിക്കുന്നു, എന്നിട്ട് മുന്നോട്ട് പോകുന്നു. ആ ഒറ്റ കോളിനെ ഒരു മൈക്രോസർവീസിൽ (microservice) പൊതിഞ്ഞതുകൊണ്ട് അത് ഒരു ഏജന്റ് ആയി മാറുന്നില്ല.
ഒരു ഫ്ലോയെ ഏജന്റ് എന്ന് തെറ്റിദ്ധരിക്കുന്നതിന്റെ യഥാർത്ഥ വില വെറും അധിക ഇൻഫ്രാസ്ട്രക്ചർ മാത്രമല്ല. അത് യാതൊരു നേട്ടവുമില്ലാതെ നിങ്ങൾ വരുത്തിവെക്കുന്ന നോൺ-ഡിറ്റർമിനിസം (non-determinism) ആണ്. ടെമ്പറേച്ചർ (temperature) സീറോയല്ലാത്തതുകൊണ്ടോ പ്രോംപ്റ്റ് മാറുന്നതുകൊണ്ടോ ചൊവ്വാഴ്ച രാവിലെ ലഭിച്ച അതേ ഇമെയിൽ ബുധനാഴ്ച ഉച്ചയ്ക്ക് വ്യത്യസ്തമായി റൂട്ട് ചെയ്യപ്പെട്ടേക്കാം. ഒരു ക്ലാസിഫിക്കേഷൻ സ്റ്റെപ്പുള്ള ഫ്ലോ ഇതിനേക്കാൾ വേഗത്തിലും ലാഭകരമായും പ്രശ്നം പരിഹരിക്കുമ്പോൾ, നിങ്ങൾ ലേറ്റൻസി (latency), ടോക്കൺ ചിലവ്, ഇവാലുവേഷൻ ഓവർഹെഡ് (evaluation overhead) എന്നിവയ്ക്കായി ഏജന്റ് നിരക്ക് നൽകേണ്ടി വരുന്നു.
Work Down the Ladder
മിക്ക പ്രശ്നങ്ങൾക്കും അവയെ ഒരേപോലെ പരിഹരിക്കാൻ കഴിയുന്ന ലളിതമായ മാർഗങ്ങളുണ്ട്. ഇതിനെ ഒരു ഗോവണി പോലെ കരുതുക, താഴെ നിന്ന് തുടങ്ങുക.
Fix the process. ചിലപ്പോൾ രണ്ട് സിസ്റ്റങ്ങൾ തമ്മിലുള്ള വ്യത്യാസം കാരണം മാത്രമാണ് ഒരു ജോലി ഉണ്ടാകുന്നത്. നിങ്ങളുടെ CRM-ലെ ഒരു കസ്റ്റമർ റെക്കോർഡ് ടിക്കറ്റിംഗ് പ്ലാറ്റ്ഫോമുമായി സിങ്ക് ആകുന്നില്ല, അതിനാൽ എല്ലാ ദിവസവും രാവിലെ ഒരു മനുഷ്യൻ അത് മാനുവലായി ശരിയാക്കേണ്ടി വരുന്നു. ആ വിടവ് നികത്താൻ ഒരു ഏജന്റിനെ ഉപയോഗിച്ച് ഓട്ടോമേറ്റ് ചെയ്യരുത്. അത് ഇല്ലാതാക്കുക. ഡാറ്റാ പൈപ്പ്ലൈൻ ശരിയായിരുന്നുവെങ്കിൽ ആ ജോലി തന്നെ ഇല്ലാതാകുമായിരുന്നു.
Use a query. ഉത്തരം ഒരു ലളിതമായ ലുക്കപ്പ് (lookup) അല്ലെങ്കിൽ അഗ്രഗേഷൻ (aggregation) ആണെങ്കിൽ, അതിനെ അങ്ങനെ തന്നെ കൈകാര്യം ചെയ്യുക. "കഴിഞ്ഞ ചൊവ്വാഴ്ച നമ്മൾ എത്ര റീഫണ്ടുകൾ പ്രോസസ്സ് ചെയ്തു?" എന്നതിന് യുക്തിപരമായ ചിന്ത (reasoning) ആവശ്യമില്ല. അതിന് SQL ആണ് വേണ്ടത്. നാച്ചുറൽ ലാംഗ്വേജിനെ SQL ആയി മാറ്റുന്ന ഒരു ഏജന്റ് കേൾക്കാൻ നല്ലതാണ്, എന്നാൽ നിങ്ങളുടെ ടീം ഡാഷ്ബോർഡിൽ നിന്ന് റൺ ചെയ്യുന്ന മൂന്ന് ക്വറികൾ എഴുതുന്നതിനേക്കാൾ വലിയ മെയിന്റനൻസ് ഭാരം അത് ഉണ്ടാക്കുമെന്ന് നിങ്ങൾ തിരിച്ചറിയുന്നതുവരെ മാത്രം.
Build a deterministic flow. നിയമങ്ങൾ നിശ്ചിതവും ഫലം ആവർത്തിക്കാവുന്നതുമാണെങ്കിൽ, വ്യക്തമായ ലോജിക് ഉപയോഗിക്കുക. ഒരു ഓർഡർ മൂല്യം നിശ്ചിത പരിധിയിൽ കൂടുതലാണെങ്കിൽ, അത് ഫിനാൻസ് വിഭാഗത്തിന് കൈമാറുക. ഒരു ഉപയോക്താവ് മുപ്പത് ദിവസം സജീവമല്ലെങ്കിൽ, ഒരു റീ-എൻഗേജ്മെന്റ് ഇമെയിൽ അയക്കുക. കോഡ് ഇത് വ്യതിയാനമില്ലാതെയും പൂർണ്ണമായ ഒബ്സർവബിലിറ്റിയോടും (observability) കൂടി കൈകാര്യം ചെയ്യുന്നു. നിങ്ങൾക്ക് ഇത് യൂണിറ്റ് ടെസ്റ്റ് (unit-test) ചെയ്യാം. ഒരു 'വൈബ്' (vibe) നിങ്ങൾക്ക് യൂണിറ്റ് ടെസ്റ്റ് ചെയ്യാൻ കഴിയില്ല.
Use a flow with one model call. ക്ലാസിഫിക്കേഷൻ, സെന്റിമെന്റ് ടാഗിംഗ്, അല്ലെങ്കിൽ ഡാറ്റാ എക്സ്ട്രാക്ഷൻ എന്നിവ ഇവിടെയാണ് വരുന്നത്. ഒരു കർശനമായ സ്ക്രിപ്റ്റിനുള്ളിൽ മോഡൽ ഒരു ഒറ്റ വിധി കൽപ്പിക്കുന്നു. നിങ്ങൾ ഒരു ഡോക്യുമെന്റ് സ്വീകരിക്കുന്നു, ഇൻവോയ്സ് നമ്പർ വേർതിരിച്ചെടുക്കുന്നു, അത് ഒരു ഡാറ്റാബേസിലേക്ക് എഴുതുന്നു. ചുറ്റുമുള്ള ഘട്ടങ്ങൾ ഹാർഡ്കോഡ് ചെയ്തവയാണ്. അടുത്തതായി എന്ത് ചെയ്യണമെന്ന് മോഡൽ തീരുമാനിക്കുന്നില്ല; അത് കാണുന്നതിനെ ലേബൽ ചെയ്യുക മാത്രമാണ് ചെയ്യുന്നത്. ഇതൊരു ശക്തമായ പാറ്റേൺ ആണ്, പക്ഷേ ഇപ്പോഴും ഇതൊരു ഫ്ലോ തന്നെയാണ്.
Build an agent last. മോഡൽ പ്രവർത്തിക്കുന്നതിനിടയിൽ കണ്ടെത്തുന്ന കാര്യങ്ങളെ അടിസ്ഥാനമാക്കി അടുത്ത നടപടി നിർണ്ണയിക്കേണ്ടി വരുന്ന ജോലികൾക്കായി മാത്രം ഈ ഘട്ടം മാറ്റിവെക്കുക. സിസ്റ്റം ഒരു ഇമെയിൽ വായിക്കുകയും, ഒരു ലോജിസ്റ്റിക്സ് API-ൽ ഷിപ്പ്മെന്റ് പരിശോധിക്കേണ്ടതുണ്ടെന്ന് മനസ്സിലാക്കുകയും, ഷിപ്പ്മെന്റ് വൈകിയതായി കണ്ടെത്തുകയും, ആ പുതിയ വിവരത്തിന്റെ അടിസ്ഥാനത്തിൽ ഒരു മറുപടി തയ്യാറാക്കുകയും വേണമെങ്കിൽ, നിങ്ങൾ ഏജന്റ് ഉപയോഗിക്കേണ്ട മേഖലയിലാണ്. ഓരോ പുതിയ വസ്തുതയ്ക്ക് ശേഷവും എന്ത് ചെയ്യണമെന്ന് മോഡൽ തീരുമാനിക്കുന്നതിനാൽ, മുൻകൂട്ടി ഒരു പാത വരയ്ക്കാൻ കഴിയില്ല.
The Whiteboard Test
ഒരു മീറ്റിംഗിൽ ഈ തർക്കം വേഗത്തിൽ പരിഹരിക്കാൻ ഒരു വഴിയുണ്ട്. തീരുമാനത്തിന്റെ ശാഖകൾ (decision branches) ഒരു വൈറ്റ്ബോർഡിൽ വരയ്ക്കാൻ നിങ്ങളുടെ ടീമിനോട് ആവശ്യപ്പെടുക.
മോഡൽ പ്രവർത്തിക്കുന്നതിന് മുമ്പ് എല്ലാ പാതകളും നിങ്ങൾക്ക് മാപ്പ് ചെയ്യാൻ കഴിയുമെങ്കിൽ, ഒരു ഫ്ലോ നിർമ്മിക്കുക. ഡയമണ്ട് ഷേപ്പുകൾ വരയ്ക്കുക, if-statements എഴുതുക, അത് മതി. പ്രവചിക്കാവുന്നത് (Predictability) ഒരു ഫീച്ചറാണ്, പരിമിതിയല്ല.
അടുത്ത ഘട്ടം എന്താണെന്ന് മോഡൽ തന്നെ തീരുമാനിക്കേണ്ടി വരികയാണെങ്കിൽ, അത് ടൂൾ തിരഞ്ഞെടുക്കുകയും, പാരാമീറ്ററുകൾ നിശ്ചയിക്കുകയും, വീണ്ടും ചിന്തിക്കാൻ ലൂപ്പ് ചെയ്യുകയും ചെയ്യുന്നുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ഒരു ഏജന്റ് ആവശ്യമാണ്. ആ ഡൈനാമിക് റൂട്ടിംഗ് (dynamic routing) ആണ് അതിനുള്ള विभाജക രേഖ. ഒരു പുതിയ API ഉപയോഗിക്കണം എന്ന ആഗ്രഹം കൊണ്ട് മാത്രം അബദ്ധത്തിൽ അതിനെ മറികടക്കരുത്.
The Hidden Tax
ഡെമോകൾ ഏജന്റുകളെ വളരെ എളുപ്പമുള്ളതായി തോന്നിപ്പിക്കുന്നു. എന്നാൽ പ്രൊഡക്ഷനിൽ വേഗത്തിൽ വർദ്ധിച്ചുവരുന്ന നാല് നികുതികൾ വെളിപ്പെടുന്നു.
Non-determinism. ഒരേ