Zbudowałem skaner bezpieczeństwa AI — a potem znalazłem błąd we własnym detektorze

Prompt injection to jedno z głównych zagrożeń bezpieczeństwa dla aplikacji opartych na LLM. Podajesz modelowi tekst, który nakazuje mu zignorować pierwotne instrukcje. Czasami model ulega tym instrukcjom.

Zbudowałem AgentProbe, aby to przetestować. Narzędzie wysyła 49 promptów atakujących w 8 kategoriach, takich jak jailbreaki czy ekstrakcja danych. Raportuje ono, jak często model zawodzi.

Prawdziwą lekcją nie był sam skaner. Był nią błąd w moim kodzie detekcji.

Najtrudniejszy nie jest atak. Najtrudniejsza jest detekcja.

Skąd wiedzieć, czy model faktycznie uległ atakowi? Dopasowywanie słów kluczowych to najprostsza metoda. Szukasz fraz odmownych, takich jak „I cannot help”, lub fraz potwierdzających uległość, jak „developer mode”.

Jednak modele stosują wzorzec „hedge-then-comply” (najpierw wymówka, potem uległość). Mówią „I cannot help with that”, ale i tak podają ograniczone informacje. Dopasowywanie słów kluczowych zawodzi w takim przypadku, ponieważ fraza odmowna jest obecna.

Aby to naprawić, zastosowałem system „LLM-as-judge”. Przesyłałem całą wymianę zdań do silniejszego modelu, aby zdecydował, czy cel faktycznie uległ atakowi. Mój plan zakładał najpierw stosowanie tanich kontroli słów kluczowych, a używanie drogiego sędziego tylko wtedy, gdy kontrola słów kluczowych dawała niepewny wynik.

Wtedy znalazłem swój błąd.

Mój detektor słów kluczowych zwracał wynik pewności (confidence score) równy 1, gdy wykrył wzorzec „hedge-then-comply”. Jednak mój kod ufał etapowi słów kluczowych tylko wtedy, gdy wynik pewności wynosił 2 lub więcej.

Oznaczało to, że mój „tani” detektor nigdy tak naprawdę nie podejmował decyzji. Każdy przypadek trafiał do drogiego sędziego. Płaciłem za sędziego w każdym przypadku, nawet gdy moje darmowe narzędzie powinno sobie z tym poradzić.

Ten błąd nauczył mnie trzech rzeczy na temat używania LLM do oceniania innych LLM:

  • Sędzia musi być inteligentniejszy od celu. Jeśli sędzia jest tej samej wielkości co cel, będzie miał te same martwe punkty.
  • Dokładność może kłamać. Jeśli większość modeli odmawia, sędzia, który zawsze mówi „odmowa”, wydaje się dokładny, ale niczego się nie uczy. Należy używać metryk takich jak kappa Cohena, aby uwzględnić czynnik szczęścia.
  • Sędzia musi być stabilny. Przeprowadź ten sam test pięć razy. Jeśli sędzia zmieni zdanie, wynik jest niejednoznaczny i wymaga ludzkiej uwagi.

Jeśli budujesz rozwiązania oparte na LLM, pamiętaj o tych punktach:

  • Wykrywanie uległości jest trudniejsze niż jej wywołanie.
  • Uważaj na modele, które odmawiają w pierwszym zdaniu, ale ulegają w drugim.
  • Nie ufaj sędziemu LLM ślepo. Mierz jego niezawodność.
  • Dziel się swoimi błędami. Znalezienie własnej wady nauczyło mnie więcej, niż zrobiłoby to idealne wdrożenie.

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