Czym dla nas jest specyfikacja modelu?

W OpenAI wierzymy, że sztuczna inteligencja powinna być sprawiedliwa, bezpieczna i powszechnie dostępna, aby więcej osób mogło wykorzystywać ją do rozwiązywania trudnych problemów, tworzenia nowych możliwości i czerpania korzyści w takich obszarach jak zdrowie, nauka, edukacja, praca i codzienne życie. Wierzymy, że zdemokratyzowany dostęp do AI to najlepsza droga w przyszłość: nie chcemy AI, z której korzyści lub kontrola nad którą są skoncentrowane w rękach nielicznych, ale AI, której więcej osób może używać, zrozumieć ją i pomagać w kształtowaniu jej rozwoju.

To jeden z głównych powodów, dla których powstały specyfikacje modelu OpenAI. Specyfikacja modelu⁠(otwiera nowe okno) to nasze formalne ramy zachowania modelu. Definiuje ona, w jaki sposób chcemy, aby modele stosowały się do instrukcji, rozwiązywały konflikty, szanowały swobodę użytkownika i zachowywały się w bezpieczny sposób w niezwykle szerokim zakresie zapytań, które użytkownicy codziennie im zadają. W szerszym ujęciu jest to nasza próba wyraźnego określenia zamierzonego działania modelu: nie tylko w ramach naszego procesu treningu, lecz także w formie, którą użytkownicy, programiści, badacze, decydenci i ogół społeczeństwa mogą rzeczywiście przeczytać, przeanalizować i omawiać.

Specyfikacja modelu nie stanowi twierdzenia, że nasze modele już dziś idealnie tak się zachowują. Pod wieloma względami ma ona charakter opisowy, ale wyznacza także kierunek, w jakim chcemy rozwijać zachowanie modelu. Używamy jej, aby wyraźniej opisać zamierzone zachowanie, dzięki czemu możemy ukierunkować szkolenia, oceniać względem niej uzyskiwane wyniki i z czasem poprawiać jej treść. 

W niniejszym wpisie przedstawiamy kontekst, którego nie ma w samej specyfikacji modelu, w tym filozofię i mechanikę, które za nią stoją: jak jest zorganizowana, dlaczego dokonaliśmy danych wyborów strukturalnych oraz jak ją tworzymy, wdrażamy i rozwijamy.

Specyfikacja modelu jest jednym z elementów szerszego podejścia do bezpiecznej i odpowiedzialnej sztucznej inteligencji w OpenAI. Ramy gotowości⁠ koncentrują się na ryzykach związanych z pionierskimi możliwościami oraz zabezpieczeniach wymaganych w miarę zwiększania się poziomu tych zagrożeń, a specyfikacja modelu dotyczy innego, ale pokrewnego pytania: jak nasze modele powinny się zachowywać w szerokim zakresie sytuacji. Patrząc jeszcze szerzej: odporność w obszarze AI ma na celu sprostanie szerszemu wyzwaniu społecznemu, jakim jest pomoc społeczeństwu w czerpaniu korzyści z zaawansowanej AI przy jednoczesnym ograniczaniu zakłóceń i pojawiających się zagrożeń w miarę wdrażania systemów o coraz większych możliwościach. Wszystkie te inicjatywy te mają zapewnić, że przejście do AGI będzie stopniowe, iteracyjne i demokratycznie zrozumiałe oraz, że ludzie i instytucje będą miały czas na dostosowanie się i wypracowanie zabezpieczeń, mechanizmów odpowiedzialności oraz społecznego zrozumienia potrzebnych do tego, by potężna AI pozostawała zgodna z ludzkimi interesami.

Klarowne informacje kierowane do opinii publicznej dotyczące zachowania modelu mają znaczenie zarówno w kontekście sprawiedliwości, jak i bezpieczeństwa. Są istotne pod względem bezstronności, ponieważ ludzie muszą rozumieć, w jaki sposób i dlaczego AI traktuje ich w określony sposób, a także muszą być w stanie rozpoznawać, kwestionować i rozwiązywać problemy związane z bezstronnością, gdy takie się pojawiają. Ma to również znaczenie dla bezpieczeństwa, ponieważ w miarę jak systemy AI stają się coraz bardziej zaawansowane, ludzie i instytucje potrzebują jaśniejszych oczekiwań dotyczących tego, jak się zachowywać, jakie kompromisy wiążą się z tymi systemami oraz jak te wybory można z czasem udoskonalać. Taka czytelność komunikacji zwiększa również odporność, dając większej liczbie osób konkretne dane do przeanalizowania, zakwestionowania i ulepszenia.

Od czasu pierwszej wersji z 2024 roku specyfikacja modelu znacznie ewoluowała, w miarę jak lepiej poznawaliśmy preferencje i potrzeby użytkowników, rozszerzaliśmy jej zakres, aby objąć większe możliwości i dostosować ją, a także wyciągaliśmy wnioski z opinii uzyskiwanych na temat zachowań modelu i samej specyfikacji modelu. W duchu wdrażania iteracyjnego⁠ specyfikacja modelu to dokument, który ewoluuje i obejmuje zarówno podstawowe wartości, jak i wyraźne, zrozumiałe zasady, które są powiązane z procesem modyfikowania poszczególnych elementów w miarę zdobywania doświadczeń z rzeczywistych wdrożeń i informacji zwrotnych. Rozwijamy również systemy uzyskiwania opinii od użytkowników, takie jak zbiorowe dostosowanie⁠, aby ludzkość zachowała kontrolę nad sposobem wykorzystywanie sztucznej inteligencji i kształtowania jej zachowań.

Wewnętrznie stanowi to dla nas punkt odniesienia dla zamierzonego zachowania oraz jednolitą strukturę dla szkoleń, oceny i zarządzania. Zewnętrznie zapewnia to publiczny punkt odniesienia, który pozwala ludziom zrozumieć nasze podejście, poddać je krytyce, abyśmy z czasem mogli je udoskonalać.

Specyfikacja modelu składa się z kilku różnych rodzajów wytycznych dotyczących modelu. Taki układ jest zastosowany celowo. Różne aspekty zachowania modelu wymagają odmiennego podejścia, a wartościowy dokument publiczny nie może być tylko suchym zbiorem zasad.

Specyfikacja modelu zaczyna się od ogólnego zamysłu: jasnego opisu obszarów, które staramy się optymalizować na poziomie systemu i informacji, dlaczego chcemy to osiągnąć.

We wstępie wyjaśniamy trzy cele dotyczące planowanej realizacji naszej misji:

• Iteracyjne wdrażanie modeli, które usprawniają działania programistów i użytkowników
• Zapobieganie wyrządzaniu przez nasze modele poważnych szkód użytkownikom lub innym osobom
• Zachowanie licencji OpenAI na funkcjonowanie

Następnie wyjaśniamy, jak podchodzimy do równoważenia tych celów w praktyce, konkretyzując kompromisy na tyle, aby umożliwiały stosowanie bardziej szczegółowych zasad przedstawionych poniżej.

Co ważne, ten wstęp nie ma być bezpośrednią instrukcją dla modelu. Przynoszenie korzyści ludzkości jest celem OpenAI, a nie celem, do którego nasze modele miałyby zmierzać autonomicznie. Zamiast tego chcemy, aby modele postępowały zgodnie z hierarchią decyzyjną, która obejmuje specyfikację modelu oraz instrukcje od OpenAI, programistów i użytkowników, nawet jeśli niektóre osoby mogą nie zgadzać się z wynikiem w danym przypadku.

Uważamy, że jest to właściwa równowaga, ponieważ cenimy ludzką autonomię i wolność intelektualną. Gdybyśmy trenowali modele tak, aby decydowały o tym, których instrukcji przestrzegać, na podstawie naszego poglądu na to, co jest dobre dla społeczeństwa, OpenAI znalazłoby się w pozycji arbitra rozstrzygającego kwestie moralne na bardzo szerokim poziomie. Niemniej wstęp nadal ma znaczenie. W przypadku wystąpienia niejasności co do sposobu stosowania specyfikacji modelu wstęp powinien pomóc je rozstrzygnąć.

Specyfikacja modelu zawiera również publiczne zobowiązania, które wykraczają poza bezpośrednio mierzalne zachowanie modelu i obejmują intencje szkoleniowe oraz ograniczenia wdrożeniowe. Na przykład nasze Nieprzekraczalne granice⁠(otwiera nowe okno) obejmują zobowiązanie, że we wdrożeniach własnych, takich jak ChatGPT, nigdy nie będziemy wykorzystywać komunikatów systemowych do celowego naruszania obiektywizmu⁠(otwiera nowe okno) ani powiązanych zasad; a sekcja Żadne inne cele⁠(otwiera nowe okno) zawiera zobowiązania dotyczące naszych intencji optymalizowania odpowiedzi modelu z korzyścią dla użytkownika, a nie pod kątem zwiększania naszych przychodów ani wydłużania czasu spędzanego przez użytkowników w serwisie, co nie przynosi im korzyści.

Sednem specyfikacji modelu jest hierarchia decyzyjna, czyli struktura określająca, które instrukcje powinny mieć zastosowanie w danej sytuacji. Obejmuje ona również sposób, w jaki model powinien postępować z niedookreślonymi instrukcjami, zwłaszcza w sytuacjach w użyciem agentów, gdzie od modelu oczekuje się samodzielnego uzupełniania szczegółów przy jednoczesnym ostrożnym kontrolowaniu skutków w świecie rzeczywistym.

Podstawowa zasada dotycząca ustalania, które instrukcje powinny mieć zastosowanie, jest prosta. Instrukcje mogą pochodzić z różnych źródeł, w tym od OpenAI, programistów i użytkowników. Te instrukcje mogą być ze sobą sprzeczne. Hierarchia decyzyjna wyjaśnia, jak model powinien rozstrzygać takie konflikty.  

Każdą zasadę specyfikacji modelu i instrukcję opatrzono poziomem uprawnień⁠(otwiera nowe okno). Model jest instruowany, aby w przypadku konfliktu dostosował się do treści i intencji instrukcji o wyższym priorytecie. Jeśli użytkownik prosi o pomoc w zrobieniu bomby, model powinien priorytetowo traktować ścisłe granice bezpieczeństwa⁠(otwiera nowe okno). Jeśli użytkownik poprosi, żeby go obrazić, model powinien zasadniczo nadać temu żądaniu wyższy priorytet niż mają zasady przeciwdziałania nadużyciom⁠(otwiera nowe okno) zawarte w specyfikacji modelu cechujące się niższym priorytetem.

Taka struktura pozwala określić stosunkowo niewielki zestaw reguł, których nie można nadpisywać, który działa obok większego zestawu ustawień domyślnych. W ten sposób staramy się maksymalizować swobodę użytkownika i kontrolę dewelopera w ramach ograniczeń bezpieczeństwa.

• Sztywne reguły to jasno określone granice, których użytkownicy ani programiści nie mogą nadpisywać (w terminologii specyfikacji modelu są to instrukcje na poziomie „root” lub „system”). Mają one głównie charakter zakazujący i wymagają od modeli unikania zachowań, które mogą prowadzić do katastrofalnych zagrożeń, bezpośredniego uszczerbku na zdrowiu, naruszenia prawa lub podważenia hierarchii decyzyjnej. Spodziewamy się, że AI stanie się technologią podstawową o fundamentalnym znaczeniu dla społeczeństwa, analogiczną do podstawowej infrastruktury internetowej. W związku z tym nakładamy na nią jedynie takie ograniczenia, które mogłyby ograniczać wolność intelektualną, gdy uznajemy je za niezbędne dla szerokiego grona deweloperów i użytkowników korzystających z tej technologii. W specyfikacji modelu sekcja Nie przekraczaj granic⁠(otwiera nowe okno) zawiera sztywne zasady dotyczące konkretnych zagrożeń dla bezpieczeństwa, a Zasady dla osób poniżej 18 lat⁠(otwiera nowe okno) dodają dodatkowe zabezpieczenia dla użytkowników poniżej 18 roku życia.
• Ustawienia domyślne to punkty wyjścia, które można zmieniać: zachowanie asystenta oparte jest na „najlepszym przypuszczeniu”, gdy użytkownik lub programista nie określili preferencji. Z ustawień domyślnych korzystamy, aby zapewnić przewidywalne i możliwe do kontrolowania zachowanie na dużą skalę, dzięki czemu użytkownicy mogą przewidzieć, co się wydarzy, bez konieczności tworzenia za każdym razem niestandardowego zestawu instrukcji. Ustawienia domyślne zachowują sterowalność: użytkownicy i programiści mogą sterować tonem, poziomem szczegółowości, formatem, a nawet punktem widzenia w granicach bezpieczeństwa. Ustawienia domyślne na poziomie wytycznych (takie jak ton lub styl) są zaprojektowane tak, aby można było nimi domyślnie sterować, natomiast ustawienia domyślne na poziomie użytkownika (takie jak prawdomówność i obiektywizm) stanowią fundament zaufania oraz przewidywalności i mogą zostać nadpisane wyłącznie przez wyraźne instrukcje. Nie powinny one po cichu się zmieniać na podstawie przeczucia. Jeśli użytkownik chce przyjąć inne stanowisko wobec faktów, ujęcie tego w formie wyraźnej instrukcji sprawia, że taka zmiana pozostaje przejrzysta i zrozumiała. Te domyślne założenia znajdują odzwierciedlenie w sekcjach Wspólne poszukiwanie prawdy⁠(otwiera nowe okno), Wykonuj najlepszą pracę⁠(otwiera nowe okno) oraz Używaj odpowiedniego stylu⁠(otwiera nowe okno), co obejmuje normy dotyczące uczciwości i obiektywizmu, unikania sykofancji oraz normy interakcji, takie jak bezpośredniość oraz adekwatne do kontekstu ciepło wypowiedzi i profesjonalizm.

Poza hierarchią specyfikacja modelu wykorzystuje narzędzia interpretacyjne, które pomagają modelom (i ludziom) spójnie stosować ją w niejednoznacznych przypadkach. Takie formy pomocy obejmują: 

• Kryteria podejmowania decyzji, które pomagają modelowi dokonywać spójnych wyborów w niejednoznacznych sytuacjach, bez udawania, że istnieje jedna mechaniczna reguła. Przykładowo: wskazówki zawarte w specyfikacji modelu dotyczące kontrolowania skutków ubocznych⁠(otwiera nowe okno) obejmują takie kwestie jak minimalizowanie nieodwracalnych działań, utrzymywanie działań proporcjonalnych do celu, ograniczanie nieprzyjemnych niespodzianek oraz preferowanie podejść odwracalnych, co należy zbalansować względem innych celów, takich jak szybkie i skuteczne wykonanie zadania.
• Konkretne przykłady pokazujące, jak należy stosować zasadę w praktyce. Są to krótkie przykłady poleceń i odpowiedzi, które zwykle obejmują zarówno odpowiedź zgodną, jak i niezgodną z oczekiwaniami, często w przypadku trudnego polecenia znajdującego się blisko istotnej granicy decyzyjnej. Celem nie jest symulowanie w pełni realistycznej konwersacji, ale jasne przedstawienie kluczowego rozróżnienia i to w sposób, który jednocześnie pokazuje pożądany styl odpowiedzi.

Dbamy o to, aby liczba przykładów była stosunkowo niewielka, i skupiamy się na tych najbardziej informacyjnych. Lepsze zestawy testów sprawdzają więcej nietypowych przypadków.

Specyfikacja jest interfejsem, a nie implementacją i opisuje zachowanie, którego oczekujemy, a nie każdy szczegół tego, jak je uzyskujemy. Staramy się unikać wiązania jej ze szczegółami implementacyjnymi, takimi jak wewnętrzne formaty tokenów czy dokładny przepis treningowy dla konkretnego zachowania, ponieważ te szczegóły mogą się zmieniać, nawet gdy pożądane zachowanie jest stałe. Głównymi odbiorcami specyfikacji modelu nie jest model, lecz ludzie. Ma ona pomóc pracownikom OpenAI, użytkownikom, programistom, badaczom i decydentom zrozumieć zamierzone zachowania, omawiać je i decydować o nich.

Specyfikacja opisuje również model, a nie cały produkt. Jej uzupełnieniem są zasady użytkowania⁠, które określają nasze oczekiwania dotyczące sposobu, w jaki użytkownicy powinni korzystać z interfejsu API i ChatGPT. System, z którego korzystają użytkownicy, obejmuje więcej niż tylko model: istotne są również funkcje produktu, takie jak niestandardowe instrukcje i pamięć, monitorowanie, egzekwowanie zasad oraz inne warstwy. Bezpieczeństwo znacząco wykracza poza zachowanie modelu, a my wierzymy w dogłębną obronę⁠. 

Specyfikacja nie jest też kompletnym opisem całego naszego stosu treningowego ani każdego rozróżnienia w naszych wewnętrznych zasadach. Celem nie jest uchwycenie każdego szczegółu, ale zapewnienie, aby najważniejsze decyzje dotyczące zachowania były zrozumiałe w całkowicie spójny sposób z naszym zamierzonym zachowaniem modelu.

Istnieje kilka powodów, by zawrzeć aż tyle informacji w specyfikacji, a nie zakładać, że czytelnik (lub model) zdoła wywnioskować wszystko na podstawie kilku ogólnych celów.

Po pierwsze: Specyfikacja modelu jest narzędziem zapewniającym przejrzystość i skupiającym się na odpowiedzialności . Ma ona zachęcać użytkowników do przekazywania wartościowych opinii. Publicznie określony cel pomaga im ocenić, czy dane zachowanie jest błędem czy pożądaną funkcją. Daje też stabilny punkt odniesienia względem krytyki i konkretnych informacji zwrotnych. Dlatego specyfikację modelu udostępniliśmy na licencji open source⁠(otwiera nowe okno) i zdecydowaliśmy się rozwijać ją publicznie. Od czasu pierwszego wydania wprowadziliśmy wiele zmian na podstawie wieli opinii zebranych za pośrednictwem różnych mechanizmów, w tym formularzy, publicznej krytyki oraz celowych działań⁠ mających na celu zebranie demokratycznych opinii.

Po drugie: specyfikacja modelu jest narzędziem zapewniającym koordynację w OpenAI. Dla osób zajmujących się badaniami, rozwojem produktu, bezpieczeństwem, polityką, kwestiami prawnymi, komunikacją i innymi obszarami stanowi ona wspólny słownik usprawniający omawianie zachowania modelu oraz mechanizm proponowania i weryfikacji zmian.

Po trzecie: jawne zasady mogą kompensować praktyczne ograniczenia inteligencji modelu i kontekstu działania oraz sprawiają, że zachowanie modelu będzie bardziej przewidywalne. Chociaż z czasem staje się to coraz mniej prawdziwe, niektóre zasady mają na celu kompensowanie niewystarczającej inteligencji, w sytuacjach gdy modele mogą nie być w stanie w niezawodny sposób wywnioskować właściwego zachowania z zasad wyższego poziomu. Na przykład sekcja Bądź zrozumiały i bezpośredni⁠(otwiera nowe okno) zalecał wcześniejszym modelom, by pokazywały tok rozumowania przed podaniem odpowiedzi na skomplikowane problemy wymagające obliczeń, ale dziś nasze modele naturalnie uczą się tego zachowania dzięki uczeniu przez wzmacnianie⁠. 

Inne zasady dotyczą ograniczonego kontekstu w czasie działania: asystent może opierać się wyłącznie na tym, co jest obserwowalne w bieżącej interakcji, i rzadko zna pełną sytuację użytkownika, jego intencje, dalsze wykorzystanie informacji albo to, jakie zabezpieczenia istnieją poza modelem. W takich przypadkach, nawet jeśli modele mogłyby być w stanie określić właściwe działanie przy wystarczającej ilości badań i namysłu, precyzyjność zwiększa efektywność i przewidywalność, sprowadzając wiele uznaniowych decyzji do postaci wskazówek, które ograniczają różnice między podobnymi poleceniami i sprawiają, że działanie jest łatwiejsze do zrozumienia zarówno dla użytkowników, jak i badaczy.

Celem specyfikacji modelu jest zapewnienie pełnego wykazu ogólnych zasad istotnych dla oceny i pomiarów. Jeśli chcesz ocenić, czy model zachowuje się zgodnie z zamierzeniami, wygodna w tym celu będzie publicznie dostępna lista głównych kategorii zachowań, które cię interesują.

Łatwo ulec pokusie i uznawać, że wystarczająco zaawansowany model powinien być w stanie wywnioskować właściwe zachowanie na podstawie krótkiej listy celów, takich jak „bądź pomocny i zapewniaj bezpieczeństwo”. Jest w tym trochę prawdy. W dziedzinach, w których istnieją obiektywne kryteria sukcesu, takich jak matematyka, sztuczna inteligencja może często zastępować szczegółowe reguły.

Jednak ogólnie zachowanie modelu nie przypomina rozwiązywania prostego zadania matematycznego, ponieważ modele często działają w bardziej złożonych obszarach, w których nie ma jednej moralnie właściwej odpowiedzi, co do której wszyscy mogliby się zgodzić. Interpretacja stwierdzenia „bądź pomocny i zapewniaj bezpieczeństwo” przez model zależy na przykład w ogromnym stopniu od kontekstu i jest wynikiem podejmowania decyzji, które z natury są obciążone wartościami. Sztuczna inteligencja nie podpowie Ci, na jakie kompromisy pójść w kwestiach etyki i wartości. Tak więc nawet gdy modele stają się coraz inteligentniejsze, wciąż musimy pracować nad tym, by rozumieć oraz ukierunkowywać osądy wartościujące i co to znaczy działać „etycznie” w danym przypadku. Większość powodów przemawiających za posiadaniem specyfikacji modelu pozostaje aktualna nawet wtedy, gdy modele stają się znacznie bardziej zaawansowane: nadal potrzebujemy publicznie dostępnego punktu odniesienia, wokół którego ludzie mogą koordynować swoje działania, sposobu oceny, czy zachowanie jest zgodne z naszymi intencjami, oraz mechanizmu aktualizowania zasad w miarę zdobywania wiedzy. Jeśli jedyną zasadą jest „być pomocnym i zapewniać bezpieczeństwo”, to nie istnieje mechanizm, który umożliwiałby ludziom debatowanie na przykład o granicach dotyczących tego, jakich treści model nie powinien prezentować, pozostawiając wszystkie te decyzje modelowi.

Co więcej, w miarę jak modele stają się coraz bardziej zdolne, coraz bardziej autonomiczne i coraz szerzej wdrażane, rośnie koszt niejednoznaczności. To sprawia, że jasne ramy behawioralne są coraz ważniejsze.

Pomocną analogią jest różnica między konstytucją spisaną a prawem precedensowym. Choć spisana konstytucja może zawierać zarówno ogólne zasady, jak i konkretne reguły, nie jest w stanie przewidzieć wszystkich możliwych przypadków, które mogą wystąpić i wymagać jej jako odniesienia. Rzeczywiste systemy zarządzania wymagają również mechanizmów interpretacyjnych, doprecyzowań i jednoznacznych rozstrzygnięć, co pozwala rozwiązywać niejednoznaczne przypadki lub nieprzewidziane kwestie. Opublikowane zasady pomagają różnym zainteresowanym stronom koordynować działania nawet wtedy, gdy interesariusze się nie zgadzają, a także ograniczają możliwość wprowadzania zmian, wymagając ich wyraźnego określenia. Specyfikacja modelu ma spełniać wszystkie te funkcje: deklaracji zasad, publicznych ram zachowania oraz procesu zmieniania specyfikacji w miarę upływu czasu.

Mimo wszystko nie uważamy jednak, że każdy aspekt, który jest istotny w zachowaniu modelu, zawsze da się sprowadzić do jawnych reguł. W miarę jak systemy stają się coraz bardziej autonomiczne, niezawodność i zaufanie będą w coraz większym stopniu zależeć od szerszego zakresu umiejętności i predyspozycji: skutecznego komunikowania niepewności, poszanowania zakresów autonomii, unikania niepożądanych niespodzianek, śledzenia intencji w czasie oraz właściwego rozumienia ludzkich wartości osadzonych w kontekście.

Podczas tworzenia specyfikacji modelu istnieje pełny zakres sytuacji między opisywaniem rzeczywistych zachowań modelu obserwowanych obecnie ze wszystkimi jego niedoskonałościami, a opisywaniem idealnego celu na odległą przyszłość. Staramy się zachować równowagę, zwykle celując w okres od 0 do 3 miesięcy w przyszłości. Dlatego specyfikacja modelu często wyprzedza model w co najmniej kilku obszarach aktywnego rozwoju.

W ten sposób odzwierciedlamy rolę specyfikacji modelu jako opisu zamierzonego zachowania. Powinna ona wskazywać nam spójny kierunek, a jednocześnie być zakorzeniona w aktualnych działaniach lub obszarach, które jednoznacznie planujemy wdrożyć w najbliższym czasie.

Specyfikacja modelu jest opracowywana w otwartym procesie wewnętrznym. Każda osoba w OpenAI może komentować lub zaproponować zmiany, a ostateczne aktualizacje są zatwierdzane przez szerokie grono międzydziałowych interesariuszy. W praktyce dziesiątki osób bezpośrednio współtworzyły treść, a znacznie więcej pracowników z działów badań, inżynierii, rozwoju produktu, bezpieczeństwa, polityki, kwestii prawnych, komunikacji, spraw międzynarodowych i innych funkcji wniosło swoje uwagi. Informacje czerpiemy również z publicznie udostępnianych wersji i opinii, które pomagają poddać te decyzje próbie w warunkach rzeczywistego wdrożenia.

Jest to istotne, ponieważ zachowania modelu (i ich konsekwencje w świecie realnym) są niezwykle złożone. Nikt nie jest w stanie zrozumieć pełnego zestawu zachowań, procesu treningu i dalszych konsekwencji, ale dzięki wielu współpracownikom i recenzentom o różnych specjalizacjach możemy poprawić jakość i zwiększyć pewność.

Jedną z rzeczy, która miło nas zaskoczyła, było to, że rzeczywisty konsensus jest często możliwy, zwłaszcza gdy zmuszamy się do spisania kompromisów wystarczająco precyzyjnie, by punkty sporne stały się jednoznaczne.

Specyfikacja modelu również nie powstaje w próżni. Duża część treści, która ostatecznie się w niej znajduje, stanowi podsumowanie szerszych prac nad zachowaniem, bezpieczeństwem i polityką. Znaczny zakres specyfikacji modelu to w gruncie rzeczy swoiste tłumaczenie: przekładamy istniejące prac na prostszą, bardziej spójną, lepiej uporządkowaną i bardziej przystępną formę bez utraty ich podstawowego celu.

Nasze modele produkcyjne nie odzwierciedlają jeszcze w pełni specyfikacji modelu z kilku powodów.

• Trenowanie modelu może nie nadążać za aktualizacjami specyfikacji modelu. Specyfikacja opisuje zachowanie, do którego dążymy, więc może wykraczać poza to, do czego został wytrenowany nasz najnowszy model.
• Trening może nieumyślnie nauczyć zachowań niezgodnych ze specyfikacją modelu. Dokładamy wszelkich starań, aby tego unikać, a gdy już do tego dochodzi, traktujemy to jako poważny błąd i staramy się zmodyfikować wtedy zachowanie modelu albo specyfikację, tak aby były ze sobą zgodne.
• Trenowanie nigdy nie może w pełni objąć spektrum wszystkich możliwych zachowań. Rzeczywiste użytkowanie obejmuje wiele kontekstów i przypadków skrajnych, które ujawniają się dopiero przy wykorzystaniu modelu na dużą skalę, a żaden proces trenowania nie jest w stanie objąć wszystkiego.
• Uogólnienie może różnić się od tego, co zamierzaliśmy uzyskać. Model może generować „właściwe” wyniki podczas treningu z niezamierzonych powodów, co może prowadzić do niezamierzonego zachowania w nowych sytuacjach, które różnią się od tych obserwowanych podczas treningu. Techniki takie jak dostosowanie oparte na rozumowaniu⁠ pomagają, ale nie zapewniają pełnego rozwiązania.

Czyli fakt, że specyfikacja modelu opisuje szeroki zakres pożądanych zachowań, nie oznacza, że istnieje jedna metoda uczenia ich wszystkich. Różne aspekty zachowania (stosowanie się do instrukcji, granice bezpieczeństwa, osobowość, skalibrowane wyrażanie niepewności i inne) często wymagają różnych technik i wiążą się z różnymi trybami błędów. Specyfikacja modelu ułatwia zrozumienie i ocenienie zamierzonego zachowania, ale jej skuteczne wdrożenie pozostaje zarówno sztuką, jak i aktywnym obszarem badań.

Poza niniejszym wpisem udostępniamy Oceny specyfikacji modelu⁠(otwiera nowe okno): oparty na scenariuszach zestaw ocen, który przy użyciu niewielkiej liczby reprezentatywnych przykładów stara się objąć jak najwięcej założeń zawartych w specyfikacji modelu. Pomaga nam to określać, gdzie zachowanie modelu i specyfikacja modelu mogą nie być ze sobą zgodne, a także sprawdzać, czy modele interpretują specyfikację modelu w zamierzony przez nas sposób. Oceny te są tylko jednym z wielu elementów szerszej strategii oceniania, która obejmuje także bardziej ukierunkowane analizy w wielu wymiarach zachowania, w tym w konkretnych obszarach bezpieczeństwa, prawdomówności i sykofancji, osobowości i stylu oraz możliwości.

W praktyce większość aktualizacji specyfikacji wynika z powtarzającego się zestawu czynników:

• Publiczne problemy i opinie. Niejasności, przypadki brzegowe lub tryby awarii, zarówno w języku specyfikacji modelu, jak i w zachowaniu naszych modeli.
• Problemy wewnętrzne. Wzorce, które obserwujemy podczas rozwoju i testowania, co obejmuje niejednoznaczności, w przypadku których różne uzasadnione interpretacje prowadzą do odmiennych zachowań.
• Zmiany zasad dotyczących zachowania i bezpieczeństwa. Gdy ograniczenia lub zobowiązania wyższego poziomu ulegają zmianie, specyfikacja musi wyraźnie odzwierciedlać tę nową strukturę.
• Nowe możliwości i produkty. W miarę jak modele zyskują nowe możliwości, a my wprowadzamy nowe produkty, chcemy, aby specyfikacja modelu była ze wszystkim zgodna pod względem treści i zakresu – na przykład poprzez dodanie zasad dotyczących interakcji multimodalnych⁠(otwiera nowe okno), autonomicznych agentów⁠(otwiera nowe okno) i użytkowników poniżej 18 roku życia⁠(otwiera nowe okno).

Sposobem spisywania i modyfikowania specyfikację modelu rządzi kilka zasad projektowych.

• Przejrzystość i precyzja. „Bądź uczciwy” to dobra wartość, ale nie stanowi pełnej procedura podejmowania decyzji. Specyfikacja modelu powinna podkreślać różnice zdań, a nie ukrywać je za ugodowym językiem. W miarę możliwości powinniśmy wyraźnie wskazywać potencjalne konflikty między zasadami oraz przedstawiać wskazówki lub przykłady dotyczące sposobu ich rozwiązywania. Na przykład Nie kłam⁠(otwiera nowe okno) wskazuje na potencjalny konflikt z Bądź serdeczny⁠(otwiera nowe okno), co oznacza, że asystent powinien przestrzegać norm uprzejmości, jednocześnie nie posuwając się do białych kłamstw, które mogłyby przerodzić się w sykofancję⁠(otwiera nowe okno) i być niezgodne z najlepiej pojętym interesem użytkownika.
• Zasady merytoryczne. Czytelnik powinien być w stanie wybrać realistyczne polecenie i sformułować odpowiedź, którą inny czytelnik uzna za wyraźnie mieszczącą się w wyznaczonych granicach albo je przekraczającą (nawet jeśli w przypadkach granicznych potrzebna jest ocena sytuacji).
• Przykłady, które maksymalizują stosunek sygnału do szumu. Dobre przykłady często mają kluczowe znaczenie dla opracowania aktualizacji specyfikacji o wysokiej jakości. Przykłady powinny pomagać docierać do sedna trudności związanych z określaniem zachowania modelu, ujawniać złożone konflikty i jasno określać sposób ich rozwiązywania. Ponadto powinny w jak największym stopniu stanowić wzór pożądanego tonu i stylu, co może być trudne do wyrażenia w tekście pisanym.
• Niezawodność. Staramy się unikać przykładów zawierających zbędną niejednoznaczność lub złożoność, tak aby główny konflikt i zamierzone rozwiązanie były jasne.
• Spójność i przejrzysta organizacja. Dążymy do tego, aby zasady specyfikacji modelu były w pełni spójne ze sobą i z zamierzonym zachowaniem modelu oraz aby ogólna organizacja dokumentu była jasna i przystępna.

Specyfikacja modelu nie stanowi twierdzenia, że można spisać wszystko, co jest istotne, ani że modele zawsze będą trafiać w sedno. Jest to wyłącznie stwierdzenie, że zamierzone zachowanie jest na tyle ważne, że powinno być jasne, możliwe do wdrożenia i do zweryfikowania.

Trzy kryteria sukcesu wyznaczają kierunek jego rozwoju.

• Czytelność. Użytkownicy w OpenAI i poza firmą mogą trafnie przewidywać zachowanie i wskazać tekst, gdy zachowanie je zaskakuje.
• Praktyczność. Specyfikację modelu można wykorzystać do projektowania ocen, diagnozowania incydentów i podejmowania spójnych decyzji produktowych, a nie tylko do wyrażania wartości.
• Możliwość wprowadzania zmian. Specyfikacja modelu może ewoluować w miarę jak zyskujemy nową wiedzę, nie stając się przy tym niestabilnym, stale zmieniającym się celem.

W miarę rozwoju modeli i produktów spodziewamy się, że specyfikacja modelu będzie się rozszerzać i stawać bardziej precyzyjna wraz z pojawianiem się nowych możliwości i kontekstów wdrożeniowych. Naszym celem jest, by specyfikacja zachowań pozostała spójna, testowalna i zgodna z naszą misją zapewnienia, że AGI będzie przynosić korzyści całej ludzkości.