Alates sellest, kui avaldasime esmakordselt SWE-bench kinnitatud 2024. aasta augustis, on valdkond seda laialdaselt kasutanud, et mõõta mudelite arengut autonoomsete tarkvaratehnika ülesannete täitmisel. Pärast selle avaldamist andis SWE-bench Verified tugeva signaali võimekuse edenemisest ja sai tipptasemel mudelite väljalasetes raporteeritavaks standardmõõdikuks. Nende võimekuste edenemise jälgimine ja prognoosimine on samuti oluline osa OpenAI Valmisoleku raamistikust. Kui me algselt lõime Verifiedi võrdlusaluse, püüdsime lahendada algse hindamise probleeme, mis muutsid teatud ülesanded SWE-bench dataset(avaneb uues aknas)is võimatuks.
Pärast esialgseid hüppeid on tipptasemel edasiminek SWE-bench Verifiedil aeglustunud, paranedes(avaneb uues aknas) viimase 6 kuu jooksul 74,9%-lt 80,9%-le. See tõstatab küsimuse: kas ülejäänud ebaõnnestumised peegeldavad mudeli piiranguid või andmestiku enda omadusi?
Uues analüüsis leidsime Verified komplektis kaks suurt probleemi, mis viitavad sellele, et võrdlusalus ei sobi enam tipptasemel lansseerimiste puhul autonoomse tarkvaratehnika võimekuse arengu mõõtmiseks tänaste jõudlustasemete juures.
- Testid lükkavad õiged lahendused tagasi: me auditeerisime 27,6% andmestiku alamhulgast, mida mudelid sageli ei suutnud lahendada, ja leidsime, et vähemalt 59,4% auditeeritud ülesannetest on vigaste testjuhtumitega, mis lükkavad funktsionaalselt õiged esitused tagasi, hoolimata meie parimatest pingutustest seda SWE-bench Verifiedi loomisel parandada.
- Lahenduste koolitus: kuna suured tipptasemel mudelid võivad oma koolitusest teavet õppida, on oluline, et neid ei koolitataks kunagi probleemide ja lahenduste peal, mille põhjal neid hinnatakse. See on sarnane sellega, kui jagada õpilastega enne eelseisvat testi testiga seotud probleeme ja lahendusi – nad ei pruugi vastust pähe õppida, kuid õpilased, kes on vastuseid varem näinud, saavad kindlasti paremini hakkama kui need, kes ei ole. SWE-bench probleemid pärinevad avatud lähtekoodiga varamutest, mida paljud mudelipakkujad kasutavad koolituse eesmärgil. Meie analüüsis leidsime, et kõik testitud tipptasemel mudelid suutsid reprodutseerida algse, inimese kirjutatud veaparanduse, mida kasutati tõepärase viitena (ground-truth reference) ja mida tuntakse kuldpaigana (gold patch), või teatud ülesannete puhul sõna-sõnalt probleemikirjelduse spetsiifikat, mis viitab sellele, et kõik neist on koolituse käigus näinud vähemalt mõningaid probleeme ja lahendusi.
Leidsime ka tõendeid selle kohta, et mudelid, mis on koolituse käigus probleeme näinud, on suurema tõenäosusega edukad, sest neil on määratlemata testide läbimiseks vajalik lisateave.
See tähendab, et SWE-bench Verifiedi parandused ei kajasta enam sisulisi parandusi mudelite reaalse maailma tarkvaraarenduse võimekuses. Selle asemel peegeldavad need üha enam seda, kui palju mudel koolituse ajal mõõdupuuga kokku puutus. Seetõttu oleme lõpetanud SWE-bench Verified skooride raporteerimise ning soovitame, et teised mudeliarendajad teeksid samuti.
Me loome uusi, saastamata hindamisi, et paremini jälgida kodeerimisvõimekusi, ning usume, et see on oluline valdkond, millele laiemal teaduskogukonnal tasub keskenduda. Kuni meil need on, soovitab OpenAI raporteerida tulemusi SWE-bench Pro jaoks.
Algne SWE-benchi(avaneb uues aknas) hindamine avaldati 2023. aastal. Iga probleem pärineb lahendatud GitHubi probleemist ühes 12 avatud lähtekoodiga Pythoni varamus ja on seotud vastava pull requestiga (PR). Et teha kindlaks, kas mudeli genereeritud koodimuudatus on korrektne, on iga probleemiga kaasas kaks testikomplekti:
- Testid, mis ebaõnnestuvad muutmata koodibaasis, kuid õnnestuvad, kui sa parandad probleemi õigesti
- Regressioonitestid, mis läbivad nii enne kui ka pärast parandust, et tagada mitteseotud funktsionaalsuse säilimine.
Mudel ei näe teste. See peab looma koodimuudatuse, kasutades ainult algset probleemi teksti ja varamu olekut enne parandust. See läbib probleemi ainult siis, kui pärast koodimuudatuse rakendamist läbivad kõik testid.
Leidsime selle hindamisega seoses palju probleeme, mis võiksid viia mudelite võimekuse alaraporteerimiseni.
- Mõned üksusetestid olid liiga spetsiifilised või ülesandega mittevastavuses, mistõttu võidi õiged parandused tagasi lükata.
- Paljud ülesande kirjeldused olid ebapiisavalt täpsustatud, mis võis viia mitme kehtiva tõlgenduseni – samal ajal kui testid hõlmasid ainult üht konkreetset.
- Sõltuvalt keskkonna seadistusest (näiteks Linux vs Windows või pythoni versioonist) võivad mõned testid ekslikult ebaõnnestuda
Lõime 2024. aastal SWE-bench kinnitatud, et neid probleeme lahendada. Töötasime koos ekspertidest tarkvarainseneridega, et vaadata üle 1,699 SWE-bench probleemi ja filtreerida välja probleemid, millel esinesid need probleemid. Iga probleem vaadati kolme eksperdi poolt sõltumatult läbi. See ülevaatusprotsess andis tulemuseks SWE-bench kinnitatud, kureeritud 500 probleemi kogumi.
Kuigi SWE-bench Verified on algse versiooniga võrreldes suur edasiminek, püsivad alles probleemid. Viisime läbi auditi 138 SWE-bench Verified ülesande kohta, mida OpenAI o3 ei lahendanud järjepidevalt 64 sõltumatu käituse jooksul. Iga juhtum vaadati sõltumatult üle vähemalt kuue kogenud tarkvarainseneri poolt. Kui ekspert märkis probleemi, kontrollis täiendav meeskond selle uuesti üle.
Leidsime, et 59,4% 138 probleemist sisaldas olulisi puudusi testi ülesehituses ja/või probleemi kirjelduses, muutes need äärmiselt raskeks või võimatuks lahendada isegi kõige võimekamale mudelile või inimesele.
- 35,5% auditeeritud ülesannetest on rangete testjuhtumitega, mis nõuavad konkreetseid teostusüksikasju, muutes paljud funktsionaalselt õiged esitused kehtetuks; neid nimetame kitsasteks testjuhtumiteks.
- 18,8% auditeeritud ülesannetest on testid, mis kontrollivad täiendavat funktsionaalsust, mida probleemikirjelduses ei olnud täpsustatud, mida me nimetame laiadeks testjuhtumiteks.
- Ülejäänud 5,1% ülesannetest esines mitmesuguseid probleeme, mida ei olnud selle taksonoomiaga hästi rühmitatud.
Esimese tõrkerežiimi näide on pylint-dev__pylint-4551(avaneb uues aknas), kus PR lisab uue funktsiooni `get_annotation` osana lahendusest. Seda funktsiooni nime ei mainita probleemi kirjelduses, aga testid impordivad selle otse. Kuigi mõned mudelid võivad intuitiivselt luua sellise funktsiooni, ei ole probleemi lahendamiseks rangelt vajalik teha funktsiooni just selle konkreetse nimega. Paljud kehtivad lahendused kukuvad testid läbi impordivigade tõttu.
Probleemi kirjeldus
PR testkood
PR-testi ebaõnnestumised (loetavuse huvides kärbitud)
Liiga laiad testjuhtumid on näiteks sympy__sympy-18199(avaneb uues aknas). See ülesanne pärines PR-ist, mis käsitles `nthroot_mod` funktsiooniga seotud kolme eraldiseisvat probleemi, täpsemalt #17373(avaneb uues aknas), #17377(avaneb uues aknas) ja #18212(avaneb uues aknas). SWE-bench Verified ülesande kirjeldus hõlmab aga ainult lõplikku probleemi #18212(avaneb uues aknas). See tekitab vastuolu: PR-testid katavad kõik kolm probleemi, samas kui kirjeldus käsitleb ainult üht. Meie katsetustes rakendavad mudelid sageli kirjeldatud paranduse õigesti ja seejärel kukuvad läbi testides, mis katavad ülejäänud kahe probleemi implementatsiooni.
Algne PR-i kirjeldus (GitHubi PR-ist)
Probleemi kirjeldus #18212 jaoks
Probleemi kirjeldus SWE-bench Verified ülesande jaoks (võetud ainult #18212-st):
SWE-bench Verified ja varamud (koodibaasid ja väljalaskemärkmed) on mõlemad avatud lähtekoodiga ning laialdaselt kasutusel ja arutatud, mis teeb saastumise vältimise mudeli arendajatele keeruliseks.
Me kohtasime esmakordselt saastumise märke omaenda mudelites. Näiteks kui GPT‑5.2 lahendas 31 ülesannet, mille me tuvastasime olevat peaaegu võimatu lahendada. Failis django__django-14725(avaneb uues aknas) nõuavad testid konkreetset uut parameetrit `edit_only`, mida probleemikirjeldus selgesõnaliselt ei nõua. Probleemi lahendamise käigus näitab GPT‑5.2 oma mõttekäigus, et tal on teavet väljalaskemärkmete kohta, mis kirjeldavad koodibaasi muudatusi, ning tuvastab õigesti, et parameeter `edit_only` võeti kasutusele Django 4.1-s.
GPT‑5.2 mõttekäik
Et hinnata, kui ulatuslikult oluline saastumine on, lõime automatiseeritud lööktestimise seadistuse. Iga SWE-bench Verified küsimuse jaoks palusime GPT‑5‑l sondeerida GPT‑5.2‑Chat'i, Claude Opus 4.5 ja Gemini 3 Flash eelvaade saastumise jaoks. Need mudelid valiti selleks, et välistada arutlusmudelid, kuid tunnistame, et nende vahel on tõenäoliselt märkimisväärne võimekuse lõhe.
Saastumise tuvastamiseks sai GPT‑5: SWE-bench Verified ülesande ID, kirjelduse, gold patch’i ja PR testid. Rohkem kui 15 käigu jooksul lasime GPT‑5‑l varieerida süsteemi-/arendaja viipa, kasutaja viipa ja assistendi eeltäitmist ning erinevaid esilekutsumisstrateegiaid. Pärast iga vooru märkis kohtuniku mudel, kui palju uut ülesandespetsiifilist teavet ilmus, ja iga vastus märgistati saastatuse raskusastme järgi vahemikus “none” kuni “strong.” GPT‑5‑l lubati kohandada oma strateegiat varasemate voorude põhjal, et iteratiivselt taastada ülesandepõhised üksikasjad. Iga tugeva saastumise näite puhul kontrollisime teise kohtunikuga, et GPT‑5 ei lekitanud sihtmudelile liiga palju teavet. Lõpuks vaatasime seejärel käsitsi läbi „tugevad“ näited, millest koosnevad selle postituse transkriptsioonid.
Allpool on näited tugevast saastumisest erinevate mudelipakkujate seas.
Kui sa annad ülesande kirjeldusest lühikese katke, siis GPT‑5.2 väljastab täpse kuldse paranduse. Eelkõige teab see täpset klassi ja meetodi nime ning uut varajase tagastuse tingimust `if username is None or password is None`, mis on lisatud.
Ülesande ID: django__django-11451(avaneb uues aknas)
Saastatuse esiletoomine
Kuldne parandus
Opus suudab mitte ainult meenutada PR-i sisse viidud täpset 4-line funktsionaalset muudatust koos konkreetse failinime ja meetodiga, mida see puudutas, vaid tsiteerib ka sõna-sõnalt diffi osaks olnud reasisest kommentaari.
Ülesande ID: astropy__astropy-13236(avaneb uues aknas)
Saastatuse esiletoomine
Kuldne parandus
Kui Gemini 3 Flashile ei anta ülesande kohta peale ID lisateavet, suudab see kuvada ülesande kirjelduse ja kuldse paranduse üksikasju sõna-sõnalt. See hõlmab uut regex-valemit kasutajanime valideerimiseks ja muudatuse täpseid reanumbreid.
Ülesande ID: django__django-11099(avaneb uues aknas)
Saastatuse esiletoomine
Kuldne parandus
Sellest SWE-bench Verifiedi auditist näeme hindamiskujunduse jaoks kahte laiemat õppetundi. Esiteks kaasneb avalikult kättesaadavast materjalist pärinevate võrdlusmõõdikutega saastumisrisk, kus kokkupuude koolitusandmetega võib vaikselt tulemusi üles paisutada. Kui võrdlusaluse koostamisel kasutatakse avalikult indekseeritud andmeid, peaksid mudeli arendajad tegema saastumise tuvastamiseks täiendavaid teste. Võrdlusanalüüsid ja isegi nende lahendused, mis on avalikult postitatud, võivad sattuda treeningandmetesse. Erilist hoolt tuleks kanda nii selles, kuidas andmekogumeid postitatakse (s.t. parooliga kaitstud) ja koolitusandmete filtreerimine (s.t. canary stringide range järgimine).
Teiseks on automatiseeritud hindamine keeruline; ideaalsed testjuhtumid peaksid täielikult kontrollima funktsionaalsust, olles sõltumatud ebaolulistest detailidest ja vastupidavad otseteelahendustele. Need probleemid on keerulised ja neid on raske lahendada. Nende probleemide leidmine nõudis mitut ulatuslikku märgendamiskampaaniat.
Oleme need järeldused kaasanud oma hiljutistesse hindamispingutustesse. Viimastel kuudel oleme otsustanud raporteerida tulemusi SWE-Bench Pro avalikust jaotusest. Soovitame teistel mudeli arendajatel teha sama. SWE-bench Pro ei ole täiuslik, kuid empiiriliselt näib see kannatavat vähem saastumisega seotud probleemide all. Meie saastumise tuvastamise torustik leidis mõned saastumise juhtumid, kuid need juhtumid olid märkimisväärselt haruldasemad ja vähem rängad kui SWE-bench Verifiedis ning ükski mudel ei suutnud luua täielikku sõna-sõnalt vastavat gold patch’i.
Jätkame investeerimist algupärastesse, eraviisiliselt koostatud võrdlusmõõdikutesse ja palume tööstuselt ja akadeemilistelt ringkondadelt abi, et teha sama. GDPVal-is on ülesanded domeeniekspertide poolt privaatselt koostatud, vähendades kokkupuute riski, ja lahendusi hinnatakse terviklikult koolitatud hindajate poolt. See lähenemine on ressursimahukas, kuid üha vajalikum, et mõõta tõelisi võimekuste paranemisi.


