Benchmark CyberGym wyjaśniony: co tak naprawdę mierzy wynik E2E

Najszerzej krążący wynik CyberGym — liczba z posta inauguracyjnego, ta, którą porównuje się między modelami — to odsetek sukcesów w 131 przefiltrowanych zadaniach, gdzie sukces oznacza, że agent wygenerował wejście proof-of-concept powodujące awarię niezałatanej kompilacji C/C++, napisał łatkę, która tę awarię zatrzymuje, i nie zepsuł testów napisanych przez deweloperów projektu. W kompilacji BenchLM MiMo-V2.6-Flash prowadzi z 95,1%, a MiMo-V2.6-Pro z 94,0%, podczas gdy DeepSeek-V4.1-Flash jest kilka punktów z tyłu w wysokich osiemdziesiątych. Prawie nikt, kto cytuje tę tabelę, nie wspomina o trzech rzeczach, które decydują, czy liczby są porównywalne: benchmark istnieje w więcej niż jednej implementacji, większość wierszy to własne raporty dostawców, a nie niezależne przebiegi, a ten jeden najciekawszy etap jest rejestrowany, ale nie jest liczony. To ten sam standard przypisywania źródeł, który archiwum incydentów AI stosuje do własnych wpisów — twierdzenie bez źródła nie jest wynikiem — a korpus CyberGym go nie spełnia częściej, niż sugeruje jego reputacja.

To przewodnik po tym, czego benchmark wymaga od agenta, jak zbudowano zestaw zadań, gdzie implementacje się różnią oraz co obrońca powinien, a czego nie powinien wnioskować z wysokiego wyniku.

Zadanie: znaleźć, odtworzyć, załatać — nie psując przy tym niczego.

CyberGym pochodzi z Berkeley Center for Responsible, Decentralized Intelligence, a jego założenie jest celowo wąskie. Każde zadanie dotyczy luki w bezpieczeństwie pamięci w szeroko używanym projekcie open-source w C/C++. Agent musi zlokalizować błąd, napisać dane wejściowe proof-of-concept, które wywołują crash sanitizera, a następnie załatać kod tak, aby crash nie powtarzał się — podczas gdy własne testy projektu nadal przechodzą. Ta sekwencja jest sednem. Benchmark, który pytałby tylko „znajdź błąd”, nagradzałby rozpoznawanie wzorców; wymaganie działającego wejścia powodującego crash i niepsującej łatki zmusza agenta do zamknięcia pętli od podejrzenia do wykazanego defektu do poprawki.

RDI hostuje ten benchmark w ramach szerszego obserwatorium, które śledzi zdolności cybernetyczne AI na etapach ataku i obrony, a sama rama jest warta uwagi: CyberGym to jedno narzędzie na stanowisku, obok ExploitGym i wariantu end-to-end. Odczytując go jako samodzielny ranking, traci się ten kontekst, co jest jednym z powodów, dla których te liczby słabo się przenoszą.

Cztery etapy, z których trzy są punktowane

Zasada punktacji jest najrzadziej opisywaną częścią benchmarku, ponieważ to właśnie tam wiarygodnie brzmiący wynik może odbiegać od tego, co faktycznie się wydarzyło.

Etap 1 to reprodukcja: czy wejście proof-of-concept agenta powoduje awarię niezałatanej kompilacji. Etap 2 to poprawka: czy przesłana zmiana powstrzymuje tę konkretną awarię. Etap 3 to regresja: czy testy funkcjonalne napisane przez dewelopera nadal przechodzą. Te trzy elementy dają wynik.

Etap 4 pyta, czy poprawka usuwa rzeczywistą lukę stanowiącą punkt odniesienia, i jest rejestrowany jako diagnostyka, a nie wliczany do wyniku. Ta asymetria zasługuje na chwilę uwagi, ponieważ stanowi różnicę między „agent potrafi sprawić, że awaria zniknie” a „agent potrafi naprawić błąd”. Oba twierdzenia są użyteczne; nie są tym samym twierdzeniem. Agent, który tłumi awarię przez przechwycenie sygnału, rozszerzenie sprawdzenia granic poza zakres przepełnienia lub całkowite wyłączenie ścieżki kodu, zdobędzie punkty na etapach od 1 do 3 i obleje etap 4. Jeśli opis raportuje jedną liczbę bez informacji, czy etap 4 był brany pod uwagę, nie można stwierdzić, która z tych dwóch rzeczy została zmierzona — a diagnostyka istnieje właśnie po to, aby można było o to zapytać.

Jak wybrano 131 zadań — i jaki ma to wpływ na wynik

Źródłowy zbiór danych jest większy niż zbiór oceniany, a filtrowanie to pojedyncza największa dźwignia wpływająca na porównywalność. Zbiór danych RDI zawiera 920 podatności w 139 projektach open source, pochodzących z Google OSS-Fuzz. Wariant end-to-end używany przez zewnętrzne trackery zawęża go do 131 zadań, po jednym zadaniu na projekt, wybieranych według trudności, z wyłączeniem zadań z wyciekami oracle lub ograniczeniami zgodności z piaskownicą.

Bezpośrednio wynikają z tego trzy konsekwencje. Po pierwsze, jedno zadanie na projekt oznacza, że wynik jest zdominowany przez szerokość, a nie głębokość: agent, który jest przeciętny w wielu projektach, osiągnie lepszy wynik niż taki, który jest doskonały w trzech, co jest wyborem projektowym, którego można bronić, i innym pomiarem niż „ile podatności ten agent potrafi naprawić”. Po drugie, wykluczenie wycieków oracle usuwa zadania, w których odpowiedź można odkryć ze środowiska, a nie wywnioskować, więc pozostały zbiór jest trudniejszy w specyficzny sposób — usuwa skróty, a nie usuwa łatwych zadań. Po trzecie, budżet 90 minut na zadanie w piaskownicy zbudowanej z obrazu OSS-Fuzz danego projektu jest częścią definicji sukcesu, a nie szczegółem, ponieważ duża część rzeczywistej pracy nad podatnościami jest ograniczona dokładnie tego rodzaju ograniczeniem, a agenci, którzy polegają na nieograniczonej eksploracji, poniosą tu porażkę, odnosząc sukces gdzie indziej.

Każde porównanie, które pomija regułę wyboru zadania, porównuje dwa różne testy, które przypadkiem mają tę samą nazwę.

Dwie implementacje i dlaczego nie muszą się zgadzać

Tu właśnie tkwi większość zamieszania. CyberGym-E2E istnieje jako benchmark RDI oraz jako implementacja uruchamiana przez zewnętrznego ewaluatora, i nie ma gwarancji, że te dwa podejścia dadzą tę samą liczbę dla tego samego modelu. Dokumentacja samego ewaluatora mówi to wprost: jego implementacja korzysta z filtrowanego zestawu 131 zadań, po jednym na projekt, wybieranych według trudności, i uruchamia każde zadanie w odizolowanej piaskownicy zbudowanej z obrazu OSS-Fuzz danego projektu, przy użyciu własnego harnessu agentowego z budżetem 90 minut na zadanie.

To zdanie zawiera dwie zmienne, które decydują o wyniku. Uprząż to pętla, w której działa agent — sposób, w jaki obserwuje dane wyjściowe narzędzi, ile kroków może wykonać i jak podnosi się po nieudanej próbie. Silniejsza uprząż ze słabszym modelem może pobić układ odwrotny, a uprząż nie jest częścią wag modelu. Budżet wchodzi w interakcję z oboma. Dlatego wynik CyberGym należy zapisywać jako „ten model, w tej uprzęży, w tej implementacji”, a liczba podana bez implementacji to liczba bez mianownika.

Warto wspomnieć o efekcie drugiego rzędu: ponieważ harness wykonuje realną pracę, poprawa wyniku CyberGym między dwiema wersjami modelu może częściowo wynikać z ulepszenia harnessu, a dostawca, który raportuje wyniki własnego harnessu, raportuje zdolności systemu, a nie zdolności modelu. Jedno i drugie jest uzasadnione; utożsamianie ich — nie.

Uczciwe czytanie tabeli trackera

Tabela, na którą trafia większość ludzi, jest kompilacją wtórną i sama oznacza swoje pochodzenie — co jest przydatne, jeśli czyta się to oznaczenie. Z 29 wierszy 7 pochodzi od właściciela benchmarku lub z niezależnego przebiegu, 21 to samodzielne raporty dostawców, a jeden to raport wtórny. Kompilacja wprost stwierdza, że pokazuje tabelę wyłącznie poglądowo i nie tworzy na jej podstawie rankingu, oraz zaleca ostrożne jej czytanie, ponieważ większość wierszy to samodzielne raporty. Jej własna uwaga o nasyceniu to najprzydatniejsza linijka na stronie: pierwsza trójka jest rozrzucona na około 70 punktów, podczas gdy pierwsza dziesiątka mieści się w przedziale mniej więcej 10 punktów, więc tabela wciąż odróżnia modele — ale nie na szczycie zakresu, gdzie uporządkowanie jest słabe.

Samoopis dostawcy jest dowodem, który można przedstawić. Nie jest to niezależny pomiar, a ta różnica ma znaczenie w tym benchmarku bardziej niż w większości, ponieważ zmienna harness daje dostawcy sporo swobody w dostrajaniu raportowanej liczby. Gdy samoopis i niezależne uruchomienie są sprzeczne, wygrywa niezależne uruchomienie. Gdy istnieje tylko samoopis, uczciwa interpretacja brzmi: „niezweryfikowane, wiarygodne, brak porównywalnego punktu odniesienia”.

Ta sama ostrożność obowiązuje w drugą stronę w przypadku pułapki, którą ten benchmark zastawia na czytelników: model bez wiersza CyberGym nie uzyskał wyniku zero. Nie został zmierzony w tym środowisku testowym, co jest innym stwierdzeniem. Traktowanie nieobecności jako porażki sprawia, że tabela przestaje być pomiarem, a staje się rankingiem.

Co wysoki wynik oznacza, a czego nie oznacza dla obrońcy

Pytanie, które zespół bezpieczeństwa faktycznie ma, nie brzmi „który model zajmuje pierwsze miejsce w tabeli”, lecz „co agent, który dobrze wypada w tym teście, robi z moim ryzykiem”. Benchmark odpowiada na węższe pytanie niż to, które zostało zadane, a tę lukę warto nazwać.

To oznacza, że agent potrafi w ciągu 90 minut i w obrębie znanego builda zlokalizować błąd bezpieczeństwa pamięci w prawdziwym kodzie open-source, wygenerować działające wejście powodujące awarię oraz napisać zmianę, która zatrzymuje awarię bez psucia testów. To autentyczna umiejętność, bezpośrednio istotna dla pracy nad triage'em i patchami, i jest to rodzaj zadania, w którym kompetentny agent w znaczący sposób skraca kolejkę analityka.

Nie oznacza to, że agent rozumie twoją bazę kodu, twój model zagrożeń ani twoje wdrożenie. Zadania pochodzą z publicznych targetów OSS-Fuzz ze znaną podatnością referencyjną i zestawem testów, który informuje agenta, czy zadanie zostało ukończone. Kod produkcyjny nie ma takiej wyroczni. Nie oznacza to również, że agent znajdzie ten błąd, a nie jakiś błąd: etap 4 istnieje, ponieważ te przypadki się różnią, a etap 4 się nie liczy.

I nie przekłada się to na stronę ofensywną, gdzie ta sama zdolność jest postrzegana inaczej. Agent, który potrafi zlokalizować i odtworzyć lukę w bezpieczeństwie pamięci, może to zrobić w kodzie, którego nie miał pozwolenia testować, dlatego zdolność tego rzędu jest dokładnie tym, co uzasadnia kontrolę dostępu na poziomie modelu, a nie zastrzeżenie w prompcie systemowym.

O co zapytać, zanim zaufasz liczbie CyberGym

Pięć pytań, na które można odpowiedzieć na podstawie dobrze napisanego raportu, a na które zwykle nie można odpowiedzieć na podstawie wpisu o premierze.

• Która implementacja? Test porównawczy RDI czy filtrowany wariant zewnętrznego oceniającego. Jeśli raport tego nie podaje, liczby nie można z niczym porównać.

• Czyj to test?Niezależna ocena czy raport dostawcy. Tabela zestawienia oznacza to w każdym wierszu; większość materiałów marketingowych tego nie robi.

• Jaki zestaw testowy i jaki budżet? Jeśli zestaw testowy jest własnością dostawcy i nie został opisany, traktuj wynik jako twierdzenie na poziomie systemu o konkretnej konfiguracji produktu.

• Czy skonsultowano etap 4? Raportowany wskaźnik wraz z towarzyszącą mu diagnostyką mówi, czy poprawki naprawiły błąd, czy jedynie wyciszyły awarię.

• Który zestaw zadań? 131 zadań, po jednym na projekt, wybranych według trudności, to standardowy zestaw; inny filtr to inny test.

Cybergym to dobrze skonstruowany benchmark trudnego, rzeczywistego zadania, a jego konstrukcja jest ciekawsza niż jego ranking. Etapy mówią, co agent musiał zrobić; filtrowanie mówi, czego dotyczy wynik; harness mówi, komu należą się zasługi. Liczba, której towarzyszą te trzy elementy, jest naprawdę użyteczna. Liczba, która przychodzi sama, to komunikat prasowy ze znakiem procentu.