ഗൂഗിളിന്റെ AI ആർക്കിടെക്ചർ ഗൈഡും ആന്ത്രോപ്പിക്കിന്റെ (Anthropic) എഞ്ചിനീയറിംഗ് ബ്ലോഗും "ReAct" ലൂപ്പിനെ സ്വയംഭരണാധികാരമുള്ള ഏജന്റുകൾക്കായുള്ള (autonomous agents) ഒരു പാറ്റേൺ ആയി വിവരിക്കുന്നു. ഒരു മോഡലിന് നിയന്ത്രണം കൈമാറുന്നതിന് മുമ്പ് ഡെവലപ്പർമാർ ചിലവ് (cost), ലേറ്റൻസി (latency), പിശക് വരാനുള്ള സാധ്യത (error risk) എന്നിവ പരിഗണിക്കണമെന്ന് അവർ ചൂണ്ടിക്കാട്ടുന്നു. തെറ്റായ ഒരു ഏജന്റ് തിരഞ്ഞെടുക്കുന്നത് ക്ലൗഡ് ബജറ്റുകൾ പാഴാക്കാനും പ്രൊഡക്ഷൻ സിസ്റ്റങ്ങളിൽ പരിഹരിക്കാൻ പ്രയാസമുള്ള പിഴവുകൾ ഉണ്ടാക്കാനും കാരണമായേക്കാം എന്നതിനാൽ ഈ ഉപദേശം വളരെ പ്രധാനമാണ്.

ReAct ലൂപ്പ് പ്രായോഗികമായി എങ്ങനെ പ്രവർത്തിക്കുന്നു

ഈ ലൂപ്പിൽ മൂന്ന് ഘട്ടങ്ങളുണ്ട്:

  • Thought – മോഡൽ നിലവിലെ ടാസ്ക്കിനെക്കുറിച്ച് ചിന്തിക്കുകയും അടുത്ത ഘട്ടം തിരഞ്ഞെടുക്കുകയും ചെയ്യുന്നു.
  • Action – ഇത് ഒരു എക്സ്റ്റേണൽ ടൂൾ വിളിക്കുകയോ (ഉദാഹരണത്തിന്, ഒരു code-search API) അല്ലെങ്കിൽ ഒരു അന്തിമ ഉത്തരം നൽകുകയോ ചെയ്യുന്നു.
  • Observation – ഇത് ടൂളിന്റെ ഔട്ട്‌പുട്ട് വായിക്കുകയും ഫലം അതിന്റെ മെമ്മറിയിൽ സൂക്ഷിക്കുകയും അടുത്ത Thought-ലേക്ക് നൽകുകയും ചെയ്യുന്നു.

ആന്ത്രോപ്പിക് ഈ സംവിധാനത്തെ മുഴുവനായി ഒരു “autonomous agent” എന്ന് വിളിക്കുന്നു; ഗൂഗിൾ ഇതിന്റെ പ്രധാന ചക്രത്തെ “ReAct” എന്ന് വിളിക്കുന്നു. ഇവ തമ്മിലുള്ള വ്യത്യാസം ചെറുതാണെങ്കിലും നിർണ്ണായകമാണ്: ഒരു പരമ്പരാഗത വർക്ക്ഫ്ലോയിൽ ഡെവലപ്പറുടെ കോഡാണ് ക്രമം തീരുമാനിക്കുന്നത്, എന്നാൽ ഒരു ഏജന്റിൽ മോഡലാണ് അത് തീരുമാനിക്കുന്നത്.

എപ്പോഴാണ് മോഡലിനെ പ്രക്രിയ നിയന്ത്രിക്കാൻ അനുവദിക്കേണ്ടത്

കൃത്യമായ പരിധികളില്ലാത്ത (Open-ended) പ്രശ്നങ്ങളാണ് ReAct ശൈലിയിലുള്ള ഏജന്റുകൾക്ക് ഏറ്റവും അനുയോജ്യം. സാധ്യമായ എല്ലാ വഴികളും മുൻകൂട്ടി നിശ്ചയിക്കാൻ കഴിയില്ലെങ്കിൽ, ഒരു ഏജന്റിന് ഡൈനാമിക് ആയി അവ പര്യവേക്ഷണം ചെയ്യാൻ കഴിയും. സാധാരണ ഉപയോഗങ്ങൾ ഇവയാണ്:

  • ഒരു റിപ്പോസിറ്ററി സ്കാൻ ചെയ്യുകയും, പരാജയപ്പെടുന്ന ടെസ്റ്റ് കണ്ടെത്തുകയും, ബിൽഡ് വിജയിക്കുന്നത് വരെ ആവർത്തിച്ച് പാച്ചുകൾ (patches) പ്രയോഗിക്കുകയും ചെയ്യുന്ന Code-fix bots.
  • ഒരു വാഹനം അപ്രതീക്ഷിത തടസ്സങ്ങളോട് പ്രതികരിക്കുകയും പാതകൾ തൽക്ഷണം പുനർനിർമ്മിക്കുകയും ചെയ്യുന്ന Robotic navigation.

ഇത്തരം സാഹചര്യങ്ങളിൽ ആവർത്തനങ്ങളുടെ (iterations) എണ്ണം മുൻകൂട്ടി അറിയാൻ കഴിയില്ല, അതിനാൽ ഒരു പാത മുൻകൂട്ടി നിശ്ചയിക്കുന്നത് (hard-coding) ഫലപ്രദമാകില്ല.

എപ്പോഴാണ് ഒരു വർക്ക്ഫ്ലോ കൂടുതൽ മികച്ചതാകുന്നത്

ഘട്ടങ്ങൾ മുൻകൂട്ടി പ്രവചിക്കാവുന്നതാണെങ്കിൽ, പരമ്പരാഗതമായ ഒരു പൈപ്പ്‌ലൈൻ ഉപയോഗിക്കുന്നതാണ് നല്ലത്. നിശ്ചിത ക്രമത്തിലുള്ളവ താഴെ പറയുന്നവയാണ്:

  • കുറഞ്ഞ ചിലവ് (Cheaper) – ഡസൻ കണക്കിന് തവണ പ്രവർത്തിച്ചേക്കാവുന്ന ഒരു മൾട്ടി-ടേൺ ലൂപ്പിനേക്കാൾ ചിലവ് കുറവാണ് ഒരു സിംഗിൾ API കോളിന്.
  • വേഗതയേറിയത് (Faster) – ഓരോ ആവർത്തനത്തിലും ലേറ്റൻസി കൂടുന്നതിനാൽ, ഒരു വട്ടം മാത്രം ചോദിക്കുന്ന (one-shot query) രീതി വേഗത്തിൽ പൂർത്തിയാകും.
  • പരിശോധിക്കാൻ എളുപ്പമാണ് (Easier to audit) – നിശ്ചിത കോഡ് പാത്തുകൾ (deterministic code paths) ടെസ്റ്റിംഗും കംപ്ലയൻസും ലളിതമാക്കുന്നു.

ബൾക്ക് ഡാറ്റാ വാലിഡേഷൻ അല്ലെങ്കിൽ പതിവായുള്ള റിപ്പോർട്ട് ജനറേഷൻ പോലുള്ള ഉയർന്ന ഫ്രീക്വൻസിയുള്ള ലളിതമായ ജോലികൾക്ക് ഒരു ഓട്ടോണമസ് ഏജന്റിനേക്കാൾ ഒരു വർക്ക്ഫ്ലോ ആണ് അനുയോജ്യം.

സ്വയംഭരണാധികാരത്തിന്റെ മറഞ്ഞിരിക്കുന്ന ചിലവുകൾ

ഒരു പ്രശ്നം അനുയോജ്യമാണെന്ന് തോന്നിയാൽ പോലും, ഡെവലപ്പർമാർ മൂന്ന് പ്രായോഗിക പോരായ്മകൾ കണക്കിലെടുക്കണം:

  • ഉയർന്ന കമ്പ്യൂട്ട് ചിലവ് (High compute expense) – ഓരോ Thought-Action-Observation ചക്രവും ഓരോ മോഡൽ ഇൻഫറൻസ് (inference) ഉപയോഗിക്കുന്നു, ഇത് ക്ലൗഡ് ചിലവ് വർദ്ധിപ്പിക്കുന്നു.
  • കൂടുതൽ ലേറ്റൻസി (Added latency) – മോഡലിലേക്കും എക്സ്റ്റേണൽ ടൂളുകളിലേക്കുമുള്ള എല്ലാ റൗണ്ട്-ട്രിപ്പുകളുടെയും ആകെ തുകയാണ് മൊത്തം റെസ്പോൺസ് സമയം.
  • പിശകുകൾ വർദ്ധിക്കുന്നു (Error amplification) – ഒരു തെറ്റായ നിരീക്ഷണം (observation) വലിയ പിശകുകളിലേക്ക് നയിക്കുകയും തികച്ചും തെറ്റായ ഒരു അന്തിമ ഉത്തരം നൽകുകയും ചെയ്തേക്കാം.

ഏജന്റുകൾ വാഗ്ദാനം ചെയ്യുന്ന സൈദ്ധാന്തികമായ വഴക്കത്തെ (flexibility) ഈ ഘടകങ്ങൾ ഇല്ലാതാക്കിയേക്കാം.

ഡെവലപ്പർമാർക്കായുള്ള സുരക്ഷാ മാർഗ്ഗനിർദ്ദേശങ്ങൾ

ഓട്ടോണമസ് ഏജന്റുകൾ നിയന്ത്രണം വിട്ടുപോകാതിരിക്കാൻ മൂന്ന് സുരക്ഷാ മാർഗ്ഗങ്ങൾ ശുപാർശ ചെയ്യുന്നു:

  1. ആവർത്തനങ്ങൾ പരിമിതപ്പെടുത്തുക (Cap iterations) – ഏജന്റ് അനന്തമായി പ്രവർത്തിക്കാതിരിക്കാൻ പരമാവധി ലൂപ്പുകളുടെ എണ്ണം നിശ്ചയിക്കുക.
  2. ശക്തമായ ടൂൾ ഇന്റർഫേസുകളിൽ നിക്ഷേപിക്കുക – സിസ്റ്റത്തിന്റെ വിശ്വാസ്യത എന്നത് ബുദ്ധിപരമായ പ്രോംപ്റ്റിംഗ് ട്രിക്കുകളേക്കാൾ ഉപരിയായി വ്യക്തവും കൃത്യവുമായ API-കളെ ആശ്രയിച്ചിരിക്കുന്നു.
  3. ഡെപ്ലോയ്മെന്റിന് മുമ്പ് സാൻഡ്‌ബോക്സ് ചെയ്യുക (Sandbox before deployment) – കർശനമായ നിയന്ത്രണങ്ങളുള്ള ഒരു ഐസൊലേറ്റഡ് എൻവയോൺമെന്റിൽ ഏജന്റുകളെ പരീക്ഷിക്കുക; അപ്രതീക്ഷിതമായ ടൂൾ കോളുകളോ നിയന്ത്രണാതീതമായ ലൂപ്പുകളോ ഉണ്ടോ എന്ന് നിരീക്ഷിക്കുക.

ഈ മാർഗ്ഗനിർദ്ദേശങ്ങൾ പിന്തുടരുന്നത് പിശകുകൾ നേരത്തെ കണ്ടെത്താനും ചിലവ് പരിധികൾ നടപ്പിലാക്കാനും എളുപ്പമാക്കുന്നു.

പ്രായോഗികമായ വിട്ടുവീഴ്ചകൾ

ഒരു ReAct ശൈലിയിലുള്ള ഏജന്റും സ്ക്രിപ്റ്റ് ചെയ്ത വർക്ക്ഫ്ലോയും തമ്മിൽ തിരഞ്ഞെടുക്കുന്നത് പ്രശ്നം ഓപ്പൺ-എൻഡഡ് ആണോ അതോ പ്രവചിക്കാവുന്നതാണോ എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. കൂടാതെ ചിലവ്, ലേറ്റൻസി, പിശക് വരാനുള്ള സാധ്യത എന്നിവയും പരിഗണിക്കേണ്ടതുണ്ട്.

ചുരുക്കത്തിൽ: ഓരോ പ്രവൃത്തിയും മുൻകൂട്ടി നിശ്ചയിക്കാൻ കഴിയില്ലായ്മയും അഡാപ്റ്റീവ് റീസണിംഗും ആവശ്യമായ സാഹചര്യങ്ങളിൽ ReAct ഏജന്റുകൾ മികച്ചതാണ്. എന്നാൽ അവ ഉയർന്ന ചിലവും സാവധാനത്തിലുള്ള പ്രതികരണങ്ങളും സൂക്ഷ്മമായ ബഗുകൾ ഉണ്ടാകാനുള്ള സാധ്യതയും നൽകുന്നു. വ്യക്തമായ സ്റ്റോപ്പിംഗ് റൂളുകൾ, ശക്തമായ ടൂൾ കോൺട്രാക്റ്റുകൾ, സാൻഡ്‌ബോക്സ് ടെസ്റ്റിംഗ് എന്നിവ ഉൾപ്പെടുന്ന ഒരു അച്ചടക്കമുള്ള സമീപനം, ഈ സാങ്കേതികവിദ്യയെ ഒരു ബജറ്റ് ചോർച്ചയാക്കുന്നതിന് പകരം നിയന്ത്രിതമായി ഉപയോഗിക്കാവുന്ന ഒരു ആസ്തിയാക്കി മാറ്റുന്നു.