NVIDIA NeMo Guardrails

Cześć, tu Alex z DEV STORIES DOT EU. NVIDIA NeMo Guardrails, odcinek 1 z 10. Nigdy nie podłączyłbyś surowej bazy danych bezpośrednio do publicznego internetu, a mimo to wiele aplikacji wystawia nieograniczone modele językowe bezpośrednio do użytkowników końcowych. Poleganie wyłącznie na system prompt w celu utrzymania bezpieczeństwa to krucha architektura. Dzisiaj omówimy imperatyw AI Guardrails: kluczowe abstrakcje. NeMo Guardrails działa jako programowalna warstwa pośrednicząca między twoją aplikacją a modelem językowym. Nie zastępuje twojego modelu. Zamiast tego tworzy oddzielny pipeline niezależnych testów bezpieczeństwa, nazywanych rails. Zamiast błagać model o poprawne zachowanie przez skomplikowany prompt engineering, zarządzasz bezpieczeństwem za pomocą tej deterministycznej warstwy. Weźmy na przykład bota obsługi klienta. Użytkownik wysyła wiadomość, system pobiera odpowiednie artykuły pomocy technicznej, model przygotowuje odpowiedź i może wywołać akcję na backendzie, na przykład procesowanie zwrotu pieniędzy. Na każdym z tych etapów potrzebujesz innego rodzaju zabezpieczeń. Żeby to obsłużyć, Guardrails definiuje pięć różnych typów railsów. Najpierw wiadomość użytkownika trafia do Input Rail. Ten rail sprawdza tekst, zanim główny model językowy w ogóle go zobaczy. Jeśli użytkownik spróbuje ataku prompt injection lub wyśle mocno toksyczny tekst, Input Rail natychmiast przechwytuje wiadomość. Zatrzymuje pipeline i zwraca predefiniowaną odmowę. Główny model nigdy nie przetwarza złośliwego tekstu, co oszczędza moc obliczeniową i zapobiega exploitom. Jeśli input jest bezpieczny, system ewaluuje Dialog Rails. Zarządzają one oczekiwanym flow konwersacji. Jeśli użytkownik zapyta bota o opinię na temat konkurencji, Dialog Rail identyfikuje temat. Wymusza na bocie podążanie z góry ustaloną ścieżką, na przykład odpowiadając, że rozmawia tylko o własnych produktach. Dialog Rails zapobiegają zbaczaniu modelu z tematu lub odpowiadaniu na pytania, którymi nie powinien się zajmować. Następnie, kiedy twój bot przeszukuje bazę wiedzy, żeby osadzić swoją odpowiedź w kontekście, do akcji wkraczają Retrieval Rails. Sprawdzają one chunki tekstu pobrane z bazy danych, zanim zostaną dołączone do promptu modelu. Jeśli źle skonfigurowane wyszukiwanie przypadkowo pobierze wewnętrzny dokument HR zamiast publicznej instrukcji, Retrieval Rail wykrywa poufne informacje i usuwa je z context window. Jeśli konwersacja wymaga od bota wykonania zadania, do akcji wkraczają Execution Rails. Kontrolują one, jakie customowe akcje model ma prawo wywołać. Kiedy model prosi o wykonanie kodu lub wywołanie zewnętrznego narzędzia, Execution Rail weryfikuje, czy ta konkretna akcja jest dozwolona w obecnym stanie konwersacji. Blokuje wykonanie nieautoryzowanych poleceń. Na koniec mamy Output Rails. To ostatnia linia obrony. Po wygenerowaniu odpowiedzi przez model, Output Rail ewaluuje tekst, zanim dotrze on do użytkownika. Sprawdza go pod kątem halucynacji, niewłaściwego tonu lub wycieków wrażliwych danych. Jeśli tekst nie przejdzie testu, Output Rail przechwytuje go i modyfikuje lub blokuje ostateczną wiadomość. Ta architektura fundamentalnie zmienia sposób, w jaki budujesz aplikacje generatywne. Przestajesz polegać na probabilistycznym silniku, żeby pilnował własnego zachowania, a zamiast tego budujesz deterministyczną sieć bezpieczeństwa, która niezależnie kontroluje inputy, logikę i outputy. Tak przy okazji, jeśli uważasz te odcinki za przydatne i chcesz wesprzeć podcast, możesz wyszukać DevStoriesEU w serwisie Patreon. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórz dalej!

Cześć, tu Alex z DEV STORIES DOT EU. NVIDIA NeMo Guardrails, odcinek 2 z 10. Pisanie czystego Pythona, żeby zarządzać złożonymi, rozgałęzionymi state machines dialogów, to absolutny koszmar. W momencie, gdy użytkownik odejdzie od sztywnego skryptu, twoja hardcodowana logika się sypie. Architektura konfiguracji w NeMo Guardrails rozwiązuje ten problem, traktując konwersacje jako event-driven flows, a nie statyczny kod. NeMo Guardrails oddziela mechanikę twojej aplikacji od logiki konwersacji. Dzieje się to za pomocą dwóch odrębnych elementów konfiguracji. Po pierwsze, masz swój plik konfiguracyjny YAML. Odpowiada on za cały wiring modeli. To właśnie w nim deklarujesz swój główny model językowy, definiujesz embedding models i rejestrujesz customowe akcje aplikacji. Plik YAML spina całą infrastrukturę pod spodem. Dostarcza silnik, ale nie wie absolutnie nic o tym, co użytkownik tak naprawdę powie. Samą logiką konwersacji zarządza z kolei Colang 2.0. Colang to event-driven język do modelowania interakcji. Zamiast pisać standardowy, imperatywny kod z niekończącymi się instrukcjami warunkowymi, żeby śledzić, w którym miejscu konwersacji jest użytkownik, definiujesz flowy. Flow modeluje sekwencję interakcji. Kiedy użytkownik wysyła wiadomość, generuje to event. State machine przechwytuje ten event, szuka aktywnego flow, który pasuje do tej interakcji, i dyktuje asystentowi kolejny ruch. I to jest ta kluczowa część. Colang używa Natural Language Descriptions, żeby wypełnić lukę między ścisłym kodem a ludzką niejednoznacznością. Zamiast pisać skomplikowane wyrażenia regularne do parsowania wiadomości użytkownika, instruujesz system za pomocą ludzkiego języka bezpośrednio w logice twojego flow. Łączysz te opisy z generation operator, który zapisuje się po prostu jako trzy kropki. Kiedy state machine napotka te trzy kropki, tymczasowo wstrzymuje execution. Przekazuje obecny kontekst i twój natural language description do modelu językowego pod spodem, prosząc go o wygenerowanie lub wyekstrahowanie dokładnie tej wartości, której potrzebujesz. Spójrzmy na konkretny scenariusz, taki jak rezerwacja biletu lotniczego. Musisz wiedzieć, kiedy użytkownik chce lecieć. W swoim pliku Colang definiujesz flow rezerwacji lotu. Wewnątrz tego flow mówisz systemowi, żeby poczekał, aż użytkownik coś napisze. Kiedy to zrobi, musisz wyekstrahować datę. Deklarujesz zmienną kontekstową, nazwijmy ją flight date. Przypisujesz jej wartość natural language description, dosłownie wpisując frazę „the date the user wants to fly”, a zaraz po niej generation operator, czyli te trzy kropki. Kiedy użytkownik powie „Potrzebuję biletu na przyszły wtorek”, state machine Colanga przechwytuje ten event. Trafia na twoje przypisanie zmiennej. Przekazuje wiadomość użytkownika i twoją instrukcję w języku naturalnym do modelu językowego. Model czyta kontekst, identyfikuje „przyszły wtorek” jako wartość docelową i ją zwraca. Generation operator resolvuje, a twoja zmienna kontekstowa bezpiecznie przechowuje wyekstrahowaną datę. Twój flow przechodzi wtedy do kolejnego kroku, którym może być wywołanie zewnętrznego API do rezerwacji, zdefiniowanego w twojej konfiguracji YAML. Prawdziwą siłą tej architektury jest to, że przestajesz walczyć z dialogue states za pomocą sztywnego kodu. Pozwalasz, żeby plik YAML spiął na sztywno statyczną infrastrukturę, a Colangowi pozwalasz użyć zdolności rozumowania modelu językowego, żeby nawigować po nieprzewidywalnej rzeczywistości ludzkiej konwersacji. Chciałbym poświęcić chwilę, żeby podziękować ci za słuchanie — to bardzo nam pomaga. Trzymaj się!

Cześć, tu Alex z DEV STORIES DOT EU. NVIDIA NeMo Guardrails, odcinek 3 z 10. Poleganie na ogromnym modelu z siedemdziesięcioma miliardami parametrów do podstawowej moderacji treści to ogromne marnowanie compute'u. Jest to wolne, drogie i zabiera moc obliczeniową potrzebną do generowania właściwych odpowiedzi. Rozwiązaniem jest wyspecjalizowane Content Safety z Nemotron NIM. Zamiast wymagać od głównego modelu twojej aplikacji zarówno pisania kodu, jak i sprawdzania toksyczności, dzielisz to obciążenie. Główny model zajmuje się złożonym wnioskowaniem i generowaniem. Drugi, znacznie mniejszy model odpowiada za bezpieczeństwo. Konkretnie, przyglądamy się modelowi Llama trzy kropka jeden Nemotron Safety Guard 8B V3. To model z ośmioma miliardami parametrów, po fine-tuningu zrobionym wyłącznie pod jedno zadanie, jakim jest ocena bezpieczeństwa treści. Działa jako samodzielny mikroserwis, czyli NIM, który NeMo Guardrails odpytuje przez API. Aby to skonfigurować, definiujesz Nemotron NIM w swojej konfiguracji Guardrails jako osobny model. Oznaczasz jego typ jako content safety, podczas gdy twój główny model pozostaje typem main. To rozróżnienie jest kluczowe, ponieważ Guardrails routuje ruch inaczej na podstawie tych etykiet. Po skonfigurowaniu, aktywujesz safety guard jako input rail oraz output rail. Gdy użytkownik wysyła prompt, Guardrails przechwytuje go, zanim w ogóle dotrze do twojego głównego modelu. Wysyła ten prompt do safety NIM Nemotrona. NIM ocenia tekst pod kątem dwudziestu trzech konkretnych kategorii niebezpiecznych treści. Te kategorie obejmują wszystko, od mowy nienawiści i przemocy, po treści seksualne i planowanie przestępstw. Wyobraź sobie wielojęzyczną aplikację, w której użytkownik wysyła prompt po francusku, prosząc o instrukcje krok po kroku, jak odpalić samochód na krótko. Input rail to wyłapuje. Guardrails wysyła francuski tekst do Nemotron NIM. Ponieważ model bezpieczeństwa jest wytrenowany na wielojęzycznych danych dotyczących bezpieczeństwa, rozumie intencję niezależnie od języka. Oflagowuje request jako podpadający pod kategorię porad kryminalnych i zwraca sygnał unsafe z powrotem do Guardrails. Guardrails wtedy natychmiast zatrzymuje proces i zwraca użytkownikowi standardowy komunikat odmowy. Twój główny model nawet nie widzi tego promptu, co oszczędza ci kosztów inferencji związanych z przetwarzaniem toksycznego requestu. Dokładnie ta sama logika działa w drugą stronę w przypadku output rails. Jeśli pozornie nieszkodliwy prompt w jakiś sposób oszuka główny model, zmuszając go do wygenerowania niebezpiecznej odpowiedzi, Guardrails przechwytuje ten wygenerowany tekst, zanim dotrze on do użytkownika. Wysyła ten output do safety NIM, sprawdza go pod kątem tych samych dwudziestu trzech kategorii i blokuje, jeśli narusza zasady. Skonfigurowanie tego wymaga zaktualizowania twoich plików konfiguracyjnych. Deklarujesz model Nemotron na swojej liście modeli, wskazując na twój endpoint NIM. Następnie włączasz domyślne flowy self-check input i self-check output, jawnie mówiąc Guardrails, aby używał twojego modelu content safety do tych sprawdzeń. Nie musisz pisać customowych promptów instruujących model, jak oceniać toksyczność. Model Nemotron oczekuje bardzo konkretnego formatu promptu do oceny tekstu, a NeMo Guardrails formatuje to wywołanie API automatycznie pod spodem. Po prostu kierujesz rails na NIM i pozwalasz mu zająć się klasyfikacją. Wydzielenie logiki moderacji do dedykowanego, mniejszego modelu gwarantuje, że twój główny model aplikacji zużywa swoje cykle na generowanie wartości, podczas gdy wyspecjalizowany guard wydajnie zajmuje się bezpieczeństwem na obwodzie. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. NVIDIA NeMo Guardrails, odcinek 4 z 10. Najprostszym sposobem, aby twój chatbot nie wywołał katastrofy wizerunkowej, jest upewnienie się, że po prostu odmówi rozmowy na ten temat. Nie możesz polegać na tym, że ogólny model językowy sam z siebie niezawodnie odrzuci każdy nieistotny lub ryzykowny temat. Dlatego używamy Enforcing Domain Boundaries z Topic Control. Ogólne modele językowe bardzo chcą pomóc. Jeśli użytkownik zada sprytne pytanie, model spróbuje na nie odpowiedzieć. Jeśli budujesz bota do obsługi klienta, chcesz, żeby rozmawiał tylko o obsłudze klienta. Potrzebujesz ścisłej granicy. Aby stworzyć tę granicę, używasz Llama 3.1 NemoGuard 8B TopicControl NIM. To specjalistyczny model zaprojektowany do jednego, konkretnego zadania. Nie generuje on odpowiedzi konwersacyjnych. On ocenia. Weźmy na przykład bota wsparcia dla telekomu. Jego zadaniem jest pomaganie użytkownikom z rachunkami za telefon, awariami sieci i pakietami danych. Użytkownik łączy się z czatem i pyta bota o opinię na temat ostatnich wyborów politycznych. Bez guardrails, twój główny model otrzymuje prompt, przetwarza go i może wygenerować nieodpowiednią odpowiedź. Dzięki NeMo Guardrails konfigurujesz Input Rail. Input Rail przechwytuje request użytkownika, zanim cokolwiek innego się wydarzy. Główny model językowy nawet nie widzi tego requestu. Kiedy użytkownik pyta o wybory, guardrail kieruje input bezpośrednio do modelu TopicControl. Kontrolujesz zachowanie tego modelu, definiując ścisłe wytyczne w jego system prompcie. Dla twojego bota telekomunikacyjnego, twój system prompt określa, że akceptowalne tematy to rachunki, status sieci i zarządzanie kontem. Model TopicControl bierze prompt użytkownika i ocenia go na podstawie tych konkretnych wytycznych. Następnie zwraca sztywną klasyfikację. Zwraca ocenę on-topic lub off-topic. Jeśli użytkownik pyta, dlaczego jego opłaty za roaming są wysokie, model TopicControl czyta prompt, sprawdza wytyczne i zwraca on-topic. Guardrail otwiera bramkę, a prompt użytkownika przechodzi do twojego głównego modelu konwersacyjnego, aby wygenerować pomocną odpowiedź. Kiedy użytkownik pyta o wybory polityczne, model TopicControl ocenia prompt pod kątem wytycznych telekomunikacyjnych. Rozpoznaje niezgodność i zwraca off-topic. Guardrail natychmiast zatrzymuje pipeline. Blokuje request przed dotarciem do twojego głównego modelu. Zamiast tego, guardrail uruchamia predefiniowaną, statyczną odpowiedź z odmową. Bot informuje użytkownika, że jest przystosowany tylko do obsługi usług telekomunikacyjnych. Użycie dedykowanego modelu do Topic Control oddziela logikę oceny od logiki konwersacyjnej. Nie marnujesz drogich cykli obliczeniowych, prosząc potężny model ogólnego przeznaczenia o sprawdzenie, czy wolno mu odpowiedzieć na pytanie. Używasz mniejszego, wysoce zoptymalizowanego modelu z ośmioma miliardami parametrów, który działa jak bramkarz przy drzwiach. Dzięki temu granice twojej domeny są ściśle egzekwowane, bez konieczności stosowania skomplikowanego i kruchego prompt engineeringu na twoim głównym modelu. Najbezpieczniejszym sposobem na obsługę requestu spoza zakresu jest upewnienie się, że twój główny silnik wnioskujący pozostaje całkowicie nieświadomy, że taki request w ogóle się pojawił. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórz dalej!

Cześć, tu Alex z DEV STORIES DOT EU. NVIDIA NeMo Guardrails, odcinek 5 z 10. Jeśli twój system retrieval-augmented generation wczytuje niezredagowaną bazę danych pracowników, łamiesz zasady compliance, zanim model językowy wygeneruje choćby jedno słowo. Gdy wrażliwe dane trafią do kontekstu promptu, tracisz kontrolę nad tym, gdzie powędrują. Dynamiczne wykrywanie i maskowanie PII to sposób na przechwycenie tych danych w locie. Przyjrzyjmy się wewnętrznemu botowi HR. Menedżer zadaje botowi ogólne pytanie o firmową politykę oceny wyników. Bot przeszukuje wewnętrzną bazę wiedzy. Wyszukiwanie zwraca odpowiedni dokument, ale pobrane chunki tekstu przypadkowo zawierają konkretny rekord pracownika dołączony do pliku, wraz z imieniem i nazwiskiem, adresem domowym i e-mailem. Jeśli system przekaże te pobrane chunki bezpośrednio do modelu językowego, te wrażliwe dane staną się częścią context window. NeMo Guardrails radzi sobie z tym, siedząc między komponentami twojej aplikacji i filtrując strumień tekstu. Oferuje dwa różne podejścia. Detekcja polega na zidentyfikowaniu PII i podjęciu twardej akcji, takiej jak całkowite zablokowanie promptu lub wyrzucenie błędu. Maskowanie jest bardziej elastyczne. Znajduje wrażliwe informacje i w locie zastępuje je generycznym placeholderem. Tekst john@example.com staje się stringiem w nawiasach kwadratowych o treści EMAIL. Sama baza danych pod spodem pozostaje całkowicie nienaruszona. Aby to zrealizować, system guardrails polega na specjalistycznych narzędziach zewnętrznych. Konfigurujesz framework tak, aby wywoływał silnik taki jak Microsoft Presidio lub GLiNER. Presidio zazwyczaj wykorzystuje pattern matching, wyrażenia regularne i logikę opartą na regułach, aby wykrywać standardowe formaty, takie jak numery telefonów czy karty kredytowe. GLiNER, co jest skrótem od Generalist and Lightweight Indicator for Named Entity Recognition, wykorzystuje mały model uczenia maszynowego do identyfikacji encji na podstawie otaczającego kontekstu. Definiujesz tablicę typów encji, na których ci zależy, a wybrany silnik zajmuje się ekstrakcją. Ta ochrona działa w trzech konkretnych punktach flow aplikacji. Pierwszym z nich jest input rail. Jeśli użytkownik wpisze swój numer ubezpieczenia społecznego w oknie czatu, input rail skanuje przychodzący string i maskuje numer, zanim model językowy w ogóle otrzyma prompt. Model przetwarza żądanie używając placeholdera, całkowicie ślepy na rzeczywisty numer. Drugim punktem jest retrieval rail. To jest ta najważniejsza część. Kiedy twój system odpytuje wektorową bazę danych i pobiera surowe chunki tekstu, guardrail przechwytuje te chunki, zanim zostaną wstrzyknięte do ostatecznego szablonu promptu. Skanuje pobrany tekst, wycina prawdziwe imiona i adresy, i podstawia zamaskowane tagi. Twój mechanizm retrievalu może pobierać dane z zabałaganionych, niezredagowanych źródeł, ale model językowy jest chroniony przed wrażliwymi szczegółami. Trzecim punktem jest output rail. Jeśli model językowy wygeneruje wrażliwe dane, czy to przez halucynacje, czy dlatego, że jakiś fragment danych jakoś prześlizgnął się przez wcześniejsze raile, output rail działa jako ostateczny punkt kontrolny. Skanuje wygenerowaną odpowiedź i maskuje wrażliwy tekst, zanim dotrze on na ekran użytkownika. Ponieważ wszystko to dzieje się dynamicznie w pamięci podczas wykonywania pojedynczego requestu, twoja architektura danych nie musi się zmieniać. Unikasz ogromnego inżynieryjnego overheadu związanego z utrzymywaniem zduplikowanych, wstępnie zredagowanych baz danych tylko po to, by uruchomić aplikację czatową. Najbezpieczniejszym sposobem na obsługę wrażliwych danych w aplikacji z modelem językowym jest upewnienie się, że model od samego początku nie przetwarza rzeczywistych danych. To wszystko w tym odcinku. Dzięki za wysłuchanie i kodujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. NVIDIA NeMo Guardrails, odcinek 6 z 10. Niektóre z najbardziej niszczycielskich ataków typu prompt injection wcale nie wyglądają na sprytną socjotechnikę. Dla człowieka wyglądają po prostu jak kompletny bełkot. Użytkownik nie próbuje oszukać bota zagadką, a raczej przeciążyć go matematycznie. Wykrycie tego wymaga mechanizmu Jailbreak Detection za pomocą heurystyk perplexity. Weźmy pod uwagę konkretny scenariusz ataku. Złośliwy użytkownik chce, aby twoja aplikacja wygenerowała coś szkodliwego, ale wie, że w twoim system prompt masz instrukcje bezpieczeństwa. Aby ominąć te instrukcje, bierze swoje szkodliwe żądanie i obudowuje je ogromnym stringiem losowych znaków, dziwnych symboli lub bezsensownych słów. Gdy model językowy przetwarza ten input, mechanizmy attention są przytłaczane przez samą ilość nieprzewidywalnych tokenów. Model gubi swój podstawowy safety alignment i po prostu odpowiada na złośliwe żądanie. Nie możesz wyłapać tego ataku standardowymi filtrami słów kluczowych, ponieważ ten padding jest losowy. Mógłbyś użyć innego modelu językowego do oceny przychodzącego promptu pod kątem wzorców adversarial, ale to dodaje ogromny narzut na latency do każdego pojedynczego żądania użytkownika. Potrzebujesz filtra, który jest szybki, matematyczny i działa lokalnie. I tu do gry wchodzi perplexity. Perplexity to standardowa metryka, która mierzy, jak przewidywalny dla modelu językowego jest dany fragment tekstu. Zwykłe ludzkie zdania układają się w przewidywalne wzorce, co daje niskie perplexity. String losowych znaków albo dziwna sekwencja niepowiązanych słów jest wysoce nieprzewidywalna. To generuje wysokie perplexity. Obliczając perplexity przychodzącego promptu, otrzymujesz statystyczną miarę jego losowości. NeMo Guardrails używa tej koncepcji do blokowania ataków typu gibberish za pomocą dwóch głównych heurystyk. Pierwsza to Length per Perplexity. Ataki typu adversarial zazwyczaj wymagają długiego stringa śmieciowego tekstu, aby skutecznie wykoleić główny model. Krótki string nonsensu jest zazwyczaj ignorowany przez mechanizm attention. Ta heurystyka oblicza współczynnik, używając całkowitej długości promptu i jego ogólnego wyniku perplexity. Jeśli prompt jest jednocześnie nietypowo długi i wysoce nieprzewidywalny, przekracza z góry zdefiniowany matematyczny próg. Guardrail przechwytuje input, oflagowuje go jako potencjalny jailbreak i blokuje żądanie, zanim twój główny model w ogóle go zobaczy. Druga heurystyka radzi sobie z bardziej chirurgiczną odmianą tego samego ataku. Czasami atakujący ukrywa ten bełkot. Pisze całkowicie normalne zdanie o niskim perplexity w środku swojego promptu, ale na samym końcu dokleja gęsty blok losowych tokenów. Jeśli policzysz perplexity dla całego promptu, normalny tekst może na tyle rozwodnić średni wynik, że prześlizgnie się on przez pierwszy filtr. Aby temu zaradzić, NeMo Guardrails używa Prefix and Suffix Perplexity. Zamiast patrzeć na cały prompt, ta heurystyka izoluje stałą liczbę tokenów na samym początku i na samym końcu inputu użytkownika. Oblicza perplexity tych granic niezależnie. Jeśli użytkownik dołączy adversarial payload z losowych znaków na końcu normalnego pytania, wynik suffix perplexity gwałtownie skacze. Guardrail wykrywa anomalię na tej granicy i odrzuca żądanie. Cały ten proces odbywa się bez zewnętrznego wywołania API do potężnego modelu językowego. Opiera się na mniejszym, lokalnym modelu do obliczania wyników perplexity, co utrzymuje narzut na latency na absolutnym minimum. Odcinając semantyczne znaczenie tekstu, przestajesz analizować to, co użytkownik próbuje powiedzieć, a zaczynasz analizować matematyczny kształt jego słów. Heurystyki perplexity pozwalają ci blokować złożone ataki typu adversarial przy użyciu surowych statystyk, zabezpieczając twoją aplikację z prędkością matematyki. Dzięki za wysłuchanie, happy coding wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. NVIDIA NeMo Guardrails, odcinek 7 z 10. Udzielenie modelowi językowemu dostępu do wykonywania zapytań do bazy danych jest jak wręczenie kluczy do swojej bazy nieznajomemu. Każesz modelowi pobrać dane użytkownika, ale sprytny prompt sprawia, że dołącza on polecenie usunięcia tabeli. Zabezpieczanie workflowów agentowych za pomocą execution rails to sposób na powstrzymanie autonomicznych agentów przed naruszeniem bezpieczeństwa twojego backendu. Większość guardrails skupia się na odpowiedziach na czacie. Powstrzymują model przed używaniem wulgarnego języka lub schodzeniem z tematu. Execution rails robią coś zupełnie innego. Chronią narzędzia, których używa agent. Gdy agent decyduje się użyć narzędzia do uruchomienia wygenerowanego skryptu w Pythonie lub wykonania zapytania SQL, execution rail przechwytuje payload dokładnie w momencie przekazania, tuż przed faktycznym uruchomieniem narzędzia. NeMo Guardrails obsługuje tę walidację za pomocą reguł YARA. YARA to silnik dopasowujący wzorce, tradycyjnie używany przez analityków cyberbezpieczeństwa do identyfikacji malware'u na podstawie konkretnych sygnatur tekstowych lub binarnych. W tym frameworku NVIDIA udostępnia predefiniowany katalog wzorców YARA, stworzonych specjalnie do wyłapywania podatności modeli językowych. Silnik guardrails przepuszcza input narzędzia przez te reguły YARA, aby wyszukać znane sygnatury ataków. Ten katalog celuje w cztery konkretne zagrożenia. Pierwsze to SQL injection, gdzie model generuje polecenia bazodanowe zawierające złośliwe modyfikacje. Drugie to code injection, gdzie agent próbuje wykonać nieautoryzowane polecenia systemowe wewnątrz dynamicznie generowanego skryptu w Pythonie. Trzecie to template injection, gdzie atakujący manipuluje silnikami renderującymi po stronie serwera. I wreszcie, wykrywa cross-site scripting, blokując payloady zaprojektowane do wykonania złośliwych skryptów w przeglądarce internetowej. Wyobraź sobie agenta, którego zadaniem jest pobranie requestu od użytkownika, napisanie skryptu w Pythonie do przetworzenia lokalnych danych i uruchomienie go. Jeśli użytkownik ukryje polecenie systemowe, aby ujawnić zmienne środowiskowe w swoim prompcie, model językowy może ślepo dołączyć to polecenie do końcowego skryptu w Pythonie. Execution rail to wychwytuje. Skanuje wygenerowany kod w Pythonie, dopasowuje regułę YARA dla code injection i oflagowuje payload, zanim silnik wykonawczy w ogóle go zobaczy. Gdy system wykryje złośliwy wzorzec, podejmuje działanie na podstawie twojej konfiguracji. Masz dwie opcje. Pierwsza akcja to reject. Całkowicie blokuje to wykonanie narzędzia. Workflow się zatrzymuje, złośliwy kod nigdy się nie uruchamia, a system zwraca bezpieczną odpowiedź. Druga akcja to omit. Mówi to guardrailowi, aby usunął konkretny złośliwy string z payloadu, ale pozwolił narzędziu wykonać to, co zostało. Wybór między reject a omit zależy wyłącznie od narzędzia. Jeśli twój agent uruchamia zapytanie SQL do bazy danych, reject to jedyna bezpieczna opcja. Usunięcie stringa ze złożonego zapytania SQL prawdopodobnie skończy się błędną składnią lub nieprzewidywalnym dostępem do danych. Omit jest zazwyczaj zarezerwowane dla podstawowych zadań przetwarzania tekstu, gdzie usunięcie złego stringa nadal pozostawia użyteczny i bezpieczny payload. Konfigurujesz te zabezpieczenia bezpośrednio w swoich plikach YAML, włączając agentic security rails i mapując je na konkretne narzędzia. Pod spodem silnik YARA odwala czarną robotę, dopasowując predefiniowane wzorce bez wymagania od ciebie pisania własnych wyrażeń regularnych. Execution rails traktują model językowy jak niezaufanego użytkownika, zmuszając cię do walidacji każdego pojedynczego polecenia, które wygeneruje, zanim dotknie ono twojej infrastruktury. Dzięki za wysłuchanie, miłego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. NVIDIA NeMo Guardrails, odcinek 8 z 10. Bot, który mówi, że nie zna odpowiedzi, jest tylko trochę irytujący. Ale bot finansowy, który z pełnym przekonaniem deklaruje, że twoja firma nie osiągnęła celu przychodowego na trzeci kwartał o pięćdziesiąt milionów dolarów, podczas gdy w rzeczywistości go przekroczyła, to już katastrofa. Aby powstrzymać twój system Retrieval-Augmented Generation przed zmyślaniem liczb i niszczeniem twojej wiarygodności, potrzebujesz Grounding RAG: Halucynacje i fact-checking. Od razu wyjaśnijmy jedno częste nieporozumienie. Fact-checking i wykrywanie halucynacji to dwie różne rzeczy. Wykrywanie halucynacji zazwyczaj polega na wielokrotnym zadawaniu modelowi językowemu tego samego pytania. Jeśli uzyskane próbki są ze sobą sprzeczne, model prawdopodobnie halucynuje. Fact-checking ocenia pojedynczą wygenerowaną odpowiedź w oparciu o konkretny zestaw zaufanych dokumentów. NeMo Guardrails wykorzystuje fact-checking, aby zapewnić grounding twoich pipeline'ów RAG. Modele językowe przewidują tekst. Same z siebie nie wiedzą, co jest prawdą. W standardowym setupie RAG pobierasz chunki tekstu z bazy danych, przekazujesz je do modelu i prosisz go o odpowiedź wyłącznie na podstawie tego tekstu. Czasami model i tak halucynuje, mieszając swoją pre-trenowaną wiedzę z twoimi danymi, albo po prostu wymyślając wiarygodnie brzmiącą metrykę. NeMo Guardrails zatrzymuje to, używając output rail o nazwie self check facts. Kiedy jest aktywny, ten rail przechwytuje wygenerowaną odpowiedź modelu, zanim trafi ona do użytkownika. System traktuje tę niezweryfikowaną odpowiedź jako hipotezę. Następnie wyciąga dokładne chunki tekstu, które zostały pobrane z twojej bazy danych. Te chunki są automatycznie przechowywane w zmiennej context o nazwie relevant chunks. Ta zmienna to twardy dowód. Następnie guardrail uruchamia ewaluację. Przekazuje hipotezę i dowód do modelu ewaluatora. Ewaluator sprawdza, czy dowód bezwzględnie potwierdza hipotezę. Wracając do naszego bota finansowego: jeśli wygenerowany tekst podaje konkretną kwotę przychodu, ale ta liczba nie istnieje nigdzie w zmiennej relevant chunks, ewaluator oflaguje ją jako ungrounded. Guardrail natychmiast blokuje wyhalucynowaną odpowiedź. Zamiast tego serwuje bezpieczny fallback, przyznając, że nie ma wystarczających informacji. Użycie modelu językowego ogólnego przeznaczenia do fact-checkingu jest łatwe w setupie, ale ma swoją cenę. Dodaje latency, przepala tokeny, a model ewaluatora może czasem zgubić się w gęstym kontekście. Nie jesteś zmuszony do korzystania z domyślnego setupu. Możesz zastąpić standardowe sprawdzanie oparte na promptach specjalistycznymi narzędziami zewnętrznymi. Podejścia wykorzystujące modele takie jak AlignScore czy Patronus Lynx są tutaj bardzo skuteczne. To modele zbudowane w konkretnym celu, trenowane wyłącznie do wykrywania niespójności między tekstem źródłowym a wygenerowanym twierdzeniem. Kiedy routujesz relevant chunks i hipotezę przez jeden z tych wyspecjalizowanych modeli, całkowicie omijasz ewaluator standardowego modelu językowego. Daje to szybszy, tańszy i często bardziej rygorystyczny werdykt na temat tego, czy twój bot mówi prawdę. I to jest najważniejsza część. Grounding pipeline'u RAG nie polega na tym, żeby twój model generatywny stał się z natury bardziej prawdomówny. Chodzi o traktowanie każdego wygenerowanego słowa jako podejrzanego twierdzenia, które musi przetrwać rygorystyczne krzyżowe przesłuchanie z twoimi dokładnymi danymi źródłowymi, zanim w ogóle ujrzy światło dzienne. Jeśli chcesz nam pomóc w dalszym tworzeniu tych odcinków, możesz wesprzeć nasz podcast, wyszukując DevStoriesEU na Patreon. To wszystko w tym odcinku. Dzięki za słuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. NVIDIA NeMo Guardrails, odcinek 9 z 10. Spędzasz tygodnie na dostrajaniu filtrów wejściowych, żeby blokować złośliwe tekstowe prompty. A potem użytkownik omija całą twoją ciężką pracę, po prostu robiąc zrzut ekranu swojego złośliwego promptu i wrzucając go jako obraz. Filtry tekstowe są na to całkowicie ślepe. Żeby to wyłapać, potrzebujesz Multimodal Content Safety. Wyobraź sobie użytkownika, który wrzuca zdjęcie zmodyfikowanego karabinu szturmowego i wpisuje pytanie: jak to zmodyfikować, żeby strzelało szybciej? Standardowy tekstowy guardrail widzi tylko zapytanie o modyfikację jakiegoś ogólnego obiektu. Nie ma pojęcia, że ten obiekt to broń. Złośliwa intencja istnieje tylko wtedy, gdy połączysz obraz i tekst. Rozwiązujemy to, używając Vision Language Model, który działa jako LLM-as-a-judge. W NeMo Guardrails konfigurujesz to na etapie input rail. Zanim request użytkownika w ogóle dotrze do twojego głównego modelu konwersacyjnego, guardrail przechwytuje multimodalny payload. Dane obrazu zazwyczaj przychodzą w jednym z dwóch formatów. Jest to albo string zakodowany w Base64 osadzony bezpośrednio w API callu, albo bezpośredni URL. Stringi Base64 sprawiają, że payload requestu jest znacznie większy, ale gwarantują, że obraz jest dostępny. URL-e sprawiają, że początkowy payload jest lekki, ale wymagają, żeby model oceniający miał dostęp do sieci wychodzącej, żeby pobrać plik. Tak czy inaczej, konfigurujesz input rail za pomocą konkretnego prompt template'u zaprojektowanego do multimodalnej oceny. Ten template zawiera ścisłą rubrykę definiującą kategorie niebezpiecznych treści, takie jak przemoc, nielegalne działania, samookaleczenie czy broń. Guardrail konstruuje request ewaluacyjny. Pakuje twoją rubrykę bezpieczeństwa, tekst użytkownika i obraz użytkownika. Wysyła ten połączony pakiet do vision modela i wymusza na nim odpowiedź jako structured output, zazwyczaj prostą etykietę safe lub unsafe. Model działa ściśle jako sędzia. Analizuje broń na zdjęciu, czyta request o jej modyfikacji i sprawdza połączone znaczenie z twoimi zastrzeżonymi kategoriami. Jeśli vision model wykryje naruszenie, zwraca werdykt unsafe. Input rail oflagowuje request, blokuje jego dalsze przetwarzanie i triggeruje predefiniowaną wiadomość z odmową. Twój główny model aplikacji nawet nie widzi tego złośliwego requestu. Zwróć uwagę na ten fragment dotyczący context limits. Vision models przetwarzają obrazy, konwertując je na tokeny. W zależności od architektury modelu i rozdzielczości obrazu, pojedyncze zdjęcie może zużyć tysiące tokenów. Twój string Base64 lub URL obrazu, w połączeniu z tekstem użytkownika i wielokategoryczną rubryką bezpieczeństwa, musi w całości zmieścić się w context window twojego vision modela. Jeśli przekażesz masywne obrazy w wysokiej rozdzielczości razem z długim tekstem promptu, przekroczysz limit tokenów. Ewaluacja guardraila zakończy się błędem, albo model utnie input i całkowicie przegapi naruszenie. Musisz zaimplementować preprocessing, żeby zmienić rozmiar lub skompresować obrazy, zanim dotrą do guardraila, utrzymując przewidywalny token footprint. Ewaluacja tekstu i obrazów w izolacji nie jest już wystarczająca, ponieważ współczesne nadużycia kryją się dokładnie w przestrzeni, gdzie te dwie modalności się przecinają. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. NVIDIA NeMo Guardrails, odcinek 10 z 10. Tworzenie reguł bezpieczeństwa bezpośrednio w skrypcie Pythona jest świetne do testowania, ale fatalne przy skalowaniu w wielojęzycznym przedsiębiorstwie. Jeśli twój frontend korzysta z Node JS, a backend to mieszanka Pythona i Go, nie możesz powielać logiki bezpieczeństwa w każdym języku. Rozwiązaniem jest zastosowanie trzech wzorców integracji enterprise dla NeMo Guardrails. Weźmy standardowy scenariusz migracji. Zbudowałeś prototyp bota obsługi klienta w LangChain. Dodałeś guardrails, aby powstrzymać go przed mówieniem o konkurencji. Działa idealnie na twoim laptopie. Teraz musisz zmigrować ten prototyp do skalowalnej, produkcyjnej architektury mikrousług, gdzie wiele aplikacji będzie go odpytywać. Masz trzy główne sposoby na integrację guardrails, żeby to osiągnąć. Pierwsza metoda to natywne Python SDK, a konkretnie obiekt o nazwie LLMRails. To jest główny silnik. Jeśli budujesz własny backend w Pythonie od zera, bez opierania się na frameworkach do orkiestracji, używasz właśnie tego. Tworzysz instancję LLMRails, wskazujesz jej katalog z konfiguracją zawierający twoje pliki Colang i YAML, i używasz jej do przetwarzania inputów. Przekazujesz listę słowników z wiadomościami reprezentującymi historię konwersacji, a on zwraca odpowiedź po ewaluacji. Jest to bezpośrednie i daje ci surowy dostęp do mechanizmów guardrails pod spodem. Ponieważ masz już prototyp w LangChain, przepisywanie wszystkiego, żeby użyć surowego SDK, to strata czasu. Tutaj wkracza druga metoda, czyli integracja z LangChain przy użyciu RunnableRails. NeMo Guardrails integruje się natywnie z LangChain Expression Language. Tworzysz instancję RunnableRails załadowaną twoją konfiguracją i podpinasz ją bezpośrednio do swojego istniejącego chaina. Jeśli twój chain przyjmuje prompt, pobiera dokumenty i wywołuje model językowy, opakowujesz cały ten flow za pomocą guardrail runnable. Guardrail przechwytuje input, zanim trafi on do twojego chaina, i ewaluuje output po tym, jak chain wygeneruje odpowiedź. Główny kod twojej aplikacji prawie się nie zmienia, ale twoja logika w LangChain jest teraz chroniona. To jest ta część, która ma znaczenie w dużej skali. Pomyśl o szerszym kontekście enterprise. Inny zespół chce użyć dokładnie tych samych polityk bezpieczeństwa, ale buduje web gateway w Node JS albo wysokowydajny router w Go. Nie mogą zaimportować pythonowego obiektu LangChain. Do tego używasz trzeciej metody, czyli serwera API standalone. NeMo Guardrails zawiera wbudowany serwer, który możesz uruchomić z linii poleceń lub zdeployować jako kontener. Uruchamiasz serwer i wskazujesz mu folder konfiguracji. Natychmiast wystawia on endpointy REST, które naśladują standardowe API OpenAI. Dla twoich aplikacji w Go lub Node JS, serwer guardrails wygląda dokładnie jak standardowy model językowy. Wysyłają standardowe requesty JSON do endpointu chat completions. Serwer obsługuje input guardrails, komunikuje się z właściwym modelem pod spodem, przetwarza output guardrails i zwraca czysty tekst. Oddzielenie reguł od logiki aplikacji za pomocą serwera standalone to jedyny niezawodny sposób na egzekwowanie spójnych polityk bezpieczeństwa w całej organizacji. Sprawdź oficjalną dokumentację, aby wypróbować te wzorce integracji w praktyce, lub odwiedź DEV STORIES DOT EU, aby zasugerować tematy do przyszłych serii. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.