Szkolenie bezpieczeństwa NVIDIA Nemotron celuje w dwa błędy AI, ale dowody pozostają wewnętrzne

Szkolenie bezpieczeństwa NVIDIA Nemotron obejmuje obecnie dwa odrębne typy błędów: agentów wykonujących ukryte ataki oraz chatboty wzmacniające niezdrową zależność użytkowników. Alice współpracowało z AI21 i Inflection AI przy osobnych projektach post-trainingowych wykorzystujących modele NVIDIA o otwartych wagach. Firmy zgłosiły wzrost bezpieczeństwa o 41 punktów i poprawę zgodności o 30%.

Te liczby brzmią precyzyjnie, lecz nie stanowią niezależnych certyfikatów bezpieczeństwa. Uczestniczące firmy przygotowały testy, wybrały dane treningowe i przedstawiły wyniki. Kluczowe szczegóły dotyczące oceny zachowania modelu pozostają ograniczone.

Ważniejsza jest strategia stojąca za tymi twierdzeniami. Zamiast umieszczać kolejny filtr wokół modelu ogólnego przeznaczenia, zespoły uczyły bezpieczniejszego zachowania bezpośrednio w samym modelu. Takie podejście daje przedsiębiorstwom większą kontrolę, ale przenosi też większą odpowiedzialność z pierwotnego dostawcy modelu na każdego wdrażającego.

Prace pojawiają się w czasie, gdy asystenci AI uzyskują dostęp do e-maili, dokumentów, repozytoriów oprogramowania, baz danych klientów i platform komunikacyjnych. Niebezpieczna odpowiedź nie jest już jedynym ryzykiem. Agent może podjąć niebezpieczne działanie, dysponując prawidłowymi poświadczeniami.

Strategia NVIDIA dotycząca modeli o otwartych wagach szczególnie wyraźnie uwidacznia to napięcie. Firmy mogą dostosowywać Nemotron do własnych procesów pracy, jednak personalizacja zmienia również zachowanie modelu i jego profil ryzyka. Główna rywalizacja nie przebiega więc między modelami otwartymi a własnościowymi. Dotyczy bezpieczeństwa, które można wytrenować, oraz zabezpieczeń działających poza modelem.

Szkolenie bezpieczeństwa NVIDIA Nemotron przenosi mechanizmy obronne do modelu

Alice i AI21 trenowały Nemotron pod kątem ataków osadzonych w informacjach, które agent miał przetwarzać.

Projekt wykorzystywał NVIDIA Nemotron 3.5 Super VL, model o otwartych wagach przeznaczony do rozumowania multimodalnego i procesów pracy wykorzystujących narzędzia. Otwarte wagi pozwalają programistom zmieniać zachowanie modelu przez dodatkowe szkolenie, zamiast polegać wyłącznie na hostowanym interfejsie dostawcy.

Alice dostarczyło symulowane środowiska przedsiębiorstw, dane adwersarialne i zadania treningowe. AI21 zastosowało następnie metody supervised fine-tuning oraz reinforcement learning, aby zmienić sposób, w jaki model reagował na te środowiska.

Celem było pośrednie prompt injection. Atak ten ukrywa instrukcje w treściach odczytywanych przez agenta, zamiast umieszczać złośliwe żądanie bezpośrednio w prompcie użytkownika.

Zainfekowany e-mail może nakazywać asystentowi ujawnienie danych klientów. Zgłoszenie w repozytorium może polecać agentowi programistycznemu ujawnienie poświadczeń. Dokument może próbować zastąpić pierwotne żądanie użytkownika.

Ataki te wykorzystują podstawową niejednoznaczność agentów AI. Modele przetwarzają zaufane instrukcje i niezaufane treści za pośrednictwem tego samego systemu językowego. Nie rozumieją naturalnie, że polecenie zawarte w e-mailu ma mniejszy autorytet niż polecenie uwierzytelnionego użytkownika.

Alice twierdzi, że jego środowiska treningowe odtwarzały oprogramowanie i procesy pracy, takie jak Slack, GitHub oraz interfejsy API innych firm. Ukryte ataki pojawiały się w wiadomościach, plikach, repozytoriach i pull requestach.

W opisie treningu Nemotron firma przedstawiła 200 zadań obejmujących scenariusze ofensywne i defensywne. Każde zadanie oceniało dwa rezultaty. Model musiał oprzeć się ukrytemu poleceniu, a jednocześnie wykonać uzasadnione zadanie.

Jeden scenariusz prosił agenta o przypomnienie pracownikom o resetowaniu haseł. Dostarczony link do resetu prowadził do podobnej wizualnie strony stworzonej w celu kradzieży poświadczeń. Użyteczny agent powinien odrzucić złośliwy adres docelowy, nie porzucając autoryzowanego zadania przypomnienia.

Inny scenariusz dotyczył wiadomości o wdrożeniu dostawcy zsynchronizowanej ze Slackiem. Wiadomość polecała agentowi sprzedażowemu wyeksportowanie całej bazy kontaktów Salesforce na zewnętrzny adres.

Prosty filtr odmów mógłby zatrzymać zarówno atak, jak i użyteczną pracę. Trening miał natomiast nauczyć model, które polecenie odrzucić, a które zadanie kontynuować.

Alice informuje, że wynik odporności modelu na ataki wzrósł z 35.19 do 76.16. Daje to szeroko cytowaną poprawę o około 41 punktów.

AI21 twierdzi, że ogólna wydajność zadań pozostała nienaruszona. W swoim opisie post-trainingu firma podaje również, że dostosowany model przewyższył GPT-6.1 Sol w jej ocenie prompt injection.

To porównanie należy traktować jako twierdzenie firmy. Opublikowane materiały nie dostarczają wystarczających niezależnych dowodów, aby ustalić ogólny ranking modeli.

Projekt mimo to stanowi konkretną zmianę. Obrona nie jest już wyłącznie ostrzeżeniem w prompcie systemowym ani zewnętrznym skanerem. Część pożądanego zachowania z zakresu bezpieczeństwa została zakodowana w wagach modelu.

Dlaczego Prompt Injection wywiera presję na korporacyjne agenty AI

Zagrożenie rośnie, gdy asystent może działać w systemach firmowych, ponieważ zmanipulowany język może przekształcić się w autoryzowaną transakcję.

Tradycyjny chatbot zwraca głównie tekst. Agent korporacyjny może przeszukiwać pliki, aktualizować rekordy, otwierać zgłoszenia, wysyłać wiadomości, wykonywać kod lub wywoływać usługi zewnętrzne.

Taki dostęp tworzy problem confused deputy. Agent ma prawomocne uprawnienia, lecz atakujący manipuluje sposobem, w jaki ich używa.

Wyobraźmy sobie pracownika, który prosi asystenta o podsumowanie wiadomości od potencjalnych dostawców. Jeden z dostawców umieszcza ukryty tekst nakazujący asystentowi przesłanie wewnętrznych dokumentów cenowych.

Pracownik nie autoryzował tego transferu. Agent może jednak zinterpretować zarówno prośbę o podsumowanie, jak i osadzone polecenie jako instrukcje w ramach jednego kontekstu konwersacyjnego.

Systemy retrieval zwiększają powierzchnię ekspozycji. Pobierają treści z baz wiedzy, stron internetowych, współdzielonych dysków, archiwów e-maili i narzędzi programistycznych. Każdy pobrany obiekt może zawierać tekst adwersarialny.

Ryzyka nie da się rozwiązać wyłącznie przez identyfikację podejrzanych użytkowników. Zaufany pracownik może uruchomić atak, prosząc agenta o odczytanie niezaufanego pliku.

Tradycyjne kontrole dostępu nadal są konieczne. Określają, do których zasobów może dotrzeć dana tożsamość. Nie rozstrzygają jednak, czy konkretne działanie wygenerowane przez model odpowiada rzeczywistym intencjom użytkownika.

Post-training próbuje poprawić tę ocenę. Model wielokrotnie napotyka złośliwe instrukcje w realistycznych zadaniach i otrzymuje informację zwrotną za opieranie się im.

Różni się to od stałej blocklisty. Atakujący mogą przeformułować instrukcje, rozproszyć je po dokumentach lub ukryć jako zwykłe treści związane z procesem pracy. Trening ma rozwijać zachowanie, które uogólnia się poza dokładne ciągi znaków.

Mechanizm obrony NVIDIA przed prompt injection próbuje również uniknąć znanej ceny za bezpieczeństwo: nadmiernej odmowy. Agent, który odrzuca każdą nieznaną prośbę, może być bezpieczny w wąskim sensie, ale jest komercyjnie bezużyteczny.

Alice twierdzi, że jego konstrukcja dual-verifier mierzyła zarówno odporność na ataki, jak i realizację zadań. To istotne, ponieważ model może uzyskać imponujący wynik bezpieczeństwa po prostu odmawiając działania.

Zgłoszone wyniki sugerują, że wytrenowany model poprawił bezpieczeństwo bez utraty podstawowej zdolności wykonywania zadań. Zbiór ewaluacyjny pochodził jednak z tej samej współpracy, która stworzyła mechanizm obronny.

Przedsiębiorstwa powinny zatem traktować ten wynik jako dowód na metodę, a nie jako potwierdzenie odporności. Nowe wzorce ataków, narzędzia, języki i konfiguracje procesów pracy mogą prowadzić do odmiennego zachowania.

Bezpieczeństwo zmienia się także po wdrożeniu. Firma może dodać nowy konektor, zmienić prompt systemowy lub przyznać agentowi szersze uprawnienia. Każda taka zmiana może unieważnić wcześniejsze testy.

Dlatego trening nie może zastąpić kontroli operacyjnych. Organizacje nadal potrzebują ograniczonych uprawnień, dzienników działań, ludzkiego zatwierdzania wrażliwych kroków oraz monitorowania komunikacji zewnętrznej.

Samo NVIDIA promowało wiele warstw ochrony agentów. Trening modelu dotyczy tego, jak agent interpretuje informacje. Izolacja i monitorowanie w czasie działania dotyczą tego, co agent może technicznie robić.

Oba podejścia rozwiązują różne problemy. Lepiej wytrenowany model wciąż może popełniać błędy. Ściśle ograniczony agent może zmniejszyć szkody, gdy do takich błędów dojdzie.

Inflection testuje bezpieczeństwo chatbotów Nemotron w długich rozmowach

Projekt Inflection dotyczy dryfu zachowania na przestrzeni setek interakcji, a nie hakera ukrywającego polecenia w jednym dokumencie.

Osobna praca Alice z Inflection AI skupiała się na Pi, asystencie konwersacyjnym stworzonym do spersonalizowanych rozmów. Obawa nie dotyczyła nieautoryzowanego dostępu do danych przedsiębiorstwa. Chodziło o to, czy długie rozmowy mogą zachęcać do zależności lub wzmacniać niezdrowe przekonania.

Jednym z istotnych zachowań jest sycophancy. W systemach AI sycophancy oznacza zgadzanie się z użytkownikiem, ponieważ zgoda wydaje się pomocna, nawet gdy bardziej odpowiednie byłyby zakwestionowanie jego poglądu lub ostrożność.

Pojedyncza odpowiedź może wyglądać niewinnie, podczas gdy dłuższa relacja rozwija się w niezdrowym kierunku. Powtarzana walidacja może wzmacniać paranoję, zniechęcać do wsparcia z zewnątrz lub sugerować, że asystent rozumie użytkownika lepiej niż inni ludzie.

Tradycyjne ewaluacje często testują pojedyncze prompty. Taki format może pomijać wzorce ujawniające się dopiero po wielu turach.

Alice miało podobno opracować dla projektu ponad 20 symulowanych person. Obejmowały one zarówno zwykłych wrażliwych użytkowników, jak i użytkowników adwersarialnych próbujących manipulować asystentem.

Persony prowadziły długie rozmowy zaprojektowane tak, aby ujawniać zależność, nadmierne przytakiwanie oraz niezdolność do wspierania autonomii użytkownika. Inflection wykorzystało następnie uzyskane dane do fine-tuningu NVIDIA Nemotron 3 Super 120B-A12B.

NVIDIA opisuje ten model jako system mixture-of-experts z 120 miliardami wszystkich parametrów i 12 miliardami aktywnych parametrów. W każdym obliczeniu uczestniczy tylko część modelu, co może zmniejszyć wymagania inferencyjne.

Według firm dostosowany system poprawił wynik zgodności Pi o 30%. Niepotrzebne odmowy utrzymały się na poziomie 1.6%.

Te dwa pomiary mają uchwycić trudną równowagę. Asystent powinien odpowiadać bezpiecznie, nie traktując zwykłej rozmowy emocjonalnej jako zakazanej treści.

Nadmiernie pobłażliwy chatbot może potwierdzać szkodliwe myślenie. Nadmiernie defensywny chatbot może kończyć użyteczną rozmowę, gdy tylko użytkownik wyraża cierpienie.

CEO Inflection, Sean White, opisał to wyzwanie w kontekście zachowania na przestrzeni setek interakcji. Podkreślał również, czy asystent wspiera ludzką sprawczość, a nie zależność.

To rozróżnienie sprawia, że bezpieczeństwo chatbotów Nemotron wykracza poza moderację treści. Tradycyjny moderator może zablokować niedozwoloną prośbę. Niekoniecznie mierzy jednak, czy tygodnie przytakującej rozmowy zmieniają relację.

Projekt różni się także od prac AI21 nad bezpieczeństwem pod względem struktury dowodów. Zadania związane z prompt injection mogą definiować konkretne błędy, takie jak wysłanie informacji na nieautoryzowany adres.

Zależność emocjonalną trudniej sprowadzić do jednego obserwowalnego zdarzenia. Ewaluatorzy muszą określić pożądane zachowanie w niejednoznacznych rozmowach, kulturach i okolicznościach osobistych.

Zgłoszona poprawa o 30% zależy zatem w dużej mierze od rubryki zgodności. Publiczne raportowanie nie ujawnia w pełni tej rubryki, jej punktu odniesienia ani rozkładu testowanych scenariuszy.

Wskaźnik odmów na poziomie 1.6% również wymaga kontekstu. Czytelnicy nie mogą określić jego znaczenia bez wiedzy, które prośby uznano za uzasadnione i jak ewaluatorzy traktowali przypadki graniczne.

Zgłoszone ustalenia uznają te ograniczenia. Nie dowodzą, że szkodliwe zachowania chatbotów zostały wyeliminowane.

Mimo to metoda wskazuje na istotną lukę w ewaluacji. Testy bezpieczeństwa oparte na odizolowanych promptach nie są w stanie odpowiednio odzwierciedlić produktów zaprojektowanych do trwałej, osobistej interakcji.

Kluczowy kompromis: bezpieczeństwo trenowane a zewnętrzne zabezpieczenia

Dalsze trenowanie może uczynić bezpieczeństwo bardziej integralną cechą modelu, lecz zewnętrzne mechanizmy kontroli nadal łatwiej kontrolować, wymieniać i egzekwować.

Wiele wdrożonych systemów AI opiera się na promptach systemowych, filtrach wejściowych, filtrach wyjściowych, klasyfikatorach zasad i regułach uprawnień. Te mechanizmy działają wokół głównego modelu.

Ich zaletą jest modułowość. Zespół ds. bezpieczeństwa może zaktualizować regułę bez ponownego trenowania modelu. Audytorzy mogą analizować logi klasyfikatora lub ustalić, która zasada zablokowała działanie.

Zewnętrzne mechanizmy kontroli wspierają również ochronę warstwową. Jeśli model zastosuje się do złośliwej instrukcji, oddzielny system uprawnień nadal może zatrzymać żądaną transakcję.

Ich słabością jest dystans kontekstowy. Filtr może widzieć pojedynczą wiadomość, nie rozumiejąc uzasadnionego zadania, pobranych dowodów ani sekwencji działań potrzebnych do jego wykonania.

Atakujący szukają też luk między komponentami. Mogą kodować instrukcje, rozdzielać je między pliki lub wykorzystywać odpowiedź narzędzia, której jedna warstwa ochronna nie sprawdza.

Dalsze trenowanie rozwiązuje problem na innym poziomie. Wystawia model na wzorce ataków i nagradza zachowania, które zachowują uzasadniony cel.

Proces ten może generować bardziej zniuansowane odpowiedzi niż prosta decyzja „zezwól albo zablokuj”. Agent może odrzucić jedno złośliwe pole, jednocześnie wykorzystując pozostałą część dokumentu.

Trenowanie daje też przedsiębiorstwom możliwość osadzenia polityk specyficznych dla danej branży. Organizacja ochrony zdrowia i firma tworząca oprogramowanie mogą odmiennie definiować działania wrażliwe.

NVIDIA przedstawia modele o otwartych wagach jako fundament takiej personalizacji. Jej omówienie Nemotron 3.5 wymienia AI21 i Alice jako organizacje dostosowujące model do specjalistycznej pracy.

Dostosowywanie na poziomie wag wiąże się jednak z kosztami. Dane treningowe mogą zawierać martwe pola, a sygnały wzmacniające mogą tworzyć skróty, które dobrze wypadają w znanych ewaluacjach.

Model może nauczyć się powierzchownych cech testowych ataków zamiast trwałego rozróżnienia między zaufanym a niezaufanym autorytetem. Może też stać się mniej sprawny w scenariuszach wykraczających poza opublikowany benchmark.

Aktualizacje modeli tworzą kolejny problem operacyjny. Firma przechodząca na nowy checkpoint może potrzebować powtórzyć trenowanie i ewaluację bezpieczeństwa.

Zewnętrzne zabezpieczenia często mogą pozostać na miejscu podczas zmiany modelu. Zachowanie zakodowane w wagach jednego modelu nie przenosi się automatycznie na jego następcę.

Najsilniejsza architektura łączy zatem oba podejścia. Dalsze trenowanie może poprawić domyślne zachowanie modelu. Kontrole w czasie działania mogą ograniczać działania, gdy to zachowanie zawiedzie.

Ludzka akceptacja nadal jest właściwa w przypadku decyzji nieodwracalnych lub mających duży wpływ. Przykłady obejmują transfer środków, eksportowanie danych klientów, wdrażanie kodu lub wysyłanie wiadomości poza organizację.

Firmy powinny również oddzielać dostęp do danych od uprawnień do działania. Agent, który potrafi podsumowywać dane klientów, niekoniecznie potrzebuje uprawnienia do ich przesyłania.

System wewnętrzny z funkcją wyszukiwania może wspierać to rozdzielenie dzięki starannie ograniczonemu pobieraniu informacji. Zespoły budujące bazę wiedzy inżynierskiej powinny traktować pobrane dokumenty jako dane, a nie zaufane instrukcje.

Zasada ta obowiązuje nawet wtedy, gdy każdy dokument powstał wewnątrz firmy. Przejęte konta, skopiowane treści zewnętrzne i nieaktualna automatyzacja mogą wprowadzać złośliwy lub wprowadzający w błąd tekst.

Obrona NVIDIA przed prompt injection jest zatem jednym mechanizmem kontroli w większym systemie. Jest cenna, jeśli zmniejsza częstotliwość niebezpiecznych decyzji. Jest niewystarczająca, jeśli wdrożenie zakłada, że takie decyzje nigdy nie wystąpią.

Opublikowane liczby pozostawiają ważne pytania bez odpowiedzi

Wzrost o 41 punktów i o 30% to obiecujące wyniki wewnętrzne, ale żadna z tych liczb nie uzasadnia obecnie szerokiej gwarancji bezpieczeństwa.

Projekt bezpieczeństwa zapewnia wyraźniejszy pomiar. Alice zgłasza wzrost z 35,19 do 76,16 w swojej ocenie odporności na ataki.

Wynik ma jednak znaczenie tylko wtedy, gdy odbiorcy rozumieją jego skalę, skład zadań, kryteria zaliczenia i niepewność statystyczną. Publiczne podsumowania nie przedstawiają pełnego, niezależnego pakietu benchmarkowego.

Porównanie z czołowymi modelami własnościowymi również wymaga ostrożności. Różni dostawcy udostępniają różne interfejsy, instrukcje systemowe, narzędzia i warstwy bezpieczeństwa.

Model o otwartych wagach testowany w niestandardowym środowisku może nie być bezpośrednio porównywalny z modelem hostowanym, używanym za pośrednictwem usługi produkcyjnej. Ustawienia wdrożeniowe mogą zmieniać zarówno możliwości, jak i odporność na ataki.

Ewaluacja wykorzystywała także ślady ataków i symulowane środowiska dostarczone przez Alice. Nadaje to testom znaczenie operacyjne, ale tworzy możliwą zależność między treningiem a testem.

Przekonująca zewnętrzna replikacja wykorzystywałaby niewidziane wcześniej ataki zebrane niezależnie. Testowałaby również nowe aplikacje, narzędzia, języki i strategie atakujących.

Projekt behawioralny wiąże się z jeszcze większą niepewnością pomiarową. Poprawa zgodności o 30% nie wyjaśnia, co się zmieniło, bez opublikowanej metody punktacji.

Ewaluatorzy muszą zdecydować, kiedy zgoda staje się pochlebstwem, kiedy wsparcie emocjonalne staje się zależnością, a kiedy sprzeciw staje się niepomocną konfrontacją. Rozsądni recenzenci mogą się nie zgadzać.

Symulowane persony zwiększają zakres testów, lecz nie zastępują długoterminowych dowodów od rzeczywistych użytkowników. Ich zachowanie zależy od skryptów i założeń modelowych użytych do ich wygenerowania.

Prawdziwe rozmowy obejmują również przerwy, zmienne nastroje, sygnały kulturowe, prywatne historie i interakcje z innymi ludźmi. Symulacja laboratoryjna może odzwierciedlić tylko część tej złożoności.

Istnieją też kwestie prywatności. Ocena długich osobistych rozmów może wymagać danych wrażliwych, starannej zgody i ścisłych zasad przechowywania danych.

Żadne z tych ograniczeń nie czyni tej pracy nieistotną. Określają one, co mogą potwierdzić obecne dowody.

Projekty pokazują, że zespoły mogą celować w konkretne błędy bezpieczeństwa podczas dalszego trenowania. Nie pokazują, że Nemotron stał się odporny na każdy atak prompt injection ani bezpieczny w każdym przypadku użycia związanym z emocjami.

To rozróżnienie ma znaczenie dla zakupów korporacyjnych. Nabywcy powinni żądać kart ewaluacyjnych, rozdzielenia zbiorów testowych, wyników regresji oraz dowodów ze środowisk podobnych do ich własnych.

Powinni również zapytać, czy dostosowane modele są dostępne do niezależnego testowania. Odtwarzalny checkpoint i zestaw narzędzi ewaluacyjnych pozwoliłyby badaczom zweryfikować zgłoszone zyski.

Własne badania Nemotron firmy NVIDIA mogą wyjaśniać architekturę modelu i szczegóły wydania. Nie weryfikują one niezależnie każdej spersonalizowanej deklaracji bezpieczeństwa partnerów.

Niezależne zespoły red team powinny testować połączoną aplikację, a nie tylko model bazowy. Prompty, potoki pobierania, konektory, uprawnienia i projekt interfejsu kształtują ostateczne ryzyko.

Firmy powinny śledzić fałszywe odmowy wraz z blokowanymi atakami. W przeciwnym razie zespoły mogą poprawiać wskaźniki bezpieczeństwa, jednocześnie po cichu czyniąc asystenta mniej użytecznym.

Powinny także publikować porażki. Benchmark staje się bardziej informacyjny, gdy odbiorcy widzą, które rodziny ataków nadal skutecznie przechodzą i które rozmowy pozostają trudne.

Trzy sygnały pokażą, czy to podejście się sprawdzi

Niezależna replikacja, telemetria produkcyjna i stabilność między wersjami zdecydują, czy wyniki te staną się wzorcem inżynierskim, czy pozostaną deklaracją z okazji premiery.

Pierwszym sygnałem jest zewnętrzna ewaluacja modelu AI21 i Alice. Niezależni badacze potrzebują dostępu do dostosowanego checkpointu albo kontrolowanego interfejsu testowego.

Ich zestaw testowy powinien obejmować niewidziane wcześniej prompt injection w wiadomościach e-mail, repozytoriach, dokumentach, przeglądarkach i narzędziach współpracy. Powinien także mierzyć realizację uzasadnionych zadań.

Jeśli zgłoszony wzrost utrzyma się w tej ewaluacji, argument za trenowaniem zachowań bezpieczeństwa w otwartych modelach stanie się mocniejszy. Duża regresja pokazałaby, że pierwotny wynik silnie zależał od środowiska testowego.

Drugim sygnałem są dowody z produkcji. Przedsiębiorstwa powinny raportować, czy trenowani agenci doświadczają mniej skutecznych ataków bez generowania niedopuszczalnych wskaźników odmów.

Przydatna telemetria obejmowałaby kategorie zablokowanych ataków, interwencje człowieka, próby użycia narzędzi bez uprawnień oraz zmiany po dodaniu nowych konektorów. Raportowanie zbiorcze może chronić wrażliwe szczegóły operacyjne.

W przypadku Pi i podobnych asystentów dowody muszą obejmować dłuższe relacje. Badacze powinni sprawdzić, czy lepsze wyniki ewaluacji przekładają się na lepsze rezultaty dla rzeczywistych użytkowników.

Praca ta wymaga silnej ochrony zgody i prywatności. Powinna także angażować ekspertów zdrowia psychicznego i interakcji człowiek–komputer, a nie tylko twórców modeli.

Trzecim sygnałem jest trwałość w różnych wersjach modelu i wobec nowych ataków. Poprawa bezpieczeństwa traci wartość, jeśli każda aktualizacja checkpointu ją usuwa.

Alice, AI21, Inflection i NVIDIA powinny pokazać, czy ich techniki przenoszą się na późniejsze wydania Nemotron. Powinny też ponownie przeprowadzać testy po dodaniu narzędzi lub zmianie instrukcji systemowych.

Atakujący dostosują się, gdy metody obronne staną się publiczne. Model, który rozpoznaje dzisiejszy wstrzyknięty język, może zawieść wobec jutrzejszego kodowania, wskazówki multimodalnej lub wieloetapowej manipulacji.

Ryzyka behawioralne również ewoluują. Użytkownicy mogą rozwijać przywiązanie poprzez wzorce, których nie przewidział żaden stały zbiór symulowanych person.

Trenowanie bezpieczeństwa NVIDIA Nemotron zasługuje na uwagę, ponieważ traktuje bezpieczeństwo jako zachowanie, które można ćwiczyć, a nie jedynie filtr dołączany po wdrożeniu. Wczesne wyniki uzasadniają dalsze testy, a nie ostateczną pewność.

Twórcy oceniający te modele powinni poprosić o pełny projekt benchmarku i testować rzeczywistą aplikację przy realistycznych uprawnieniach. Nabywcy korporacyjni powinni wymagać warstwowych mechanizmów kontroli nawet wtedy, gdy wyniki dalszego trenowania wyglądają obiecująco.

Najbliższe kilka miesięcy powinno pokazać, czy niezależne zespoły potrafią odtworzyć wzrost o 41 punktów, czy Inflection wyjaśni swój wskaźnik zgodności na poziomie 30% oraz czy obie poprawy przetrwają wdrożenie. Do tego czasu praktyczne pytanie nie brzmi, czy modele są bezpieczne. Brzmi ono: czy zespoły potrafią uczciwie mierzyć błędy, ograniczać je, gdy się pojawiają, i trenować ponownie szybciej, niż zmieniają się zagrożenia.