Oddzielanie sygnału od szumu w ewaluacjach kodowania

Dokładny pomiar możliwości naszych modeli jest ważny dla trafnych decyzji dotyczących wdrażania i bezpieczeństwa, w tym decyzji podejmowanych w ramach Ram gotowości⁠(otwiera nowe okno) OpenAI. Przy każdej premierze modelu raportujemy wyniki dla różnych zewnętrznych i wewnętrznych benchmarków, aby śledzić postępy modeli. Gdy ewaluacje mają wady wpływające na wyniki, mogą dawać fałszywy obraz możliwości, zniekształcając argumenty dotyczące bezpieczeństwa i wpływając na priorytety badawcze.

Niedawno zbadaliśmy, w jaki sposób jeden z najczęściej używanych benchmarków kodowania, SWE-bench Verified, miał fundamentalne problemy projektowe i problemy z kontaminacją, i ustaliliśmy, że ewaluacja nie dostarcza już znaczącego sygnału o możliwościach w zakresie tworzenia oprogramowania. Wtedy zachęcaliśmy szerszą społeczność do przejścia na SWE-Bench Pro.

SWE-Bench Pro⁠(otwiera nowe okno) zaprojektowano jako ulepszenie SWE-bench Verified: testuje on modele przez dłuższy czas i w bardziej realistycznych zadaniach programistycznych, aby lepiej śledzić możliwości kodowania agentowego. Podobnie jak w SWE-bench Verified zadania są pozyskiwane programowo z historii zmian funkcji w zestawie publicznych i prywatnych repozytoriów. Modele muszą zaimplementować rozwiązanie, które przechodzi nowe testy dla danej funkcji, nie psując istniejącej funkcjonalności. W publicznym podzbiorze obejmującym 731 zadań pionierskie modele poprawiły współczynnik zaliczeń z 23,3% do 80,3% w ciągu ośmiu miesięcy.

Od tego czasu przeprowadziliśmy podobny audyt SWE-Bench Pro, przeglądając zbiór danych za pomocą procesu analizy punktów danych. Proces analizował próby wykonania zadania przez model, metadane zadań oraz ślady awarii, aby oznaczyć prawdopodobne wady ewaluacji. Każde oznaczone zadanie oceniano następnie w ramach wielu przebiegów z agentami-śledczymi i niezależnie recenzowało je pięciu doświadczonych inżynierów oprogramowania, a sporne przypadki przekazywano do dalszego zbadania.

Występowały głównie cztery kategorie problemów:

• Zbyt rygorystyczne testy¹ wymuszają konkretne szczegóły implementacji niewskazane w poleceniu, unieważniając wiele funkcjonalnie poprawnych zgłoszeń.
• Niedookreślone polecenia² pomijają wymagania egzekwowane przez ukryte testy, których nie da się rozsądnie wywnioskować.
• Testy o niskim pokryciu niedostatecznie sprawdzają żądaną funkcję, więc niekompletne poprawki mogą zostać zatwierdzone.
• Mylące polecenie kieruje modele ku niewłaściwemu zachowaniu albo przeczy temu, czego wymagają testy.

Nasze ustalenia wskazują, jak trudno jest tworzyć trudne, ale sprawiedliwe benchmarki, oraz pokazują rosnącą użyteczność agentów w skalowalnych kontrolach jakości danych. W świetle tych wyników szacujemy, że około 30% zadań SWE-bench Pro jest wadliwych, i zalecamy twórcom modeli uważną analizę wyników.

Naszym celem jest dopilnowanie, aby porażki w zadaniach odzwierciedlały rzeczywiste ograniczenia modelu, a sukcesy – kompletne i poprawne rozwiązania wymagań wynikających z polecenia. Aby sprawdzić jakość danych użytych w ewaluacji, stworzyliśmy proces zapewniania jakości, który ocenia, czy każdy punkt danych dokładnie odzwierciedla możliwości modelu.

Wstępny automatyczny filtr analizuje instrukcje przekazane modelowi, próby rozwiązania zadania przez model oraz testy użyte do oceny tych prób, aby oznaczyć prawdopodobnie wadliwe lub problematyczne przykłady. Ten filtr oznaczył 286 potencjalnie wadliwych zadań. Następnie przeprowadziliśmy głębszy przegląd tego podzbioru na dwa sposoby: przegląd agentowy nadzorowany przez człowieka, który wykonuje szerokie kontrole z użyciem agentów-śledczych i końcowej oceny realizowanej przez człowieka, oraz kampanię adnotacji ludzkich prowadzoną z doświadczonymi programistami.

Każdy oznaczony problem jest audytowany przez agentów-śledczych opartych na Codex, którym zapewniono dostęp do repozytorium zadania i środowiska. Pomaga im to odróżnić rozsądną niejednoznaczność zadania, którą często da się rozwiązać przez analizę pobliskiego kodu i konwencji repozytorium, od rzeczywistego niedookreślenia. Agent może uruchamiać testy, przeglądać pliki w repozytorium oraz badać próby modelu i ich typowe tryby awarii w danym zadaniu. Po kilku niezależnych powtórzeniach tych głębszych audytów badacz przejrzał podsumowania, wydał ostateczną ocenę i oznaczył prawdopodobne problemy.

Równolegle przeprowadziliśmy kampanię wprowadzania adnotacji dodawanych przez programistów w oznaczonym podzbiorze. Współpracowaliśmy z doświadczonymi inżynierami oprogramowania, którzy przed przeglądem zadań zostali przeszkoleni w zakresie celów benchmarku, taksonomii problemów i przypadków granicznych. Każde zadanie zostało przejrzane przez pięciu inżynierów.

Recenzenci formułowali niezależną ocenę na podstawie widocznego opisu problemu, przypadków testowych oraz referencyjnego rozwiązania podstawowego (nazywanego „gold patch”), zanim użyli analizy procesu lub transkryptu jako kontekstu pomocniczego. Następnie recenzenci przypisywali etykietę i ocenę dotkliwości na podstawie konkretnych dowodów, a spory lub przypadki o niskiej pewności eskalowali do dalszej weryfikacji.

Recenzenci częściej niż agenci-śledczy oznaczali zadania jako wadliwe. Między obiema ścieżkami przeglądu występowały też pewne rozbieżności co do kategorii, ale w żadnym oznaczonym zadaniu najczęstszą etykietą dodaną przez człowieka nie było „niewadliwe”. Wśród kategorii oznaczonych przez proces agentowy oceny recenzentów pokrywały się w 74% przypadków.

W porównaniu z procesem agentowym recenzenci częściej wybierali też wiele etykiet dla jednego zadania, co wskazuje, że uznawali zadania za wadliwe na kilka sposobów albo niemieszczące się jednoznacznie w jednej kategorii. Sugeruje to, że proces łączący agenty i recenzentów prowadził do konserwatywnego etykietowania: obejmował te same szerokie tryby awarii, które wskazali ludzie, ale zaniżał liczbę przypadków, w których recenzenci zauważali dodatkowe lub nakładające się problemy. Największa różnica dotyczyła testów o niskim pokryciu, które recenzenci wybierali jako najczęstszy problem dla 9,4% benchmarku, w porównaniu z 4,1% w procesie agentowym.

Zidentyfikowane przez nas problemy, wraz z podobnymi przypadkami w SWE-bench Verified, podkreślają znaczenie rygorystycznego sprawdzania benchmarków. Zgłoszenia i pull requesty z repozytoriów open source były pierwotnie tworzone z myślą o współpracy między ludźmi, często bazującej na długiej wymianie informacji między opiekunami projektu a kontrybutorami. W rezultacie opisy problemów, scalony kod i testy jednostkowe nie zawsze układają się w czyste, odizolowane zadania pozwalające wiarygodnie oceniać modele. W szczególności testy dołączone do pull requestów mogą być zbyt rygorystyczne, ponieważ pisze się je, by zweryfikować konkretną zmianę, a nie zdefiniować niezależny od implementacji standard rozwiązania zadania.

Jednocześnie wady ewaluacji są dziś łatwiejsze do wykrycia, niż byłyby jeszcze niedawno. Wraz ze wzrostem możliwości modeli możemy używać tych modeli do znacznie głębszej i bardziej spójnej analizy poleceń, testów, poprawek, śladów i przypadków granicznych, co pomaga ujawniać problemy benchmarków, których znalezienie na dużą skalę było wcześniej kosztowne lub niepraktyczne.

Mamy nadzieję, że społeczność zajmująca się weryfikacjami opracuje nowe benchmarki, przy współpracy z doświadczonymi programistami, które pozwolą na testowanie możliwości modeli. Takie podejście może zachować wysoki próg jakości i realizm, których potrzebujemy do mierzenia możliwości modeli, a także zapewnia lepszy nadzór ludzki w całym procesie. W związku z problemami ujawnionymi w tej analizie wycofujemy naszą wcześniejszą rekomendację przyjęcia SWE-Bench Pro.

Ostatecznie ewaluacja powinna dostarczać znaczącego sygnału dzięki benchmarkom, które trudno obejść, którym łatwo zaufać i które rzeczywiście odzwierciedlają możliwości lub dostosowane modelu. Ponieważ te wyniki wpływają na decyzje OpenAI dotyczące wdrażania i bezpieczeństwa, śledzone przez nas ewaluacje muszą być trafne i informatywne.