പങ്കിട്ട ഒരു റെക്കോർഡ് ഇല്ലാതെ AI ഇൻസിഡന്റ് മാനേജ്‌മെന്റ് പരാജയപ്പെടുന്നു

AI ഏജന്റുകൾ ഇൻസിഡന്റ് റെസ്പോൺസ് (incident response) മേഖലയിലേക്ക് കടന്നുവരികയാണ്.

LangChain, PagerDuty, New Relic തുടങ്ങിയ കമ്പനികൾ SRE ഏജന്റുകൾ നിർമ്മിച്ചുവരികയാണ്. ഈ ടൂളുകൾക്ക് ട്രേസുകൾ (traces) വായിക്കാനും ലോഗുകൾ (logs) എടുക്കാനും അപ്‌ഡേറ്റുകൾ തയ്യാറാക്കാനും കഴിയും. അവ വേഗത്തിൽ പ്രവർത്തിക്കുന്നു. അവ മികച്ച കോൺടെക്സ്റ്റ് (context) നൽകുന്നു.

എന്നാൽ ഇതിലൊരു കെണിയുണ്ട്.

പല ടീമുകളും AI കോൺടെക്സ്റ്റിനെ ഒരു സ്വകാര്യ സ്ക്രാച്ച്പാഡ് (private scratchpad) പോലെയാണ് കാണുന്നത്. ഒരു റൂട്ട് കോസ് (root cause) കണ്ടെത്തുന്നതുപോലെയുള്ള മിറ്റിഗേഷൻ (mitigation) ജോലികൾക്കായി അവർ AI ഉപയോഗിക്കുന്നു. എന്നാൽ കോർഡിനേഷൻ ജോലികൾ അവർ മറന്നുപോകുന്നു.

ഇൻസിഡന്റ് മാനേജ്‌മെന്റ് എന്നത് ഒരു കാരണം കണ്ടെത്തുന്നതിനെക്കുറിച്ച് മാത്രമല്ല. അത് കോർഡിനേഷനെക്കുറിച്ചാണ്. താഴെ പറയുന്ന കാര്യങ്ങളിൽ ആളുകളെ യോജിക്കാൻ പ്രേരിപ്പിക്കുന്നതിനെക്കുറിച്ചാണത്:

  • എന്താണ് സംഭവിച്ചത്.
  • എന്താണ് മാറിയത്.
  • നിങ്ങൾ ഒഴിവാക്കിയ കാര്യങ്ങൾ.
  • അടുത്ത ഘട്ടം ആർക്കാണ് ഉത്തരവാദിത്തം.
  • ബിസിനസ്സിന് എന്താണ് അറിയേണ്ടത്.

ഈ വിവരങ്ങൾ ഒരു സ്വകാര്യ ചാറ്റിലോ ഏജന്റിന്റെ കുറിപ്പുകളിലോ മാത്രം ഒതുങ്ങിനിൽക്കുകയാണെങ്കിൽ, പ്രക്രിയ പരാജയപ്പെടും.

ഉപയോഗപ്രദമായ ഒരു AI ഇൻസിഡന്റ് റെക്കോർഡ് എന്നത് വെറുമൊരു ചാറ്റ് ലോഗ് അല്ല. അതൊരു സ്ട്രക്ചേർഡ് ഓപ്പറേഷണൽ ഒബ്‌ജക്റ്റ് (structured operational object) ആണ്. അതിൽ ഇവ ഉൾപ്പെടണം:

  • ട്രിഗർ (അലേർട്ട്, സർവീസ്, സെവറിറ്റി).
  • തെളിവുകൾ (ട്രേസുകൾ, ലോഗുകൾ, മെട്രിക്സ്, സമീപകാല ഡിപ്ലോയ്‌മെന്റുകൾ).
  • ഹൈപ്പോത്തിസസ് (എന്താണ് സംഭവിക്കുന്നതെന്ന് നിങ്ങൾ കരുതുന്നു, എന്തുകൊണ്ട്).
  • തള്ളിക്കളഞ്ഞ സിദ്ധാന്തങ്ങൾ (കാരണം അല്ലെന്ന് നിങ്ങൾ തെളിയിച്ച കാര്യങ്ങൾ).
  • തീരുമാനങ്ങളും അംഗീകാരങ്ങളും (എന്തുകൊണ്ട് നിങ്ങൾ റോൾബാക്ക് ചെയ്യാൻ അല്ലെങ്കിൽ കാത്തിരിക്കാൻ തീരുമാനിച്ചു).

ഈ ഘടന ഒരു സാധാരണ AI പരാജയത്തെ തടയുന്നു. ഒരു ഏജന്റ് ഒരു 'ഗ്രാവിറ്റി വെൽ' (gravity well) പോലെയാകാൻ സാധ്യതയുണ്ട്. അത് ഒരു സാധ്യതയുള്ള കാരണം കണ്ടെത്തി അതിൽ തന്നെ തങ്ങിനിൽക്കും. തുടർന്ന് ആ ഒരു സിദ്ധാന്തത്തെ പിന്തുണയ്ക്കുന്ന രീതിയിൽ എല്ലാ പുതിയ ഡാറ്റയെയും അത് വ്യാഖ്യാനിക്കും.

പങ്കിട്ടതും സ്ട്രക്ചേർഡ് ആയതുമായ ഒരു റെക്കോർഡ്, തെറ്റാണെന്ന് തെളിയിക്കുന്ന തെളിവുകൾ പരിശോധിക്കാൻ ടീമിനെ നിർബന്ധിക്കുന്നു. ഇത് ഏജന്റിന്റെ പക്ഷപാതം (bias) നിയന്ത്രിക്കാൻ സഹായിക്കുന്നു.

റെസ്പോണ്ടർമാർക്ക് (Responders) കൂടുതൽ ബഹളങ്ങളല്ല വേണ്ടത്. അവർക്ക് ഒരു പങ്കിട്ട അവസ്ഥ (shared state) ആണ് വേണ്ടത്. ഒരു പുതിയ വ്യക്തി ഒരു ഇൻസിഡന്റിൽ ചേരുമ്പോൾ, Slack-ൽ തിരഞ്ഞ് സമയം കളയേണ്ടി വരരുത്. നിലവിലെ ഹൈപ്പോത്തിസിസ്, തെളിവുകൾ, പെൻഡിംഗ് ആയ നടപടികൾ എന്നിവ അവർക്ക് ഉടൻ തന്നെ കാണാൻ കഴിയണം.

ആകർഷകമായ ഡെമോ കാണിക്കുന്ന ഒരു സ്വയംഭരണാധികാരമുള്ള (autonomous) റെസ്പോണ്ടർ ഉണ്ടാക്കുക എന്നതല്ല ലക്ഷ്യം. ഇൻസ്റ്റിറ്റ്യൂഷണൽ നോളജ് (institutional knowledge) അവശേഷിപ്പിക്കുന്ന ഒരു ടൂൾ ഉണ്ടാക്കുക എന്നതാണ് ലക്ഷ്യം.

ഏറ്റവും ബുദ്ധിയുള്ള മോഡലിനായി തിരയുന്നത് നിർത്തുക. ഒരു സ്ട്രക്ചേർഡ് റെക്കോർഡ് നിർമ്മിക്കാൻ തുടങ്ങുക.

  • ഇൻസിഡന്റുകൾക്കായി വ്യക്തമായ ഫീൽഡുകൾ നിർവചിക്കുക.
  • ഏജന്റുകൾക്ക് ഈ റെക്കോർഡ് സുരക്ഷിതമായി വായിക്കാനും എഴുതാനും അനുവദിക്കുക.
  • റെക്കോർഡ് ഡാറ്റ മാത്രമല്ല, തീരുമാനങ്ങളും രേഖപ്പെടുത്തുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക.
  • ഇൻസിഡന്റ് കുഴപ്പങ്ങളെ വീണ്ടും ഉപയോഗിക്കാവുന്ന അറിവായി മാറ്റാൻ ഈ റെക്കോർഡ് ഉപയോഗിക്കുക.

മനുഷ്യരായ ടീമിനെ ഒരൊറ്റ യൂണിറ്റായി പ്രവർത്തിപ്പിക്കാൻ സഹായിക്കുന്നതാണ് ഏറ്റവും മികച്ച AI ടൂൾ.

Source: https://dev.to/focused_dot_io/ai-incident-management-breaks-without-a-shared-record-focused-labs-1og5

Optional learning community: https://t.me/GyaanSetuAi