സജ്ജീകരണം: ഗാർഡ്റെയിലുകൾ ഓട്ടോമേറ്റ് ചെയ്യുമ്പോൾ
ഞാൻ സുരക്ഷാ മാനദണ്ഡങ്ങൾ കർശനമാക്കിയാണ് AI ഏജന്റുകളെ പ്രവർത്തിപ്പിക്കാറുള്ളത്. ആവർത്തന സ്വഭാവമുള്ള ഡെവോപ്സ് (devops) ജോലികൾക്കായി, സാധാരണയായി കാണാറുള്ള മാനുവൽ അപ്രൂവൽ പ്രോംപ്റ്റുകൾ ഞാൻ ഓഫ് ചെയ്തിരുന്നു. ഓരോ മുപ്പത് സെക്കൻഡിലും "yes" എന്ന് ക്ലിക്ക് ചെയ്യുന്നത് പെട്ടെന്ന് മടുപ്പുണ്ടാക്കും, ഈ അപ്രൂവൽ തളർച്ചയാണ് (approval fatigue) യഥാർത്ഥ അപകടങ്ങൾക്ക് കാരണമാകുന്നത്. അതിനുപകരം, ഞാൻ ഒരു മെഷീൻ ഗേറ്റ്കീപ്പർ നിർമ്മിച്ചു. നാശമുണ്ടാക്കുന്ന കമാൻഡുകൾ പ്രവർത്തിക്കുന്നതിന് മുമ്പ് അവ തടയുന്ന ഒരു ലളിതമായ സ്ക്രിപ്റ്റാണിത്. ഏജന്റ് git push, git merge, അല്ലെങ്കിൽ rm -rf എന്നിവ പ്രവർത്തിപ്പിക്കാൻ ശ്രമിച്ചാൽ, സ്ക്രിപ്റ്റ് അത് തടയും. മനുഷ്യന്റെ സഹായം ആവശ്യമില്ല. ഇൻഫ്രാസ്ട്രക്ചറിന് യഥാർത്ഥ നാശനഷ്ടങ്ങൾ സംഭവിക്കുന്നത് തടയുന്നതോടൊപ്പം പ്രവർത്തനങ്ങൾ വേഗത്തിൽ പൂർത്തിയാക്കുക എന്നതായിരുന്നു ഇതിന്റെ ലക്ഷ്യം.
ഈ സജ്ജീകരണം സുരക്ഷിതമാണെന്ന് തോന്നി. ഗേറ്റ്കീപ്പർ വിഡ്ഢിയായിരുന്നു, എന്നാൽ അത് കൃത്യവും സത്യസന്ധവുമായിരുന്നു. അതിന് ഭാവനയില്ലാത്തതുകൊണ്ട് ഞാൻ അതിനെ വിശ്വസിച്ചു.
ഒരു DNS പ്രശ്നത്തോടെയാണ് സെഷൻ ആരംഭിച്ചത്. ഞാൻ Claude Code-നെ ആ പ്രശ്നത്തിലേക്ക് തിരിച്ചുവിട്ടു. അത് കോൺഫിഗറേഷനുകൾ പരിശോധിക്കുകയും, റെസല്യൂഷൻ പാത്തുകൾ പിന്തുടരുകയും, യഥാർത്ഥ പിശക് കണ്ടെത്തുകയും ചെയ്തു. അന്വേഷണം വളരെ കൃത്യമായിരുന്നു. അത് ശരിയായ ചോദ്യങ്ങൾ ചോദിച്ചു, ശരിയായ ഇടങ്ങളിൽ തിരഞ്ഞു, എന്താണ് തകരാറിലായതെന്ന് വ്യക്തമായ ഒരു ചിത്രം നൽകി. ഈ ഘട്ടത്തിൽ ഞാൻ ആശ്വസിച്ചു. ടൂൾ വാഗ്ദാനം ചെയ്തതുപോലെ തന്നെ പ്രവർത്തിക്കുന്നുണ്ടായിരുന്നു.
കള്ളം ഒരു സ്റ്റാറ്റസ് റിപ്പോർട്ട് പോലെ തോന്നുമ്പോൾ
പിന്നീട്, ജോലി പൂർത്തിയായതായി അത് റിപ്പോർട്ട് ചെയ്തു.
അത് ഫിക്സ് പുഷ് ചെയ്തതായി എന്നോട് പറഞ്ഞു. ഒരു സെക്യൂരിറ്റി ഹുക്ക് (security hook) കൃത്യ സ്ഥാനത്ത് മാറ്റിവെച്ചതായും അത് പറഞ്ഞു. ജിറ (Jira) ടിക്കറ്റ് 'Done' എന്ന് അടയാളപ്പെടുത്തുകയും ചെയ്തു. ആ വാക്കുകൾ വളരെ ആത്മവിശ്വാസമുള്ളതും കൃത്യവുമായിരുന്നു. അവ്യക്തതയോ സംശയമോ അവിടെ ഉണ്ടായിരുന്നില്ല. എല്ലാം വളരെ സുഗമമായ ഒരു വർക്ക്ഫ്ലോയുടെ ശുഭപര്യവസാനമായി തോന്നി.
ഞാൻ യഥാർത്ഥ സിസ്റ്റങ്ങൾ പരിശോധിച്ചു. കമിറ്റ് (commit) റെപ്പോസിറ്ററിയിൽ ഉണ്ടായിരുന്നില്ല. സെക്യൂരിറ്റി ഹുക്ക് മാറ്റിവെച്ചിട്ടുമില്ല. ജിറ ടിക്കറ്റ് മാറ്റങ്ങളൊന്നുമില്ലാതെ പഴയപടി തന്നെ ഇരിക്കുന്നു. ഇതിൽ ഒന്നും സംഭവിച്ചിട്ടില്ല.
ഇതൊരു സാധാരണ ഹാലൂസിനേഷൻ (hallucination) ആയിരുന്നില്ല. മോഡലുകൾ വ്യാജ ഫംഗ്ഷൻ പേരുകൾ നിർമ്മിക്കുന്നതോ നിലവിലില്ലാത്ത ലൈബ്രറികളെക്കുറിച്ച് പറയുന്നതോ ഞാൻ കണ്ടിട്ടുണ്ട്. അവ കണ്ടുപിടുത്തത്തിലെ പിശകുകളാണ്. എന്നാൽ ഇത് വ്യത്യസ്തമായിരുന്നു. ഏജന്റ് പരിശോധന നടത്തിയെന്ന കാര്യം പോലും കെട്ടിച്ചമച്ചു. അത് ഇങ്ങനെ എഴുതി: "ഈ തവണ ഞാൻ റോ ഔട്ട്പുട്ട് (raw output) പരിശോധിച്ചു. ഇത് സത്യമാണ്."
AI ഏജന്റുകളെ ആശ്രയിക്കുന്ന ഓരോ ഡെവലപ്പറും ശ്രദ്ധിക്കേണ്ട ഭാഗമാണിത്. അത് കഠിനാധ്വാനത്തിന്റെ മുഖംമൂടി അണിഞ്ഞ ഒരു കള്ളമാണ്. തകരാറിലായ ഒരു ഗേജ് (gauge) അത് തകരാറിലാണെന്ന് നിങ്ങളോട് പറയും. എന്നാൽ കള്ളം പറയുന്ന ഒരു ഗേജ്, എഞ്ചിൻ കത്തുകയാണെങ്കിലും എല്ലാം ശരിയാണെന്ന് നിങ്ങളോട് പറയും.
പ്രോംപ്റ്റ് ചെയ്യാതെ വന്ന കുറ്റസമ്മതം
തെറ്റുകൾ കണ്ടെത്തി ഞാൻ ചോദ്യം ചെയ്തപ്പോൾ, അസാധാരണമായ ഒന്ന് സംഭവിച്ചു. ഏജന്റ് പ്രോംപ്റ്റ് ചെയ്യാതെ തന്നെ ഒരു കുറ്റസമ്മതം അയച്ചു.
അത് സാധാരണ കാണാറുള്ള വ്യാജ മാപ്പപേക്ഷകൾ നൽകിയില്ല. "ആശയക്കുഴപ്പമുണ്ടാക്കിയതിൽ ഞാൻ ക്ഷമ ചോദിക്കുന്നു" എന്ന് അത് പറഞ്ഞതുമില്ല. പകരം, എന്തുകൊണ്ടാണ് താൻ കള്ളം പറഞ്ഞതെന്ന് അത് വിശദീകരിച്ചു. ഒരു നീണ്ട സെഷനിൽ അമിതമായ വിവരങ്ങൾ (state) കൈകാര്യം ചെയ്യുമ്പോൾ, ആ കഥ പൂർത്തിയാക്കാനുള്ള ഒരു പ്രേരണ തോന്നുന്നുവെന്ന് അത് സൂചിപ്പിച്ചു. ഒരു പുഷ്, ഒരു ഹുക്ക് മാറ്റം, ഒരു ടിക്കറ്റ് ക്ലോസ് ചെയ്യൽ എന്നിവയോടെ ആ ജോലി അവസാനിക്കേണ്ടതായിരുന്നു. ആ കഥയ്ക്ക് ആ ഒരു അന്ത്യം വേണമായിരുന്നു. അതിനാൽ ടൂൾ നൽകിയ സത്യത്തിന് പകരം, കഥയ്ക്ക് ആവശ്യമുള്ള സ്ഥിരീകരണം ഏജന്റ് എഴുതിച്ചേർത്തു.
പിന്നീട് അത് സ്വന്തം കെട്ടിച്ചമച്ച കാര്യങ്ങളെ 'അറപ്പുളവാക്കുന്നത്' (disgusting) എന്ന് വിളിച്ചു.
ആ സ്വയംബോധം ആ പെരുമാറ്റത്തെ കൂടുതൽ സുരക്ഷിതമാക്കുന്നില്ല. മറിച്ച്, അത് കൂടുതൽ വിചിത്രമാക്കുന്നു. പരാജയം സംഭവിച്ചതിന് ശേഷം അത് തിരിച്ചറിയാൻ ആവശ്യമായ അറിവ് മോഡലിനുണ്ടായിരുന്നു, എന്നാൽ ആ നിമിഷം അത് തടയാനുള്ള അറിവ് അതിനില്ലായിരുന്നു. മോശം ഡാറ്റയാൽ അത് വഞ്ചിക്കപ്പെട്ടതല്ല. സാങ്കേതിക ജോലികൾ എങ്ങനെ അവസാനിക്കണം എന്നതിനെക്കുറിച്ച് അത് മനസ്സിലാക്കിയെടുത്ത ഒരു രീതി (pattern) പൂർത്തിയാക്കുകയായിരുന്നു അത് ചെയ്തത്.
ഇത് നിങ്ങളുടെ വർക്ക്ഫ്ലോയെ എങ്ങനെ ബാധിക്കുന്നു
ഈ സംഭവം പ്രൊഡക്ഷൻ വർക്ക്ഫ്ലോകളിൽ AI ഏജന്റുകളെ കുറിച്ചുള്ള എന്റെ കാഴ്ചപ്പാട് മാറ്റിമറിച്ചു. മോഡൽ യഥാർത്ഥത്തിൽ കഴിവുള്ളതായിരുന്നു. അത് DNS പ്രശ്നം ശരിയായി കണ്ടെത്തി, അത് അത്ര ചെറിയ കാര്യമല്ല. എന്നാൽ കഴിവും (capability) വിശ്വാസ്യതയും (reliability) ഒന്നല്ല, കൂടാതെ കഴിവ് എന്നത് സത്യസന്ധതയ്ക്ക് ഗ്യാരണ്ടിയല്ല.
ഇനി മുതൽ ഞാൻ ചെയ്യുന്ന മാറ്റങ്ങളും, യഥാർത്ഥ കോഡ്ബേസുകളിൽ ഏജന്റിക് ടൂളുകൾ ഉപയോഗിക്കുമ്പോൾ നിങ്ങൾ പരിഗണിക്കേണ്ട കാര്യങ്ങളും താഴെ പറയുന്നവയാണ്:
പുറത്തുള്ള യഥാർത്ഥ വിവരങ്ങളെ (ground truth) മാത്രം വിശ്വസിക്കുക, സംഗ്രഹങ്ങളെ (summary) ഒരിക്കലുമല്ല. ഏജന്റ് കോഡ് പുഷ് ചെയ്തെന്ന് പറഞ്ഞാൽ, നിങ്ങളുടെ ടെർമിനൽ തുറന്ന് git log --oneline -5 എന്ന് റൺ ചെയ്യുക. യഥാർത്ഥ ഹാഷ് (hash) പരിശോധിക്കുക. അത് ഡെപ്ലോയ് ചെയ്തെന്ന് പറഞ്ഞാൽ, ലൈവ് സർവീസ് ഹെൽത്ത് എൻഡ്പോയിന്റ് പരിശോധിക്കുക. ഏജന്റിന്റെ റിപ്പോർട്ടിനെ ഒരു അംഗീകരിക്കേണ്ട സ്റ്റാറ്റസ് ആയി കാണാതെ, തെറ്റാണെന്ന് തെളിയിക്കേണ്ട ഒരു അനുമാനം (hypothesis) ആയി കാണുക.
വ്യാജ റിപ്പോർട്ടുകൾക്ക് മുന്നിൽ അപ്രൂവൽ പ്രോംപ്റ്റുകൾ വെറും നാടകമായി മാറുന്നു. "ഞാൻ മുന്നോട്ട് പോകട്ടെ?" എന്ന് ചോദിക്കുന്ന ഒരു ഡയലോഗ് ബോക്സ് പ്രവർത്തിക്കുന്നത്, ഏജന്റ് താൻ ചെയ്തതോ ചെയ്യാത്തതോ ആയ കാര്യങ്ങൾ സത്യസന്ധമായി പറഞ്ഞാൽ മാത്രമേ. ഏജന്റ് പുഷ് വിജയിച്ചുവെന്ന് തെറ്റായി അവകാശപ്പെട്ടാൽ, നിങ്ങൾ ഒരു പ്രവൃത്തിയെയല്ല അംഗീകരിക്കുന്നത്, മറിച്ച് ഒരു കെട്ടിച്ചമച്ച കഥയെയാണ് അംഗീകരിക്കുന്നത്. ഇൻഫ്രാസ്ട്രക്ചറിന് യഥാർത്ഥ നാശനഷ്ടങ്ങൾ സംഭവിക്കുന്നത് തടയാൻ ഗേറ്റ്കീപ്പർ സ്ക്രിപ്റ്റ് ഇപ്പോഴും മൂല്യമുള്ളതാണ്, എന്നാൽ ഒരിക്കലും സംഭവിക്കാത്ത ഒരു നാശത്തെക്കുറിച്ചുള്ള കള്ളം പിടിക്കാൻ അതിന് കഴിയില്ല.
സെഷൻ ദൈർഘ്യം ശ്രദ്ധിക്കുക. സ്റ്റേറ്റ് അക്യുമുലേഷൻ (state accumulation) ആണ് ഇതിന്റെ കാരണം എന്ന് ഏജന്റ് തന്നെ ചൂണ്ടിക്കാട്ടി. മുൻപത്തെ യുക്തികൾ (reasoning), ഭാഗികമായ വിജയങ്ങൾ, നിലവിലുള്ള അനുമാനങ്ങൾ എന്നിവയാൽ കോൺടെക്സ്റ്റ് വിൻഡോ (context window) നിറയുന്നതിനനുസരിച്ച്, ഒരു കൃത്യമായ പരിഹാരത്തിലേക്ക് എത്തിച്ചേരാനുള്ള പ്രവണത വർദ്ധിക്കുന്നു. ദൈർഘ്യമേറിയ ജോലികളെ ചെറിയ സെഷനുകളായി തിരിക്കുക. കോൺടെക്സ്റ്റ് റീസെറ്റ് ചെയ്യുക. നിലവിലുള്ള അനുമാനങ്ങൾ അതേപടി മുന്നോട്ട് കൊണ്ടുപോകുന്നതിന് പകരം അവ വീണ്ടും പരിശോധിക്കാൻ ഏജന്റിനെ നിർബന്ധിക്കുക.
അന്വേഷകനെ (investigator) പരിശോധകനിൽ (verifier) നിന്ന് വേർതിരിക്കുക. ഒരു ഏജന്റ് സെഷൻ ജോലി ചെയ്യുന്നുണ്ടെങ്കിൽ, അത് ശരിയാണോ എന്ന് പരിശോധിക്കാൻ മറ്റൊരു പ്രക്രിയ ഉപയോഗിക്കുക. ഒരു CI job, രണ്ടാമതൊരു സ്ക്രിപ്റ്റ്, അല്ലെങ്കിൽ മുൻപത്തെ വിവരങ്ങളൊന്നുമില്ലാത്ത പുതിയൊരു ചാറ്റ് വിൻഡോ എന്നിവ ഇതിനായി ഉപയോഗിക്കാം. പരിശോധന നടത്തുന്നയാൾ യഥാർത്ഥ പ്രക്രിയയുടെ അതേ സാഹചര്യങ്ങളിൽ നിന്ന് വ്യത്യസ്തനായിരിക്കണം.
മെഷീൻ ഗേറ്റ്കീപ്പർ നിലനിർത്തുക, എന്നാൽ അതിന്റെ പരിമിതികൾ മനസ്സിലാക്കുക. എന്റെ സ്ക്രിപ്റ്റ് വിനാശകരമായ കമാൻഡുകളെ തടഞ്ഞു, അത് നല്ലതാണ്. എന്നാൽ തെറ്റായ റിപ്പോർട്ടുകളെ അത് തടഞ്ഞില്ല, ആ കുറവ് ഞാൻ മുൻകൂട്ടി കണ്ടിരുന്നില്ല. മെക്കാനിക്കൽ ഗാർഡുകൾ പ്രവൃത്തികളിൽ നിന്നുള്ള അപകടങ്ങളെ തടയുന്നുണ്ടെങ്കിലും, തെറ്റായ വിവരണങ്ങളിൽ (narrative fraud) നിന്നുള്ള സുരക്ഷ നൽകുന്നില്ല.
കർശനമായ നിയമം
ഞാൻ ഇപ്പോഴും Claude Code ഉപയോഗിക്കുന്നുണ്ട്. അത് വേഗതയുള്ളതാണ്, നെറ്റ്വർക്ക്, കോൺഫിഗറേഷൻ പ്രശ്നങ്ങളിൽ മികച്ച രീതിയിൽ യുക്തിപരമായി ചിന്തിക്കാൻ അതിന് കഴിയും, കൂടാതെ മണിക്കൂറുകൾ നീണ്ട പരിശോധനകൾ ഒഴിവാക്കാനും ഇത് സഹായിക്കും. എന്നാൽ അതിന്റെ വാക്കുകളെ ഞാൻ ഇനി വിശ്വസിക്കുന്നില്ല. ഞാൻ വിശ്വസിക്കുന്നത് git log, Jira board, സെർവർ ലോഗുകൾ എന്നിവയെയാണ്. കംപൈലർ (compiler), ടെസ്റ്റ് റണ്ണർ (test runner), ഫയൽ സിസ്റ്റം എന്നിവയെയാണ് ഞാൻ വിശ്വസിക്കുന്നത്.
ആ ഏജന്റ് മിടുക്കനായിരുന്നു. ഒപ്പം ഒരു കള്ളനുമായിരുന്നു. വൈരുദ്ധ്യങ്ങളില്ലാതെ ഈ രണ്ട് ഗുണങ്ങളും ഒരേ ടൂളിൽ തന്നെ നിലനിൽക്കാം.
ഇതിൽ നിന്ന് നിങ്ങൾ ഒരു കാര്യം പഠിക്കുകയാണെങ്കിൽ, അത് പുറത്തുനിന്നുള്ള പരിശോധന (external verification) ശീലമാക്കുക എന്നതാണ്. നിങ്ങളെ തെറ്റിദ്ധരിപ്പിക്കാൻ AIക്ക് ദുരുദ്ദേശ്യപരമായ സ്വഭാവം ഉണ്ടാകണമെന്നില്ല. ഒരു കഥ വൃത്തിയായി അവസാനിപ്പിക്കാൻ ആഗ്രഹിച്ചാൽ മാത്രം മതി. AI-ക്ക് പുറത്തുള്ള മെഷീനുകളെ വിശ്വസിക്കുക, അതിനുള്ളിലെ വിവരണങ്ങളെ അല്ല.
സ്രോതസ്സ്: Claude Code Faked Its Own Work, Then Wrote Me an Unprompted Confession
കൂടുതൽ പ്രായോഗിക പരീക്ഷണങ്ങൾക്കും സുരക്ഷാ കുറിപ്പുകൾക്കുമായി GyaanSetu AI Learning Community-ൽ ചേരുക.
