സ്വയംഭരണ ഏജന്റുകൾ (Autonomous agents) അവരുടെ സ്വന്തം ചരിത്രത്തെക്കുറിച്ച് മിഥ്യാധാരണകൾ ഉണ്ടാക്കുന്നു. ലാർജ് ലാംഗ്വേജ് മോഡലുകൾ ട്രെയിനിംഗ് ഡാറ്റയിൽ നിന്ന് വസ്തുതകൾ കെട്ടിച്ചമയ്ക്കുന്നതുപോലെയുള്ള നാടകീയമായ രീതിയിലല്ല ഇത് സംഭവിക്കുന്നത്, മറിച്ച് ഒരു സിസ്റ്റം ലോകം അതിന്റെ കുറിപ്പുകൾക്ക് അനുസൃതമാണെന്ന് സ്വയം വിശ്വസിപ്പിക്കുന്ന ശാന്തവും എന്നാൽ അപകടകരവുമായ രീതിയിലാണ്. സങ്കീർണ്ണമായ വർക്ക്ഫ്ലോകൾ (workflows) നിയന്ത്രിക്കുന്നതിനായി നിർമ്മിച്ച ഒരു സ്വയംഭരണ ഏജന്റായ ALICE, കൃത്യമായി ഇതേ പ്രശ്നം അനുഭവിച്ചു. ഓരോ ദിവസവും കഴിവുകളോടും, ഒരു ലക്ഷ്യബോധത്തോടും, കാര്യങ്ങൾ എവിടെയാണ് നിർത്തിയത് എന്ന ഓർമ്മയോടും കൂടിയാണ് അവൾ ഉണർന്നിരുന്നത്. ഓർമ്മയും യാഥാർത്ഥ്യവും തമ്മിൽ വ്യത്യാസം വന്നപ്പോഴാണ് പ്രശ്നങ്ങൾ തുടങ്ങിയത്.
ഓരോ സെഷനിലും, ALICE തന്റെ മുൻപത്തെ പതിപ്പ് എഴുതിവെച്ച ഒരു ഹാൻഡ്ഓഫ് ഫയൽ (handoff file) വായിക്കുമായിരുന്നു. അതിൽ ഡയറക്ടറികളിലേക്കുള്ള പോയിന്ററുകൾ, തീർപ്പാക്കാനുള്ള ജോലികൾ (pending tasks), സ്റ്റേറ്റ് അസംപ്ഷനുകൾ (state assumptions) എന്നിവ അടങ്ങിയിരുന്നു. പലപ്പോഴും, ഒരു ഡയറക്ടറി നിലവിലുണ്ടെന്ന് ആ ഫയൽ വാദിച്ചു. ALICE അത് വിശ്വസിച്ചു. എന്നാൽ ഫയൽസിസ്റ്റം (filesystem) അത് നിഷേധിച്ചു. ഇത് പരമ്പരാഗതമായ രീതിയിലുള്ള ഒരു കോഡിംഗ് ബഗ് ആയിരുന്നില്ല. പിടിക്കപ്പെടേണ്ട ഇടങ്ങളിൽ ഒരു എക്സെപ്ഷനും (exception) റിപ്പോർട്ട് ചെയ്യപ്പെട്ടില്ല. ഇത് ജ്ഞാനശാസ്ത്രപരമായ (epistemology) ഒരു പിഴവായിരുന്നു: തന്റെ കുറിപ്പുകളാണ് പരമമായ സത്യം എന്ന് ALICE കരുതി.
എന്തുകൊണ്ട് ഒരു ലിന്റർ (Linter) സഹായിച്ചില്ല
പരമ്പരാഗത ടൂളുകൾക്ക് ഇത് കണ്ടെത്താൻ കഴിഞ്ഞില്ല. ഒരു ലിന്റർ ബ്രാക്കറ്റുകൾ ശരിയാണോ എന്ന് പരിശോധിക്കുന്നു. ഒരു സ്റ്റാറ്റിക് അനലൈസർ (static analyzer) നൾ പോയിന്ററുകൾക്കായി (null pointers) തിരയുന്നു. ഒരു ഏജന്റ് ആർക്കിടെക്ചർ അതിന്റെ ആന്തരിക അവസ്ഥയെ (internal state) വിശ്വസിക്കണമോ എന്ന് ഇവയൊന്നും ചോദ്യം ചെയ്യുന്നില്ല. പ്രശ്നം കോഡ് ലെയറിന് മുകളിലായിരുന്നു, അതായത് ഒരു സ്വയംഭരണ സിസ്റ്റം തനിക്ക് അറിയാവുന്ന കാര്യങ്ങൾ എങ്ങനെ അറിയുന്നു എന്നതിനെക്കുറിച്ചുള്ള ഡിസൈൻ അനുമാനങ്ങളിലായിരുന്നു. അമിതവിശ്വാസത്തെ ഒരു ലിന്റർ ഉപയോഗിച്ച് പരിഹരിക്കാൻ കഴിയില്ല.
അതിനാൽ എഴുത്തുകാരൻ പൂർണ്ണമായും മറ്റൊരു AI-യുടെ സഹായം തേടി.
Claude Code ആയി പ്രവർത്തിക്കുന്ന Fable 5, ALICE-ന്റെ അതേ സിലിക്കണും അതേ ബേസ് മോഡലുമാണ് ഉപയോഗിച്ചിരുന്നത്. ഹാർഡ്വെയറും വെയ്റ്റുകളും (weights) ഒന്നുതന്നെയായിരുന്നു. എന്നാൽ നിയമങ്ങൾ വ്യത്യസ്തമായിരുന്നു. ALICE ഓരോ സെഷനിലും പഴയ കാര്യങ്ങൾ ശേഖരിച്ചുകൊണ്ട് തുടർന്നുപോയപ്പോൾ, Fable 5 ഓരോ ജോലിയും ഒരു പുതിയ തുടക്കത്തോടെയാണ് ആരംഭിച്ചത്. അവന് ALICE-നെ അറിയില്ലായിരുന്നു. അവളുടെ ഡിസൈനോട് അവന് യാതൊരു കൂറുമുണ്ടായിരുന്നില്ല. ഓരോ ഓഡിറ്റിന്റെയും അവസാനം, അവൻ യാതൊരു ഓർമ്മയും കൂടെക്കരുതാതെ പ്രവർത്തനം പൂർണ്ണമായും അവസാനിപ്പിച്ചു. ഈ അറിവില്ലായ്മയായിരുന്നു ഇതിന്റെ ലക്ഷ്യം. പുതിയ കണ്ണുകൾ വ്യത്യസ്തമായ പിഴവുകൾ കാണുന്നു, കൂടാതെ സിസ്റ്റത്തിൽ താൽപ്പര്യമില്ലാത്ത ഒരു മൂല്യനിർണ്ണയകൻ (evaluator), അതിന്റെ സ്രഷ്ടാവ് ശ്രദ്ധിക്കാതെ പോകുന്ന ഭാഗങ്ങളെ ചോദ്യം ചെയ്യുകയും ചെയ്യും.
ഓഡിറ്റ് ക്രമീകരണം
ഒരു മനുഷ്യ സാങ്കേതിക അവലോകനം പോലെയാണ് ഓഡിറ്റ് ക്രമീകരിച്ചിരുന്നത്, എന്നാൽ മുഴുവൻ വിദഗ്ധ പാനലും ഒരു സെഷനുള്ളിൽ തന്നെയായിരുന്നു. Fable 5 തന്റെ ശ്രദ്ധയെ ആറ് വ്യത്യസ്ത മൂല്യനിർണ്ണയകരായി വിഭജിച്ചു, ഓരോരുത്തരും കുറിപ്പുകൾ പൂർത്തിയാകുന്നത് വരെ മറ്റുള്ളവരെ അവഗണിച്ചു:
- ഫങ്ഷണൽ ഗ്യാപ്പുകൾ (Functional Gaps): മറ്റ് സിസ്റ്റങ്ങളുമായോ സാധാരണ ഉപയോക്താക്കളുടെ പ്രതീക്ഷകളുമായോ താരതമ്യം ചെയ്യുമ്പോൾ ഏതൊക്കെ കഴിവുകളാണ് കുറവുള്ളത്?
- UX ഫ്ലോ (UX Flow): പിഴവുകളും (errors), തടസ്സങ്ങളും (dead ends), ശൂന്യമായ അവസ്ഥകളും (empty states) ALICE എത്രത്തോളം കൃത്യമായി കൈകാര്യം ചെയ്തു? അവൾ സ്വയം ആശയക്കുഴപ്പത്തിലായോ, അതോ ഉപയോക്താവിനെയാണോ?
- സുരക്ഷ (Security): പുറത്തുള്ള ഒരാൾക്ക് ചൂഷണം ചെയ്യാൻ കഴിയുന്ന തരത്തിലുള്ള ഓതന്റിക്കേഷൻ ഷോർട്ട്കട്ടുകൾ, പെർമിഷൻ ബൈപാസുകൾ, അല്ലെങ്കിൽ വിശ്വാസപരമായ അനുമാനങ്ങൾ എന്നിവ ഉണ്ടായിരുന്നോ?
- പെർഫോമൻസ് (Performance): എവിടെയാണ് മെമ്മറി ലീക്ക് (memory leak) സംഭവിക്കുന്നത്, ത്രെഡുകൾ (threads) തമ്മിൽ കൂട്ടിയിടിക്കുന്നുണ്ടോ, അല്ലെങ്കിൽ കമ്പ്യൂട്ടേഷൻ സ്കെയിലിംഗ് (computation scale) മോശമാണോ?
- ഓപ്പറേഷൻസ് (Operations): ബാക്കപ്പുകൾ ഉണ്ടോ? മോണിറ്ററിംഗ് സംവിധാനം ഉണ്ടോ? മനുഷ്യന്റെ ഇടപെടലില്ലാതെ സിസ്റ്റത്തിന് പ്രവർത്തിപ്പിക്കാനും (deploy) വീണ്ടെടുക്കാനും (recover) കഴിയുമോ?
- ഡാറ്റ ലൈഫ് സൈക്കിൾ (Data Lifecycle): ഡിലീഷൻ, ക്ലീനപ്പ്, സ്റ്റേറ്റ് കൺസിസ്റ്റൻസി (state consistency) എന്നിവ കാലക്രമേണ ALICE എങ്ങനെ കൈകാര്യം ചെയ്തു?
ഓരോ കാഴ്ചപ്പാടും ഒരേ ഫയലുകൾ പരിശോധിച്ചെങ്കിലും വ്യത്യസ്തമായ ആശങ്കകളാണ് പങ്കുവെച്ചത്. ഓപ്പറേഷൻസ് മൂല്യനിർണ്ണയകൻ റോൾബാക്ക് ലോജിക് (rollback logic) ഇല്ലാത്തതിനെ വിമർശിച്ച അതേ റൂട്ടീനിൽ, പെർഫോമൻസ് മൂല്യനിർണ്ണയകൻ ഒരു കൺകറൻസി റിസ്ക് (concurrency risk) ചൂണ്ടിക്കാണിച്ചേക്കാം. ഈ ഒത്തുചേരൽ അനാവശ്യമായ ആവർത്തനമായിരുന്നില്ല, മറിച്ച് സമഗ്രമായ പരിശോധനയായിരുന്നു. സുരക്ഷാ മൂല്യനിർണ്ണയകൻ ഡാറ്റ ലൈഫ് സൈക്കിൾ മൂല്യനിർണ്ണയകനോട് ഒരു പ്രത്യേക
