OpenAI

Control Room

Ładowanie…

W miarę jak rosną możliwości naszych modeli i związane z nimi zagrożenia dla bezpieczeństwa, coraz ważniejsza staje się zdolność wykrywania potencjalnych problemów i szybkiego zatrzymywania modeli w razie potrzeby. Właśnie dlatego stworzyliśmy Control Room.

Control Room to centralny system, który śledzi zadania obliczeniowe modeli w całej naszej infrastrukturze badawczej i szybko je zatrzymuje, gdy pojawiają się obawy o bezpieczeństwo lub zabezpieczenia. Obejmuje wszystkie badawcze zadania wnioskowania, w tym próbkowanie z użyciem agentów na potrzeby trenowania i ewaluacji modeli, przetwarzanie danych i inne zastosowania. Współpracuje z naszymi systemami monitorowania zachowań niezgodnych z założeniami i wstrzymuje generowanie wyników przez model w ciągu 35 sekund od decyzji o interwencji w celu zatrzymania lub wstrzymania zadania. Zaprojektowaliśmy go tak, aby działał nawet w razie awarii innych systemów, a także wstrzymywał generowanie wyników przez modele, jeśli sam Control Room przestanie działać.

Control Room jest już wdrożony w całej naszej infrastrukturze badawczej, gdzie jest najbardziej potrzebny. Nasza infrastruktura udostępniająca modele użytkownikom zewnętrznym jest już z natury znacznie bardziej scentralizowana i dysponuje rozwiniętymi mechanizmami operacyjnymi pozwalającymi w razie potrzeby szybko wyłączyć wdrożone modele.

Jak to działa

Control Room działa dzięki integracji kilku elementów: zadania obliczeniowego, silnika wnioskowania i scentralizowanej usługi Control Room.

  • Zadanie obliczeniowe to wykonywana praca, na przykład eksperyment z uczeniem przez wzmacnianie, ewaluacja, próbkowanie na dużą skalę lub przetwarzanie danych. Wymagamy, aby każde zadanie badawcze wykorzystujące wnioskowanie agentowe było powiązane z zatwierdzonym uzasadnieniem bezpieczeństwa.

  • Silnik wnioskowania, w skrócie silnik, to sam model. Można go traktować jako mózg modelu, działający bezpośrednio na procesorach graficznych (GPU). Zadanie obliczeniowe zwykle korzysta z jednego lub kilku modeli, które mogą działać na jednym lub kilku różnych silnikach wnioskowania. Z tego samego silnika wnioskowania może korzystać więcej niż jedno zadanie obliczeniowe.

  • Usługa Control Room śledzi zadania i decyduje, czy mogą nadal generować wyniki za pomocą modeli. Przed realizacją żądania silniki sprawdzają w usłudze Control Room, czy zadanie ma do tego uprawnienia. Jeśli zadanie zostało zatrzymane, usługa odrzuca żądanie, uniemożliwiając generowanie dalszych wyników.

Integracja z Control Room działa następująco:

  • Przy uruchamianiu nowego zadania jego kod wysyła do Control Room żądanie nowego identyfikatora job_id.

  • Za każdym razem, gdy zadanie musi próbkować tokeny z modelu, wysyła żądanie do silnika wnioskowania obsługującego ten model, przekazując job_id. Silnik prosi Control Room o zgodę na realizację tego żądania, przekazując mu job_id.

  • Control Room sprawdza, czy zadanie zostało zatrzymane, a jeśli tak — odrzuca żądanie wnioskowania. Silnik odpowiada odmową na żądanie wnioskowania wysłane przez zadanie, uniemożliwiając modelowi generowanie dalszych wyników dla tego zadania.

Jak działa Control Room

Badacz

Zadanie badawcze

<No job ID yet>

Silnik wnioskowania

Uruchamia model na GPU

Control Room

  • job_039, aktywne
  • job_040, aktywne
  • job_041, aktywne
KROK 1

Badacz decyduje o uruchomieniu zadania

Proces rozpoczyna się, gdy badacz uruchamia zadanie — na przykład eksperyment lub ewaluację.

Przykład: reakcja na alert z systemu monitorowania

Wszystkie nasze zadania uczenia przez wzmacnianie modeli pionierskich działają pod nadzorem modelu monitorującego. Model monitorujący to inny model, który sprawdza wszystkie działania trenowanego modelu i zgłasza alert, jeśli wykryje problem. Na przykład nasz niedawny incydent związany z DNS⁠(otwiera nowe okno) został wykryty przez model monitorujący.

Control Room i nasz system monitorowania są zintegrowane w następujący sposób:

  • Jeśli system monitorowania wykryje potencjalny problem, może zdecydować o zatrzymaniu zadania, zależnie od charakteru i wagi problemu.

  • W takim przypadku system monitorowania wysyła do Control Room komunikat z poleceniem zatrzymania zadania, przekazując job_id. Control Room odnotowuje zatrzymanie zadania.

  • Gdy zadanie o tym job_id ponownie wyśle żądanie wnioskowania w celu próbkowania kolejnych tokenów z dowolnego modelu działającego na dowolnym silniku, żądanie zostanie odrzucone, co uniemożliwi modelowi generowanie dalszych wyników.

Szybkość i niezawodność

Od chwili, gdy Control Room otrzyma polecenie zatrzymania zadania, do momentu, w którym dalszy postęp w realizacji zadania staje się niemożliwy, mija maksymalnie 35 sekund. To 35-sekundowe opóźnienie wynika z zastosowania warstwy pamięci podręcznej do autoryzacji wnioskowania, niezbędnej do obsługi wymaganej skali ruchu. Pracujemy nad skróceniem tego czasu do zera, aby móc natychmiast zatrzymywać zadania.

Za zadania obliczeniowe, w tym eksperymenty, zadania ewaluacyjne i inne, zwykle odpowiadają badacze lub zespoły badawcze, które je uruchamiają i obsługują. W rezultacie kod tych zadań często się zmienia i nie jest najlepszym miejscem na wdrażanie kluczowych mechanizmów, od których zależy bezpieczeństwo. Dlatego nasze rozwiązanie zaprojektowaliśmy tak, aby było odporne na błędy i awarie kodu zadań.

Osiągamy to dzięki wdrożeniu mechanizmu zatrzymywania w warstwie wnioskowania. Kod zadań obliczeniowych jest bardzo zróżnicowany i zdecentralizowany. Natomiast we wszystkich badaniach OpenAI używamy zaledwie kilku ścieżek wykonania kodu wnioskowania, a ich wdrożenia są znacznie bardziej scentralizowane i ujednolicone. Warstwa wnioskowania może więc służyć jako wspólny punkt kontroli, zapewniając silne gwarancje, że każde żądanie wnioskowania kierowane do modeli w ramach badań podlega autoryzacji przez Control Room. Dodatkowo stale prowadzimy kontrole za pomocą agentów i automatycznych procedur, aby sprawdzać, czy użytkownicy przypadkowo lub celowo nie uruchamiają nieautoryzowanych implementacji silników, w których integracja z Control Room nie została wdrożona lub jest wyłączona.

Ponadto nasz system „blokuje dostęp w razie awarii”. Oznacza to, że integracja Control Room z silnikami jest skonfigurowana tak, aby w razie niedostępności usługi Control Room wszystkie żądania wnioskowania były odrzucane do czasu przywrócenia jej normalnego działania. Dotyczy to zarówno błędów systemowych, jak i wyłączenia usługi z dowolnego innego powodu, w tym wskutek złośliwej ingerencji. Mechanizm blokowania w razie awarii jest już wdrożony we wszystkich zadaniach badawczych dotyczących modeli pionierskich. W ciągu najbliższych kilku dni zakończymy jego wdrażanie we wszystkich pozostałych zadaniach badawczych.


Control Room to tylko jeden z elementów naszego kompleksowego podejścia do bezpiecznego trenowania i wdrażania modeli pionierskich. W nadchodzących miesiącach będziemy nadal wzmacniać i rozbudowywać ten system, jednocześnie inwestując w monitorowanie zachowań niezgodnych z założeniami i naruszeń zabezpieczeń. Jeśli chcesz pomóc w tworzeniu systemów zapewniających bezpieczny rozwój i wdrażanie AGI oraz ochronę przed zagrożeniami, sprawdź nasze⁠ oferty pracy⁠!