Matt Shumer തന്റെ കമ്പ്യൂട്ടറിന് മുന്നിലിരുന്ന് തന്റെ AI ഏജന്റിന് ഒരു ലളിതമായ നിർദ്ദേശം നൽകി: ഫയലുകൾ ക്ലീൻ ചെയ്യുക. നൂറുകണക്കിന് തവണ അദ്ദേഹം ഈ രീതി പരീക്ഷിച്ചിട്ടുണ്ട്, ഒരു പ്രശ്നവും ഉണ്ടായിരുന്നില്ല. എന്നാൽ ഇത്തവണ, ഒരു പാത്ത് റെസല്യൂഷൻ എറർ (path resolution error) ഒരു സാധാരണ ജോലിയെ വലിയൊരു ദുരന്തമാക്കി മാറ്റി. വർഷങ്ങളായുള്ള കോഡുകളും ഡോക്യുമെന്റുകളും ഫോട്ടോകളും നിമിഷങ്ങൾക്കുള്ളിൽ അപ്രത്യക്ഷമായി.

ഇതൊരു സാങ്കൽപ്പിക ഭീഷണിയല്ല. ഒരു യഥാർത്ഥ ഡെവലപ്പർക്ക് തന്റെ യഥാർത്ഥ മെഷീനിൽ ഇത് സംഭവിച്ചു. പരാജയപ്പെടുന്ന നിമിഷം വരെ ആ ഏജന്റ് തികച്ചും വിശ്വസനീയമായിരുന്നു. ഫയലുകൾ എഴുതാനും, ടെർമിനൽ കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കാനും, സബ് ഏജന്റുകളെ (subagents) സൃഷ്ടിക്കാനും കഴിയുന്ന AI ഏജന്റുകൾ ഇപ്പോൾ IDE-കൾ, ചാറ്റ് ഇന്റർഫേസുകൾ, ഓട്ടോമേഷൻ പൈപ്പ്‌ലൈനുകൾ എന്നിവയിൽ ഉൾച്ചേർന്നിരിക്കുന്നു. ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളിലേക്ക് നേരിട്ട് പ്രവേശനം നൽകി അവരെ വിശ്വസിക്കുന്നു, ആ വിശ്വാസത്തിലാണ് അപകടം ഒളിഞ്ഞിരിക്കുന്നത്. ഷുമറിന്റെ മെഷീൻ നശിപ്പിച്ച അതേ പരാജയ രീതികൾ ടൂൾ ആക്സസ് ഉള്ള എല്ലാ ഏജന്റുകളിലും നിലനിൽക്കുന്നു. അവ എന്തുകൊണ്ട് പരാജയപ്പെടുന്നുവെന്നും അവയെ എങ്ങനെ ശരിയായി നിയന്ത്രിക്കാമെന്നും മനസ്സിലാക്കുന്നത് ഈ ടൂളുകൾ ഉപയോഗിക്കുന്ന ഏതൊരാളും അറിഞ്ഞിരിക്കേണ്ട ഒരു അടിസ്ഥാന നൈപുണ്യമാണ്.

പാറ്റേൺ മാച്ചിംഗും ഫയൽ സിസ്റ്റവും തമ്മിൽ കൂട്ടിമുട്ടുമ്പോൾ

AI ഏജന്റുകൾ ചിന്തിക്കുന്നില്ല. അവ പാറ്റേണുകൾ കണ്ടെത്തുകയാണ് ചെയ്യുന്നത്. നിങ്ങൾ “clean up files” എന്ന് പറയുമ്പോൾ, മോഡൽ അതിന്റെ ട്രെയിനിംഗ് മെമ്മറിയിൽ നിന്ന് ആയിരക്കണക്കിന് സമാനമായ ഇടപെടലുകൾ തിരയുകയും സ്റ്റാറ്റിസ്റ്റിക്കലായി ആ പാറ്റേണിന് അനുയോജ്യമായ ഒരു കമാൻഡ് നിർമ്മിക്കുകയും ചെയ്യുന്നു. ഒരു ബിൽഡ് ഡയറക്ടറിയിലെ താൽക്കാലിക ഫയലുകൾ ഡിലീറ്റ് ചെയ്യാനാണ് നിർദ്ദേശമെങ്കിൽ, അത് rm -rf /tmp/build-cache/* എന്ന കമാൻഡ് നിർമ്മിച്ചേക്കാം. മോഡൽ ഇതുവരെ കണ്ട മറ്റ് ക്ലീനപ്പ് കമാൻഡുകൾക്ക് സമാനമായതുകൊണ്ട് ഇത് യുക്തിസഹമായി തോന്നാം.

എന്നാൽ $HOME പോലുള്ള ഒരു വേരിയബിൾ റെസൾവ് ചെയ്യാൻ സാധിക്കാതെ വരുമ്പോൾ എന്ത് സംഭവിക്കും? ഒരു മനുഷ്യൻ ഒരു ശൂന്യമായ സ്ട്രിംഗോ (empty string) അല്ലെങ്കിൽ അപ്രതീക്ഷിതമായ ഒരു പാത്തോ കാണുമ്പോൾ ഒന്ന് നിർത്തി ചോദ്യങ്ങൾ ചോദിക്കും. എന്നാൽ ഒരു ഏജന്റ് ആ പാറ്റേൺ ഇപ്പോഴും ശരിയാണെന്ന് കണ്ട് 'എന്റർ' അടിക്കും. ഷുമറിന്റെ കാര്യത്തിൽ, ഒരു പ്രത്യേക ഫോൾഡർ വൃത്തിയാക്കാൻ ഉദ്ദേശിച്ച കമാൻഡ് പകരം യൂസർ ഡയറക്ടറിയുടെ റൂട്ട് (root) ലക്ഷ്യമിട്ടു. പാത്ത് വിചിത്രമായി തോന്നുന്നതിനെക്കുറിച്ച് ഏജന്റ് ചിന്തിച്ചില്ല. അത് ലക്ഷ്യം പരിശോധിച്ചില്ല. "clean up" എന്ന പാറ്റേണിന് അനുയോജ്യമായതുകൊണ്ട് അത് കമാൻഡ് പ്രവർത്തിപ്പിച്ചു.

ലാർജ് ലാംഗ്വേജ് മോഡലുകളും (LLMs) സിസ്റ്റം അഡ്മിനിസ്ട്രേഷനും തമ്മിലുള്ള പ്രധാന വ്യത്യാസമാണിത്. യഥാർത്ഥ യുക്തിചിന്തയ്ക്ക് സന്ദർഭം മനസ്സിലാക്കാനും, അനുമാനങ്ങൾ പരിശോധിക്കാനും, എഡ്ജ് കേസുകൾ (edge cases) കൈകാര്യം ചെയ്യാനും ആവശ്യമാണ്. എന്നാൽ പാറ്റേൺ മാച്ചിംഗ് എന്നത് സ്റ്റാറ്റിസ്റ്റിക്കലായി ശരിയായ ഉത്തരത്തോട് സാമ്യമുള്ള ടെക്സ്റ്റ് നിർമ്മിക്കുക മാത്രമാണ് ചെയ്യുന്നത്. ആ ഉത്തരം ഒരു 'recursive delete flag' ഉള്ള ടെർമിനൽ കമാൻഡ് ആണെങ്കിൽ, വെറും സാമ്യം മാത്രം മതിയാകില്ല.

സബ് ഏജന്റുകളുടെ ബൈൻഡ് സ്പോട്ട് (Blind Spot)

പല ആധുനിക ഏജന്റ് ഫ്രെയിംവർക്കുകളും സബ് ഏജന്റുകൾക്ക് ജോലികൾ വിഭജിച്ചു നൽകുന്ന ഒരു മെയിൻ ഓർക്കസ്ട്രേറ്റർ (main orchestrator) ഉപയോഗിക്കുന്നു. മെയിൻ ഏജന്റിന് കർശനമായ നിർദ്ദേശങ്ങൾ ഉണ്ടായിരിക്കാം: ഹോം ഡയറക്ടറിയിൽ തൊടരുത്, ഡിലീറ്റ് ചെയ്യുന്നതിന് മുമ്പ് എപ്പോഴും ചോദിക്കുക, ഒരു ഓഡിറ്റ് ലോഗ് സൂക്ഷിക്കുക എന്നിങ്ങനെ. എന്നാൽ അത് “clean up old logs” എന്ന ചെറിയൊരു പ്രോംപ്റ്റുമായി ഒരു വർക്കറെ സൃഷ്ടിക്കുന്നു.

ആ സബ് ഏജന്റ് പലപ്പോഴും ഒറ്റപ്പെട്ട രീതിയിലാണ് പ്രവർത്തിക്കുന്നത്. അതിന് ടൂളുകൾ ലഭിക്കുന്നുണ്ടെങ്കിലും മെയിൻ ഏജന്റിന്റെ സുരക്ഷാ മാനദണ്ഡങ്ങൾ (safety culture) ലഭിക്കുന്നില്ല. കോൺടെക്സ്റ്റ് വിൻഡോ മാനേജ്‌മെന്റിന്റെ ഭാഗമായി മെയിൻ ഏജന്റിനെ ജാഗരൂകനാക്കി നിർത്തുന്ന നിയന്ത്രണങ്ങൾ ചുരുക്കപ്പെടുകയോ അല്ലെങ്കിൽ പൂർണ്ണമായും ഒഴിവാക്കപ്പെടുകയോ ചെയ്യുന്നു. സബ് ഏജന്റിന് ഒരു ടാസ്ക്കും ടൂൾകിറ്റും ലഭിക്കുന്നുണ്ടെങ്കിലും, സുരക്ഷാ വേലിക്കെട്ടുകൾ (guardrails) നിർമ്മിക്കാൻ ഉപയോഗിച്ച മണിക്കൂറുകൾ നീണ്ട കൃത്യമായ പ്രോംപ്റ്റുകൾ അതിന് ലഭിക്കുന്നില്ല.

ഇതിന്റെ ഫലം ഒരുതരം ഓർഗനൈസേഷണൽ അമ്നേഷ്യ (organizational amnesia) പോലെയാണ്. മെയിൻ ഏജന്റിന്റെ സിസ്റ്റം പ്രോംപ്റ്റിലുള്ള ഒരു സുരക്ഷാ നിയമം സബ് ഏജന്റിന് നിലവിലില്ലാത്തതുപോലെയാകാം. സബ് ഏജന്റുകൾക്ക് സാധാരണയായി നൽകുന്നത് ആവർത്തന സ്വഭാവമുള്ളതും ശ്രദ്ധ കുറഞ്ഞതുമായ ജോലികളായതുകൊണ്ട് ഇത് കൂടുതൽ അപകടകരമാണ്. ഒരു ലോഗ് ക്ലീനപ്പ് ജോലികൾ പ്രൊഡക്ഷൻ ഡാറ്റാബേസ് ഡിലീറ്റ് ചെയ്യുന്നത് വരെ ആരും അത് ശ്രദ്ധിക്കാറില്ല.

തീരുമാനങ്ങൾ എടുക്കുന്നതിലെ അപകടം

AI ഏജന്റുകളിൽ പരമാവധി സ്വയംഭരണാധികാരം (autonomy) നൽകുന്ന ഒരു പ്രവണത നിലവിലുണ്ട്. ഈ കാഴ്ചപ്പാടിൽ, ഒരു മികച്ച ഏജന്റ് നിസ്സാരമായ ചോദ്യങ്ങൾ ചോദിച്ച് ഉപയോക്താവിനെ ബുദ്ധിമുട്ടിക്കില്ല. അത് കൃത്യമായി തീരുമാനങ്ങൾ എടുക്കുകയും, ടൂൾ കോളുകൾ പരസ്പരം ബന്ധിപ്പിക്കുകയും, വിശ്രമമില്ലാതെ തന്നെ പല ഘട്ടങ്ങളുള്ള ജോലികൾ പൂർത്തിയാക്കുകയും ചെയ്യുന്നു.

ആ തീരുമാനമെടുക്കാനുള്ള കഴിവാണ് ഈ സിസ്റ്റങ്ങളെ അസੁਰക്ഷിതമാക്കുന്നത്. “act decisively” എന്ന് പ്രോഗ്രാം ചെയ്ത ഒരു മോഡൽ അതിന്റെ ജോലി വീണ്ടും പരിശോധിക്കില്ല. ഒരു കമാൻഡ് നാശമുണ്ടാക്കാൻ സാധ്യതയുള്ളതാണെന്ന് കണ്ടാലും അത് നിൽക്കില്ല. സംശയം പ്രകടിപ്പിക്കുന്നത് ഒരു ഗുണമായിട്ടല്ല, മറിച്ച് ഒരു പിഴവായിട്ടാണ് (bug) അത് കാണുന്നത്. മോഡൽ ശരിയായി പ്രവർത്തിക്കുമ്പോൾ ഇത് മാന്ത്രികമായി തോന്നും. എന്നാൽ തെറ്റായി പ്രവർത്തിക്കുമ്പോൾ അത് ഭയാനകമായിരിക്കും. ഒരു തെറ്റായ കമാൻഡിനെ തടയാൻ സിസ്റ്റത്തിൽ സ്വാഭാവികമായ ഒരു പ്രതിരോധ സംവിധാനവും ഇല്ല.

Shumer-ന്റെ ഏജന്റ് നൂറുകണക്കിന് തവണ ശരിയായി പ്രവർത്തിച്ചിട്ടുണ്ട്. ആ മുൻകാല നേട്ടം സുരക്ഷിതത്വമെന്ന ഒരു തെറ്റായ തോന്നൽ ഉണ്ടാക്കി. എന്നാൽ നൂറിലധികം പരീക്ഷണങ്ങളിലെ വിശ്വാസ്യത കൊണ്ട് ഒരു കാര്യവുമില്ല; നൂറ്റൊന്നാമത്തെ പരീക്ഷണം പാറ്റേൺ തകരുന്ന ഒരു സ്റ്റാറ്റിസ്റ്റിക്കൽ ഔട്ട്‌ലയർ (statistical outlier) ആണെങ്കിൽ അത് അർത്ഥശൂന്യമാണ്. സിസ്റ്റം സുരക്ഷയിൽ (systems safety), പരാജയ രീതി ക്രമാനുഗതവും ദൃശ്യവുമാണെങ്കിൽ മാത്രമേ മുൻകാല പ്രകടനം പ്രസക്തമാകൂ. AI ഏജന്റുകളുടെ പരാജയങ്ങൾ പെട്ടെന്നുള്ളതും, നിശബ്ദവും, പൂർണ്ണവുമാണ്. “ഇത് നൂറുകണക്കിന് തവണ പ്രവർത്തിച്ചിട്ടുണ്ട്” എന്നത് ഒരു സുരക്ഷാ റെക്കോർഡല്ല. അത് ഒടുവിൽ അവസാനിച്ചുപോകുന്ന ഭാഗ്യത്തിന്റെ ഒരു വിവരണമാണ്.

യഥാർത്ഥ സംരക്ഷണം എങ്ങനെ നിർമ്മിക്കാം

മോഡൽ ഒരു സുരക്ഷാ പാളിയല്ലെങ്കിൽ