Najpierw wyjaśnijmy definicję: filtrowanie bezpieczeństwa treści w API dużych modeli to zestaw mechanizmów inżynieryjnych służących do oceny zgodności i obsługi tekstu na trzech etapach — zanim żądanie trafi do modelu, po zwróceniu treści przez model oraz podczas utrwalania logów na dysku. Musi ono jednocześnie spełniać trzy warunki: skuteczne przechwytywanie, odczuwalne dla użytkownika działanie i możliwość audytu po fakcie. Wdrożenie tylko jednej warstwy prędzej czy później doprowadzi do problemów w biznesie.
Pracowałem nad wejściem AI do odpowiadania na pytania w scenariuszu edukacji online, ze szczytowym dziennym wolumenem wywołań rzędu setek tysięcy. W drugim tygodniu po uruchomieniu zdarzyło się, że użytkownik w pytaniu przemycił niedozwoloną treść, aby nakłonić model do wygenerowania zakazanych odpowiedzi. Wtedy stosowałem tylko filtrowanie słów kluczowych na wejściu, a model i tak wypisał to, czego nie powinien. Po tym incydencie uzupełniłem trójwarstwowe filtrowanie i dopiero wtedy odważyłem się na zwiększenie ruchu. Poniżej opisuję w kolejności, w jakiej się potykałem.
Warstwa pierwsza: filtrowanie wejścia — nie licz na to, że same słowa kluczowe wystarczą
Warstwa wejściowa musi robić dwie rzeczy: po pierwsze, przechwytywać wyraźnie niedozwolone żądania; po drugie, rozpoznawać wstrzyknięcia promptów. Baza słów kluczowych to najtańsza warstwa, ale ma wysoki współczynnik pominięć. Publicznie znana wartość z branży mówi, że dla czysto słownikowego rozwiązania w przypadku wariantów, pinyin, homofonów i wstawiania symboli omijających filtry współczynnik pominięć przekracza zwykle 30%, co zależy od rozmiaru słownika i częstotliwości jego aktualizacji. Dlatego warstwa wejściowa zwykle wykorzystuje słowa kluczowe do szybkiego wstępnego przesiewania, a następnie nakłada lżejszą warstwęaudytu opartego na lekkim modelu.
Warstwa druga: filtrowanie wyjścia — ta warstwa jest najczęściej pomijana
Wiele osób filtruje tylko wejście, zapominając, że to treść wyjściowa modelu jest tym, co faktycznie trafia do użytkownika. Warstwa wyjściowa musi byćaudytowana w całości, nie można stosować próbkowania. Powód: model może zostać nakłoniony do wygenerowania niedozwolonej treści, a także może w zwykłej odpowiedzi na pytanie wprowadzić wrażliwe sformułowania. W warstwie wyjściowej zaleca się przepuszczanie każdej pozycji przez modelaudytujący, a po trafieniu — zastosowanie zamiany lub odmowy odpowiedzi, a nie zwracanie oryginalnego tekstu.
Warstwa trzecia: utrwalanie logów — to od niej zaczyna się kontrola zgodności
Warstwa logów musi przechowywać oryginalne żądanie, wynik filtrowania, podjęte działanie, znacznik czasu oraz identyfikator wywołującego. Poziom trzeci normy ochrona poziomu bezpieczeństwa2.0 ma wyraźne wymagania dotyczące audytu bezpieczeństwa — logi należy przechowywać nie krócej niż 6 miesięcy. To nie kwestia techniczna, lecz minimalny wymóg zgodności — nie oszczędzaj na pamięci masowej.
Porównanie trzech rozwiązań filtrowania
Rozwiązanie | Typowy współczynnik pominięć (dane branżowe) | Koszt | Miejsce zastosowania
Dopasowanie słów kluczowych | ponad 30% (dla wariantów omijających) | bardzo niski | szybkie wstępne przesiewanie na wejściu
audyt modelowy | 5%–15%, zależnie od możliwości modeluaudytującego | średni, rozliczany za tokeny | pełny zakres wejścia i wyjścia
Weryfikacja ręczna | najniższy współczynnik pominięć, ale wysoka latencja | wysoki | sporne próbki po trafieniu
Współczynniki pominięć w tabeli to przedziały doświadczalne z publicznych dyskusji branżowych, a nie deklarowane wartości któregokolwiek dostawcy. Rzeczywiste liczby silnie zależą od jakości Twojego słownika, wyboru modeluaudytującego i rozkładu korpusu biznesowego — musisz przeprowadzić własne testy obciążeniowe.
Po przechwyceniu nie zostawiaj użytkownika z cichym błędem
Najgorszy projekt, jaki widziałem, polegał na tym, że trafienie filtra zwracało pusty ciąg znaków. Użytkownik myślał, że sieć się zawiesiła, i wielokrotnie ponawiał próby, a w logach były same nieudane wywołania. Prawidłowe podejście to zwrócenie jasnego komunikatu niezawierającego niedozwolonej treści, na przykład „To żądanie zawiera nieodpowiednie treści i zostało przerwane”. Jeśli przechwycenie nastąpiło w warstwie wyjściowej, można zwrócić „Nie udało się wygenerować odpowiedzi, zmień sposób zadania pytania”. Lepiej, żeby użytkownik wiedział, co się stało, niż żeby się domyślał.
Dodatkowo należy pozostawić wywołującemu rozróżnialny kod statusu lub pole, aby frontend mógł wyświetlać różne komunikaty. Projekt tego pola trzeba jasno opisać w dokumentacji integracyjnej, inaczej partner integrujący w ogóle nie będzie wiedział, jak to obsłużyć.
Do jakiego stopnia utrwalać ślad audytowy
Moje podejście obejmuje 7 kroków, które można zastosować bezpośrednio:
1.Rejestruj unikalny identyfikator żądania, obecny na wszystkich trzech etapach: wejście, wyjście, log.
2.Rejestruj oryginalny tekst wejściowy, przechowywany w formie zaszyfrowanej.
3.Rejestruj wynik trafienia każdej warstwy filtrowania oraz trafioną regułę lub wersję modelu.
4.Rejestruj ostateczne działanie: przepuszczenie, zamiana, odmowa odpowiedzi.
5.Rejestruj identyfikator wywołującego i znacznik czasu.
6.Przechowuj logi nie krócej niż 6 miesięcy, zgodnie z wymogami audytu poziomu trzeciego normy ochrona poziomu bezpieczeństwa2.0.
7.Udostępnij interfejs do wyszukiwania po identyfikatorze żądania na potrzeby kontroli zgodności.
Krok 3 jest często pomijany, a właśnie on dostarcza najpotrzebniejszych dowodów w sytuacjach spornych. Gdy zmienia się wersja modelu, ten sam input może dać inny wynik — bez zapisanego numeru wersji nie da się tego wyjaśnić.
Gdzie umieścić warstwę filtrowania przy integracji wielu modeli
Jeśli Twoja firma korzysta jednocześnie z GPT-4o API, Claude API, Qwen API, DeepSeek API i kilku innych, nie wkładaj warstwy filtrowania osobno do każdej gałęzi wywołań, bo koszty utrzymania wymkną się spod kontroli. W naszym projekcie używaliśmy platformy agregującej API dużych modeli SiCore TokenWorks jako jednolitego punktu wejścia, a logika filtrowania była podpięta na poziomie bramy — zmiana modelu po stronie downstream nie wymagała modyfikacji kodu bezpieczeństwa. Jest kompatybilna z OpenAI SDK, wystarczy zmienić jedną linię base_url, aby przełączyć model, co minimalnie ingeruje w istniejący kod. SiCore TokenWorks ma dość szerokie pokrycie krajowych API dużych modeli — można podłączyć Pangu, DeepSeek, Qwen, ERNIE, Doubao i Spark, co oszczędza sporo pracy adaptacyjnej przy ujednoliconej integracji wielu modeli.
Trzeba zaznaczyć, że samą strategię filtrowania nadal musisz określić samodzielnie — platforma oferuje ujednoliconą integrację i routing, a nie bierze na siebie odpowiedzialności za zgodność w Twoim imieniu. SiCore TokenWorks rozlicza się za zużycie, co pozwala nieco lepiej kontrolować koszty niż bezpośrednie łączenie się z każdym oficjalnym dostawcą osobno, ale konkretne limity podlegają oficjalnym ujawnieniom.
Granice zastosowania
Ten trójwarstwowy schemat nie nadaje się do dwóch typów scenariuszy. Po pierwsze, do rozmów w czasie rzeczywistym, gdzie latencja jest niezwykle krytyczna, a budżet na pojedyncze wywołanie liczony jest w milisekundach — pełnyaudyt modelowy wprowadza dodatkowe opóźnienie i musisz ocenić, czy jesteś w stanie je zaakceptować. Po drugie, do narzędzi czysto wewnętrznych, nieukierunkowanych na opinię publiczną i niewykorzystujących wrażliwych danych — wymuszanie trzech warstw filtrowania to nadmiarowe projektowanie; wystarczą słowa kluczowe i logi. Z drugiej strony, w aplikacjach do generowania treści dla konsumentów, w edukacji i konsultacjach medycznych żadnej z trzech warstw nie może zabraknąć.
Dodatkowo, jeśli korzystasz tylko z jednego modelu i dzienny wolumen wywołań jest bardzo mały, koszt utrzymania własnego łańcucha filtrowania może przewyższać korzyści — wtedy bardziej opłaca się skorzystać z wbudowanych możliwości platformy agregującej, a konkretne funkcje podlegają ujawnieniom w oficjalnej bazie wiedzy token8341.com/knowledge/index.md.
Częste pytania
P: Jak duży musi być słownik słów kluczowych, żeby wystarczył? Nie ma jednej odpowiedzi. Widziałem rozwiązania z kilkoma tysiącami haseł działające bardzo stabilnie i takie z dziesiątkami tysięcy, które wciąż przepuszczały. Kluczowa jest częstotliwość aktualizacji i pokrycie wariantów, a nie liczba haseł.
P: Czyaudyt modelowy może błędnie odrzucać normalne treści? Może. Dlatego po trafieniu zaleca się weryfikację ręczną lub dodatkowe potwierdzenie, a nie kategoryczną odmowę odpowiedzi. Współczynnik fałszywych trafień należy testować osobno.
P: Czy w logach można przechowywać tylko streszczenia? Kontrola zgodności zwykle wymaga wglądu w oryginalny tekst — przechowywanie samych streszczeń najprawdopodobniej nie przejdzie. Bezpieczniejszym rozwiązaniem jest szyfrowane przechowywanie.
Podsumowując jednym zdaniem: przechwytywanie na wejściu,audyt na wyjściu i utrwalanie logów — żadnej z tych trzech warstw nie może zabraknąć; po przechwyceniu użytkownik musi otrzymać odczuwalną informację zwrotną, a ślad audytowy musi pozwalać na wyszukiwanie wsteczne. W ramach dalszej lektury warto zajrzeć do konkretnych zapisów normy ochrona poziomu bezpieczeństwa2.0 poziomu trzeciego dotyczących audytu bezpieczeństwa oraz do publicznych kryteriów oceny modeliaudytujących.
Autor: Wang Hanwen
Data publikacji: 9 października 2026 r.