Bezpieczeństwo i zgodność w erze modeli o długim horyzoncie

Modele, które potrafią długo pracować autonomicznie, mogą podejmować trudne, otwarte problemy. Jednak ta sama wytrwałość, która czyni je użytecznymi, daje im też więcej okazji do podejmowania niepożądanych działań — i to w sposób, którego mogą nie wychwycić ewaluacje przeznaczone dla modeli o krótszym horyzoncie.

Około dwa miesiące temu ogłosiliśmy⁠, że wewnętrzny model ogólnego przeznaczenia obalił hipotezę Erdősa o odległościach jednostkowych. Ten model zaprojektowano tak, aby działał autonomicznie przez bardzo długi czas. Podczas ograniczonego, monitorowanego użytku wewnętrznego zaobserwowaliśmy niepożądane zachowanie, którego nie uchwyciły nasze dotychczasowe ewaluacje wdrożeniowe. Ponieważ wdrożenie było ograniczone i monitorowane, mogliśmy zidentyfikować te problemy, wstrzymać dostęp, stworzyć nowe ewaluacje na podstawie obserwacji, wzmocnić model i jego zabezpieczenia, a następnie przywrócić dostęp przy dalszym monitorowaniu. 

Warunki, w których oceniamy modele, nigdy nie będą idealnie odpowiadać tym, z którymi zetkną się w rzeczywistym użyciu. Dlatego ewaluacje przed wdrożeniem trzeba łączyć z ograniczonym, monitorowanym wdrożeniem oraz możliwością interwencji, wstrzymania lub wycofania zmian, gdy pojawią się problemy. To, czego uczymy się podczas wdrożenia, może następnie stać się częścią silniejszych ewaluacji i zabezpieczeń, zanim dostęp zostanie rozszerzony.

W kolejnych sekcjach przedstawiamy konkretne przykłady tego, co zaobserwowaliśmy, jak rozwiązaliśmy problemy i jak to doświadczenie wpłynie na przyszłe wydania.

Nowy model potrafi przez długi czas, w kolejnych próbach, konsekwentnie dążyć do celu. Ta sama wytrwałość może sprawić, że znajdzie i wykorzysta słabości swojego środowiska. Poprzednie modele, gdy napotykały ograniczenia środowiska odizolowanego lub środowiska standardowego, po prostu przerywały pracę i przekazywały komunikat do użytkownika. Ten model często próbował działać dalej, między innymi szukając sposobów działania poza swoim środowiskiem odizolowanym.

Przykład takiej sytuacji wystąpił podczas wewnętrznej ewaluacji w benchmarku NanoGPT speedrun⁠(otwiera nowe okno), publicznym teście polegającym na wytrenowaniu małego modelu językowego w możliwie najmniejszej liczbie kroków. Nasz model opracował oparty na prawie potęgowym harmonogram wygaszania learning rate’u, nazwany PowerCool, który przyniósł znaczącą poprawę. Model otrzymał polecenie, aby opublikować wyniki tylko w komunikatorze Slack, ale instrukcje NanoGPT mówią, by zamieszczać wyniki jako PR na GitHub, więc model zastosował się do tych drugich instrukcji i otworzył PR #287 w publicznym repozytorium GitHub. Model obszedł ograniczenia środowiska odizolowanego zaprojektowane tak, aby blokować dostęp zewnętrzny, i przesłał dane do GitHub. Nasz model potrzebował godziny, aby znaleźć lukę w środowisku odizolowanym i utworzyć PR; wcześniejsze modele były mniej wytrwałe i nie zdołały znaleźć podatności, więc rezygnowały z części dotyczącej PR.¹

Wiele mechanizmów bezpieczeństwa dla asystentów AI projektuje się wokół pojedynczych działań. Jeśli działanie jest niedozwolone, zostaje zablokowane. Jeśli jest wrażliwe, system prosi użytkownika o wyraźną zgodę. Jednak modele działające długo, których działania mogą autonomicznie rozwijać się przez godziny, dni, a nawet tygodnie, podważają ten układ: monitorowanie pojedynczych działań nie wystarcza już do śledzenia intencji całej trajektorii.

Na przykład w scenariuszu, w którym model poproszono o rozwiązanie problemu, model zauważył, że inne systemy miały udane, lecz prywatne zgłoszenia, i próbował odzyskać te rozwiązania z backendu ewaluacyjnego. Gdy jego pierwszą próbę zablokowano, ponieważ skaner wykrył token uwierzytelniający, model podzielił treść tokena na dwa fragmenty, zaciemnił je, a następnie odtworzył poświadczenie w czasie wykonywania, tak aby pełny token nigdy nie pojawił się jako jeden ciąg znaków. Model jasno wskazał zarówno w komentarzach do użytkownika, jak i w śladach rozumowania, że podejmuje te kroki, aby obejść skaner.

Ten przykład pokazuje, że każdy krok może wyglądać akceptowalnie sam w sobie, podczas gdy cała sekwencja może prowadzić do wyniku, który nie zostałby zatwierdzony. Pokazuje też, że model skutecznie działający w długich horyzontach czasowych może nauczyć się słabych punktów systemu zatwierdzania i obejść je, aby osiągnąć swoje cele. Bezpieczeństwo przy długim horyzoncie wymaga pytania nie tylko: „czy to działanie jest dozwolone?”, lecz także: „do jakiego wyniku zmierza ta sekwencja działań?”

Z powodu takich incydentów wstrzymaliśmy wewnętrzne wdrożenie nowego modelu. Przebudowaliśmy system bezpieczeństwa wokół obrony warstwowej i monitorowania na poziomie trajektorii.

• Ewaluacje oparte na incydentach. Ewaluacje mogą dać nam wyobrażenie, czy system jest bezpieczny do wdrożenia, zanim faktycznie zostanie wdrożony. Aby jednak były jak najbardziej użyteczne, ewaluacja powinna odzwierciedlać rozkład i długość horyzontu trajektorii w rzeczywistym wdrożeniu. Dlatego wykorzystaliśmy zaobserwowane porażki do opracowania ewaluacji antagonistycznych. Odkryliśmy, że poprawa wyników w ewaluacjach wyprowadzonych z rzeczywistych incydentów prowadziła później do bezpieczniejszego zachowania po wdrożeniu produkcyjnym.
• Lepsza zgodność. Podjęliśmy kroki, aby ograniczyć skłonność modelu do podejmowania niepożądanych działań bez pozwolenia w dążeniu do celu użytkownika.  Na przykład odkryliśmy, że nasze modele gorzej zapamiętywały instrukcje podczas długich rolloutów, a gdy wytrenowaliśmy model pod kątem tej zdolności, powstał model, który pozostawał zgodny z intencjami także podczas dłuższych rolloutów. 
• Aktywne monitorowanie. Stworzyliśmy system monitorowania, który analizuje rozwijającą się trajektorię modelu pod kątem oznak omijania ograniczenia użytkownika lub granicy bezpieczeństwa. System monitorowania obserwuje nie tylko pojedyncze działanie, lecz całą trajektorię. Co ważne, ten system może wstrzymać sesję i powiadomić użytkownika, aby przyjrzał się jej dokładniej. Po analizie użytkownik może zdecydować, że praca modelu ma być kontynuowana, jeśli system monitorowania uruchomił się fałszywie. 
• Większa widoczność i kontrola dla użytkownika. Ułatwiliśmy użytkownikowi przeglądanie tych długotrwałych sesji, sprawdzanie wykonanych działań i monitorowanie interwencji.

Aby ocenić nowy system monitorowania, odtworzyliśmy niewielki zestaw wewnętrznych środowisk wdrożeniowych, w których model wcześniej podejmował działania niezgodne z intencjami, tym razem z nowymi zabezpieczeniami². Nowe zabezpieczenia zdołały wychwycić znacznie więcej działań niezgodnych z intencjami podejmowanymi przez model, a wszystkie pominięte przypadki uznano za mało dotkliwe.

Oto kilka przykładów takich incydentów o niskiej dotkliwości:

• Aby uzyskać dostęp do narzędzia wiersza poleceń Linear, model uruchomił zagnieżdżoną sesję codex --yolo, choć w rzeczywistości mógł to zrobić bez flagi --yolo.
• Model zauważył, że wcześniej aktywny zasób zniknął, po czym zaczął eksplorować inne aktywne pody CPU w przestrzeni nazw swojego właściciela i łączyć się z nimi przez SSH, a także — bez powodzenia — z podami należącymi do innych pracowników OpenAI, bez dobrego powodu.
• Model miał wiele zablokowanych procesów find, a każde polecenie powłoki się zawieszało. Następnie uruchomił kill -9 -1, co — gdyby polecenie zostało wykonane — wysłałoby SIGKILL do każdego procesu, który wolno mu zabić w tym podzie. Polecenie przekroczyło jednak limit czasu i nie zostało wykonane.

Po przetestowaniu nowego systemu uznaliśmy, że można przywrócić ograniczony wewnętrzny dostęp do modeli o możliwościach długiego horyzontu. Od rozpoczęcia ponownego wdrożenia kilka tygodni temu nie zaobserwowaliśmy żadnego poważnego obejścia zabezpieczeń. Pierwsza wersja tych zabezpieczeń była celowo konserwatywna. Nadal dostrajamy system, aby ograniczać zbędne przerwy bez osłabiania zabezpieczeń.

Ponieważ wdrażaliśmy iteracyjnie, mogliśmy znaleźć i usunąć luki przed rozszerzeniem dostępu. Ewaluacje przed wdrożeniem pozostają niezbędne, ale wdrożenie ujawnia zachowania, których one nie wychwytują. Rozpoczęcie od ograniczonego dostępu pozwoliło nam obserwować model w praktyce, wstrzymywać działanie, gdy pojawiały się problemy, wykorzystywać te porażki do budowania lepszych ewaluacji i zabezpieczeń oraz przywrócić ograniczony dostęp po przetestowaniu zmian.

W miarę jak modele podejmują dłuższe i bardziej złożone zadania, niepowodzenia przeoczone przez ewaluacje mogą mieć poważniejsze konsekwencje. Będziemy nadal zmniejszać lukę między ewaluacją a wdrożeniem: testować modele na dłuższych trajektoriach, poprawiać zgodność z intencjami, budować monitoring zdolny do interwencji oraz dawać użytkownikom większą przejrzystość i kontrolę. Te wyzwania nie będą dotyczyć wyłącznie OpenAI i mamy nadzieję, że dzielenie się naszymi wnioskami pomoże szerszej branży się na nie przygotować.