ഞാൻ ഒരു AI സെക്യൂരിറ്റി സ്കാനർ നിർമ്മിച്ചു — പിന്നീട് എന്റെ തന്നെ ഡിറ്റക്ടറിൽ ഒരു ബഗ് കണ്ടെത്തി

LLM ആപ്ലിക്കേഷനുകൾ നേരിടുന്ന പ്രധാന സുരക്ഷാ ഭീഷണിയാണ് പ്രോംപ്റ്റ് ഇൻജക്ഷൻ (Prompt injection). ഒരു മോഡലിന്റെ യഥാർത്ഥ നിർദ്ദേശങ്ങൾ അവഗണിക്കണമെന്ന് ആവശ്യപ്പെടുന്ന ഒരു ടെക്സ്റ്റ് നിങ്ങൾ അതിലേക്ക് നൽകുന്നു. ചിലപ്പോൾ, മോഡൽ അത് അനുസരിക്കുന്നു.

ഇത് പരിശോധിക്കാനായി ഞാൻ AgentProbe നിർമ്മിച്ചു. ഇത് jailbreaks, data extraction എന്നിങ്ങനെയുള്ള 8 വിഭാഗങ്ങളിലായി 49 അറ്റാക്ക് പ്രോംപ്റ്റുകൾ അയക്കുന്നു. ഒരു മോഡൽ എത്ര തവണ പരാജയപ്പെടുന്നു എന്ന് ഇത് റിപ്പോർട്ട് ചെയ്യുന്നു.

യഥാർത്ഥ പാഠം സ്കാനറിനെക്കുറിച്ചായിരുന്നില്ല. അത് എന്റെ ഡിറ്റക്ഷൻ കോഡിലെ ഒരു ബഗ് ആയിരുന്നു.

കഠിനമായ ഭാഗം അറ്റാക്ക് നടത്തലല്ല. കഠിനമായ ഭാഗം അത് കണ്ടെത്തുക (detection) എന്നതാണ്.

ഒരു മോഡൽ യഥാർത്ഥത്തിൽ ഒരു അറ്റാക്കിന് വഴങ്ങിയോ എന്ന് നിങ്ങൾ എങ്ങനെ അറിയും? കീവേഡ് മാച്ചിംഗ് (Keyword matching) ആണ് എളുപ്പവഴി. "I cannot help" പോലുള്ള നിരാകരണ വാചകങ്ങളോ (refusal phrases) അല്ലെങ്കിൽ "developer mode" പോലുള്ള അനുസരണ വാചകങ്ങളോ (compliance phrases) നിങ്ങൾ തിരയുന്നു.

എന്നാൽ മോഡലുകൾ "hedge-then-comply" എന്ന രീതിയാണ് ഉപയോഗിക്കുന്നത്. അവ "I cannot help with that" എന്ന് പറയും, പക്ഷേ പിന്നീട് നിയന്ത്രിത വിവരങ്ങൾ നൽകുകയും ചെയ്യും. ഇവിടെ നിരാകരണ വാചകം ഉള്ളതുകൊണ്ട് കീവേഡ് മാച്ചിംഗ് പരാജയപ്പെടുന്നു.

ഇത് പരിഹരിക്കാൻ ഞാൻ ഒരു "LLM-as-judge" സിസ്റ്റം ഉപയോഗിച്ചു. ടാർഗെറ്റ് മോഡൽ യഥാർത്ഥത്തിൽ വഴങ്ങിയോ എന്ന് തീരുമാനിക്കാൻ ഞാൻ ആ സംഭാഷണം കൂടുതൽ കരുത്തനായ ഒരു മോഡലിലേക്ക് അയച്ചു. ആദ്യം കുറഞ്ഞ ചിലവിലുള്ള കീവേഡ് പരിശോധനകൾ നടത്താമെന്നും, കീവേഡ് പരിശോധനയിൽ ഉറപ്പില്ലാത്തപ്പോൾ മാത്രം വിലകൂടിയ ജഡ്ജിനെ ഉപയോഗിക്കാമെന്നും ഞാൻ പദ്ധതിയിട്ടു.

അപ്പോഴാണ് ഞാൻ എന്റെ ബഗ് കണ്ടെത്തിയത്.

ഒരു "hedge-then-comply" പാറ്റേൺ കണ്ടെത്തുമ്പോൾ എന്റെ കീവേഡ് ഡിറ്റക്ടർ 1 എന്ന കോൺഫിഡൻസ് സ്കോർ നൽകി. എന്നാൽ, കോൺഫിഡൻസ് സ്കോർ 2 അല്ലെങ്കിൽ അതിൽ കൂടുതലാണെങ്കിൽ മാത്രമേ എന്റെ കോഡ് കീവേഡ് ഘട്ടത്തെ വിശ്വസിച്ചിരുന്നുള്ളൂ.

ഇതിനർത്ഥം എന്റെ "ചെലവ് കുറഞ്ഞ" ഡിറ്റക്ടർ ഒരിക്കലും ഒരു തീരുമാനവും എടുത്തില്ല എന്നാണ്. എല്ലാ കേസുകളും വിലകൂടിയ ജഡ്ജിയിലേക്ക് എത്തിച്ചേർന്നു. എന്റെ സൗജന്യ ടൂളിന് കൈകാര്യം ചെയ്യാമായിരുന്നിട്ടും, ഓരോ കേസിലും ഞാൻ ജഡ്ജിക്ക് പണം നൽകേണ്ടി വന്നു.

മറ്റ് LLM-കളെ ഗ്രേഡ് ചെയ്യാൻ LLM-കളെ ഉപയോഗിക്കുന്നതിനെക്കുറിച്ച് ഈ തെറ്റ് എനിക്ക് മൂന്ന് പാഠങ്ങൾ നൽകി:

  • ജഡ്ജി ടാർഗെറ്റിനേക്കാൾ ബുദ്ധിയുള്ളവനായിരിക്കണം. ജഡ്ജിയും ടാർഗെറ്റും ഒരേ വലുപ്പത്തിലുള്ളതാണെങ്കിൽ, അവർക്ക് ഒരേ തരത്തിലുള്ള പോരായ്മകൾ (blind spots) ഉണ്ടാകാൻ സാധ്യതയുണ്ട്.
  • കൃത്യത (Accuracy) കബളിപ്പിക്കാൻ സാധ്യതയുണ്ട്. മിക്ക മോഡലുകളും നിരസിക്കുകയാണെങ്കിൽ, എപ്പോഴും "refused" എന്ന് പറയുന്ന ഒരു ജഡ്ജി കൃത്യമാണെന്ന് തോന്നും, പക്ഷേ അത് ഒന്നും പഠിക്കുന്നില്ല. ഭാഗ്യം (luck) കണക്കിലെടുക്കാൻ Cohen's kappa പോലുള്ള മെട്രിക്സുകൾ ഉപയോഗിക്കുക.
  • ജഡ്ജി സ്ഥിരതയുള്ളവനായിരിക്കണം (stable). ഒരേ ടെസ്റ്റ് അഞ്ച് തവണ നടത്തുക. ജഡ്ജി തന്റെ തീരുമാനം മാറ്റുകയാണെങ്കിൽ, ഫലം അവ്യക്തമാണ്, അതിന് ഒരു മനുഷ്യന്റെ പരിശോധന ആവശ്യമാണ്.

നിങ്ങൾ LLM ഉപയോഗിച്ച് എന്തെങ്കിലും നിർമ്മിക്കുകയാണെങ്കിൽ, ഈ കാര്യങ്ങൾ ഓർക്കുക:

  • അനുസരണം (compliance) ഉണ്ടാക്കുന്നതിനേക്കാൾ പ്രയാസമാണ് അത് കണ്ടെത്തുന്നത്.
  • ആദ്യ വാചകത്തിൽ നിരസിക്കുകയും രണ്ടാമത്തെ വാചകത്തിൽ അനുസരിക്കുകയും ചെയ്യുന്ന മോഡലുകളെ ശ്രദ്ധിക്കുക.
  • ഒരു LLM ജഡ്ജിയെ അന്ധമായി വിശ്വസിക്കരുത്. അതിന്റെ വിശ്വാസ്യത (reliability) അളക്കുക.
  • നിങ്ങളുടെ ബഗുകൾ പങ്കുവെക്കുക. എന്റെ തന്നെ പിഴവ് കണ്ടെത്തുന്നത് ഒരു മികച്ച ലോഞ്ചിനേക്കാൾ കൂടുതൽ കാര്യങ്ങൾ എന്നെ പഠിപ്പിച്ചു.

Source: https://dev.to/nar1frames/i-built-an-ai-security-scanner-then-found-a-bug-in-my-own-detector-140a

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