ഒരു AI-ജനറേറ്റഡ് എക്സ്പ്ലനേഷൻ ഫീച്ചറിലെ (AI-generated explanation feature) ഒരു സിംഗിൾ സേഫ്റ്റി-ഗേറ്റ് മെട്രിക് (safety-gate metric), ഒരു ദിവസം നീണ്ടുനിന്ന തകരാറിനെ മറച്ചുവെച്ചതായി ഞാൻ കണ്ടെത്തി. "ഗേറ്റ് റിജക്ഷൻ" (gate rejection), "മോഡൽ ലോഡ് ഫെയിലിയർ" (model load failure) എന്നിവ ഒന്നുതന്നെയായി പരിഗണിച്ചതിനാൽ, സിസ്റ്റം സുഗമമായി പ്രവർത്തിക്കുന്നു എന്ന തെറ്റായ തോന്നൽ ആ മെട്രിക് നൽകി. അത് നാല് റിജക്ഷനുകൾ രേഖപ്പെടുത്തിയിട്ടുണ്ടെങ്കിലും വിജയകരമായ പ്രവർത്തനങ്ങൾ പൂജ്യമായിരുന്നു—ആ സമയത്ത് മോഡൽ ഒരിക്കൽ പോലും പ്രവർത്തിച്ചിരുന്നില്ല. ഇത് ഒരു വലിയ പിഴവാണ്, സിസ്റ്റം തകരാറിലായ കാര്യം ഓപ്പറേറ്റർമാർ അറിയാതിരിക്കാൻ ഇത് കാരണമായേനെ.
ഈ ആശയക്കുഴപ്പം എങ്ങനെ സംഭവിച്ചു
യന്ത്രങ്ങളുടെ ലോജിക് (machine logic) മനുഷ്യർക്ക് വായിച്ചു മനസ്സിലാക്കാൻ കഴിയുന്ന വാചകങ്ങളാക്കി മാറ്റാൻ ഈ ഫീച്ചർ ഒരു ലോക്കൽ ലാംഗ്വേജ് മോഡൽ ഉപയോഗിക്കുന്നു. മുൻകൂട്ടി നിശ്ചയിച്ച നിയമങ്ങൾ ലംഘിക്കുന്ന ഔട്ട്പുട്ടുകളെ ഒരു സേഫ്റ്റി ഗേറ്റ് (safety gate) തടയുന്നു. പ്രൊഡക്ഷനിൽ, ഗേറ്റ് ഒരു വാചകം നിരസിക്കുമ്പോഴെല്ലാം വർദ്ധിക്കുന്ന ഒരു സിംഗിൾ കൗണ്ടർ ഞാൻ ഉപയോഗിച്ചിരുന്നു. ഡ്രോൺ നാല് AI വിശദീകരണങ്ങൾ രേഖപ്പെടുത്തിയപ്പോൾ, കൗണ്ടർ നാല് റിജക്ഷനുകളും വിജയകരമായ ഔട്ട്പുട്ടുകൾ ഒന്നുമില്ലെന്നും റിപ്പോർട്ട് ചെയ്തു. ഗേറ്റ് അതിന്റെ ജോലി കൃത്യമായി ചെയ്യുന്നു എന്നാണ് ഞാൻ കരുതിയത്, അല്ലാതെ ഫീച്ചർ പ്രവർത്തനരഹിതമാണെന്ന് ഞാൻ ചിന്തിച്ചില്ല.
ആ കൗണ്ടർ മറച്ചുവെച്ചത് രണ്ട് ഘട്ടങ്ങളിലായുള്ള ഒരു പരാജയമായിരുന്നു:
- മോഡൽ പ്രവർത്തിക്കുന്നില്ല – മോഡൽ സിസ്റ്റത്തിന്റെ മറ്റ് ഭാഗങ്ങളോടൊപ്പം ഒരു മെഷീൻ പങ്കിടുന്നു. മെമ്മറി ലാഭിക്കുന്നതിനായി, ഉപയോഗത്തിലില്ലാത്തപ്പോൾ ഹോസ്റ്റ് (host) അത് അൺലോഡ് ചെയ്യുന്നു.
- റീലോഡ് ചെയ്യുമ്പോൾ ടൈമൗട്ട് സംഭവിക്കുന്നു – ഒരു പുതിയ ഭീഷണി വന്നപ്പോൾ, സിസ്റ്റം ഏകദേശം രണ്ട് ഗിഗാബൈറ്റ് മോഡൽ ഡാറ്റ റീലോഡ് ചെയ്യാൻ ശ്രമിച്ചു. ഈ റീലോഡ് പ്രക്രിയ മുപ്പത് സെക്കൻഡ് മറുപടി നൽകാനുള്ള സമയപരിധിയെ (timeout) മറികടന്നു, അതിനാൽ റിക്വസ്റ്റ് ടൈമൗട്ട് ആകുകയും ശൂന്യമായ ഒരു ഉത്തരം നൽകുകയും ചെയ്തു.
ഗേറ്റ് റിജക്ഷനും ടൈമൗട്ട് കാരണം ഉണ്ടായ ശൂന്യമായ ഉത്തരവും ഒരേ സംഭവമായി കൗണ്ടർ കണക്കാക്കിയതിനാൽ, AI ഫീച്ചർ യഥാർത്ഥത്തിൽ പ്രവർത്തനരഹിതമായിരിക്കുമ്പോഴും ഡാഷ്ബോർഡ് ഒരു "പ്രവർത്തിക്കുന്ന സേഫ്റ്റി ഗേറ്റ്" ആണ് കാണിച്ചിരുന്നത്.
ഇത് എന്തുകൊണ്ട് പ്രധാനമാണ്
AI അധിഷ്ഠിത ഉൽപ്പന്നങ്ങളിൽ, ദോഷകരമോ അർത്ഥശൂന്യമോ ആയ ഔട്ട്പുട്ടുകളെ തടയാൻ സേഫ്റ്റി ഗേറ്റുകൾ ഉപയോഗിക്കുന്നു. ഓപ്പറേറ്റർമാർ സിസ്റ്റത്തിന്റെ ആരോഗ്യം മനസ്സിലാക്കാൻ ഗേറ്റിന്റെ ഫയർ റേറ്റ് (fire rate) നിരീക്ഷിക്കുന്നു. ആ സിഗ്നൽ മറ്റ് പരാജയങ്ങളുമായി കലരുമ്പോൾ, ആ മെട്രിക് ഒരു നിശബ്ദമായ കള്ളമായി മാറുന്നു: സേവനം ലഭ്യമാകാതിരിക്കുമ്പോഴും അത് എല്ലാം ശരിയാണെന്ന് തോന്നിപ്പിക്കുന്നു.
കാഴ്ചപ്പാട് വീണ്ടെടുത്ത പരിഹാരം
ഞാൻ മൂന്ന് പ്രായോഗിക മാറ്റങ്ങൾ വരുത്തി:
- മോഡൽ മെമ്മറിയിൽ നിലനിർത്തുക – റീലോഡ് വൈകുന്നത് ഒഴിവാക്കാൻ മോഡൽ മെമ്മറിയിൽ തന്നെ നിലനിർത്താൻ ഹോസ്റ്റിനെ ക്രമീകരിച്ചു.
- ടൈമൗട്ട് സമയം വർദ്ധിപ്പിക്കുക – ഇടയ്ക്കിടെ ഉണ്ടാകുന്ന സാവധാനത്തിലുള്ള ലോഡുകൾ കൈകാര്യം ചെയ്യാൻ മറുപടി നൽകാനുള്ള സമയപരിധി വർദ്ധിപ്പിച്ചു.
- കൗണ്ടർ വിഭജിക്കുക – ഒറ്റപ്പെട്ട "rejected by gate" മെട്രിക് മാറ്റി പകരം നാല് വ്യത്യസ്ത കൗണ്ടറുകൾ ഉപയോഗിച്ചു: accepted, rejected, empty response, പിന്നെ no answer.
മൂന്നാമത്തെ ഘട്ടമാണ് നിർണ്ണായകമായത്. ഒരു സംശയം ഉണ്ടാക്കുന്ന ഒറ്റ സംഖ്യയ്ക്ക് പകരം, ഈ നാല് ഭാഗങ്ങളുള്ള വിഭജനം സേഫ്റ്റി ഗേറ്റ് സജീവമാണോ, മോഡൽ മറുപടി നൽകുന്നുണ്ടോ, അതോ റിക്വസ്റ്റ് മോഡലിൽ എത്തുന്നില്ലേ എന്ന് വ്യക്തമായി കാണിക്കുന്നു.
Trade-offs and counter-arguments
ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
AI ഘടകങ്ങൾ പുറത്തിറക്കുന്ന ഡെവലപ്പർമാർ, സേഫ്റ്റി ചെക്കുകളും സിസ്റ്റം തലത്തിലുള്ള പരാജയങ്ങളും കൂട്ടിച്ചേർത്ത് കാണിക്കുന്ന അഗ്രഗേറ്റഡ് കൗണ്ടറുകൾ (aggregated counters) പരിശോധിക്കേണ്ടതുണ്ട്. ഓരോ റിക്വസ്റ്റും കടന്നുപോകുന്ന പാത—മോഡൽ ലോഡ് ആരംഭിക്കുന്നത്, ഗേറ്റ് മൂല്യനിർണ്ണയം, അന്തിമ ഫലം—എന്നിവ രേഖപ്പെടുത്തുന്ന വിശദമായ ഹിസ്റ്ററി ലോഗ് നിർമ്മിക്കുന്നത് ഒളിഞ്ഞിരിക്കുന്ന പ്രശ്നങ്ങൾ കണ്ടെത്താൻ ആവശ്യമായ ഫോറൻസിക് ഡാറ്റ (forensic data) നൽകും.
പ്രധാന പാഠം: ഒരു സിംഗിൾ "gate-rejection" മെട്രിക് ഒരു പ്രവർത്തനരഹിതമായ AI സർവീസിനെ മറച്ചുവെച്ചേക്കാം; ആ മെട്രിക് അതിന്റെ ഘടകങ്ങളായി വിഭജിക്കുന്നത് സത്യം വെളിപ്പെടുത്തുകയും യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കാത്ത ഒരു സിസ്റ്റത്തിൽ തെറ്റായ ആത്മവിശ്വാസം ഉണ്ടാകുന്നത് തടയുകയും ചെയ്യുന്നു.