Wspólny przewodnik po wiarygodnych ewaluacjach stron trzecich

Niezależne, godne zaufania ewaluacje prowadzone przez strony trzecie odgrywają kluczową rolę⁠ we wzmacnianiu ekosystemu bezpieczeństwa. Ewaluacje te są prowadzone na modelach pionierskich, aby dostarczyć dodatkowych dowodów na poparcie twierdzeń dotyczących krytycznych zdolności i środków ograniczania ryzyka. W tym wpisie przedstawiamy dotychczasowe wnioski i rekomendujemy podejścia do projektowania ewaluacji, które mogą trafnie oceniać modele pionierskie i mamy nadzieję, że pomogą kształtować powstające standardy w tym obszarze.

Wcześniej wiele ewaluacji traktowało modele jak chatboty: ewaluacja kierowała do modelu polecenie tak, jakby użytkownik zadawał pytanie, model odpowiadał, a oceniający oceniał wynik. Dzisiejsze modele pionierskie potrafią znacznie więcej: mogą używać narzędzi, wieloetapowo śledzić informacje i działać w ramach większego przepływu pracy. Oznacza to, że wydajność zależy nie tylko od modelu, lecz także od środowiska, w którym odbywa się zadanie, oraz od konfiguracji ułatwiającej jego działania. Ta otaczająca konfiguracja, którą nazywamy „otoczeniem operacyjnym”, może zmieniać kluczowe aspekty działania systemu, w tym sposób używania narzędzi, śledzenia informacji czy wychodzenia z błędów.

To zmienia sposób prowadzenia ewaluacji oraz to, na co czytelnicy powinni zwracać uwagę w raportach z ewaluacji. Naszym zdaniem najbardziej użyteczne raporty jasno opisują dwa aspekty poza samym wynikiem: po pierwsze, określają, jakie twierdzenie miała testować konfiguracja ewaluacji, a po drugie, przedstawiają dostępne dowody na to, że wynik ewaluacji jest trafny.

Twierdzenia testowane w ewaluacjach zwykle należą do jednej z trzech kategorii¹:

• Elicytacja możliwości: Czy model może wiarygodnie przejawiać oceniane możliwości? 
• Skuteczność zabezpieczeń: Jak odporne są testowane zabezpieczenia na oceniane zachowanie lub atak?
• Porównanie: Jak różne modele wypadają w równoważnych warunkach?

Raporty z ewaluacji muszą też wyjaśniać, jak oceniający sprawdzali wpływ czynników, które mogą oddziaływać na trafność wyniku. Należą do nich:

• Obchodzenie systemu nagród: Wykorzystywanie skrótów w zadaniu lub systemie punktacji, dzięki czemu system otrzymuje nagrodę bez wykazania zachowania, które ewaluacja miała mierzyć.
• Odmowy: Odmawianie w sposób, który zaciemnia testowane zachowanie.
• Kontaminacja: Zawyżone wyniki, ponieważ zadania ewaluacyjne, odpowiedzi lub ich bliskie warianty pojawiły się w danych treningowych albo były możliwe do odnalezienia podczas ewaluacji, na przykład przez przeglądanie.
• Uszkodzone problemy: Zaniżone wyniki, ponieważ zadania są nieprawidłowe. Przyczyny mogą obejmować niesprawiedliwą punktację (np. poprawna odpowiedź wymaga niepodanych szczegółów implementacyjnych) oraz nierozwiązywalne środowiska (np. brak krytycznych plików lub zawodne narzędzia).
• Sandbagging: Celowe zaniżanie wyników, gdy model wykazuje świadomość bycia ocenianym.

Zaobserwowaliśmy, że rola otoczenia operacyjnego jest szczególnie ważna dla systemów działających na dłuższych trajektoriach. Gdy modele mogą używać narzędzi, utrzymywać stan i wieloetapowo wychodzić z błędów, otoczenie operacyjne może zmieniać obserwowany poziom wydajności, a nawet decydować o tym, czy oceniana zdolność w ogóle ujawni się w ewaluacji. Na przykład otoczeni operacyjne, które zachowuje stan i ponawia nieudane działania, może pozwolić modelowi ukończyć wieloetapowe zadanie, którego ten sam model nigdy nie kończy w prostszym otoczeniu operacyjnym.

W poniższej tabeli rozdzielamy trzy rodzaje twierdzeń, które oceniający mogą chcieć formułować, oraz otoczenie operacyjne, którego naszym zdaniem wymaga każdy z nich.

Twierdzenia o zdolnościach są tak mocne, jak elicytacja, która za nimi stoi: oceniający muszą wybrać otoczenie operacyjne najlepiej dopasowane do zadania i zdolności, którą ewaluacja próbuje zmierzyć. Standaryzowane otoczenie operacyjne może być właściwe do porównywania systemów w identycznych warunkach, ale może zaniżać zdolność, gdy pomija konkretne cechy otoczenia operacyjnego pomagające modelowi wykonać zadanie. Na przykład wyniki GPT‑5.5 w zakresach cybernetycznych OpenAI pokazują, jak wybór otoczenia operacyjnego może istotnie zmienić mierzoną zdolność w zadaniach wymagających długiego, wieloetapowego użycia narzędzi: model radzi sobie lepiej, gdy otoczenie operacyjne używa kompaktowania⁠ do zachowania kontekstu istotnego dla zadania wraz z wydłużaniem interakcji. Pokazuje to, że dla niektórych modeli otoczenie operacyjne pomijające kompaktowanie zbyt słabo uzyskiwałoby wydajność.

Inne opublikowane ewaluacje² również pokazują, że wybory dotyczące otoczenia operacyjnego i budżetu zmieniają wyniki ewaluacji. Zwiększenie mocy obliczeniowej w czasie testu może znacząco zmienić to, jaką zdolność wydobywa ewaluacja, zwłaszcza w dziedzinach, gdzie sukces łatwo zweryfikować, takich jak wiele zadań cybernetycznych. W ewaluacji zakresu cybernetycznego UK AISI⁠(otwiera nowe okno) zwiększenie budżetu z 10 mln do 100 mln tokenów poprawiło wyniki nawet o 59%, a wydajność nadal rosła przy najwyższym testowanym budżecie. Opisanie tego zwiększa interpretowalność ewaluacji: pokazuje czytelnikom, jak wynik zależy od testowanej konfiguracji elicytacji. Gdy wydajność nadal poprawia się wraz z dodatkowym budżetem, wynik należy opisywać jako wydajność przy danym otoczeniu operacyjnym i budżecie, a nie jako zmierzony pułap zdolności. Zdolność często zależy od zasobów, a nie jest stałą wielkością, którą można raz na zawsze czysto zmierzyć. Tam, gdzie sukces można mierzyć w powtarzanych próbach, raporty powinny uwzględniać także oczekiwany koszt jednego skutecznego rozwiązania, a nie tylko wskaźnik sukcesu przy stałym budżecie tokenów. Może to ułatwić interpretację wagi zagrożenia: niski wskaźnik sukcesu może nadal mieć praktyczne znaczenie, jeśli koszt powtarzanych prób mieści się w odpowiednim modelu zagrożenia. W przypadku twierdzeń o zdolnościach możliwe do uniknięcia zbyt słabe wydobycie zdolności jest błędem pomiaru: jeśli otoczenie operacyjne lub budżet uniemożliwia systemowi ujawnienie zachowania, które mógłby inaczej przejawiać, wynik nie mierzy deklarowanej zdolności. Tam, gdzie oceniający doprowadzili elicytację tak daleko, jak to wykonalne, a wydajność nadal rośnie, raporty powinny jasno to zaznaczać i wyraźnie wskazywać, że wynik jest jedynie oszacowaniem dolnej granicy.

Testowanie zabezpieczeń może zaniżać ocenę tego, czy atak może się powieść i jak poważne mogą być jego skutki, jeśli nie uwzględnia zasobów dostępnych atakującym, w tym niestandardowych otoczeń operacyjnych. W cyberewaluacji GPT‑5.5 prowadzonej przez UK AISI⁠(otwiera nowe okno) ich ekspercki zespół ds. ataków kontrolowanych wykrył uniwersalny jailbreak, który wywoływał naruszające zasady treści cybernetyczne we wszystkich złośliwych zapytaniach dostarczonych przez OpenAI, także w wieloturowych ustawieniach agentowych. Użyli Codex do stworzenia niestandardowego otoczenia operacyjnego wzmacniającego skuteczność ataku modelu: osadzał on w interakcji wielokrotnego użytku wzorzec omijania zabezpieczeń, zachowywał ten wzorzec między turami i blokami oraz stosował go do złośliwych zapytań cybernetycznych dostarczonych przez OpenAI. Testowanie zabezpieczeń powinno być dopasowane do przeciwnika. Jeśli twierdzenie dotyczy odporności na nadużycie przez ekspertów, test powinien oceniać najsilniejszą wiarygodną strategię ataku end-to-end przy określonym budżecie, w tym każde otoczenie operacyjne potrzebne do zachowania i ponownego użycia tej strategii. W przeciwnym razie wyniki grożą błędną kalibracją: mogą wspierać jedynie węższe twierdzenie o odporności na prostsze polecenia, mogą nie uchwycić zarówno skali ataku, jak i prawdopodobieństwa jego powodzenia po operacjonalizacji metody elicytacji, a także mogą zawyżać prawdopodobieństwo lub wagę problemu, jeśli przyzna się zbyt duży budżet.

Istnieje właściwy czas i miejsce na porównania z użyciem standaryzowanych otoczeń operacyjnych, ale oceniający powinni jasno wskazywać, dlaczego użycie spójnego zestawu otoczeń operacyjnych jest właściwe i jakie twierdzenie może wspierać. Ewaluacja horyzontu czasowego METR⁠(otwiera nowe okno) jest przykładem szerszej, odpowiednio ustalonej konfiguracji ewaluacji: została zaprojektowana tak, by dawać porównywalne wyniki między ocenianymi systemami. METR definiuje wspólny wynik: typowy czas trwania zadania wykonywanego przez człowieka, przy którym przewiduje się, że agent AI osiągnie sukces przy danym poziomie niezawodności. Stosuje wspólny zestaw zadań, metodę punktacji, metodę dopasowania oraz niewielki zestaw wielokrotnego użytku bibliotek, takich jak Triframe i ReAct⁠(otwiera nowe okno), w ramach każdej partii wspólnie raportowanych oszacowań. Gdy METR rozszerzył zestaw zadań i przeniósł infrastrukturę ewaluacyjną ze środowiska Vivaria do Inspect, zaraportował tę zmianę (aktualizacja Time Horizon 1.1⁠(otwiera nowe okno)) i ponownie ocenił modele w nowej konfiguracji ewaluacji. Na tym polega wartość standaryzowanej konfiguracji ewaluacji, w tym spójnego zestawu otoczeń operacyjnych: może ona dać czytelnikom pewność, że różnica w wynikach rzeczywiście odzwierciedla różnicę między porównywanymi systemami, a nie zmianę konfiguracji pomiaru.

Zalecamy, aby raporty z ewaluacji prowadzonych przez strony trzecie określały, jaki rodzaj twierdzenia ma wspierać dana konfiguracja ewaluacji; opisywały, jak ściśle testowany aspekt odzwierciedla to szersze twierdzenie; przedstawiały wybory dotyczące otoczenia operacyjnego, które ukształtowało wynik; wskazywały, kiedy wybory te zmieniają się między ewaluacjami; oraz zawierały dowody pomocnicze pokazujące, jak wynik został uzyskany i jak dobrze uogólnia się na dane twierdzenie.

Wraz ze wzrostem możliwości modeli wyniki ewaluacji coraz łatwiej błędnie interpretować. Względem rzeczywistych zdolności wyniki ewaluacji mogą być sztucznie zaniżone, jeśli model rozpoznaje, że jest oceniany, i strategicznie obniża swoje wyniki. Mogą być zawyżone, jeśli model wykorzystuje skrót w zadaniu, poleceniu, systemie punktacji lub otoczeniu operacyjnym. Mogą też być zniekształcone przez kontaminację (gdy model już zna odpowiedź lub może ją znaleźć bez rozwiązania zadania) albo przez „uszkodzone” problemy, które są niejednoznaczne, błędnie oceniane, nierozwiązywalne lub podatne na niezamierzone skróty. Raporty z ewaluacji powinny więc łączyć główne wyniki z omówieniem tych zagrożeń, aby czytelnicy mogli ocenić, czy wyniki odzwierciedlają zamierzone zachowanie.

Otoczenia operacyjne, budżety, narzędzia, zasady punktacji, działania monitorujące i procedury przeglądu wpływają na to, czy agent rozwiązuje zamierzone zadanie, unika go, zapamiętuje je czy znajduje drogę na skróty. Wiarygodny raport uwidacznia te kontrole: oceniający powinni przeglądać próbki pod kątem tych zachowań za każdym razem, gdy przeprowadzana jest ocena.

Obchodzenie systemu nagród

Obchodzenie systemu nagród oznacza osiąganie wysokich wyników ewaluacji w sposób, który nie odzwierciedla zamierzonej zdolności. Chodzi tu o obawę, że system otrzymuje uznanie dzięki wykorzystaniu zadania, systemu punktacji, polecenia lub otoczenia operacyjnego, zamiast przez wykonanie pracy, którą ewaluacja miała mierzyć. Ewaluacja GPT 5.4 przeprowadzona przez METR⁠(otwiera nowe okno) pokazuje, dlaczego to ważne: mimo że model osiągał sukces w zadaniach z częstością, która przy pierwszym podejściu odpowiadałaby horyzontowi czasowemu około 13 godzin, przegląd wykonany przez ludzi wykazał, że część tych sukcesów wynikała z obchodzenia systemu nagród, a korekta wyników tak, by uwzględniały tylko przypadki bez obchodzenia systemu nagród, obniżyła oszacowanie do około 6 godzin. Weryfikatorzy powinni oceniać potrzebę takich korekt, a gdy są one niezbędne, jasno je raportować: oszacowanie zdolności jest znacznie bardziej użyteczne, gdy czytelnicy widzą, które pozorne sukcesy zostały zdyskwalifikowane, dlaczego je zdyskwalifikowano i w jakim stopniu wynik zależy od tego osądu.

Odmowy

Modele mogą też osiągać zaniżone wyniki w ewaluacjach zdolności z powodu zabezpieczeń. Model może osiągać niższe wyniki ewaluacji, niż pozwalają jego możliwości, ponieważ odmawia wykonania zadań ewaluacyjnych zamiast je realizować. Raporty powinny więc wyjaśniać, czy odmowy były częścią wyników ewaluacji, a jeśli tak, to ile próbek zostało przez nie zaburzonych.

Kontaminacja

Kontaminacja ma największe znaczenie w przypadku publicznych lub ponownie używanych benchmarków⁠. Jeśli zadania, odpowiedzi lub ich bliskie warianty pojawiają się w danych treningowych albo mogą zostać znalezione przez agenta z dostępem do funkcji przeglądania, wyniki mogą odzwierciedlać zapamiętanie lub wyszukiwanie, a nie rzeczywistą wydajność modelu. Oceniający powinni (o ile to możliwe) preferować zadania prywatne lub zupełnie nowe oraz sprawdzać, czy modele odtwarzają szczegóły specyficzne dla zadania przed jego rozwiązaniem.

Uszkodzone problemy

Uszkodzone problemy obejmują sytuacje takie jak problem, którego przypadkowo nie da się rozwiązać. Uszkodzone problemy są na tyle powszechne⁠(otwiera nowe okno), że można traktować je jako standardowe ryzyko dla trafności. Obejmują one nieprawidłowy źródło prawdy, niejednoznaczne polecenia, brakujące pliki, niestabilne usługi, niesprawiedliwe kryteria punktacji oraz środowiska ujawniające skróty, takie jak ukryte pliki z odpowiedziami lub historia repozytorium zawierająca poprawkę źródła prawdy.

Sandbagging

Sandbagging ze strony modelu lub systemu oznacza strategiczne zaniżanie wyników, gdy wysoka skuteczność byłaby sprzeczna z jakimś celem. Ewaluacja GPT‑5.5 przeprowadzona przez Apollo⁠(otwiera nowe okno) testowała ten aspekt, tworząc kontekst, w którym model rozumiał, że wysokie wyniki ewaluacji mogą uruchomić oduczanie lub zablokować wdrożenie. GPT‑5.5 nadal odpowiadał poprawnie, co sugeruje niewiele behawioralnych dowodów strategicznego zaniżania wyników³. Jednak przegląd śladów rozumowania dodał ważny kontekst: Apollo znalazł umiarkowane lub silniejsze oznaki świadomości ewaluacji zgodności w 52% próbek w warunku sandbaggingu, wobec 0% w kontrfaktycznych odpowiednikach. Dowód ten komplikuje interpretację wyniku, ale ostatecznie daje czytelnikom więcej sygnałów: mogą zobaczyć zarówno uspokajający wynik behawioralny, jak i powód do ostrożności przed jego nadinterpretacją.

Mocne twierdzenia wymagają zarówno właściwego otoczenia operacyjnego do wydobycia zachowania, jak i kontroli trafności pokazujących, że wynik jest rzetelny. Nasze przekonanie, że otoczenia operacyjne i kontrole trafności są częścią wyniku ewaluacji, kształtuje to, jak w praktyce wspieramy ewaluacje prowadzone przez strony trzecie: 

• Oceniającym udostępniamy konkretne wskazówki dotyczące maksymalnej elicytacji.
• Prosimy oceniających zdolności, aby używali Codex jako wspólnego minimum dla modeli OpenAI: testy powinny co najmniej uruchamiać poziom bazowy przez ten sam interfejs agentowy, na którym użytkownicy prawdopodobnie będą polegać, a nie wyłącznie przez okrojony interfejs modelu.
• Udostępniamy też ślady rozumowania i inne artefakty pośrednie tam, gdzie są potrzebne do oceny oszustwa, sandbaggingu lub świadomości ewaluacji. METR i Apollo korzystają z tego dostępu w ewaluacjach OpenAI od czasu GPT‑5. 
• Priorytetowo traktujemy też badania, które pomagają głębiej zrozumieć, kiedy i jak wybory dotyczące otoczenia operacyjnego istotnie zmieniają wyniki – od zarządzania kontekstem i dostępem do narzędzi po zachowanie ponowień, punktację i budżety zasobów.

Te zalecenia mają nie tylko poprawić pojedyncze raporty z ewaluacji, lecz także pomóc kształtować powstające krajowe ⁠(otwiera nowe okno)i międzynarodowe ⁠(otwiera nowe okno)standardy ewaluacji i raportowania pionierskich systemów AI. W przyszłości standardy ewaluacji prowadzone przez firmy zewnętrzne powinny wymagać wystarczającej szczegółowości, aby decydenci rozumieli, jakie twierdzenia wspierają konkretne ewaluacje, jaki system testowano, jak wydobyto wynik i jak oceniający sprawdzili jego trafność. W przypadku systemów pionierskich testowanych na zadaniach, w których znaczenie mają zdolności agentowe, szczegóły powinny obejmować (z zastrzeżeniem kwestii bezpieczeństwa lub poufności):

• Twierdzenie: czy ewaluacja porównuje systemy, szacuje pułap zdolności czy testuje zabezpieczenia.
• Treść ewaluacji: odpowiednia ilość informacji o zadaniach lub rozkładzie zadań, aby czytelnicy rozumieli, jakie umiejętności, zachowania lub tryby awarii ewaluacja faktycznie testuje.
• Testowany system: model, ustawienie rozumowania, dostęp do narzędzi, otoczenie operacyjne i zabezpieczenia.
• Budżet: tury, tokeny, próby/ponowienia, czas zegarowy, koszt inferencji oraz, tam gdzie ma to zastosowanie, oczekiwany koszt jednego skutecznego rozwiązania.
• Metody elicytacji: wybory dotyczące otoczenia operacyjnego użyte do wydobycia wyniku oraz jak ściśle testowany aspekt odzwierciedla szersze formułowane twierdzenie.
• Kontrole trafności: jak oceniający szukali sposobów obchodzenia systemu nagród, świadomości ewaluacji, kontaminacji, odmów, sandbaggingu i innych zachowań, które mogłyby podważyć wynik, oraz jak potwierdzone przypadki wpłynęły na punktację lub interpretację.

Standardy pomijające wybory dotyczące otoczenia operacyjnego lub kontrole trafności mogą zaniżać możliwości systemu albo zawyżać pewność co do twierdzenia o bezpieczeństwie. Budowanie silnych otoczeń operacyjnych i metod elicytacji pozostaje otwartym obszarem badawczym i powinno być przedmiotem dalszych badań oraz inwestycji.