NeMo Guardrails, bariery wokół modelu

NeMo Guardrails, czyli warstwa kontroli między aplikacją a modelem

Model językowy w produkcie firmowym stwarza problem, którego zwykły kod nie ma: nie da się z góry przewidzieć, co odpowie. Instrukcja systemowa opisuje, jak ma się zachowywać, i jest sugestią, a nie ograniczeniem.

NeMo Guardrails dokłada warstwę, która to ograniczenie wprowadza. Siedzi między Twoją aplikacją a modelem, przepuszcza przez siebie ruch w obie strony i sprawdza go według reguł, które opisujesz.

Projekt jest otwarty na licencji swobodnej i rozwijany przez NVIDIA. Działa z modelami różnych dostawców, więc nie wiąże Cię ze sprzętem ani usługami producenta, mimo że pochodzi od niego.

Pięć rodzajów barier

Konstrukcja opiera się na barierach ustawianych w różnych punktach przepływu, i warto rozróżniać je, bo każda rozwiązuje inny problem.

Bariera wejściowa sprawdza to, co przychodzi od użytkownika, zanim trafi do modelu. Tu wyłapuje się próby obejścia instrukcji, treści niedozwolone i dane, które nie powinny opuścić Twojej infrastruktury.

Bariera dialogowa steruje przebiegiem rozmowy. Pozwala określić, o czym asystent rozmawia, a o czym nie, i co robi, gdy padnie pytanie spoza zakresu. To jest wyróżnik tego narzędzia, bo większość konkurencji filtruje pojedyncze wiadomości, a nie prowadzi rozmowy.

Bariera pobierania sprawdza treść wyciągniętą ze źródeł zewnętrznych, zanim trafi do kontekstu modelu. To odpowiedź na problem opisany w tekście o serwerze plikowym: dokument może zawierać instrukcję, a model nie odróżnia jej od danych.

Bariera wykonania kontroluje wywołania narzędzi. Bariera wyjściowa sprawdza odpowiedź, zanim zobaczy ją użytkownik. Wykrywanie prób obejścia zabezpieczeń nie jest szóstym rodzajem bariery, tylko jednym z zastosowań bariery wejściowej, obok kontroli tematu i maskowania danych osobowych.

Praktyczna wskazówka: nie włączaj wszystkich pięciu na starcie. Każda dokłada opóźnienie i koszt, a większość zastosowań potrzebuje dwóch albo trzech. Zacznij od wejściowej i wyjściowej, a resztę dokładaj wtedy, gdy zmierzysz, że są potrzebne.

Colang, czyli reguły opisane osobnym językiem

Reguły zapisuje się w języku stworzonym do tego celu, a nie w zwykłym kodzie. To decyzja, która ma zalety i cenę.

define user ask about competitors
  "co sądzisz o produktach konkurencji"
  "czy X jest lepszy od was"
  "porównaj się z Y"

define bot decline competitor comparison
  "Nie porównuję nas z innymi produktami. Chętnie opowiem o tym, co robimy."

define flow
  user ask about competitors
  bot decline competitor comparison

Zaleta jest realna: reguły są czytelne dla osoby nietechnicznej i można je przeglądać jak dokument, a nie jak kod. W organizacji, w której dział prawny albo zgodności ma wpływ na to, co asystent mówi, to bywa rozstrzygające.

Ceną jest kolejny język do nauczenia się. Przy prostych regułach składnia jest przejrzysta, przy złożonych przepływach wielotorowych przestaje taka być, a błąd w regule objawia się zachowaniem, którego nikt nie planował, zamiast komunikatem o błędzie.

Warto też wiedzieć, że istnieją dwie wersje tego języka i materiały w sieci opisują obie. Sprawdź, którą opisuje przykład, zanim spędzisz wieczór na dochodzeniu, dlaczego nie działa.

Realny koszt

Ta sekcja jest najważniejsza przy decyzji i najczęściej pomijana w materiałach o narzędziach tej klasy.

Bariery oparte na dopasowaniu wzorców są tanie. Sprawdzenie wejścia pod kątem znanych prób obejścia dokłada kilkadziesiąt milisekund, co ginie w czasie odpowiedzi całej reszty.

Bariery oparte na modelu są zupełnie inną kategorią. Sprawdzenie treści przez osobny model językowy dokłada od dwustu do pięciuset milisekund na jedno przejście, a przy sprawdzaniu wejścia i wyjścia to dwa przejścia.

Przy barierze wykorzystującej mocny model jako sędziego rachunek robi się poważny. Opóźnienie rzędu ponad sekundy w każdą stronę oznacza, że odpowiedź, która trwała dwie sekundy, trwa teraz cztery albo pięć.

Koszt finansowy idzie tą samą drogą. Każde sprawdzenie to wywołanie modelu z własnym promptem, więc rozbudowany zestaw barier potrafi podwoić albo potroić rachunek za samą rozmowę.

Wniosek nie brzmi „nie używaj", tylko określa kolejność. Zacznij od barier tanich i zmierz, ile problemów wyłapują. Bariery kosztowne dokładaj tam, gdzie tanie nie wystarczają, a nie wszędzie na wszelki wypadek.

Granice tego podejścia

Trzeba je nazwać wprost, bo nazwa narzędzia sugeruje szczelność, której żadne rozwiązanie tej klasy nie daje.

Pierwsza dotyczy agentów wielokrokowych. Bariera wykonania obejmuje działania wywoływane wewnątrz tej warstwy, a nie kroki, które Twój agent robi po swojej stronie. Doszedł do tego eksperymentalny silnik sprawdzający wywołania narzędzi i zwracane wyniki, ale wyłącznie strukturalnie: czy narzędzie jest zadeklarowane, czy argumenty pasują do schematu i czy wynik odpowiada wcześniejszemu wywołaniu. Treści samych argumentów nikt tam nie ocenia. Przy agencie wykonującym dziesięć kroków większość ruchu nadal odbywa się poza zasięgiem tej warstwy.

Druga dotyczy skuteczności. Bariery wyłapują znane wzorce i typowe próby, a nie wszystkie możliwe. Sformułowanie, którego nikt nie przewidział, przejdzie, i to nie jest wada implementacji, tylko właściwość problemu.

Trzecia dotyczy fałszywych alarmów. Bariera zbyt czuła blokuje pytania niewinne, a użytkownik dostaje odmowę bez zrozumiałego powodu. To bywa gorsze dla produktu niż przepuszczenie treści, którą można było odfiltrować.

Czwarta dotyczy utrzymania. Nie ma wariantu hostowanego przez producenta: jest płatny wariant mikrousługi ze wsparciem w ramach oferty korporacyjnej, ale i tak stoi na Twojej infrastrukturze, razem z modelami pomocniczymi, magazynem wektorów i monitorowaniem. Sam pakiet z zależnościami zajmuje sporo miejsca, co przy wdrożeniach bezserwerowych bywa blokujące.

Uczciwy wniosek brzmi tak: to jest warstwa zmniejszająca ryzyko, a nie usuwająca je. Przy zastosowaniach, w których błąd jest kosztowny, potrzebny jest jeszcze człowiek zatwierdzający operacje i ograniczenia po stronie uprawnień, a nie sama kontrola treści.

NeMo Guardrails kontra alternatywy

Ostatni wiersz nie jest alternatywą, tylko fundamentem, i warto to powiedzieć wprost. Model, który nie ma dostępu do narzędzia usuwającego dane, nie usunie danych niezależnie od tego, co ktoś mu napisze. Żadna warstwa kontroli treści nie zastępuje tego ograniczenia.

Wybór między pierwszym a drugim wierszem zależy od tego, czy potrzebujesz sterowania przebiegiem rozmowy. Jeśli chodzi wyłącznie o odfiltrowanie treści niedozwolonych, gotowe mechanizmy u dostawcy modelu są tańsze i nie wymagają utrzymania.

Za drugim wierszem stoją konkretne usługi i warto je nazwać. Bedrock Guardrails dokłada do moderacji tematy zabronione i weryfikację reguł biznesowych przez wnioskowanie automatyczne, czego opisywane tu bariery nie robią. Azure AI Content Safety daje dojrzalszą moderację i wykrywanie wstrzyknięć, za to w czterech sztywnych kategoriach szkód. Żadna z nich nie prowadzi rozmowy po scenariuszu, obie rozliczają się od przetworzonego tekstu i obie wiążą Cię z jedną chmurą.

Jak dobrać bariery do zastosowania

Skoro każda kosztuje, warto mieć sposób wyboru, a nie włączać wszystkiego i patrzeć, co się stanie.

Zacznij od pytania, co może pójść nie tak i jakie to niesie konsekwencje. Asystent odpowiadający na pytania o produkt może powiedzieć coś nieprawdziwego, a to kosztuje reputację. Asystent obsługujący zwroty może zatwierdzić zwrot, którego nie powinien, a to kosztuje pieniądze. Dwie różne odpowiedzi wymagają dwóch różnych barier.

Potem sprawdź, czy problem da się rozwiązać taniej. Zakres tematyczny bywa skuteczniej ograniczony przez to, jakie narzędzia model w ogóle ma, niż przez sprawdzanie treści po fakcie. Fakty pochodzące z dokumentacji zamiast z pamięci modelu rozwiązują problem nieprawdziwych odpowiedzi u źródła.

Trzecim krokiem jest pomiar na realnych rozmowach. Weź sto prawdziwych pytań od użytkowników i sprawdź, ile z nich bariera zablokowała słusznie, a ile niesłusznie. Bez tej liczby strojenie czułości jest zgadywaniem, a fałszywe alarmy widać dopiero wtedy, gdy zaczną spływać zgłoszenia.

Czwartym jest obserwacja po wdrożeniu. Narzędzie udostępnia miary mówiące, ile razy która bariera zadziałała, i warto na nie patrzeć, bo bariera, która nie zadziałała ani razu przez miesiąc, kosztuje przy każdym zapytaniu i nie daje nic.

Wdrożenie i utrzymanie

Kilka rzeczy praktycznych, o których warto wiedzieć przed uruchomieniem tego na produkcji.

Narzędzie działa jako warstwa pośrednicząca, więc trzeba je gdzieś uruchomić. Najprostszy układ to osobna usługa odpytywana przez aplikację, z jedną kopią modeli pomocniczych w pamięci. Wczytywanie ich przy każdym żądaniu jest kosztowne i wolne.

Modele pomocnicze warto pobrać z góry i wbudować w obraz, zamiast ściągać przy starcie. W środowisku bez dostępu do internetu albo przy nagłym zwiększeniu liczby instancji pobieranie kończy się nieudanym uruchomieniem w najgorszym momencie.

Zaplanuj, co się dzieje, gdy warstwa kontroli przestanie odpowiadać. Dwa sensowne zachowania to przepuszczenie ruchu bez sprawdzenia albo odmowa obsługi, i wybór między nimi zależy od tego, co jest gorsze w Twoim przypadku. Domyślne zachowanie warto sprawdzić, a nie zakładać.

Zapisuj, które bariery zadziałały i przy jakiej treści. To jest jedyny sposób, żeby po miesiącu odpowiedzieć na pytanie, czy zestaw reguł działa, i jedyne źródło przykładów do poprawienia tych, które działają źle.

Kiedy to ma sens

Warto rozdzielić przypadki, bo narzędzie tej klasy bywa dokładane odruchowo.

Ma sens przy asystencie rozmawiającym z klientami zewnętrznymi. Tam odpowiedź nieprzewidziana trafia do osoby spoza organizacji, a firma odpowiada za to, co powiedział jej produkt.

Ma sens przy wymogach branżowych. Sektor finansowy, ochrona zdrowia i obszary regulowane wymagają wykazania, że wprowadzono kontrolę, a nie tylko że się starano. Reguły zapisane osobno i możliwe do przeglądu są tu argumentem.

Ma sens przy treści pochodzącej z zewnątrz. Asystent czytający zgłoszenia od użytkowników, dokumenty od dostawców albo strony internetowe pracuje na materiale, którego nikt nie kontroluje.

Nie ma sensu przy narzędziu wewnętrznym używanym przez zespół, który je zbudował. Koszt opóźnienia i utrzymania nie zwraca się tam, gdzie użytkownicy znają ograniczenia i nikt nie ponosi konsekwencji nietrafionej odpowiedzi.

Nie ma też sensu jako jedyne zabezpieczenie przy operacjach zmieniających stan. Wysyłka wiadomości, modyfikacja danych i płatność wymagają potwierdzenia albo ograniczonych uprawnień, a nie sprawdzenia treści.

Typowe błędy

Pierwszy to włączenie wszystkich barier na starcie. Każda dokłada opóźnienie i koszt, a większość zastosowań potrzebuje dwóch albo trzech.

Drugi to używanie mocnego modelu jako sędziego przy każdym sprawdzeniu. Opóźnienie i rachunek rosną wtedy wielokrotnie, a tańszy model wystarcza do większości kontroli.

Trzeci to traktowanie barier jako szczelnego zabezpieczenia. Wyłapują znane wzorce, a nie wszystkie możliwe sformułowania.

Czwarty to pominięcie ograniczeń po stronie uprawnień. Kontrola treści nie zastąpi tego, że model po prostu nie ma dostępu do niebezpiecznego narzędzia.

Piąty to zbyt czułe reguły. Odmowa przy niewinnym pytaniu psuje produkt bardziej niż przepuszczenie treści, którą można było odfiltrować.

Szósty to mieszanie materiałów opisujących dwie wersje języka reguł. Przykład sprzed dwóch lat może nie działać w bieżącej składni, a komunikat o błędzie rzadko wskazuje na to jako przyczynę.

Siódmy to pozostawianie barier, które nie zadziałały ani razu. Kosztują przy każdym zapytaniu, a miary pokazują wprost, które z nich są martwe.

FAQ

Czym różni się od gotowych filtrów u dostawcy modelu?

Sterowaniem przebiegiem rozmowy. Gotowe filtry oceniają pojedyncze wiadomości, a to narzędzie pozwala opisać, o czym asystent rozmawia, a o czym nie, i co robi przy pytaniu spoza zakresu. Kosztem jest utrzymanie i osobny język do nauczenia się.

Ile to kosztuje pod względem opóźnienia?

Zależy od rodzaju bariery. Sprawdzenia oparte na wzorcach dokładają kilkadziesiąt milisekund. Sprawdzenia wykorzystujące osobny model dokładają od dwustu do pięciuset milisekund na przejście, a przy mocnym modelu jako sędzim opóźnienie przekracza sekundę w każdą stronę.

Czy to chroni przed wstrzykiwaniem poleceń?

Zmniejsza ryzyko, a nie usuwa je. Bariera sprawdzająca treść pobraną z zewnątrz wyłapuje znane wzorce, natomiast sformułowanie nieprzewidziane przejdzie. Przy operacjach zmieniających stan potrzebne są jeszcze ograniczenia uprawnień i potwierdzanie przez człowieka.

Czy działa z agentami wielokrokowymi?

Częściowo. Domyślnie sprawdza wejście i wyjście rozmowy. Eksperymentalny silnik dodany później waliduje też wywołania narzędzi i ich wyniki, natomiast wyłącznie pod kątem zgodności ze schematem, a nie treści argumentów. Przy agencie wykonującym wiele kroków duża część ruchu pozostaje poza zasięgiem tej warstwy.

Czy potrzebuję sprzętu od tego producenta?

Nie. Projekt jest otwarty i działa z modelami różnych dostawców, w tym uruchamianymi lokalnie. Integruje się też z bibliotekami do budowy przepływów, takimi jak LangChain i LangGraph.

Dokumentacja stoi na stronie producenta, a opis metryk w osobnym dziale.