ഏജന്റിന്റെ പ്രവർത്തനം മെച്ചപ്പെടുത്താൻ ശ്രമിക്കുന്ന മിക്ക AI ടീമുകളും ഒരേ മാർഗങ്ങളെയാണ് ആശ്രയിക്കുന്നത്: വലിയ സന്ദർഭ പരിധികൾ, കൂടുതൽ രേഖകൾ, കൂടുതൽ ബുദ്ധിപരമായ പ്രോംപ്റ്റുകൾ. ആ സമീപനം പൂർണമായും തെറ്റാണെന്നാണ് ഈ ലേഖനത്തിന്റെ വാദം. കുറവുള്ളത് കൂടുതൽ വിവരങ്ങളല്ല. നിയന്ത്രണമാണ്. പ്രദർശനത്തിൽ മാത്രം പ്രവർത്തിക്കുന്ന ഏജന്റിനെയും പ്രൊഡക്ഷനിൽ പ്രവർത്തിക്കുന്ന ഏജന്റിനെയും വേർതിരിക്കുന്നത് നന്നായി രൂപകൽപ്പന ചെയ്ത നിയന്ത്രണപാളിയാണ്.
AI ഏജന്റിന് വലിയ ഓർമ്മയോ കൂടുതൽ രേഖകളോ നീളമേറിയ സന്ദർഭ പരിധിയോ നൽകുന്നത് അതിനെ കൂടുതൽ ബുദ്ധിമാനാക്കില്ല; വേഗം കുറയ്ക്കുകയും ചെലവ് കൂട്ടുകയും മാത്രമേ ചെയ്യൂ. എല്ലാം ഒരുമിച്ച് ഉപയോഗിക്കുന്നതിനുപകരം, ആവശ്യമുള്ളപ്പോൾ എന്താണ് വേണ്ടതെന്ന് തിരഞ്ഞെടുക്കാൻ ഏജന്റിനെ പഠിപ്പിക്കുമ്പോഴാണ് യഥാർഥ നേട്ടമുണ്ടാകുന്നത്.
വിശ്വാസ്യത മോഡലിൽനിന്നല്ല, ആവർത്തനചക്രത്തിൽനിന്നാണ് ലഭിക്കുന്നത്. പ്രദർശനത്തിൽ മതിപ്പുണ്ടാക്കുന്ന ഏജന്റും പ്രൊഡക്ഷനിൽ ഉറച്ചുനിൽക്കുന്ന ഏജന്റും തമ്മിലുള്ള വ്യത്യാസം AI-യുടെ ഗുണമേന്മയല്ല; സിസ്റ്റം സ്വന്തം പ്രവർത്തനം പരിശോധിക്കുന്നുണ്ടോ എന്നതാണ്. ഓരോ ഘട്ടത്തിലും ആസൂത്രണം ചെയ്യുകയും പ്രവർത്തിക്കുകയും നിരീക്ഷിക്കുകയും പരിശോധിക്കുകയും ചെയ്യുന്ന ഏജന്റുകൾ ആത്മവിശ്വാസത്തോടെ തെറ്റിക്കുന്നതിനുപകരം സ്വന്തം പിഴവുകൾ കണ്ടെത്തുന്നു.
ഇന്നത്തെ മിക്ക AI ഏജന്റുകളും അടിസ്ഥാനപരമായി അധിക ഘട്ടങ്ങളുള്ള ചാറ്റ്ബോട്ടുകളാണ്; ശരിയായ പാതയിലാണോ, എപ്പോൾ നിർത്തണം, എപ്പോൾ മറ്റൊരു സമീപനം പരീക്ഷിക്കണം എന്നിവ അറിയാനുള്ള സംവിധാനമൊന്നും അവയ്ക്കില്ല. വ്യക്തമായ വിജയമാനദണ്ഡങ്ങൾ, ഘടനാബദ്ധമായ നില, സാധുതാപരിശോധനകൾ എന്നിവയുള്ള ശരിയായൊരു നിയന്ത്രണപാളിയാണ് ഏജന്റിന്റെ രൂപത്തിലുള്ള വസ്തുവിനെ യഥാർഥത്തിൽ വിശ്വസിക്കാവുന്ന ഒന്നാക്കി മാറ്റുന്നത്.
ഇന്നലെ ഉച്ചഭക്ഷണത്തിന് നിങ്ങൾ എന്താണ് കഴിച്ചത്?
“ഇന്നലെ + ഉച്ചഭക്ഷണം” എന്നതിലെത്തുന്നതുവരെ ജീവിതത്തിലെ എല്ലാ ഓർമ്മകളും നിങ്ങൾ വീണ്ടും ഓർത്തുനോക്കിയിരിക്കില്ല. ആ ആശയങ്ങൾ ഉൾപ്പെടുന്ന അനുഭവഭാഗത്തേക്ക് നേരിട്ട് പോയിരിക്കാം. ഏജന്റുകൾ നിർമ്മിക്കുമ്പോൾ ഉപയോഗിക്കാവുന്ന നല്ലൊരു മാനസിക മാതൃകയാണത്:
ഭീമമായ സന്ദർഭ പരിധി ഓർമ്മയല്ല.
വീണ്ടെടുത്ത രേഖകളുടെ കൂമ്പാരം ധാരണയല്ല.
നീണ്ട ചെയ്ൻ-ഓഫ്-തോട്ട് വിശ്വാസ്യതയല്ല.
അവ ചേരുവകളാണ്. എന്നാൽ ഒരു ഏജന്റിനെ യഥാർഥ ഏജന്റായി അനുഭവപ്പെടാൻ സഹായിക്കുന്നതും നിങ്ങളുടെ ജീവിതചരിത്രം മുഴുവൻ ബലപ്രയോഗത്തിലൂടെ പരിശോധിക്കുന്നതിൽനിന്ന് തലച്ചോറിനെ തടയുന്നതും ഒരേ കാര്യമാണ്: നിയന്ത്രണം.
അടുത്തിടെ പ്രസിദ്ധീകരിച്ച വലിയ ഭാഷാ മോഡലുകൾക്കായുള്ള ഏജന്റാധിഷ്ഠിത റീസണിംഗ് എന്ന സർവേ, നിർമ്മാണപ്രവർത്തനത്തിനിടെ നമ്മിൽ പലരും അനുഭവിച്ച മാറ്റത്തെ മികച്ച രീതിയിൽ സംഗ്രഹിക്കുകയും പേരിടുകയും ചെയ്തു: മോഡലിന് അകത്തെ റീസണിംഗിൽനിന്ന് പരസ്പരപ്രവർത്തനത്തിലൂടെയുള്ള റീസണിംഗിലേക്ക്. ഈ ലേഖനം ആ പ്രബന്ധത്തിന്റെ സംഗ്രഹമല്ല. ആ മാറ്റത്തെ പ്രായോഗിക സിസ്റ്റം രൂപകൽപ്പനയിലേക്ക് മാറ്റാനുള്ള ശ്രമമാണിത്:
ഉപകരണങ്ങളുള്ള ചാറ്റ്ബോട്ടുകളെപ്പോലെ ഏജന്റുകൾ നിർമ്മിച്ചാൽ, ചാറ്റ്ബോട്ടുകളുടെ പരാജയരീതികൾ തന്നെയാകും തുടർന്നും ലഭിക്കുക; പിഴവുകൾക്ക് കൂടുതൽ ചെലവുണ്ടാകുമെന്നുമാത്രം.
“മോഡലിനെ കൂടുതൽ ബുദ്ധിമാനാക്കാൻ” കുറച്ചുകാലമായി നാം സ്വീകരിച്ചിരുന്ന പൊതുവായ മാർഗരേഖ ഇതായിരുന്നു: മെച്ചപ്പെട്ട പ്രോംപ്റ്റുകൾ, ചെയ്ൻ-ഓഫ്-തോട്ട്, സ്വയംസ്ഥിരത / സാമ്പിളിങ് അടിസ്ഥാനമാക്കിയ മെച്ചപ്പെടുത്തലുകൾ, ചിലപ്പോൾ തിരയലും.
“ചിന്ത → പ്രവർത്തനം → നിരീക്ഷണം” സ്വാഭാവികമായി തോന്നിച്ചതിനാൽ ReAct ഒരു നിർണായക വഴിത്തിരിവായിരുന്നു. എന്നാൽ പരോക്ഷമായ നിയന്ത്രണം ശ്രദ്ധിക്കുക: ഇതിൽ പലതും ഇപ്പോഴും “കൂടുതൽ ടോക്കണുകളുള്ള വൺ-ഷോട്ട് അനുമാനം” എന്ന നിലയിലാണ് അവസാനിക്കുന്നത്. സർവേയുടെ അവതരണം കൂടുതൽ കൃത്യമാണ്: ഏജന്റാധിഷ്ഠിത റീസണിംഗ് പരിശോധനാസമയ പരസ്പരപ്രവർത്തനം വിപുലീകരിക്കുന്നതിന് ഊന്നൽ നൽകുന്നു—മോഡലും ഓർമ്മയും പരിസരവും ആവർത്തനചക്രത്തിൽ നിലനിൽക്കുന്ന പുനരാവർത്തന പ്രക്രിയയായി അനുമാനത്തെ മാറ്റുന്നു.
പ്രദർശനങ്ങളിൽ മതിപ്പുളവാക്കുന്നതും യഥാർഥ പ്രവർത്തനക്രമങ്ങളിൽ ദുർബലവുമായ ഏജന്റുകൾ നിങ്ങൾ നിർമ്മിക്കുകയോ ഉപയോഗിക്കുകയോ ചെയ്തിട്ടുണ്ടെങ്കിൽ, ഇത് നിങ്ങൾക്കുള്ളതാണ്.
ഞാൻ പലതവണ കണ്ടിട്ടുള്ളതും തീർച്ചയായും സ്വയം പല പതിപ്പുകൾ നിർമ്മിച്ചിട്ടുള്ളതുമായ ഒരു മാതൃക വിവരിക്കാം:
നല്ലൊരു ചാറ്റ് മോഡൽ എടുക്കുക.
കുറച്ച് ഉപകരണങ്ങൾ ചേർക്കുക—തിരയൽ, DB അന്വേഷണം, ഒരുപക്ഷേ കോഡ് നിർവഹണവും.
RAG ചേർക്കുക.
“നിങ്ങൾ സ്വയംഭരണ ഏജന്റാണ്” എന്ന സിസ്റ്റം പ്രോംപ്റ്റ് ചേർക്കുക.
നിർത്തുകയോ സമയപരിധി തീരുകയോ ചെയ്യുന്നതുവരെ എല്ലാം ഒരു ആവർത്തനചക്രത്തിൽ പൊതിയുക.
അഭിനന്ദനങ്ങൾ, നിങ്ങൾക്കിപ്പോൾ ഏജന്റിന്റെ രൂപത്തിലുള്ളൊരു വസ്തുവുണ്ട്. എന്നാൽ പ്രവചിക്കാവുന്ന ചില രീതികളിലാണ് അത് സാധാരണ പരാജയപ്പെടുന്നത്:
സന്ദർഭപ്പെരുപ്പം: ഓരോ നിരീക്ഷണവും കൂട്ടിച്ചേർക്കപ്പെടുന്നു; പ്രോംപ്റ്റുകൾ പുരാവസ്തുപാളികൾ പോലെയാകുന്നു.
ഉപകരണങ്ങളുമായുള്ള പരക്കംപാച്ചിൽ: “തെറ്റായ ഉപകരണം, പക്ഷേ പൂർണ ആത്മവിശ്വാസം” എന്നത് പതിവ് പരാജയരീതിയാകുന്നു.
നിർത്തൽ വ്യവസ്ഥകളില്ല: തുടരേണ്ടതുകൊണ്ടല്ല, തുടരാനാകുന്നതുകൊണ്ടുമാത്രം അത് മുന്നോട്ടുപോകുന്നു.
ഗ്രൗണ്ടിംഗ് ശീലമില്ല: നിർബന്ധിച്ച് പരിശോധിപ്പിച്ചില്ലെങ്കിൽ തെറ്റുപറ്റിയത് അത് തിരിച്ചറിയില്ല.
ഓർമ്മ = ചാറ്റ് ചരിത്രം: അടിസ്ഥാനപരമായി രേഖകൾ എഴുതിയിട്ട് അതിനെ പഠനമെന്ന് വിളിക്കുകയാണ്.
അതുകൊണ്ടാണ് “ഏജന്റുകൾ” പ്രദർശനങ്ങളിൽ മാന്ത്രികമായും പ്രൊഡക്ഷനിൽ കുഴഞ്ഞുമറിഞ്ഞതായും തോന്നുന്നത്. ഏജന്റാധിഷ്ഠിത സിസ്റ്റങ്ങളെ പ്രൊഡക്ഷനിൽ വിന്യസിച്ച ഞങ്ങളുടെ അനുഭവവും ഇത് വ്യക്തമാക്കുന്നു: മോഡലിനെയല്ല സിസ്റ്റത്തെ വിലയിരുത്താൻ തുടങ്ങുമ്പോൾ പരാജയരീതികളിൽ വഴികണ്ടെത്തൽ, ഉപകരണശുചിത്വം, സന്ദർഭം വെട്ടിച്ചുരുക്കൽ, വിലയിരുത്തൽ രൂപകൽപ്പന എന്നിവയും ഉൾപ്പെടും; “മോഡൽ ശരിയായി ഉത്തരം നൽകിയോ” എന്നത് മാത്രമല്ല.
അപ്പോൾ ചോദ്യം ഇതാണ്: ഉദ്ദേശ്യപൂർവ ഏജന്റ് എങ്ങനെയിരിക്കണം?
ഇത് കൂടുതൽ വ്യക്തമായി മനസ്സിലാക്കാൻ, മിക്കവർക്കും സങ്കൽപ്പിക്കാവുന്ന ലളിതമായൊരു പ്രവർത്തനക്രമം നോക്കാം: “അടുത്ത ചൊവ്വാഴ്ച ലണ്ടനിൽനിന്ന് ന്യൂയോർക്കിലേക്ക് എനിക്കൊരു വിമാനയാത്ര ബുക്ക് ചെയ്യൂ. വൈകുന്നേരം 6-ന് മുമ്പ് എത്തണം. ചെലവ് £900-ൽ താഴെയായിരിക്കണം. ഇടനാഴിയോടു ചേർന്ന സീറ്റ് വേണം.”
സാധാരണ “ഏജന്റിന്റെ രൂപത്തിലുള്ള” നടപ്പാക്കൽ ഇങ്ങനെയാണ്:
ഇതുവരെ ആവശ്യമില്ലെങ്കിലും വിമാനക്കമ്പനി / യാത്രാനയ രേഖകൾ ഉടൻ തന്നെ കൂട്ടത്തോടെ വീണ്ടെടുക്കുന്നു.
തിരയൽ ഉപകരണം വിളിച്ച് ഫലങ്ങളുടെ നീണ്ട പട്ടിക പ്രോംപ്റ്റിലേക്ക് പകർത്തുകയും “ഒരെണ്ണം തിരഞ്ഞെടുക്കുകയും” ചെയ്യുന്നു.
എത്തിച്ചേരുന്ന സമയം / ബാഗേജ് / സീറ്റ് / നയം തുടങ്ങിയ നിയന്ത്രണങ്ങൾ പരിശോധിക്കാതെ തിടുക്കത്തിൽ ബുക്ക് ചെയ്യുന്നു.
പരാജയപ്പെട്ടാൽ അല്പം വ്യത്യസ്തമായി വീണ്ടും ശ്രമിക്കുന്നു; എന്നാൽ എന്ത് മാറിയെന്നോ എന്ത് പഠിച്ചെന്നോ വ്യക്തമായ ധാരണയില്ല.
മോഡലിന് റീസണിംഗ് നടത്താനാകാത്തതല്ല പരാജയകാരണം; പ്രവർത്തനക്രമത്തെ സിസ്റ്റം നിയന്ത്രിക്കുന്നില്ല എന്നതാണ്.
കൂടുതൽ ഏജന്റ് സ്വഭാവമുള്ള പതിപ്പ് ഈ ജോലിയെ വ്യക്തമായ നിലയും പരിശോധനകളുമുള്ള സംവേദനാത്മക പ്രക്രിയയായി കാണുന്നു:
ആസൂത്രണം: നിയന്ത്രണങ്ങൾ വീണ്ടും വ്യക്തമാക്കുക, ലഭ്യമല്ലാത്ത വിവരങ്ങൾ പട്ടികപ്പെടുത്തുക. ഉദാ., “ഏത് വിമാനത്താവളമാണ് ഇഷ്ടം?” / “ഒരു ഇടത്താവളം സ്വീകാര്യമാണോ?”.
പ്രവർത്തനം: ഘടനാബദ്ധമായ അന്വേഷണത്തോടെ വിമാനതിരയൽ വിളിക്കുക—തീയതിപരിധി, എത്തിച്ചേരൽ നിയന്ത്രണം, ചെലവുപരിധി.
നിരീക്ഷണം: ഫലങ്ങൾ വലിയൊരു പകർത്തിയ കൂമ്പാരമായല്ല, വില / എത്തിച്ചേരൽ / ഇടത്താവളങ്ങൾ ഉൾപ്പെടുന്ന മികച്ച 5 സാധ്യതകളുള്ള ഒതുക്കമുള്ള നിലാ-ഒബ്ജക്റ്റായി സൂക്ഷിക്കുക.
പുതുക്കൽ: നിയന്ത്രണങ്ങൾ നിറവേറുന്നില്ലെങ്കിൽ അന്വേഷണം പരിഷ്കരിക്കുക. ഉദാ., “വൈകുന്നേരം 6-ന് മുമ്പ് എത്തണമെന്നത് വളരെ കർശനമാണ്—സമയപരിധി നീട്ടണോ ചെലവുപരിധി ഉയർത്തണോ?”.
പരിശോധന: സാധുതാപരിശോധനകൾ നടത്തുക—“എത്തിച്ചേരൽ < 18:00,” “വില ≤ £900,” “നയാനുസൃതം,” “സീറ്റ് തിരഞ്ഞെടുപ്പ് ലഭ്യം”.
നിർത്തൽ: ബുക്കിങ് API സ്ഥിരീകരണം നൽകുകയും എല്ലാ സാധുതാപരിശോധനകളും വിജയിക്കുകയും ചെയ്തശേഷം മാത്രം.
മാറിയത് സൂക്ഷ്മമാണെങ്കിലും നിർണായകമാണ്. വീണ്ടെടുക്കൽ വ്യവസ്ഥാപിതമാണ്, യാന്ത്രികപ്രതികരണമല്ല; സന്ദർഭം നിയന്ത്രിക്കപ്പെടുന്നു, അതായത് നില ഘടനാബദ്ധമാണ്, കുമിഞ്ഞുകൂടുന്നതല്ല; പരിശോധന ആവർത്തനചക്രത്തിനുള്ളിലാണ്, ഉപയോക്താവിന് വിട്ടിട്ടില്ല. “വിമാനയാത്ര ബുക്ക് ചെയ്യൽ” എന്നതിന് പകരം “വാങ്ങൽ ഓർഡർ സൃഷ്ടിക്കൽ,” “പണം മടക്കിനൽകൽ,” “പ്രൊഡക്ഷൻ ക്രമീകരണം മാറ്റൽ,” അല്ലെങ്കിൽ “PR പുറത്തിറക്കൽ” എന്നാക്കിയാലും കഥ ഒന്നുതന്നെ: ഏജന്റിന് പ്രവർത്തിക്കാനാകുമ്പോൾ, പ്രോംപ്റ്റിനേക്കാൾ ആവർത്തനചക്രമാണ് പ്രധാനം.
മുകളിൽ പറഞ്ഞ സർവേ ഏജന്റാധിഷ്ഠിത റീസണിംഗിനെ മൂന്ന് തലങ്ങളായി ക്രമീകരിക്കുന്നു: അടിസ്ഥാനം—ആസൂത്രണം / ഉപകരണ ഉപയോഗം / തിരയൽ; സ്വയം പരിണമിക്കുന്നത്—പ്രതികരണം + ഓർമ്മ; കൂട്ടായത്—ഒന്നിലധികം ഏജന്റുകളുടെ ഏകോപനം.
എന്നാൽ കൂടുതൽ ആഴത്തിലുള്ള ആശയം ഇതാണ്: വിശ്വസനീയമായി തോന്നുന്ന ചെയ്ൻ-ഓഫ്-തോട്ട് സൃഷ്ടിക്കുന്നതിൽ ഒതുങ്ങാതെ, ആസൂത്രണം, തീരുമാനമെടുക്കൽ, പരിശോധന എന്നിവയുടെ സംഘാടനതത്വമായി റീസണിംഗ് മാറുന്നു. നിങ്ങളുടെ സിസ്റ്റംഘടനയിൽ ഉണ്ടാകുന്ന മാറ്റങ്ങളുമായി ബന്ധപ്പെടുത്തി നോക്കുന്നതുവരെ ഇത് അമൂർത്തമായി തോന്നാം. ഓർക്കേണ്ട മൂന്ന് അടിസ്ഥാന കാര്യങ്ങളുണ്ട്:
നല്ലൊരു ഏജന്റ് വീണ്ടെടുക്കലിനെ “എപ്പോഴും ചെയ്യേണ്ടത്” എന്ന നിലയിൽ കാണരുത്. വീണ്ടെടുക്കൽ ഒരു തീരുമാനമാണ്, യാന്ത്രികപ്രതികരണമല്ല.
പ്രായോഗികമായൊരു പൊതുനിയമം ഇതാണ്:
ഓരോ ഘട്ടത്തിലും നിങ്ങളുടെ സിസ്റ്റം വിവരങ്ങൾ വീണ്ടെടുക്കുന്നുവെങ്കിൽ, നിങ്ങൾ നിർമ്മിച്ചത് വീണ്ടെടുക്കൽ സംവിധാനമല്ല; സന്ദർഭനികുതിയാണ്.
യഥാർഥ ജോലിയിൽ ഇത് എപ്പോഴും കാണാം. പ്രൊഡക്ഷൻ തകരാർ കണ്ടെത്തുമ്പോൾ എല്ലാ രേഖകളും സന്ദർഭത്തിലേക്ക് തള്ളുകയല്ല ചെയ്യുന്നത്; നിലവിലെ അനുമാനത്തെ അടിസ്ഥാനമാക്കി അടുത്തതായി ഏത് അളവുകളും രേഖകളും ലഭ്യമാക്കണമെന്ന് തീരുമാനിക്കുന്നു. അതാണ് “ഏജന്റാധിഷ്ഠിത വീണ്ടെടുക്കൽ.” കൂടുതൽ വ്യക്തമായ മാതൃക ഇതാണ്:
വീണ്ടെടുക്കൽ ആവശ്യമുണ്ടോ എന്ന് തീരുമാനിക്കുക.
ഉണ്ടെങ്കിൽ: അന്വേഷണം തയ്യാറാക്കുക, ലഭ്യമാക്കുക, വേഗത്തിൽ പരിശോധിക്കുക, ആവശ്യമായത് വേർതിരിക്കുക.
തെളിവുകൾ തമ്മിൽ പൊരുത്തക്കേടുണ്ടെങ്കിൽ: വീണ്ടും ലഭ്യമാക്കുക.
അതിനുശേഷം മാത്രം സംഗ്രഹിച്ച് നിഗമനത്തിലെത്തുക.
ഇവിടെയാണ് “ഏജന്റാധിഷ്ഠിത RAG” പരമ്പരാഗത RAG-ൽനിന്ന് വ്യത്യസ്തമാകുന്നത്: വീണ്ടെടുക്കൽ സ്വതേയുള്ള പ്രക്രിയാഘട്ടമല്ല, ബോധപൂർവമായ റീസണിംഗ് ഘട്ടമായി മാറുന്നു.
“ഒരു മോഡലിനെ” വിലയിരുത്തുന്നത് നിർത്തി “ഒരു സിസ്റ്റത്തെ” വിലയിരുത്താൻ തുടങ്ങുന്ന നിമിഷം മുതൽ നില നിരീക്ഷണവും പ്രവർത്തനപഥം പിന്തുടരലും പ്രധാനമാകുന്നു.
ഏജന്റ് പ്രവർത്തനക്രമങ്ങളുടെ നിരീക്ഷണക്ഷമതയെക്കുറിച്ച് വ്യവസായം ഇപ്പോൾ കൂടുതൽ വ്യക്തമായിട്ടുണ്ട്. ഉദാഹരണത്തിന്, OpenAI-യുടെ Agents SDK-യിൽ അന്തർനിർമിത പ്രവർത്തനപഥ നിരീക്ഷണവും ഏജന്റിന്റെ പ്രവർത്തനങ്ങൾ—ഉള്ളടക്കസൃഷ്ടി, ഉപകരണവിളികൾ, കൈമാറ്റങ്ങൾ, സുരക്ഷാനിയന്ത്രണങ്ങൾ, ഇഷ്ടാനുസൃത സംഭവങ്ങൾ—രേഖപ്പെടുത്തുന്ന Traces ഡാഷ്ബോർഡും ലഭ്യമാണ്. സംഭവിച്ചത് ഓരോ ഘട്ടമായും കണ്ടെത്താനും ഓഡിറ്റ് ചെയ്യാനുമാണ് ഇത്.
അത് “ഉണ്ടെങ്കിൽ നന്ന്” എന്ന തരത്തിലുള്ള സൗകര്യമല്ല. പ്രശ്നം കണ്ടെത്താനാകുന്ന സിസ്റ്റവും പുറമേനിന്ന് ഊഹിച്ച് വിലയിരുത്താൻ മാത്രം കഴിയുന്ന സിസ്റ്റവും തമ്മിലുള്ള വ്യത്യാസമാണത്.
എന്റെ അഭിപ്രായത്തിൽ, പ്രതികരണത്തെക്കുറിച്ച് സർവേ പുലർത്തുന്ന വ്യക്തതയാണ് അതിലെ ഏറ്റവും പ്രായോഗികമായ ഭാഗം. അത് പ്രതികരണത്തെ മൂന്ന് രീതികളായി തിരിക്കുന്നു: പ്രതിഫലന പ്രതികരണം—സൃഷ്ടിക്കുക → വിമർശിക്കുക → തിരുത്തുക; പരാമീറ്റർ പൊരുത്തപ്പെടുത്തൽ—സൂക്ഷ്മപരിശീലനം / RL വഴി പഠിക്കുക; സാധുതാപരിശോധകൻ നയിക്കുന്ന പ്രതികരണം—പരിശോധന വിജയിക്കുന്നതുവരെ വീണ്ടും ശ്രമിക്കുക.
മിക്ക ടീമുകളും സാധുതാപരിശോധകൻ നയിക്കുന്ന പ്രതികരണത്തിൽ നിന്ന് തുടങ്ങണം; അത് ആവേശകരമല്ലെങ്കിലും ഫലപ്രദമാണ്. ഘടകപരിശോധന നടത്തുന്നതോ സ്കീമ പരിശോധിക്കുന്നതോ ബിസിനസ് നിയമങ്ങളും നിയന്ത്രണങ്ങളും നിശ്ചയിക്കുന്നതോ—“മേലധികാരിക്ക് കൈമാറാതെ X-നു മുകളിലുള്ള പണം മടക്കിനൽകരുത്”—വസ്തുതാപരത ഉറപ്പാക്കുന്നതോ—“അവലംബങ്ങൾ നിർബന്ധം”—ആയ ഏതെങ്കിലും സാധുതാപരിശോധകൻ എഴുതാനാകുമെങ്കിൽ, നിർണിതമല്ലാത്ത മോഡൽ ഫലത്തെ യഥാർഥത്തിൽ വിശ്വസിക്കാവുന്ന ഒന്നാക്കി മാറ്റാം.
ഇവിടെയുള്ള മുൻകൂട്ടി അറിയാനാവാത്ത മാറ്റങ്ങളിലൊന്ന് ലളിതമാണ്: ഏജന്റുകളുടെ ലോകത്ത് വിശ്വാസ്യത പലപ്പോഴും മോഡലിനേക്കാൾ ആവർത്തനചക്രത്തിൽ നിന്നാണ് ലഭിക്കുന്നത്.
പരിശീലനം കൂടാതെ തന്നെ പെരുമാറ്റം വിശ്വസനീയമായി മെച്ചപ്പെടുത്തുന്ന, ഞാൻ കണ്ടെത്തിയ ഏറ്റവും ചെറിയ ആവർത്തനചക്ര ശീലം ഇതാണ്:
ഘട്ടങ്ങളായി പ്രവർത്തിക്കുക: ആസൂത്രണം → പ്രവർത്തനം → നിരീക്ഷണം → പുതുക്കൽ.
ഓരോ പ്രവർത്തനത്തിനുശേഷവും നിരീക്ഷണം 1–3 ബുള്ളറ്റുകളിൽ ചുരുക്കുക.
വിജയമാനദണ്ഡങ്ങൾ നിറവേറുമ്പോഴോ പരിധി എത്തുമ്പോഴോ നിർത്തുക; ലഭ്യമായ ഏറ്റവും മികച്ച ഫലവും ശേഷിക്കുന്ന അനിശ്ചിതത്വങ്ങളും നൽകുക.
മോഡലിനെ വാചാലമാക്കുകയല്ല ഇതിന്റെ ലക്ഷ്യം. സിസ്റ്റത്തെ മനസ്സിലാക്കാവുന്നതാക്കുകയും ഓരോ ഘട്ടത്തിലും “യാഥാർഥ്യവുമായി ബന്ധം” നിർബന്ധമാക്കുകയും ചെയ്യുകയാണ് ലക്ഷ്യം. എൻജിനീയർമാർക്ക് എളുപ്പം ബന്ധപ്പെടുത്താവുന്ന ഉദാഹരണമാണ് CI മാതൃകയിലുള്ള അടഞ്ഞ ആവർത്തനചക്ര ഗ്രൗണ്ടിംഗ്:
ആസൂത്രണം: മാറ്റങ്ങളുടെ പട്ടിക നിർദേശിക്കുക.
പ്രവർത്തനം: പരിശോധനകൾ / കോഡ്-ശൈലി പരിശോധന നടത്തുക.
നിരീക്ഷണം: പരാജയങ്ങൾ വിശകലനം ചെയ്യുക.
പുതുക്കൽ: തിരുത്തി വീണ്ടും ശ്രമിക്കുക.
യാദൃച്ഛികമായി ഏജന്റായി മാറിയ രൂപകൽപ്പനകളെ വെളിപ്പെടുത്തുന്ന ചില ചോദ്യങ്ങൾ:
“എന്ത് വീണ്ടെടുക്കണമെന്ന് എന്റെ ഏജന്റ് തിരഞ്ഞെടുക്കുന്നുണ്ടോ, അതോ ഞാൻ എല്ലായ്പ്പോഴും വിവരങ്ങൾ വീണ്ടെടുക്കുന്നുണ്ടോ?”
വീണ്ടെടുക്കൽ നിരുപാധികമാണെങ്കിൽ പ്രതികരണവൈകൽ, ചെലവ്, സന്ദർഭത്തിന്റെ നേർപ്പ് കുറയൽ, മോശം ഇൻപുട്ടിൽനിന്ന് മോശം ഫലം ലഭിക്കാനുള്ള ഉയർന്ന സാധ്യത എന്നിവയ്ക്ക് നിങ്ങൾ വില നൽകേണ്ടിവരും.
“തെറ്റുപറ്റിയെന്ന് എന്റെ ഏജന്റിന് തിരിച്ചറിയാനാകുമോ?”
“ഉപയോക്താവ് അസ്വസ്ഥനാകുന്നു” എന്നത് മാത്രമാണ് ഏജന്റിനുള്ള പ്രതികരണ സൂചനയെങ്കിൽ, മനുഷ്യരുടെ ദുരിതം ഉപയോഗിച്ചാണ് നിങ്ങൾ RL നടത്തുന്നത്. യാഥാർഥ്യം പരിശോധിക്കാൻ അതിനെ പ്രാപ്തമാക്കുന്നതിനുള്ള ഏറ്റവും വൃത്തിയുള്ള മാർഗമാണ് സാധുതാപരിശോധകൻ നയിക്കുന്ന പുനഃശ്രമ ആവർത്തനചക്രം.
“ഓർമ്മയിൽ എഴുതാനാകുമോ, കാലക്രമേണ അത് മെച്ചപ്പെടുന്നുണ്ടോ?”
നിങ്ങളുടെ “ഓർമ്മ” ചാറ്റ് ചരിത്രം കൂട്ടിച്ചേർക്കുക മാത്രമാണെങ്കിൽ, അടിസ്ഥാനപരമായി നിങ്ങൾ രേഖകൾ എഴുതുകയാണ്. സർവേ ഓർമ്മയെ അവതരിപ്പിക്കുന്ന രീതി പ്രധാനമാണ്: കേവലം സംഭാഷണരേഖയല്ല, ഏജന്റുകൾ കാലക്രമേണ പരിഷ്കരിക്കുന്ന ചലനാത്മകമായി വളരുന്ന സന്ദർഭമാണ് ഓർമ്മ.
എന്താണ് സംഭവിച്ചതെന്ന് രേഖകൾ പറയുന്നു; അടുത്ത തവണ എന്ത് ചെയ്യണമെന്ന് ഓർമ്മ പറയുന്നു. ചാറ്റ് ചരിത്രം ഒരു സംഭാഷണരേഖയാണ്. ഭാവിയിലേക്ക് എന്തെല്ലാം കൊണ്ടുപോകണം എന്നതിനെക്കുറിച്ച് പരിണമിച്ചുകൊണ്ടിരിക്കുന്ന നയമാണ് ഓർമ്മ.
പ്രായോഗികമായൊരു തുടക്കം ചെറിയൊരു “പഠിച്ച പാഠങ്ങൾ” പട്ടികയാണ്: ജോലിയുടെ തരം, ഉപകരണം, പരാജയരീതി എന്നിവ താക്കോലായും ഫലിച്ചതും ഒഴിവാക്കേണ്ടതും മൂല്യങ്ങളായും ക്രമീകരിക്കാം. പൂർണതയുള്ള വിജ്ഞാനഗ്രാഫ് നിർമ്മിക്കുകയല്ല ലക്ഷ്യം. കൂട്ടുപലിശപോലെ മെച്ചപ്പെടുന്ന പെരുമാറ്റം സൃഷ്ടിക്കുകയാണ് ലക്ഷ്യം: ഓർമ്മയും പ്രതികരണവും ചേർന്ന് “നിലയില്ലാത്ത സഹായികളെ” കാലക്രമേണ മെച്ചപ്പെടുന്ന സിസ്റ്റങ്ങളാക്കി മാറ്റുന്നു.
പ്രശ്നത്തിലേക്ക് കൂടുതൽ ഏജന്റുകളെ നിയോഗിക്കാൻ പ്രലോഭനമുണ്ടാകും; എന്നാൽ ഇത് പലപ്പോഴും ഏകോപനച്ചെലവ് വർധിപ്പിക്കുന്നു. “പ്രവർത്തനക്ഷമമായ ഏറ്റവും ചെറിയ ടീമിന്റെ” നല്ലൊരു മാതൃക:
ഏകോപകൻ: ജോലിയെ വിഭജിച്ച് ചുമതലപ്പെടുത്തുന്നു.
നിർവാഹകൻ: ഉപകരണവിളികളും മാറ്റങ്ങളും നടത്തുന്നു.
വിമർശകൻ / വിലയിരുത്തുന്നയാൾ: കൃത്യതയും അപകടസാധ്യതയും പരിശോധിക്കുന്നു.
ഓർമ്മപരിപാലകൻ: പാഠങ്ങൾ എഴുതുകയും ക്രമീകരിക്കുകയും ചെയ്യുന്നു.
ഓരോ ഏജന്റിനും എന്ത് ഉത്തരവാദിത്വമാണുള്ളതെന്ന് വിശദീകരിക്കാനാകുന്നില്ലെങ്കിൽ, ഇപ്പോൾ നിങ്ങൾക്ക് ഒന്നിലധികം ഏജന്റുകൾ ആവശ്യമില്ലായിരിക്കാം.
ഈ മാതൃകാമാറ്റം നാം യഥാർഥത്തിൽ അംഗീകരിക്കുന്നുവെങ്കിൽ, എല്ലാം പ്രോംപ്റ്റുകളിൽ കുത്തിനിറയ്ക്കുന്നതും പരാജയങ്ങളെ അന്തിമഫലങ്ങളായി കാണുന്നതും ഏജന്റുകളെ ചാറ്റ്ബോട്ടുകളെപ്പോലെ വിലയിരുത്തുന്നതും നിർത്തേണ്ടിവരും. ഏജന്റുകളെ അവ യഥാർഥത്തിൽ എന്താണോ അതായി കാണാൻ തുടങ്ങണം: ഭാഷ നിയന്ത്രണതലമായുള്ള സോഫ്റ്റ്വെയർ സിസ്റ്റങ്ങൾ; വിശ്വാസ്യത ലഭിക്കുന്നത് ആവർത്തനചക്രത്തിൽനിന്നാണ്.
മറ്റൊരു മോഡൽ ചേർക്കുന്നതിനുമുമ്പ് മറ്റൊരു വിലയിരുത്തൽ ആവർത്തനചക്രം ചേർക്കുക. എല്ലാം വീണ്ടെടുക്കുന്നതിനുമുമ്പ് അതിനെ വ്യവസ്ഥാപിതമാക്കുക. പത്തെണ്ണം പുറത്തിറക്കുന്നതിനുമുമ്പ് ഒരു സാധുതാപരിശോധകൻ പുറത്തിറക്കുക. ഓർമ്മയെ ഡാറ്റാബേസായല്ല, നയപരമായ തീരുമാനങ്ങളായി പരിഗണിക്കുക. ഒന്നിലധികം ഏജന്റുകളിലേക്ക് മാറുമ്പോൾ ഇരുപതിൽനിന്നല്ല, രണ്ട് ഏജന്റുകളിൽനിന്ന് തുടങ്ങുക. ഇവ നിയമങ്ങളല്ല; പ്രൊഡക്ഷനിലെ പരീക്ഷണങ്ങളെ അതിജീവിച്ച മാതൃകകളാണ്.