Control Room
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.
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
Zadanie badawcze
Silnik wnioskowania
Uruchamia model na GPU
Control Room
- job_039, aktywne
- job_040, aktywne
- job_041, aktywne
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.
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!

