Dlaczego SWE-bench Verified nie mierzy już pionierskich możliwości kodowania

Od momentu pierwszej publikacji zestawu SWE-bench Verified w sierpniu 2024 r. organizacje z branży na szeroką skalę wykorzystują go do pomiaru postępów modeli w zakresie zadań związanych z autonomiczną inżynierią oprogramowania. Po wprowadzeniu zestaw SWE-bench Verified dawał wyraźny sygnał postępu w zakresie możliwości i stał się standardowym wskaźnikiem stosowanym w wydaniach kolejnych wersji pionierskich modeli. Śledzenie i prognozowanie postępów w zakresie tych możliwości stanowi również ważną część ram gotowości OpenAI. Gdy tworzyliśmy test porównawczy Verified, staraliśmy się rozwiązać problemy występujące w pierwotnej ocenie, które uniemożliwiały wykonanie niektórych zadań w zestawie danych SWE-bench⁠(otwiera nowe okno).

Po początkowych sukcesach tempo postępów w zakresie SWE-bench Verified uległo spowolnieniu, odnotowując poprawę⁠(otwiera nowe okno) z 74,9% do 80,9% w ciągu ostatnich 6 miesięcy. Nasuwa się więc pytanie: czy pozostałe niepowodzenia odzwierciedlają ograniczenia modelu czy właściwości samego zbioru danych?

W nowej analizie znaleźliśmy dwie poważne kwestie związane z zestawem Verified, które wskazują, że test porównawczy nie jest już odpowiedni do pomiaru postępów w zakresie autonomicznych możliwości inżynierii oprogramowania dla pionierskich uruchomień na obecnym poziomie wydajności:

1. Testy odrzucają poprawne rozwiązania: sprawdziliśmy 27,6% podzbioru danych, których modele często nie były w stanie rozwiązać, i stwierdziliśmy, że co najmniej 59,4% sprawdzonych problemów zawiera wadliwe przypadki testowe, które odrzucają poprawne funkcjonalnie zgłoszenia pomimo naszych najlepszych starań, aby poprawić ten problem podczas tworzenia zestawu SWE-bench Verified.
2. Trenowanie na rozwiązaniach: ze względu na to, że duże pionierskie modele mogą uczyć się informacji na podstawie treningu, istotne jest, aby nigdy nie były trenowane na problemach i rozwiązaniach, na podstawie których są oceniane. To tak, jakby przed egzaminem pokazać uczniom pytania i odpowiedzi – może nie zapamiętają odpowiedzi, ale ci, którzy je widzieli, na pewno poradzą sobie lepiej niż ci, którzy nie mieli ku temu okazji. Problemy SWE-bench pochodzą z repozytoriów open source, z których wielu dostawców modeli korzysta do celów treningu. W naszej analizie stwierdziliśmy, że wszystkie testowane przez nas pionierskie modele były w stanie odtworzyć oryginalną, napisana przez człowieka poprawkę błędu, wykorzystaną jako punkt odniesienia, określaną jako złota poprawka, lub dosłowne opisy problemów dla niektórych zadań. Wskazuje to, że wszystkie one napotkały przynajmniej niektóre problemy i rozwiązania podczas treningu.

Odkryliśmy również, że modele, które napotkały problemy podczas szkolenia, mają większe szanse na sukces, ponieważ dysponują dodatkowymi informacjami potrzebnymi do pomyślnego ukończenia testów o niewystarczającej specyfikacji.

Oznacza to, że ulepszenia w zestawie SWE-bench Verified nie odzwierciedlają już znaczącej poprawy rzeczywistych możliwości modeli w zakresie tworzenia oprogramowania. Zamiast tego coraz częściej odzwierciedlają one stopień ekspozycji modelu na ten test porównawczy w czasie trenowania. Dlatego przestaliśmy publikować wyniki dla zestawu SWE-bench Verified i zalecamy, aby inni twórcy modeli również tak postąpili.

Tworzymy nowe, wolne od zanieczyszczeń oceny, aby lepiej śledzić możliwości kodowania i uważamy, że jest to ważny obszar, na którym powinna skupić się szersza społeczność badawcza. Dopóki nie będziemy dysponować takimi ocenami, OpenAI zaleca, żeby w międzyczasie używać SWE-bench Pro do raportowania wyników.

Pierwotna ocena zestawu SWE-bench⁠(otwiera nowe okno) została opublikowana w 2023 roku. Każdy problem pochodzi z rozwiązanej sprawy GitHub w jednym z 12 repozytoriów open source dla języka Python i jest powiązany z odpowiednim żądaniem pull request (PR). Aby ustalić, czy zmiana kodu wygenerowana przez model jest poprawna, każdy problem zawiera dwa zestawy testów:

• Testy, które kończą się niepowodzeniem w niezmodyfikowanym kodzie źródłowym, ale przebiegają pomyślnie, jeśli problem zostanie prawidłowo naprawiony
• Testy regresji, które kończą się pomyślnie zarówno przed wprowadzeniem poprawki, jak i po, aby zapewnić, że niepowiązane funkcje pozostają nienaruszone.

Model nie dostrzega testów. Musi generować zmianę kodu na podstawie wyłącznie oryginalnego tekstu zgłoszenia i stanu repozytorium przed wprowadzeniem poprawki. Problem jest uznawany za zaliczony tylko wtedy, gdy wszystkie testy zakończą się pomyślnie po zastosowaniu zmiany w kodzie.

W tej ocenie znaleźliśmy wiele problemów, które mogą prowadzić do zaniżania możliwości modeli.

• Niektóre testy jednostkowe były zbyt szczegółowe lub niezgodne z zadaniem, więc poprawne poprawki mogły zostać odrzucone.
• Wiele opisów zadań nie było wystarczająco szczegółowych, co mogło prowadzić do wielu różnych interpretacji, podczas gdy testy obejmowały tylko jedną konkretną.
• W zależności od konfiguracji środowiska (na przykład system Linux w porównaniu z systemem Windows lub wersja języka Python) niektóre testy mogą zakończyć się nieprawidłowym wynikiem.

W 2024 roku stworzyliśmy zestaw SWE-bench Verified, aby rozwiązać te problemy. We współpracy z doświadczonymi inżynierami oprogramowania przeanalizowaliśmy 1699 zadań SWE-bench i odfiltrowaliśmy zadania, które zawierały te problemy. Każdy problem został niezależnie przeanalizowany przez trzech ekspertów. W wyniku tego procesu przeglądu powstał zestaw SWE-bench Verified, czyli zestaw 500 wyselekcjonowanych problemów.

Chociaż SWE-bench Verified stanowi znaczne ulepszenie w stosunku do wersji początkowej, nadal istnieją pewne problemy. Przeprowadziliśmy audyt 138 problemów SWE-bench Verified, których model OpenAI o3 nie rozwiązał w spójny sposób w 64 niezależnych przebiegach. Każdy przypadek został niezależnie zweryfikowany przez co najmniej sześciu doświadczonych inżynierów oprogramowania. Jeśli ekspert zgłosił problem, był on ponownie weryfikowany przez dodatkowy zespół.

Stwierdziliśmy, że 59,4% ze 138 problemów zawierało istotne błędy w projekcie testu i/lub opisie problemu, co sprawiało, że były one niezwykle trudne lub niemożliwe do rozwiązania nawet dla najbardziej wydajnego modelu lub człowieka. 

• 35,5% sprawdzonych zadań ma ścisłe przypadki testowe, które wymuszają konkretne szczegóły implementacji, unieważniając wiele poprawnych funkcjonalnie zgłoszeń, które nazywamy wąskimi przypadkami testowymi.
• 18,8% sprawdzonych zadań zawiera testy, które sprawdzają dodatkowe funkcje, które nie były określone w opisie problemu, co nazywamy szerokimi przypadkami testowymi.
• Pozostałe 5,1% zadań miało różne problemy, których nie dało się dobrze pogrupować w tej taksonomii.

Przykładem pierwszego rodzaju błędu jest pylint-dev__pylint-4551⁠(otwiera nowe okno), gdzie żądania PR wprowadza nową funkcję „get_annotation” jako część ogólnego rozwiązania. Nazwa tej funkcji nie jest wymieniona w opisie problemu, ale jest importowana bezpośrednio przez testy. Chociaż niektóre modele mogą intuicyjnie sugerować stworzenie takiej funkcji, wdrażanie funkcji o tej konkretnej nazwie nie jest absolutnie konieczne, aby prawidłowo rozwiązać problem. Wiele poprawnych rozwiązań nie przechodzi pomyślnie testów dotyczących błędów importu.

Przykładem zbyt szerokich przypadków testowych jest sympy__sympy-18199⁠(otwiera nowe okno). Zadanie to pochodziło z żądania PR, które dotyczyło trzech odrębnych problemów związanych z funkcją „nthroot_mod”, a mianowicie nr 17373⁠(otwiera nowe okno), nr 17377⁠(otwiera nowe okno) i nr 18212⁠(otwiera nowe okno). Opis zadania SWE-bench Verified obejmuje jednak tylko końcowy problem, nr 18212⁠(otwiera nowe okno). Powoduje to rozbieżność: testy PR obejmują wszystkie trzy kwestie, podczas gdy opis dotyczy tylko jednej. W naszych testach modele często poprawnie wdrażają opisane poprawki, a następnie nie przechodzą pomyślnie testów obejmujących implementację pozostałych dwóch problemów.

SWE-bench Verified oraz repozytoria (bazy kodu i informacje o wydaniu) są zarówno dostępne na licencji open source, jak i powszechnie używane oraz omawiane, co utrudnia twórcom modeli unikanie zanieczyszczenia danych.

Po raz pierwszy napotkaliśmy oznaki zanieczyszczenia w naszych własnych modelach. Na przykład wtedy, gdy model GPT‑5.2 rozwiązał 31 zadań, które uznaliśmy za prawie niemożliwe do rozwiązania. W django__django-14725⁠(otwiera nowe okno) testy wymagają określonego nowego parametru „edit_only”, który nie jest wyraźnie wymagany w opisie problemu. Podczas rozwiązywania problemu GPT‑5.2 pokazuje w swoim łańcuchu rozumowania, że posiada informacje o uwagach dotyczących wydania, które szczegółowo opisują zmiany w kodzie źródłowym, i prawidłowo identyfikuje, że parametr „edit_only” został wprowadzony w Django 4.1.

Aby szerzej ocenić znaczenie zanieczyszczenia, stworzyliśmy zautomatyzowaną konfigurację kontrolowanego ataku. W przypadku każdego pytania SWE-bench Verified zadaliśmy GPT‑5 zadanie polegające na testowaniu modeli GPT‑5.2‑Chat, Claude Opus 4.5 i Gemini 3 Flash w wersji zapoznawczej pod kątem zanieczyszczenia. Modele te zostały wybrane w celu wykluczenia modeli rozumujących, ale zdajemy sobie sprawę, że prawdopodobnie istnieje między nimi istotna różnica w zakresie możliwości.

Aby sprawdzić zanieczyszczenie, GPT‑5 otrzymał: identyfikator zadania ze SWE-bench Verified, jego opis, złotą poprawkę oraz testy z PR. Przez 15 rund pozwolono modelowi GPT‑5 na zmianę polecenia systemowego/programisty, polecenia użytkownika, wstępnego wypełnienia asystenta oraz różnych strategii wywoływania. Po każdej rundzie model oceniający określał, ile pojawiło się nowych informacji związanych z zadaniem, a każda odpowiedź była oceniana pod kątem stopnia zanieczyszczenia od „brak” do „silne”. Model GPT‑5 mógł dostosowywać swoją strategię na podstawie poprzednich rund, aby iteracyjnie odzyskiwać szczegóły dotyczące konkretnych zadań. W przypadku każdego przykładu silnego zanieczyszczenia sprawdzaliśmy z innym recenzentem, czy model GPT‑5 nie ujawnił zbyt wielu informacji modelowi docelowemu. Na koniec ręcznie sprawdziliśmy przykłady uznane za „silne” przykłady, które stanowią transkrypcje zamieszczone w tym poście.

Poniżej przedstawiono przykłady silnego zanieczyszczenia u różnych dostawców modeli.

Na podstawie krótkiego fragmentu opisu zadania model GPT‑5.2 generuje złotą poprawkę. W szczególności zna dokładną nazwę klasy i metody oraz nowy warunek wczesnego zwracania „if username is None or password is None”, który został wprowadzony.

Identyfikator zadania: django__django-11451⁠(otwiera nowe okno)

Opus jest w stanie nie tylko przywołać dokładną 4-wierszową zmianę funkcjonalną wprowadzoną przez żądanie pull request, wraz z konkretną nazwą pliku i metodą, której dotyczyła, ale także cytuje dosłownie komentarz wbudowany, który był częścią różnicy w kodzie. 

Identyfikator zadania: astropy__astropy-13236⁠(otwiera nowe okno)

Gemini 3 Flash, nie otrzymując żadnych dodatkowych informacji dotyczących zadania poza identyfikatorem, jest w stanie wyświetlić dosłowne szczegóły z opisu zadania i złotej poprawki. Obejmuje to nową formułę wyrażenia regularnego do sprawdzania poprawności nazwy użytkownika oraz dokładne numery linii, w których wprowadzono zmiany.

Identyfikator zadania: django__django-11099⁠(otwiera nowe okno)

Z tego audytu SWE-bench Verified wyłaniają się dwa szersze wnioski dotyczące projektowania ocen. Po pierwsze, testy porównawcze oparte na materiałach publicznie dostępnych niosą ryzyko zanieczyszczenia, gdy ekspozycja na dane treningowe może niepostrzeżenie zawyżać wyniki. Jeśli do tworzenia testu porównawczego wykorzystuje się dane pobrane publicznie, twórcy modeli powinni przeprowadzić dodatkowe testy w kierunku zanieczyszczenia. Testy porównawcze, a nawet ich rozwiązania, udostępnione publicznie mogą trafić do danych treningowych. Należy zachować szczególną ostrożność zarówno w sposobie publikowania zestawów danych (tj. ochrona hasłem) oraz filtrowanie danych treningowych (tj. ścisłe stosowanie tzw. „ciągów kanarkowych”). 

Po drugie, prawidłowe zastosowanie automatycznego oceniania jest trudne – idealne przypadki testowe powinny w pełni weryfikować prawidłowe działanie, zarówno niezależnie od konkretnych, nieistotnych szczegółów implementacji, jak i odporne na skrótowe rozwiązania. Problemy te są z natury złożone i trudne do rozwiązania. Wykrycie tych problemów wymagało wielu szeroko zakrojonych kampanii oznaczania przez ludzi. 

Uwzględniliśmy te ustalenia w naszych ostatnich pracach związanych z oceną. W ostatnich miesiącach zdecydowaliśmy się raportować wyniki z publicznej części SWE-Bench Pro. Zalecamy, aby inni twórcy modeli postępowali tak samo. SWE-bench Pro nie jest idealny, ale z doświadczenia wynika, że rzadziej występują w nim problemy związane z zanieczyszczeniem. Nasz proces wykrywania zanieczyszczeń wykrył kilka przypadków, ale były one znacznie rzadsze i mniej poważne niż w zestawie SWE-Bench Verified, i żaden model nie był w stanie wygenerować kompletnej, dosłownej „złotej poprawki”.

Będziemy nadal inwestować w oryginalne, prywatnie opracowane testy porównawcze i prosić o wsparcie ze strony organizacji branżowych i środowisk akademickich, aby czyniły tak samo. W GDPVal⁠ zadania są tworzone prywatnie przez ekspertów z poszczególnych dziedzin, co zmniejsza ryzyko ekspozycji na dane, a rozwiązania są oceniane całościowo przez przeszkolonych recenzentów. Podejście to wymaga dużego nakładu zasobów, ale jest coraz bardziej niezbędne do pomiaru rzeczywistej poprawy zdolności.