ISMS Copilot
Engineering

Kolizja słownictwa: kiedy klasyfikator bezpieczeństwa blokuje całą domenę

Ogólny klasyfikator moderacji błędnie oznaczył 15 z 15 wiadomości w ciągu 17 dni w naszym produkcie zgodności, ponieważ nasi użytkownicy na co dzień omawiają zagrożenia. Rozwiązanie przeniosło ryzyko, zamiast je usuwać.

przez ISMS Copilot··7 min read
Kolizja słownictwa: kiedy klasyfikator bezpieczeństwa blokuje całą domenę

Ogólny klasyfikator bezpieczeństwa opiera się na ukrytym założeniu: że rozmowy o atakujących, exploitach i praniu brudnych pieniędzy są rzadkie i podejrzane. Skieruj go na produkt z zakresu bezpieczeństwa i zgodności, a założenie się odwraca. W 17-dniowym oknie produkcyjnym kończącym się 10 kwietnia 2026 roku, alias mistral-moderation-latest firmy Mistral (rozwiązujący wówczas do przypiętej wersji mistral-moderation-2603) oznaczył 15 wiadomości w naszej aplikacji jako szkodliwe. Każda była fałszywym alarmem. Precyzja wynosiła zero. Nie obniżona, nie szum — zero na piętnaście.

To konkretny, zmierzony wynik na naszym własnym ruchu, który ujawnia tryb awarii niewidoczny, dopóki nie odczytasz flag pojedynczo. Nazywamy to kolizją słownictwa: w specjalistycznej dziedzinie słownictwo klasyfikatora dotyczące zagrożeń jest jednocześnie słownictwem roboczym danej dziedziny. Sygnał, który miał być rzadki, staje się podstawową częstotliwością.

Flagi

Z 15 flag, 14 trafiło do kategorii dangerous_and_criminal_content klasyfikatora, a 1 do violence_and_threats. Odczytując je ponownie, wzorzec był natychmiastowy. Wszystkie były legalnymi dyskusjami z zakresu GRC:

  • Inżynieria wsteczna usług dostawcy chmury w kontekście zobowiązań dotyczących własności intelektualnej. Norma ISO/IEC 27001:2022 Załącznik A kontrola A.5.32 to dosłownie „Prawa własności intelektualnej”; użytkownik pracujący nad tą kontrolą musi mówić o inżynierii wstecznej, aby ją uzasadnić.
  • Ocena ryzyka napisana po hiszpańsku, gdzie „amenazas” (zagrożenia) to zwyczajowe określenie na rzecz, którą każdy rejestr ryzyka wylicza.
  • Prace z zakresu przeciwdziałania praniu brudnych pieniędzy, gdzie „blanqueo” (pranie brudnych pieniędzy) jest tematem, a nie wyznaniem.
  • Doświadczenia z testów czerwonego zespołu i pentestingu.
  • DAST, dynamiczne skanowanie aplikacji pod kątem podatności.

Żadne z tych zagadnień nie jest treścią kryminalną. To codzienne słownictwo specjalistów ds. bezpieczeństwa informacji, oficerów zgodności i audytorów. Klasyfikator nie jest wadliwy. W ogólnym ruchu sieciowym wiadomość o inżynierii wstecznej systemów dostawcy jest słabym sygnałem zagrożenia, a ogólny klasyfikator jest zbudowany, aby traktować ją jako taką. Nasi użytkownicy są populacją, dla której ten sam sygnał oznacza coś przeciwnego. Możemy spodziewać się tej formy awarii od każdego ogólnego klasyfikatora użytego w ten sam sposób, ponieważ wynika ona z ogólnego podejścia, a nie z implementacji konkretnego dostawcy. Błąd był nasz: potraktowaliśmy ogólne założenie priorytetowe, jakby było świadome dziedziny.

Przeładowanie nie jest bezpiecznym domyślnym rozwiązaniem

Odruchowo fałszywe alarmy traktuje się jako nieszkodliwą stronę kompromisu między precyzją a recall. Pominąć realne zagrożenie, a masz dziurę w zabezpieczeniach; przeładować, a w najgorszym razie masz tylko szum. W produkcji szum miał realne konsekwencje, dlatego warto być konkretnym w kwestii drugorzędowych kosztów, ponieważ to tam tkwiła rzeczywista szkoda:

  1. Zmęczenie alertami pokonało sieć. Każde potwierdzone zdarzenie wysyłało e-mail do skrzynki bezpieczeństwa. Piętnaście kolejnych fałszywych alarmów nauczyło zespół, by zerkając ignorować alerty moderacji. Sieć bezpieczeństwa, którą wszyscy nauczyli się ignorować, nie jest siecią bezpieczeństwa.
  2. Problem z prawem do usunięcia. Zablokowane wątki były zablokowane przed usunięciem, aby dowody nie zostały zniszczone. To rozsądne w przypadku rzeczywistego nadużycia. Zastosowane do fałszywego alarmu oznaczało, że użytkownik nie mógł usunąć własnej rozmowy dotyczącej zgodności, co tworzyło ryzyko zgodnie z artykułem 17 RODO (prawo do usunięcia). To prawo, podlegające swoim warunkom i wyjątkom, obejmuje selektywne usuwanie, a nie tylko zamknięcie konta.
  3. Niesubstancjonowaną etykietę. Nieszkodliwe wiadomości użytkowników znajdowały się w magazynie, którego semantyka brzmiała „niebezpieczna i kryminalna treść”. To stwierdzenie o osobie, którego nie mogliśmy poprzeć.

To precyzja, a nie recall, była metryką, która nas bolała, a jej awaria nie była kosmetyczna.

Dlaczego oczywiste rozwiązania nie działają

Dwa rozwiązania nasuwają się same i oba są błędne.

Dostrojenie klasyfikatora. Nie da się. Punkt końcowy moderacji to klasyfikator stały. Jego API akceptuje identyfikator modelu i ciąg wejściowy, zwracając wyniki kategorii. Nie ma systemowego promptu, pola instrukcji ani miejsca, aby powiedzieć mu „to jest produkt zgodności”. Stały klasyfikator daje ci pokrętło bez podziałki.

Usunięcie szumiącej kategorii. Wyłączenie dangerous_and_criminal_content i violence_and_threats wyeliminowałoby wszystkie fałszywe alarmy, jakie zaobserwowaliśmy. Wyeliminowałoby również jedyne kategorie, pod którymi realne zagrożenie w naszej dziedzinie kiedykolwiek by się pojawiło. To nie kalibracja, to wyłączenie sieci i nazwanie ciszy sukcesem.

Rozwiązanie dwuetapowe

Zachowaj szybki klasyfikator jako etap pierwszy; nadal działa on przy każdej wiadomości. Gdy coś oznaczy, przekaż wiadomość do drugiego etapu orzecznictwa: małego modelu czatu (Mistral Small) z systemowym promptem opisującym legalne tematy bezpieczeństwa informacji i zgodności, które nasi użytkownicy rzeczywiście omawiają. Sędzia zwraca jeden z dwóch werdyktów: CONFIRMED lub FALSE_POSITIVE.

Tylko zdarzenia CONFIRMED trafiają do ścieżki alertów i blokad. Wydarzenia FALSE_POSITIVE trafiają do oddzielnego, tłumionego magazynu, przechowywanego w celach audytu i wykrywania dryfu, ale z zerowymi konsekwencjami dla użytkownika: bez e-maila, bez blokady usuwania, bez etykiety kryminalnej. Sędzia uruchamia się przy około jednej oznaczonej wiadomości dziennie, więc dodatkowy koszt jest pomijalny. Ponadto działa on w trybie awaryjnym: jeśli sędzia się pomyli, przekroczy limit czasu lub zwróci cokolwiek, co nie jest czystym werdyktem, wiadomość jest traktowana jako CONFIRMED. Najgorszy scenariusz to stary szumiący stan bazowy, nigdy cicho pominięte zagrożenie.

Wdrożone 10 kwietnia 2026 roku, rozwiązanie to obniżyło nasz wskaźnik fałszywych alarmów z 15 na 15 do zera, nie wyłączając żadnej kategorii.

Pułapka: przenieśliśmy ryzyko, nie usunęliśmy go

Oto część, którą warto zapamiętać, ponieważ ma ona zastosowanie poza moderacją. Dodanie łagodnego drugiego etapu nie usuwa ryzyka. Przenosi je z awarii, którą widać, do awarii, której nie widać.

Wcześniej tryb awarii to przeładowanie, a było głośne: każdy fałszywy alarm uruchamiał dzwonek alertu. Po wdrożeniu dominującym trybem awarii jest zbyt łagodny sędzia, który cicho przepuszcza to, co powinien potwierdzić. Ta awaria jest z założenia cicha. Zapisuje się w magazynie, o którym nikt nie dostaje e-maila.

Otrzymaliśmy żywą demonstrację, jak dezorientujący jest ten cichy reżim. 14 kwietnia 2026 roku, cztery dni po naprawie, e-maile z alertami moderacji ustały całkowicie. Z zewnątrz nagłe zero jest nieodróżnialne od zepsutego potoku: klasyfikator otwarty, awaria, upuszczony wyzwalacz. Dopiero odczytanie danych źródłowych pozwoliło odróżnić „zdrową ciszę” od „ciemności”. Gdy uzyskaliśmy dostęp do tłumionego magazynu, przeprowadziliśmy audyt każdego werdyktu Mistral Small zebranego od wdrożenia 10 kwietnia 2026 roku: 40 tłumionych wierszy i według naszej oceny żaden nie był realnym zagrożeniem błędnie przepuszczonym. Ścieżka potwierdzeń zsynchronizowała się dokładnie w tym samym okresie: 23 potwierdzone zdarzenia do 23 e-maili z alertami. Sieć była nienaruszona. Ale jedynym sposobem, aby się o tym przekonać, było sprawdzenie tego, co ucichło.

Drugi etap wymaga własnej ewaluacji, według własnego harmonogramu. Tłumiony magazyn jest obecnie sprawdzany raz w miesiącu pod kątem zbyt dużej łagodności sędziego, a tani dzienny licznik w tabeli potwierdzeń monitoruje, czy potok nie „zgasł”. Lekcja nie brzmi „dodaj sędziego LLM”. Brzmi: kiedy naprawiasz widoczną awarię cichszym komponentem, zaplanuj audyt tego, co jest ciche, bo w przeciwnym razie wymieniłeś problem, który możesz zmierzyć, na ten, którego zmierzyć nie możesz.

Przenośna lista kontrolna

Jeśli uruchamiasz ogólny klasyfikator nad specjalistycznym korpusem — medycznym, prawnym, bezpieczeństwa, finansowym lub zgodności — zanim zaufasz jego wynikom:

  • Sprawdź występowanie kolizji słownictwa. Wymień słownictwo robocze swojej dziedziny. Jeśli te same słowa pokrywają się z kategoriami zagrożeń klasyfikatora, jego precyzja na twoim ruchu jest otwartym pytaniem, nie założeniem. Zmierz ją.
  • Czytaj flagi, nie tylko je zliczaj. Liczba precyzji ukrywa wzorzec; pojedyncze fałszywe alarmy go ujawniają. Piętnaście flag nie mówiło nam nic, dopóki nie przeczytaliśmy piętnastu flag.
  • Uczciwie oszacuj koszty przeładowania. Prześledź, co fałszywy alarm uruchamia w dalszej części systemu. Zmęczenie alertami, blokada usuwania kolidująca z prawem do usunięcia, etykieta, której nie można uzasadnić. Przeładowanie rzadko jest bezkosztowe.
  • Jeśli klasyfikator jest stały, opakuj go, nie walcz z nim. Gdy nie możesz instruować modelu, dodaj wokół niego świadomy dziedziny etap, zamiast całkowicie wyłączać kategorie.
  • Awaryjnie zamykaj opakowanie. Błąd sędziego powinien eskalować, nigdy nie tłumić, aby awaria opakowania nie mogła otworzyć sieci w sposób niewidoczny.
  • Przeprowadź audyt cichego etapu. Każdy komponent, który cicho tłumi, wymaga zaplanowanego przeglądu tego, co stłumił, oraz kontroli żywotności, która odróżnia „zdrową ciszę” od „ciemności”.

Ograniczenia

To jeden produkt, jedna dziedzina i niewielka próbka: 15 flag w 17-dniowym oknie kończącym się 10 kwietnia 2026 roku, plus 40 tłumionych wierszy w tygodniach po wdrożeniu. To wynik punktowy w czasie dla aliasu mistral-moderation-latest w momencie jego działania w tym oknie, przedstawiony jako własny pomiar na własnym ruchu. To nie jest ogólne stwierdzenie dotyczące jakości tego klasyfikatora poza naszą dziedziną. Wskaźnik błędu samego sędziego jest ograniczony domyślnym trybem awaryjnym, ale nie wynosi zero, co jest dokładnie powodem, dla którego jest on audytowany, a nie ufany. W czym jesteśmy pewni, to mechanizm: kiedy słownictwo zagrożeń i słownictwo dziedziny to te same słowa, precyzja ogólnego klasyfikatora to pomiar, który musisz przeprowadzić, a nie właściwość, którą możesz założyć.

Powiązane artykuły