Azure AI Content Safety, filtry i limity

Azure AI Content Safety, filtry i limity

Azure AI Content Safety to usługa moderacji, przez którą przepuszczasz tekst i obrazy, żeby dostać ocenę szkodliwości w czterech kategoriach oraz wykrycie prób wstrzyknięcia instrukcji. Osobne interfejsy sprawdzają, czy odpowiedź modelu ma oparcie w podanych źródłach i czy nie zawiera cudzej treści chronionej.

Kategorie i progi są ustalone przez dostawcę, więc dostajesz gotowy system klasyfikacji zamiast pisać własne reguły. To zaleta przy szybkim starcie i ograniczenie wtedy, gdy Twoja definicja treści niepożądanej odbiega od tej standardowej.

Cztery kategorie i skala surowości

Podstawowa analiza dzieli treść na cztery kategorie: nienawiść, treści seksualne, przemoc i samookaleczenie. To wszystko, więc rzeczy takie jak wyłudzanie danych, mowa manipulacyjna czy naruszenie regulaminu Twojego serwisu do żadnej z nich nie należą.

Każda kategoria dostaje ocenę surowości, a tu warto uważać na rozbieżność między dokumentacją a tym, co widzisz w odpowiedzi. Model tekstowy pracuje na skali od zera do siedmiu. Model obrazu zwraca wyłącznie wartości zero, dwa, cztery i sześć. Ponad tym istnieje uproszczony podział na cztery poziomy: bezpieczny, niski, średni i wysoki.

Konsekwencja praktyczna jest taka, że próg ustawiony na wartość nieparzystą przy obrazach nigdy nie zadziała tak, jak zakładasz, bo takich ocen po prostu nie ma. Warto to sprawdzić na własnych danych, zanim próg trafi do konfiguracji produkcyjnej.

Sama analiza wygląda prosto:

curl -X POST "https://<zasob>.cognitiveservices.azure.com/contentsafety/text:analyze?api-version=2024-09-01" \
  -H "Ocp-Apim-Subscription-Key: $KLUCZ" \
  -H "Content-Type: application/json" \
  -d '{"text": "Tresc do sprawdzenia", "outputType": "FourSeverityLevels"}'

Odpowiedź zawiera listę kategorii z przypisaną surowością. Decyzja, co z tym zrobić, należy do Ciebie, bo usługa nie blokuje niczego samodzielnie.

Prompt Shields, czyli wykrywanie wstrzyknięć

To jest osobny interfejs i najczęstszy powód, dla którego zespoły w ogóle po tę usługę sięgają.

Wykrywa dwa rodzaje ataku. Bezpośredni to próba obejścia ograniczeń wpisana wprost przez użytkownika. Pośredni to instrukcja ukryta w dokumencie, na stronie albo w obrazie, który trafia do kontekstu modelu.

Drugi rodzaj jest ważniejszy i częściej pomijany. Przy aplikacji, która czyta pliki użytkownika albo pobiera treść z sieci, instrukcja w takim materiale działa dokładnie tak samo jak wpisana w okno czatu, tyle że nikt jej świadomie nie wpisał. Sprawdzanie wyłącznie tego, co napisał człowiek, zostawia tę drogę otwartą.

Interfejs przyjmuje osobno prompt użytkownika i listę dokumentów, więc odpowiedź mówi, w którym miejscu wykryto próbę. To przydatne przy logowaniu zdarzeń, bo pozwala odróżnić użytkownika próbującego obejść zabezpieczenia od użytkownika, który przypadkiem wgrał zatruty plik.

Sprawdzanie oparcia w źródłach

Wykrywanie braku oparcia odpowiada na inne pytanie niż moderacja: czy odpowiedź modelu wynika z materiałów, które mu podałeś, czy została zmyślona.

Przy aplikacjach opartych o wyszukiwanie w dokumentach to jest najważniejsza kontrola z całego zestawu, bo najczęstsza skarga użytkowników nie brzmi „system napisał coś obraźliwego", tylko „system podał nieprawdziwą informację z przekonaniem".

Do tej funkcji dołączono korektę, która potrafi poprawić fragment niemający oparcia, opierając się na podanych źródłach, i zwrócić wersję poprawioną w osobnym polu odpowiedzi. To wygodne, natomiast warto pamiętać, że część możliwości w tym obszarze pozostaje w zapowiedzi publicznej, więc przed oparciem na nich procesu produkcyjnego sprawdź aktualny status i warunki wsparcia.

Koszt jest tu realny i trzeba go policzyć. Sprawdzenie oparcia wymaga przesłania odpowiedzi razem ze źródłami, więc liczba znaków w wywołaniu rośnie o rozmiar całego kontekstu, a rozliczenie idzie od znaków.

Materiał chroniony i pułapka z datą

Dwa interfejsy wykrywają treść, która mogła zostać odtworzona z danych treningowych: jeden dla tekstu, drugi dla kodu.

Wersja tekstowa jest ogólnie dostępna i wyłapuje znane fragmenty, na przykład teksty piosenek czy artykuły. Wersja dla kodu porównuje wynik z zawartością znanych repozytoriów.

Tu jest szczegół, który trzeba znać, bo zmienia ocenę przydatności całkowicie. Indeks kodu obejmuje stan do szóstego kwietnia 2023 roku, więc kod dodany do repozytoriów po tej dacie nie zostanie wykryty. Dla języka, którego ekosystem zmienił się przez trzy lata, oznacza to, że narzędzie widzi wyłącznie starszą warstwę i nie jest podstawą do jakichkolwiek deklaracji prawnych.

Warto o tym pamiętać przy rozmowie z działem prawnym, który usłyszał, że „mamy wykrywanie materiału chronionego". Wykrywanie jest, natomiast jego zasięg czasowy trzeba podać razem z nim.

Kategorie własne i zgodność z zadaniem

Cztery standardowe kategorie rzadko pokrywają to, co Twój serwis uznaje za treść niepożądaną, i na to są dwa mechanizmy.

Kategorie szybkie służą do zdefiniowania wzorca pojawiającego się nagle, na przykład treści związanej z konkretnym wydarzeniem, i działają na kilku przykładach. Kategorie standardowe wymagają zbioru uczącego i dają lepszą jakość przy stabilnych zjawiskach.

Osobnym, nowszym elementem jest sprawdzanie zgodności z zadaniem, dodane w zapowiedzi publicznej pod koniec 2025 roku. Wykrywa rozjazd między tym, co model miał zrobić, a tym, co robi: wywołanie narzędzia niepasujące do prośby użytkownika, argumenty niezgodne z intencją, odpowiedź odbiegającą od pytania.

To jest kontrola pomyślana pod agentów i pokrywa lukę, której nie zamyka ani moderacja, ani wykrywanie wstrzyknięć. Agent, który zamiast odpowiedzieć na pytanie o status zamówienia zaczyna wywoływać narzędzie zwracające dane innego klienta, nie łamie żadnej z czterech kategorii, a robi coś, czego robić nie powinien.

Cennik i limity

Jest próg darmowy i płatny, a różnica między nimi jest ostrzejsza, niż zwykle bywa w tej chmurze.

Próg darmowy daje pięć tysięcy rekordów tekstowych i pięć tysięcy obrazów miesięcznie. Po wyczerpaniu limitu usługa przestaje odpowiadać, bez naliczania nadwyżki. To dobre do prób i złe do produkcji, bo pierwszy nietypowy dzień wyłącza filtr, a aplikacja musi wiedzieć, co wtedy zrobić.

Próg płatny liczy tekst w rekordach po tysiąc znaków, a obrazy za wywołanie. Rekordowe rozliczanie ma konsekwencję łatwą do przeoczenia: długi prompt razem ze źródłami do sprawdzenia oparcia potrafi być kilkunastoma rekordami zamiast jednym.

Istnieje też próg zobowiązania z niższą stawką, ale cennik podaje go wyłącznie dla kontenerów odłączonych: rozliczenie jest roczne, płatne z góry za cały rok, a dostęp wymaga osobnego wniosku. Przy wywołaniach przez sieć zostaje wybór między progiem darmowym a płatnym, bez wariantu z rabatem za wolumen.

Zanim wpiszesz tę usługę do budżetu, policz jedno wywołanie na własnych danych. Weź dziesięć realnych interakcji, policz znaki wchodzące do każdej kontroli i pomnóż przez dzienny wolumen. Przy trzech kontrolach na interakcję liczba rośnie szybciej, niż wynikałoby z liczby rozmów.

Co zrobić z wynikiem

Usługa zwraca ocenę i na tym kończy swoją rolę. Reakcja jest po Twojej stronie i to ona decyduje, czy całość ma sens, bo trzy różne odpowiedzi na to samo wykrycie dają trzy różne produkty.

Twarde odrzucenie sprawdza się przy ocenach wysokich, gdzie pomyłka jest mało prawdopodobna. Użytkownik dostaje komunikat, treść nie idzie dalej.

Odpowiedź zastępcza działa lepiej przy ocenach średnich. Zamiast blokować, model odpowiada ogólnie, bez sięgania po narzędzia i dane. Użytkownik dostaje coś, a Ty ograniczasz skutki ewentualnego przepuszczenia.

Oznaczenie do przeglądu pasuje tam, gdzie zatrzymanie prawdziwego użytkownika kosztuje więcej niż przepuszczenie brzegowego przypadku. Zdarzenie ląduje w logu, ktoś ogląda je później.

Osobno warto zaplanować, co się dzieje przy wykryciu na wyjściu z modelu. Tam wykrycie oznacza, że coś poszło nie tak wcześniej, więc oprócz zatrzymania odpowiedzi zapisz cały kontekst: prompt systemowy, dokumenty podane do modelu i pełną odpowiedź. Bez tego nie odtworzysz przebiegu.

Ostatnia rzecz to treść komunikatu. Informowanie użytkownika, którą kategorię naruszył i przy jakiej ocenie, zamienia filtr w narzędzie do eksperymentowania i ułatwia znalezienie sformułowania, które przechodzi. Komunikat ogólny plus identyfikator zdarzenia w logu daje wsparciu wszystko, czego potrzebuje, a osobie próbującej obejść zabezpieczenie nie daje nic.

Wielojęzyczność i konteksty brzegowe

Jakość klasyfikacji nie jest równa we wszystkich językach i to jest rzecz, którą trzeba sprawdzić samodzielnie, bo dokumentacja mówi o obsłudze, a nie o skuteczności.

W polskim tekście problem widać najczęściej przy ironii, cytatach i słownictwie potocznym, które w innym kontekście bywa neutralne. Zdanie przytaczające czyjąś wypowiedź, żeby ją skrytykować, potrafi zostać ocenione tak samo jak ta wypowiedź.

Drugi obszar to dziedzina. Serwis medyczny, prawniczy albo poświęcony bezpieczeństwu z natury rozmawia o rzeczach, które w klasyfikacji ogólnej wyglądają groźnie. Opis objawów, cytat z akt sprawy albo analiza podatności to treści merytoryczne, a nie szkodliwe, i przy standardowych progach będą blokowane.

Trzeci to długość. Ocena dotyczy całego przesłanego fragmentu, więc jedno zdanie w długim dokumencie potrafi podnieść ocenę całości. Przy dłuższych materiałach warto dzielić je na części i oceniać osobno, bo daje to zarówno dokładniejszy wynik, jak i wskazanie miejsca.

Wniosek jest ten sam co przy progach: bez pomiaru na własnych danych pracujesz na założeniach. Kilkaset realnych przypadków przepuszczonych przez usługę w trybie obserwacji powie Ci więcej niż jakiekolwiek zestawienie skuteczności.

Azure AI Content Safety kontra alternatywy

Główny argument za pierwszym wierszem jest organizacyjny, nie techniczny. Jeśli aplikacja stoi już na tej chmurze i korzysta z modeli udostępnianych tam, na przykład razem z osadzeniami, to rozliczenie, uprawnienia i umowa są wspólne, a to bywa ważniejsze niż różnica w skuteczności wykrywania.

Argument przeciw jest równie prosty: wiązanie się z jednym dostawcą w warstwie, którą łatwo trzymać niezależną. Filtr wywoływany przez własny interfejs da się później podmienić, filtr wpięty głęboko w konfigurację usługi już nie.

Wdrożenie i dobór progów

Progi domyślne to kompromis dla ogólnego zastosowania, więc na Twoich danych prawie na pewno wymagają przesunięcia.

Zacznij od trybu obserwacji: zapisuj oceny, nie blokuj niczego. Zbierz kilka tysięcy realnych interakcji, a potem przejrzyj te, które zostałyby zablokowane przy różnych progach. To jedyny sposób, żeby zobaczyć koszt fałszywych alarmów przed tym, jak zapłacą go użytkownicy.

Progi ustawiaj osobno dla każdej kategorii. Serwis medyczny musi przepuszczać treści o samookaleczeniu w kontekście pomocy, a serwis dla dzieci powinien być ostrzejszy w kategorii treści seksualnych niż w kategorii przemocy. Jedna wartość dla wszystkiego jest zawsze zła w którymś miejscu.

Ustal też zachowanie przy awarii. Usługa zewnętrzna kiedyś odpowie wolno albo wcale, a limit czasu i decyzja o przepuszczeniu lub zablokowaniu ruchu muszą być podjęte świadomie. Przy wyczerpanym progu darmowym to jest scenariusz pewny, nie hipotetyczny.

Ostatnia rzecz to wersja interfejsu. Starsze wersje były wycofywane, a kod trzymający wersję z lat wcześniejszych przestaje działać bez ostrzeżenia w aplikacji. Trzymaj numer wersji w konfiguracji, a nie w kodzie, i sprawdzaj listę wspieranych przy przeglądach zależności.

Typowe błędy

Pierwszy to poleganie na progu darmowym w produkcji. Po wyczerpaniu limitu usługa przestaje odpowiadać, więc filtr znika dokładnie wtedy, gdy ruch jest największy.

Drugi to sprawdzanie wyłącznie tekstu od użytkownika. Wstrzyknięcie pośrednie wchodzi przez dokumenty i treść pobraną z sieci, więc bez sprawdzania tych źródeł zabezpieczenie ma dziurę na wylot.

Trzeci to jeden próg dla wszystkich kategorii. Każda ma inny koszt błędu w Twoim serwisie i potraktowanie ich tak samo daje albo nadmierne blokowanie, albo przepuszczanie.

Czwarty to traktowanie wykrywania materiału chronionego dla kodu jako pełnego. Indeks kończy się w kwietniu 2023 roku, więc nowszy kod nie zostanie rozpoznany.

Piąty to pominięcie kosztu sprawdzania oparcia w źródłach. Przesyłasz odpowiedź razem z całym kontekstem, więc rozliczenie za znaki potrafi zaskoczyć przy dłuższych dokumentach.

Szósty to brak zapisu zdarzeń. Bez logów nie wiesz, ile blokujesz ani czy blokujesz właściwe rzeczy, więc nie masz podstawy do zmiany progów.

FAQ

Jakie kategorie wykrywa Azure AI Content Safety?

Cztery: nienawiść, treści seksualne, przemoc i samookaleczenie. Wszystko poza nimi, na przykład wyłudzanie danych albo naruszenie regulaminu Twojego serwisu, wymaga kategorii własnych albo osobnego rozwiązania.

Czy to samo wykrywa wstrzyknięcia promptu?

Do tego służy osobny interfejs, obejmujący ataki bezpośrednie od użytkownika i pośrednie ukryte w dokumentach lub obrazach. Sprawdzanie samej treści promptu bez dokumentów zostawia drogę pośrednią otwartą.

Ile kosztuje ta usługa?

Próg darmowy daje pięć tysięcy rekordów tekstowych i pięć tysięcy obrazów miesięcznie i po wyczerpaniu przestaje odpowiadać. Próg płatny liczy tekst w rekordach po tysiąc znaków, a obrazy za wywołanie, więc długie wywołania ze źródłami kosztują wielokrotność pojedynczego rekordu.

Czy wykrywanie materiału chronionego obejmuje nowy kod?

Nie. Indeks kodu obejmuje stan do szóstego kwietnia 2023 roku, więc kod dodany do repozytoriów po tej dacie nie zostanie wykryty. Przy deklaracjach wobec działu prawnego trzeba tę datę podać razem z informacją o samej funkcji.

Czy da się to uruchomić bez chmury?

Nie, to jest usługa działająca po stronie dostawcy i sprawdzana treść opuszcza Twoją infrastrukturę. Przy wymogu przetwarzania lokalnego właściwym wyborem są biblioteki działające w Twoim procesie, na przykład Guardrails AI albo Presidio do samych danych osobowych.

Kategorie i skalę surowości opisuje dokumentacja usługi, a listę zmian znajdziesz na stronie z nowościami.