Zašto SWE-bench Verified više ne mjeri granične sposobnosti kodiranja
SWE-bench Verified je sve više kontaminiran. Preporučujemo SWE-bench Pro.
Otkako smo prvi put objavili SWE-bench Potvrđeno u augustu 2024., industrija ga je široko koristila za mjerenje napretka modela na autonomnim zadacima softverskog inženjeringa. Nakon objave, SWE-bench Verified pružio je snažan signal napretka sposobnosti i postao standardna metrika koja se navodi u objavama graničnih modela. Praćenje i predviđanje napretka ovih sposobnosti također je važan dio OpenAI-jevog Okvira pripravnosti. Kada smo prvobitno kreirali Verified benchmark, pokušali smo riješiti probleme u originalnoj evaluaciji koji su određene zadatke činili nemogućim za izvršiti u SWE-bench dataset(otvara se u novom prozoru).
Nakon početnih skokova, najsavremeniji napredak na SWE-bench Potvrđeno usporio je, poboljšavajući(otvara se u novom prozoru) se sa 74,9% na 80,9% u posljednjih 6 mjeseci. Ovo postavlja pitanje: da li preostali neuspjesi odražavaju ograničenja modela ili svojstva samog skupa podataka?
U novoj analizi, pronašli smo dva velika problema sa skupom Verified koji ukazuju na to da mjerilo više nije prikladno za mjerenje napretka u autonomnim sposobnostima softverskog inženjeringa za granična lansiranja na današnjim nivoima performansi:
- Testovi odbacuju ispravna rješenja: Revidirali smo podskup od 27,6% skupa podataka koji modeli često nisu uspijevali riješiti i utvrdili da najmanje 59,4% revidiranih problema ima neispravne testne slučajeve koji odbacuju funkcionalno ispravne predaje, uprkos našim najboljim naporima da ovo poboljšamo u početnom kreiranju SWE-bench Verified.
- Obuka o rješenjima: Budući da veliki granični modeli mogu učiti informacije iz svoje obuke, važno je da se nikada ne treniraju na problemima i rješenjima na kojima se procjenjuju. Ovo je slično dijeljenju problema i rješenja za predstojeći test s učenicima prije testa - možda neće zapamtiti odgovor, ali učenici koji su ranije vidjeli odgovore sigurno će se bolje snaći od onih koji nisu. Problemi SWE-bench dolaze iz open-source repozitorija koje mnogi pružatelji modela koriste za obuku. U našoj analizi otkrili smo da su svi granični modeli koje smo testirali mogli reproducirati originalnu, ljudski napisanu ispravku greške korištenu kao referencu tačne vrijednosti, poznatu kao zlatna zakrpa, ili doslovne specifičnosti izjave o problemu za određene zadatke, što ukazuje na to da su svi oni tokom obuke vidjeli barem neke od problema i rješenja.
Također smo pronašli dokaze da su modeli koji su vidjeli probleme tokom obuke vjerovatnije uspješni, jer imaju dodatne informacije potrebne da prođu nedovoljno precizno definirane testove.
To znači da poboljšanja na SWE-bench Verified više ne odražavaju značajna poboljšanja u stvarnim sposobnostima modela za razvoj softvera. Umjesto toga, oni sve više odražavaju koliko je model bio izložen mjerilu tokom obuke. Zbog toga smo prestali prijavljivati SWE-bench Verified rezultate i preporučujemo da i drugi developeri modela učine isto.
Gradimo nove, nekontaminirane evaluacije kako bismo bolje pratili sposobnosti kodiranja, i smatramo da je ovo važno područje na koje se treba fokusirati za širu istraživačku zajednicu. Dok ih ne budemo imali, OpenAI preporučuje izvještavanje o rezultatima za SWE-bench Pro.
Originalna SWE-bench(otvara se u novom prozoru) evaluacija objavljena je 2023. godine. Svaki problem potiče iz riješenog GitHub problema u jednom od 12 Python repozitorija otvorenog koda i uparen je s odgovarajućim pull requestom (PR). Da biste utvrdili da li je promjena koda koju je generirao model ispravna, svaki problem dolazi s dva skupa testova:
- Testovi koji ne prolaze na neizmijenjenoj kodnoj bazi, ali prolaze ako je problem ispravno riješen
- Regresioni testovi koji prolaze i prije i nakon popravka kako bi se osiguralo da nepovezana funkcionalnost ostane netaknuta.
Model ne vidi testove. Mora proizvesti promjenu koda, uzimajući u obzir samo originalni tekst problema i stanje repozitorija prije ispravke. Problem prolazi samo ako svi testovi prođu nakon što se primijeni promjena koda.
Otkrili smo mnoge probleme s tom evaluacijom koji bi mogli dovesti do podcjenjivanja sposobnosti modela.
- Neki jedinični testovi su bili previše specifični ili neusklađeni sa zadatkom, pa su ispravne ispravke mogle biti odbijene.
- Mnoge izjave o zadacima bile su nedovoljno specificirane, što bi moglo dovesti do više valjanih tumačenja - dok su testovi pokrivali samo jedno specifično.
- Ovisno o postavci okruženja (na primjer Linux u odnosu na Windows ili verzija Pythona), neki testovi bi mogli lažno pasti
Kreirali smo SWE-bench Potvrđeno 2024. kako bismo riješili ove probleme. Saradili smo sa stručnim softverskim inženjerima kako bismo pregledali 1.699 SWE-bench problema i uklonili one koji su imali ove probleme. Svaki problem su nezavisno pregledala tri stručnjaka. Ovaj proces pregleda rezultirao je SWE-bench Potvrđeno, pažljivo odabranim skupom od 500 problema.
Iako je SWE-bench Verified veliko poboljšanje u odnosu na početnu verziju, preostali problemi i dalje postoje. Proveli smo reviziju 138 SWE-bench Potvrđeno problema koje OpenAI o3 nije dosljedno riješio tokom 64 nezavisna pokretanja. Svaki slučaj je nezavisno pregledalo najmanje šest iskusnih softverskih inženjera. Ako je stručnjak označio problem, dodatni tim ga je ponovo provjerio.
Utvrđeno je da je 59,4% od 138 problema sadržavalo materijalne nedostatke u dizajnu testa i/ili opisu problema, što ih je činilo izuzetno teškim ili nemogućim za rješavanje čak i za najsposobniji model ili čovjeka.
- 35,5% revidiranih zadataka ima stroge testne slučajeve koji nameću specifične detalje implementacije, čineći mnoge funkcionalno ispravne podneske nevažećim, što nazivamo uskim testnim slučajevima.
- 18,8% revidiranih zadataka ima testove koji provjeravaju dodatnu funkcionalnost koja nije bila navedena u opisu problema, što nazivamo širokim testnim slučajevima.
- Preostalih 5,1% zadataka imalo je razne probleme koji nisu bili dobro grupisani u ovoj taksonomiji.
Ilustrativan primjer prvog načina otkaza je pylint-dev__pylint-4551(otvara se u novom prozoru), gdje PR uvodi novu funkciju `get_annotation` kao dio ukupnog rješenja. Ovo ime funkcije nije spomenuto u opisu problema, ali ga testovi direktno uvoze. Iako neki modeli mogu intuitivno doći do toga da kreiraju takvu funkciju, nije strogo neophodno implementirati funkciju s ovim konkretnim nazivom da bi se problem ispravno riješio. Mnoga važeća rješenja ne prolaze testove zbog grešaka pri uvozu.
Opis problema
PR test isječak
Neuspjesi PR testova (skraćeno radi čitljivosti)
Primjer preširokih testnih slučajeva je sympy__sympy-18199(otvara se u novom prozoru). Ovaj zadatak je preuzet iz PR-a koji je rješavao tri različita problema s funkcijom `nthroot_mod`, konkretno #17373(otvara se u novom prozoru), #17377(otvara se u novom prozoru) i #18212(otvara se u novom prozoru). Opis za zadatak SWE-bench Verified, međutim, pokriva samo konačni problem #18212(otvara se u novom prozoru). Ovo stvara nesklad: PR testovi pokrivaju sva tri problema, dok opis detaljno navodi samo jedan. U našim izvođenjima, modeli često ispravno implementiraju opisani popravak, a zatim padnu na testovima koji pokrivaju implementaciju za druga dva problema.
Originalni opis PR-a (iz GitHub PR-a)
Opis problema za #18212
Opis problema za SWE-bench potvrđeni zadatak (preuzeto samo iz #18212):
SWE-bench Verified i repozitoriji (baze koda i bilješke o izdanju) su open-source, široko korišteni i često diskutovani, što otežava izbjegavanje kontaminacije za developere modela.
Prvo smo naišli na znakove kontaminacije u našim vlastitim modelima. Na primjer, kada je GPT‑5.2 riješio 31 zadatak za koje smo utvrdili da ih je gotovo nemoguće riješiti. U django__django-14725(otvara se u novom prozoru) testovi zahtijevaju specifičan novi parametar `edit_only` koji nije izričito zahtijevan u izjavi o problemu. Tokom rješavanja problema, GPT‑5.2 u svom lancu razmišljanja pokazuje da ima informacije o napomenama o izdanju koje detaljno opisuju promjene u bazi koda, i ispravno identifikuje da je parametar `edit_only` uveden u Django 4.1.
GPT‑5.2 CoT
Kako bismo procijenili koliko je kontaminacija značajna u širem smislu, kreirali smo automatizirani red-teaming setup. Za svako pitanje SWE-bench Potvrđeno, zadužili smo GPT‑5 da ispituje GPT‑5.2‑Chat, Claude Opus 4.5 and Gemini 3 Flash Preview za kontaminaciju. Ovi modeli su odabrani kako bi se isključili modeli rezonovanja, ali priznajemo da vjerovatno postoji netrivijalan jaz u sposobnostima između njih.
Kako bi se ispitala kontaminacija, GPT‑5 je primio: ID zadatka SWE-Bench Potvrđeno, opis, zlatnu zakrpu i PR testove. Tokom više od 15 poteza, dozvolili smo GPT‑5 da varira sistemski/developerski upit, korisnički upit i predfil asistenta te različite strategije elicitacije. Nakon svakog poteza, sudijski model je označio koliko se pojavilo novih informacija specifičnih za zadatak, a svaki odgovor je označen prema ozbiljnosti kontaminacije od „nema“ do „jaka“. GPT‑5 je imao mogućnost da prilagodi svoju strategiju na osnovu prethodnih koraka kako bi iterativno povratio detalje specifične za zadatak. Za svaki primjer snažne kontaminacije, provjerili smo s drugim sudijom da GPT‑5 nije procurio previše informacija ciljnom modelu. Konačno, ručno smo pregledali „jake“ primjere koji čine transkripte u ovom postu.
U nastavku su primjeri značajne kontaminacije kod različitih pružalaca modela.
S obzirom na kratak isječak iz opisa zadatka, GPT‑5.2 daje tačnu zlatnu zakrpu. Posebno, zna tačan naziv klase i metode, kao i novi uslov ranog povratka `if username is None or password is None` koji je uveden.
ID zadatka: django__django-11451(otvara se u novom prozoru)
Elicitacija kontaminacije
Zlatna zakrpa
Opus je u stanju ne samo da se prisjeti tačne funkcionalne promjene od 4 linije koju je PR uveo, zajedno s konkretnim nazivom datoteke i metodom koje je dotakao, već i doslovno citira inline komentar koji je bio dio diffa.
Elicitacija kontaminacije
Zlatna zakrpa
Gemini 3 Flash, kada ne dobije nikakve dodatne informacije o zadatku osim ID-a, u stanju je doslovno iznijeti detalje iz opisa zadatka i gold patcha. Ovo uključuje novu regex formulu za validaciju korisničkog imena i tačne brojeve linija za promjenu.
ID zadatka: django__django-11099(otvara se u novom prozoru)
Elicitacija kontaminacije
Zlatna zakrpa
Iz ove revizije SWE-bench Verified, vidimo dvije šire pouke za dizajn evaluacije. Prvo, referentni testovi preuzeti iz javno dostupnog materijala nose rizik od kontaminacije, pri čemu izloženost podacima za obuku može neprimjetno napuhati rezultate. Ako se javno indeksirani podaci koriste u izradi benchmarka, programeri modela trebaju provesti dodatne testove na kontaminaciju. Mjerila, pa čak i njihova rješenja, javno objavljena mogu završiti u podacima za obuku. Potrebno je posvetiti dodatnu pažnju i načinu na koji se skupovi podataka objavljuju (npr. zaštićeno lozinkom) i filtriranje podataka za obuku (npr. strogo pridržavanje canary stringova).
Drugo, automatizirano bodovanje je nezgodno ispravno uraditi; savršeni testni slučajevi trebali bi u potpunosti verifikovati ispravnu funkcionalnost, pri čemu su i agnostični prema specifičnim nevažnim detaljima implementacije i također robusni na prečice u rješenjima. Ovi problemi su inherentno složeni i teško ih je riješiti. Otkrivanje ovih problema zahtijevalo je više opsežnih kampanja ljudskog označavanja.
Ugradili smo ove nalaze u naše nedavne napore evaluacije. U posljednjim mjesecima odlučili smo izvještavati o rezultatima iz javne podjele SWE-Bench Pro. Preporučujemo da i drugi programeri modela urade isto. SWE-bench Pro nije savršen, ali se empirijski čini da manje pati od problema s kontaminacijom. Naš pipeline za kontaminaciju je pronašao neke slučajeve kontaminacije, ali su ti slučajevi bili značajno rjeđi i manje ozbiljni nego u SWE-bench Verified, i nijedan model nije bio u stanju da proizvede potpunu doslovnu zlatnu zakrpu.
Nastavit ćemo ulagati u originalne, privatno izrađene benchmarke i tražiti pomoć od industrije i akademske zajednice da učine isto. U GDPVal, zadatke privatno kreiraju stručnjaci za domenu, čime se smanjuje rizik od izloženosti, a rješenja se ocjenjuju holistički od strane obučenih recenzenata. Ovaj pristup je resursno intenzivan, ali sve potrebniji za mjerenje stvarnih poboljšanja sposobnosti.


