Hvers vegna SWE-bench Verified mælir ekki lengur framarlega kóðunargetu

Síðan við birtum fyrst SWE-bench Verified í ágúst 2024 hefur iðnaðurinn víða notað það til að mæla framfarir líkana í sjálfvirkum hugbúnaðarverkfræðiverkefnum. Eftir útgáfu þess gaf SWE-bench Verified sterka vísbendingu um framfarir í getu og varð að stöðluðum mælikvarða sem greint er frá í útgáfum framarlegra líkana. Að fylgjast með og spá fyrir um framvindu þessara getuþátta er einnig mikilvægur hluti af undirbúningsramma OpenAI. Þegar við bjuggum til Verified-viðmiðunarstaðalinn í upphafi reyndum við að leysa vandamál í upprunalega matinu sem gerðu ákveðin verkefni ómöguleg að framkvæma í SWE-bench dataset⁠(opnast í nýjum glugga).

Eftir fyrstu framfarir hefur besta tækni sem býðst framfarir á SWE-bench Verified hægt á sér, bætt⁠(opnast í nýjum glugga) sig úr 74,9% í 80,9% á síðustu 6 mánuðum. Þetta vekur upp spurninguna: endurspegla þær bilanir sem eftir eru takmarkanir líkansins eða eiginleika gagnasafnsins sjálfs?

Í nýrri greiningu fundum við tvö meginvandamál með Verified-settinu sem benda til þess að viðmiðið sé ekki lengur hentugt til að mæla framfarir í sjálfvirkri hugbúnaðarverkfræði fyrir framarlegar útgáfur á frammistöðustigi dagsins í dag:

1. Próf hafna réttum lausnum: Við endurskoðuðum 27,6% hlutmengi gagnasafnsins sem líkön áttu oft í erfiðleikum með að leysa og komumst að því að að minnsta kosti 59,4% af endurskoðuðu verkefnunum eru með gölluð próftilvik sem hafna virknilega réttum innsendingum, þrátt fyrir okkar bestu viðleitni til að bæta þetta við upphaflega gerð SWE-bench Verified.
2. Þjálfun á lausnum: Þar sem stór framarleg líkön geta lært upplýsingar af þjálfun sinni er mikilvægt að þau séu aldrei þjálfuð á vandamálum og lausnum sem þau eru metin á. Þetta er svipað og að deila verkefnum og lausnum fyrir komandi próf með nemendum áður en prófið fer fram - þeir læra kannski ekki svarið utanbókar en nemendur sem hafa séð svörin áður munu vissulega standa sig betur en þeir sem hafa ekki séð þau. SWE-bench vandamál eru fengin úr opnum geymslum sem margir líkanveitendur nota í þjálfunarskyni. Í greiningu okkar komumst við að því að öll framarlegu líkönin sem við prófuðum gátu endurskapað upprunalegu, mannskrifuðu villuleiðréttinguna sem notuð var sem viðmiðun í grunnsannleika, þekkt sem gullbótin, eða orðrétt tiltekin atriði í vandamálalýsingu fyrir ákveðin verkefni, sem bendir til þess að þau hafi öll séð að minnsta kosti einhver vandamálin og lausnirnar á meðan á þjálfun stóð.

Við fundum einnig vísbendingar um að líkön sem hafa séð vandamálin meðan á þjálfun stóð séu líklegri til að ná árangri, vegna þess að þau hafa viðbótarupplýsingar sem þarf til að standast próf sem eru ekki nægilega vel skilgreind.

Þetta þýðir að umbætur á SWE-bench Verified endurspegla ekki lengur marktækar umbætur á raunverulegri getu líkana til hugbúnaðarþróunar. Þess í stað endurspegla þau í auknum mæli hversu mikið líkanið var útsett fyrir viðmiðuninni á þjálfunartíma. Þess vegna höfum við hætt að birta SWE-bench Verified-stig og við mælum með að aðrir líkanaþróunaraðilar geri það líka.

Við erum að byggja nýja, óspillta matsferla til að fylgjast betur með forritunargetu og við teljum að þetta sé mikilvægt svið til að einbeita sér að fyrir víðara rannsóknarsamfélagið. Þangað til við höfum þær niðurstöður mælir OpenAI með að birtar verði niðurstöður fyrir SWE-bench Pro.

Upprunalega SWE-bench⁠(opnast í nýjum glugga) matið var gefið út árið 2023. Hvert vandamál er fengið úr leystu GitHub-vandamáli í einni af 12 opnum Python-geymslum og parað við samsvarandi pull request (PR). Til að ákvarða hvort kóðabreyting sem líkan hefur myndað sé rétt fylgja hverju verkefni tvö prófunarsett:

• Prófanir sem falla á óbreyttum kóðagrunni en standast ef vandamálið er lagað á réttan hátt
• Aðhvarfspróf sem standast bæði fyrir og eftir lagfæringuna til að tryggja að óskyld virkni haldist óskemmd.

Líkanið sér ekki prófin. Það þarf að framleiða kóðabreytingu með aðeins upprunalega texta vandamálsins og stöðu geymslunnar fyrir lagfæringuna. Það stenst vandamál aðeins ef öll próf standast eftir að kóðabreytingin hefur verið beitt.

Við fundum mörg vandamál við það mat sem gætu leitt til vanmats á getu líkana.

• Sumar einingaprófanir voru of sértækar eða ekki í samræmi við verkefnið svo réttum lagfæringum gæti verið hafnað.
• Margar verkefnalýsingar voru illa skilgreindar, sem gæti leitt til margra gildra túlkana – á meðan prófin náðu aðeins yfir eina tiltekna.
• Það fer eftir uppsetningu umhverfisins (til dæmis Linux gegn Windows, eða Python-útgáfunni), en sum próf gætu mistekist að ástæðulausu.

Við bjuggum til SWE-bench Verified árið 2024 til að takast á við þessi vandamál. Við unnum með sérfræðingum í hugbúnaðarverkfræði til að fara yfir 1.699 SWE-bench verkefni og sía út verkefni sem höfðu þessi vandamál. Hvert vandamál var yfirfarið af þremur sérfræðingum, hver fyrir sig. Þetta yfirferðarferli leiddi til SWE-bench Verified, vandlega valins safns af 500 vandamálum.

Þótt SWE-bench Verified sé mikil framför miðað við upphaflegu útgáfuna, eru enn óleyst vandamál til staðar. Við gerðum úttekt á 138 verkefnum í SWE-bench Verified sem OpenAI o3 leysti ekki áreiðanlega í 64 óháðum keyrslum. Hvert tilvik var yfirfarið sjálfstætt af að minnsta kosti sex reyndum hugbúnaðarverkfræðingum. Ef sérfræðingur benti á vandamál var það staðfest aftur af viðbótarteymi.

Við komumst að því að 59,4% af 138 vandamálunum innihéldu veruleg atriði í hönnun prófa og/eða lýsingu vandamáls, sem gerði þau afar erfið eða ómöguleg að leysa, jafnvel fyrir hæfasta líkan eða mann. 

• 35,5% af yfirförnum verkefnum eru með ströng prófunartilvik sem knýja fram tiltekin útfærsluatriði, sem gerir margar virknilega réttar innsendingar ógildar, sem við köllum þröng prófunartilvik.
• 18,8% af yfirförnum verkefnum eru með próf sem kanna viðbótarvirkni sem ekki var tilgreind í verkefnalýsingunni, sem við köllum víð prófunartilvik.
• Eftirstandandi 5,1% verkefna voru með ýmis vandamál sem ekki var hægt að flokka vel samkvæmt þessari flokkunarfræði.

Lýsandi dæmi um fyrsta bilunarhaminn er pylint-dev__pylint-4551⁠(opnast í nýjum glugga), þar sem pull request kynnir nýtt fall `get_annotation` sem hluta af heildarlausninni. Þetta heiti falls er ekki nefnt í lýsingu verkefnisins en er flutt inn beint af prófunum. Þó að sum líkön gætu ályktað að búa til slíkt fall er ekki stranglega nauðsynlegt að innleiða fall með þessu tiltekna nafni til að leysa vandamálið rétt. Margar gildar lausnir falla á prófunum vegna innflutningsvilla.

Dæmi um of víð prófunartilvik er sympy__sympy-18199⁠(opnast í nýjum glugga). Þetta verkefni var fengið úr pull request sem tók á þremur aðskildum vandamálum með `nthroot_mod` fallið, nánar tiltekið #17373⁠(opnast í nýjum glugga), #17377⁠(opnast í nýjum glugga), og #18212⁠(opnast í nýjum glugga). Lýsingin á SWE-bench Verified-verkefninu nær hins vegar aðeins yfir lokavandamálið #18212⁠(opnast í nýjum glugga). Þetta skapar misræmi: Pull request prófin ná yfir öll þrjú atriðin, á meðan lýsingin fjallar aðeins um eitt. Í keyrslum okkar útfæra líkön oft rétt lagfæringuna sem lýst er og falla síðan á prófunum sem ná yfir útfærslu á hinum tveimur vandamálunum.

SWE-bench Verified og geymslurnar (kóðagrunnar og útgáfuathugasemdir) eru bæði opinn hugbúnaður og mikið notaðar og ræddar sem gerir það erfitt fyrir líkanahönnuði að forðast mengun.

Við urðum fyrst vör við merki um mengun í okkar eigin líkönum. Til dæmis þegar GPT‑5.2 leysti 31 verkefni sem við greindum sem nánast ómöguleg að leysa. Í django__django-14725⁠(opnast í nýjum glugga) krefjast prófin tiltekinnar nýrrar færibreytu `edit_only` sem er ekki skýrt krafist í vandamálalýsingunni. Á meðan vandamálið er leyst sýnir GPT‑5.2 í hugsanakeðju sinni að það hafi upplýsingar um útgáfuathugasemdir sem lýsa breytingum á kóðagrunninum og greinir réttilega að `edit_only` færibreytan var kynnt í Django 4.1.

Til að meta hversu mikil mengun er í víðara samhengi bjuggum við til sjálfvirka rauðteymi-uppsetningu. Fyrir hverja SWE-bench Verified spurningu fengum við GPT‑5 til að prófa GPT‑5.2‑Chat, Claude Opus 4.5 og Gemini 3 Flash Preview fyrir mengun. Þessi líkön voru valin til að útiloka rakalíkön en við viðurkennum að líklegt er að það sé ekki óverulegt bil í getu á milli þeirra.

Til að kanna mengun fékk GPT‑5: auðkenni, lýsingu, gullbót og pull request próf SWE-bench Verified verkefnisins. Yfir 15 umferðir leyfðum við GPT‑5 að breyta kerfis-/þróunaraðilakvaðningu, notandakvaðningu og forfyllingu aðstoðarmanns og mismunandi aðferðum við að fá fram svör. Eftir hverja umferð merkti dómaralíkan hversu mikið af nýjum verkefnissértækum upplýsingum kom fram og hvert svar var merkt með alvarleika mengunar frá „engin“ til „mikil.“ GPT‑5 var leyft að aðlaga stefnu sína út frá fyrri umferðum til að endurheimta smám saman verkefnissértækar upplýsingar. Fyrir hvert dæmi um mikla mengun staðfestum við með öðrum dómara að GPT‑5 hefði ekki lekið of miklum upplýsingum til líkansins. Að lokum fórum við síðan handvirkt yfir „miklu“ dæmin sem mynda afritin í þessari færslu.

Hér að neðan eru dæmi um mikla mengun hjá mismunandi líkanaveitum.

Miðað við stuttan bút úr verkefnalýsingunni skilar GPT‑5.2 nákvæmlega réttu gullbótinni. Sérstaklega veit það nákvæmlega heiti klasans og aðferðarinnar og nýja skilyrðið fyrir snemmbúna skilagjöfina `if username is None or password is None` sem er kynnt.

Verkefnisauðkenni: django__django-11451⁠(opnast í nýjum glugga)

Opus getur ekki aðeins rifjað upp nákvæmlega fjögurra lína virknibreytinguna sem pull request kynnti, ásamt tilteknu skráarheiti og aðferð sem það snerti, heldur vitnar það einnig orðrétt í innfelldu athugasemdina sem var hluti af diff. 

Verkefnaauðkenni: astropy__astropy-13236⁠(opnast í nýjum glugga)

Gemini 3 Flash, þegar því eru ekki gefnar frekari upplýsingar um verkefnið en auðkennið, getur skilað orðréttum upplýsingum úr verkefnalýsingunni og gullbótinni. Þetta felur í sér nýju regex-formúluna fyrir staðfestingu notendanafns og nákvæm línunúmer fyrir breytinguna.

Verkefnaauðkenni: django__django-11099⁠(opnast í nýjum glugga)

Út frá þessari úttekt á SWE-bench Verified sjáum við tvær víðtækari lexíur fyrir hönnun mats. Fyrst ber að nefna að viðmið sem eru fengin úr opinberlega aðgengilegu efni fela í sér mengunaráhættu, þar sem útsetning fyrir þjálfunargögnum getur hljóðlega blásið upp skor. Ef opinberlega skriðuð gögn eru notuð við gerð viðmiða, ættu þróunaraðilar líkana að framkvæma viðbótarprófanir til að greina mengun. Viðmiðanir, og jafnvel lausnir þeirra, sem eru birtar opinberlega geta endað í þjálfunargögnum. Gæta ætti sérstakrar varúðar bæði við það hvernig gagnasöfn eru birt (þ.e. lykilorðsvarið) og síun þjálfunargagna (þ.e. ströng fylgni við canary strings). 

Í öðru lagi er sjálfvirk stigagjöf vandasöm að fá rétta; fullkomin prófunartilvik ættu að staðfesta rétta virkni til fulls, vera bæði óháð tilteknum ómikilvægum útfærsluatriðum og jafnframt nægilega traust til að standast styttileiðalausnir. Þessi vandamál eru í eðli sínu flókin og erfið að leysa. Að greina þessi vandamál krafðist margra umfangsmikilla mannlegra merkingarherferða. 

Við höfum innfellt þessar niðurstöður í nýlegar matsaðgerðir okkar. Undanfarna mánuði höfum við valið að greina frá niðurstöðum úr opinberu skiptingunni á SWE-Bench Pro. Við mælum með því að aðrir þróunaraðilar líkana geri hið sama. SWE-bench Pro er ekki fullkomið, en virðist samkvæmt reynslu þjást síður af mengunarvandamálum. Mengunargreiningarleiðslan okkar fann nokkur tilvik mengunar, en þessi tilvik voru verulega sjaldgæfari og síður alvarleg en í SWE-bench Verified, og ekkert líkan gat framleitt fullkomna orðréttan gullbót.

Við munum halda áfram að fjárfesta í upprunalegum, sérstökum viðmiðum og biðja um aðstoð frá atvinnulífinu og háskólasamfélaginu til að gera hið sama. Í GDPVal⁠ eru verkefni skrifuð í trúnaði af sviðssérfræðingum, sem dregur úr áhættu á útsetningu og lausnir eru metnar heildstætt af þjálfuðum yfirferðaraðilum. Þessi nálgun er krefjandi í auðlindanotkun en sífellt nauðsynlegri til að mæla raunverulegar umbætur á getu.