Bedrock Guardrails, filtry i weryfikacja logiczna

Bedrock Guardrails, filtry i weryfikacja logiczna

Bedrock Guardrails to warstwa zabezpieczeń w usłudze Amazon Bedrock, którą konfigurujesz raz i podpinasz do wywołań modelu. Sprawdza wejście i wyjście pod kątem sześciu rodzajów polityk, od klasycznej moderacji po formalną weryfikację, czy odpowiedź spełnia reguły, które sam zapisałeś.

Ostatni punkt odróżnia to rozwiązanie od typowych filtrów treści. Większość konkurencji ocenia, czy tekst jest szkodliwy. Ta usługa potrafi dodatkowo sprawdzić, czy odpowiedź nie kłóci się z regułami Twojej firmy, i zrobić to metodą dowodzenia, a nie zgadywania.

Sześć rodzajów polityk

Warto je znać osobno, bo różnią się przeznaczeniem, ceną i jakością, a włączanie wszystkich naraz jest najczęstszym błędem.

Filtry treści wykrywają materiał szkodliwy w kategoriach obejmujących nienawiść, zniewagi, treści seksualne, przemoc, wykroczenia oraz ataki na prompt. Dla każdej kategorii ustawiasz siłę filtrowania osobno.

Ataki na prompt są podkategorią filtrów treści i obejmują ucieczki z ograniczeń, wstrzyknięcia instrukcji oraz wyciek promptu systemowego.

Tematy zabronione pozwalają wypisać obszary, których aplikacja ma unikać, opisane językiem naturalnym. Asystent bankowy może w ten sposób odmawiać rozmowy o doradztwie inwestycyjnym, mimo że taka rozmowa nie jest szkodliwa w sensie moderacji.

Filtry słów działają na dokładne dopasowanie i służą do wycinania konkretnych wyrażeń: wulgaryzmów z gotowej listy albo własnych pozycji, na przykład nazw konkurencji.

Filtry danych wrażliwych wykrywają dane osobowe w formatach standardowych oraz własne wzorce, i mogą je blokować albo maskować. Działają na modelu uczonym, więc uwzględniają kontekst, a nie tylko kształt ciągu znaków.

Sprawdzanie oparcia w kontekście wykrywa odpowiedzi, które nie wynikają z podanych źródeł albo nie odpowiadają na pytanie. To jest kontrola przeznaczona do aplikacji opartych o wyszukiwanie w dokumentach.

Weryfikacja formalna, czyli najciekawszy element

Sprawdzanie przez wnioskowanie automatyczne to osobna kategoria i warto zrozumieć, na czym polega jej przewaga.

Zapisujesz politykę językiem naturalnym: jakie reguły muszą być spełnione, co jest dozwolone, a co się wyklucza. Usługa przekłada to na reprezentację formalną, a potem dla każdej odpowiedzi modelu sprawdza, czy da się ją pogodzić z tymi regułami.

Różnica wobec klasyfikatora jest zasadnicza. Klasyfikator zwraca prawdopodobieństwo, więc odpowiedź brzmi „to prawdopodobnie narusza zasady". Weryfikacja formalna zwraca rozstrzygnięcie z uzasadnieniem, więc odpowiedź brzmi „to jest sprzeczne z regułą trzecią". Dostawca podaje skuteczność wykrywania odpowiedzi poprawnych sięgającą dziewięćdziesięciu dziewięciu procent, przy czym liczbę tę traktuj jako deklarację do sprawdzenia na własnych regułach.

Zastosowania są węższe, niż sugeruje sam opis. To działa tam, gdzie reguły dają się wyrazić logicznie: dostępność produktów, warunki cenowe, zgodność z regulaminem, kryteria kwalifikacji do usługi. Nie działa tam, gdzie ocena zależy od kontekstu społecznego albo tonu wypowiedzi.

Ta funkcja stała się ogólnie dostępna w sierpniu 2025 roku, po wersji zapoznawczej ogłoszonej w grudniu 2024 roku.

Poziomy jakości i wsparcie dla kodu

Usługa rozróżnia dwa poziomy przetwarzania i to rozróżnienie ma konsekwencje, o których łatwo nie wiedzieć.

Poziom wyższy rozszerza wykrywanie na treść w elementach kodu: komentarze, nazwy zmiennych i funkcji oraz łańcuchy znaków. Na poziomie podstawowym te miejsca pozostają nieprzejrzane.

Ma to znaczenie przy asystentach programistycznych i wszędzie tam, gdzie model generuje kod. Instrukcja ukryta w komentarzu albo treść niepożądana wpisana jako nazwa zmiennej przechodzi przez filtr, który patrzy wyłącznie na prozę.

Na tym samym poziomie działa wykrywanie wycieku promptu systemowego, którego na poziomie podstawowym nie ma. Jeśli Twój prompt systemowy zawiera cokolwiek, czego użytkownik nie powinien zobaczyć, to jest argument rozstrzygający.

Pułapka z logami

To jest szczegół, który potrafi zniweczyć cały sens wdrożenia, a nie pojawia się w materiałach handlowych.

Treść zablokowana przez którąkolwiek z polityk trafia do logów wywołań modelu jako zwykły tekst, o ile te logi masz włączone. Znaczy to, że dane osobowe, które filtr wykrył i zamaskował w odpowiedzi do użytkownika, leżą w pełnej postaci w dzienniku.

Konsekwencje są dwie. Przy wymogach dotyczących przetwarzania danych osobowych log staje się kolejnym miejscem, które trzeba objąć retencją, kontrolą dostępu i szyfrowaniem. Oraz: jeśli filtr wdrożyłeś właśnie po to, żeby dane nie były gdzieś zapisywane, samo włączenie logów podważa cel.

Rozwiązania są dwa, oba niewygodne. Można wyłączyć logi wywołań, tracąc materiał do diagnostyki. Można je zostawić i objąć tym samym reżimem co dane produkcyjne. Trzeciej drogi tu nie ma i decyzję warto podjąć świadomie, zanim ktoś z zewnątrz o to zapyta.

Cennik i jak go policzyć

Rozliczenie idzie od jednostek tekstu, gdzie jedna jednostka to do tysiąca znaków, a stawka podawana jest za tysiąc jednostek.

Filtry treści oraz tematy zabronione kosztują po piętnaście centów za tysiąc jednostek, tyle samo na obu poziomach przetwarzania, a filtrowanie obrazów rozlicza się osobno, po 0,00075 dolara za obraz. Filtry słów i filtry danych wrażliwych oparte o wyrażenia regularne są bezpłatne. Filtry danych wrażliwych oparte o model kosztują dziesięć centów za tysiąc jednostek, tyle samo co sprawdzanie oparcia w kontekście. Weryfikacja formalna kosztuje siedemnaście centów za tysiąc jednostek na każdą politykę.

Ostatnie zdanie zawiera pułapkę arytmetyczną. Stawka jest naliczana za politykę, więc trzy polityki weryfikacji formalnej to trzykrotność tej kwoty za ten sam tekst. Przy kilku regułach biznesowych opisanych osobno rachunek rośnie szybciej, niż wynikałoby z liczby zapytań.

Każdy rodzaj filtra rozlicza się niezależnie, a płacisz wyłącznie za te, które włączyłeś. To jest zaproszenie do dyscypliny: włączenie wszystkiego, bo tak bezpieczniej, mnoży koszt przez liczbę mechanizmów, z których większość nie dotyczy Twojego przypadku.

Policz jedno wywołanie na własnych danych, zanim wpiszesz to do budżetu. Weź dziesięć realnych interakcji, policz znaki wchodzące do każdego włączonego filtra, podziel przez tysiąc i pomnóż przez dzienny wolumen. Przy sprawdzaniu oparcia dochodzi jeszcze rozmiar źródeł, który zwykle przekracza rozmiar samej odpowiedzi.

Wersjonowanie i praca zespołu

Konfiguracja zabezpieczeń jest osobnym zasobem z własnymi wersjami, i to jest cecha, którą warto wykorzystać, zamiast odkryć przypadkiem.

Wersja robocza służy do eksperymentów, a wersje ponumerowane są niezmienne. Aplikacja wskazuje konkretną wersję, więc zmiana progów przez kogoś w panelu nie wchodzi natychmiast na produkcję. To jedyna sensowna droga, bo filtr zmieniony bez uprzedzenia potrafi zablokować ruch, który wcześniej przechodził, a nikt nie połączy tego ze zmianą, której nie widział.

Praktyczny układ wygląda tak: osobna konfiguracja dla środowiska testowego, osobna dla produkcyjnego, a numer wersji trzymany w zmiennych środowiskowych aplikacji, a nie w kodzie. Podniesienie wersji staje się wtedy wdrożeniem, które da się cofnąć.

Warto też ustalić, kto jest właścicielem tej konfiguracji. Progi filtrów są decyzją produktową, a nie techniczną, bo rozstrzygają, jaki odsetek prawdziwych użytkowników zostanie zatrzymany. Zespół, w którym nikt nie odpowiada za tę liczbę, prędzej czy później dostaje ustawienia dobrane przez osobę, która akurat miała dostęp.

Ostatnia rzecz to obserwowanie zdarzeń. Odpowiedź zawiera informację, która polityka zadziałała, więc zapisywanie tego razem z identyfikatorem sesji daje materiał do stwierdzenia, czy filtr działa i czy blokuje właściwe rzeczy. Bez tych danych zmiana progów jest zgadywaniem.

Opóźnienie i wpływ na odczucia użytkownika

Każde sprawdzenie to dodatkowy czas i przy strumieniowaniu odpowiedzi robi się z tego problem projektowy, a nie tylko wydajnościowy.

Sprawdzenie wejścia jest proste: dokładasz je przed wywołaniem modelu i użytkownik czeka trochę dłużej na pierwszy znak. Sprawdzenie wyjścia jest trudniejsze, bo albo czekasz z pokazaniem czegokolwiek do końca generowania, tracąc cały zysk ze strumieniowania, albo sprawdzasz fragmentami i ryzykujesz wycofanie tekstu, który użytkownik już przeczytał.

Trzecia droga polega na sprawdzaniu fragmentami przy jednoczesnym opóźnieniu wyświetlania o jeden fragment. Użytkownik widzi płynny strumień, a Ty masz zawsze jeden kawałek zapasu na zatrzymanie. Kosztuje to niewielkie opóźnienie startu i jest zwykle najlepszym kompromisem.

Sprawdzanie oparcia w źródłach do tego układu nie pasuje, bo wymaga całej odpowiedzi razem ze źródłami. Przy aplikacji opartej o wyszukiwanie w dokumentach trzeba więc wybrać: albo strumieniowanie bez tej kontroli, albo ta kontrola bez strumieniowania.

Bedrock Guardrails kontra alternatywy

Wyróżnikiem pierwszego wiersza są dwie rzeczy, których pozostałe nie robią w tym samym stopniu: tematy zabronione opisane językiem naturalnym oraz weryfikacja formalna reguł. Jeśli Twój problem brzmi „model nie może obiecywać rzeczy niezgodnych z regulaminem", to jest jedyna pozycja z tej listy, która odpowiada wprost.

Argument przeciw jest znany i ten sam co przy każdej usłudze wbudowanej w chmurę: warstwa, którą łatwo trzymać niezależną, zostaje związana z jednym dostawcą. Istnieje tu jednak furtka, o której warto wiedzieć.

Użycie poza wywołaniem modelu

Zabezpieczenia da się wywołać osobno, bez przechodzenia przez wywołanie modelu w tej usłudze. Podajesz tekst i identyfikator konfiguracji, dostajesz ocenę.

To zmienia obraz, bo pozwala używać tych polityk przy modelu uruchamianym gdzie indziej: u innego dostawcy, we własnej infrastrukturze albo lokalnie. Warstwa zabezpieczeń przestaje wtedy wymuszać wybór modelu.

Praktycznie oznacza to trzy wywołania na interakcję, jeśli sprawdzasz wejście, treść pobraną z zewnątrz i wyjście. Każde kosztuje osobno i każde dokłada opóźnienie, więc warto od razu ustalić, które sprawdzenia są konieczne, a nie włączać wszystkich z ostrożności.

Warto też zaplanować zachowanie przy awarii. Wywołanie zewnętrzne kiedyś odpowie wolno albo wcale, a decyzja o przepuszczeniu bądź zablokowaniu ruchu musi zapaść świadomie i być zapisana w kodzie razem z limitem czasu.

Wdrożenie i dobór siły filtrów

Siła filtrowania ustawiana jest osobno dla każdej kategorii i to jest właściwe podejście, o ile z niego skorzystasz.

Zacznij od trybu obserwacji. Zapisuj oceny, nie blokuj niczego, zbierz kilka tysięcy realnych interakcji. Dopiero na tych danych zobaczysz, ile zwykłej pracy zatrzymałaby każda kategoria przy każdym ustawieniu.

Progi dobieraj do dziedziny. Serwis medyczny musi przepuszczać opisy objawów, serwis prawniczy cytaty z akt, a narzędzie dla zespołów bezpieczeństwa opisy podatności. Wszystkie trzy przy ustawieniach ogólnych będą blokowane, i wszystkie trzy to treści merytoryczne.

Tematy zabronione opisuj wąsko. Temat sformułowany ogólnie, na przykład „finanse", wyłączy połowę rozmów, które chcesz obsłużyć. Temat sformułowany konkretnie, na przykład „rekomendowanie konkretnych instrumentów inwestycyjnych", robi dokładnie to, co miał zrobić.

Komunikat blokady pisz ogólnie. Informowanie użytkownika, którą regułę naruszył i jak dokładnie, zamienia filtr w narzędzie do eksperymentowania i ułatwia znalezienie sformułowania, które przechodzi.

Typowe błędy

Pierwszy to włączenie wszystkich polityk naraz. Koszt mnoży się przez liczbę mechanizmów, opóźnienie rośnie, a większość z nich nie dotyczy Twojego przypadku.

Drugi to pominięcie kwestii logów. Zablokowana treść trafia do dziennika w pełnej postaci, więc filtr chroniący dane osobowe nie chroni ich w tym jednym miejscu.

Trzeci to liczenie kosztu weryfikacji formalnej bez uwzględnienia liczby polityk. Stawka jest za politykę, więc trzy reguły opisane osobno kosztują trzykrotnie.

Czwarty to sprawdzanie wyłącznie tego, co wpisał użytkownik. Wstrzyknięcie pośrednie wchodzi przez dokumenty i treść pobraną z sieci.

Piąty to zbyt szerokie tematy zabronione. Jedno słowo w opisie potrafi wyłączyć całą kategorię rozmów, których obsługa była celem aplikacji.

Szósty to poleganie na poziomie podstawowym przy asystencie generującym kod. Bez rozszerzenia na elementy kodu treść w komentarzach i nazwach zmiennych przechodzi bez sprawdzenia.

FAQ

Jakie polityki oferuje Bedrock Guardrails?

Sześć rodzajów: filtry treści z kategoriami szkód i atakami na prompt, tematy zabronione opisane językiem naturalnym, filtry słów na dokładne dopasowanie, filtry danych wrażliwych, sprawdzanie oparcia w podanych źródłach oraz weryfikację formalną reguł, które sam zapisujesz.

Czym jest weryfikacja przez wnioskowanie automatyczne?

Sprawdzaniem, czy odpowiedź modelu daje się pogodzić z regułami zapisanymi przez Ciebie językiem naturalnym, wykonanym metodą formalną zamiast klasyfikacji. Zwraca rozstrzygnięcie z uzasadnieniem, a nie prawdopodobieństwo, i stała się ogólnie dostępna w sierpniu 2025 roku.

Ile to kosztuje?

Rozliczenie idzie od jednostek tekstu po tysiąc znaków, za tysiąc jednostek. Filtry słów i wzorce oparte o wyrażenia regularne są bezpłatne, filtry treści i tematy zabronione kosztują po piętnaście centów, filtry danych wrażliwych i sprawdzanie oparcia po dziesięć centów, a weryfikacja formalna siedemnaście centów za każdą politykę osobno.

Czy da się użyć tych zabezpieczeń z modelem spoza tej usługi?

Tak, zabezpieczenia da się wywołać osobno, podając sam tekst i identyfikator konfiguracji. Pozwala to filtrować treść przy modelu uruchamianym u innego dostawcy albo we własnej infrastrukturze, kosztem dodatkowego wywołania sieciowego.

Czy to wystarczy do ochrony danych osobowych?

Filtry wykrywają i maskują dane osobowe w treści, natomiast zablokowana zawartość trafia do logów wywołań w pełnej postaci. Przy poważnych wymogach warto rozważyć dodatkowo rozwiązanie działające lokalnie, na przykład Presidio, i objąć logi tym samym reżimem co dane produkcyjne.

Opis polityk stoi w dokumentacji usługi, a ogłoszenie o weryfikacji formalnej w komunikacie AWS.