Kodėl „SWE-bench Verified“ nebeįvertina priešakinių programavimo gebėjimų
„SWE-bench Verified“ tampa vis labiau užterštas. Rekomenduojame naudoti „SWE-bench Pro“.
Nuo tada, kai 2024 m. rugpjūčio mėn. pirmą kartą paskelbėme „SWE-bench Verified“, pramonė jį plačiai naudoja siekdama išmatuoti modelių pažangą atliekant autonominės programinės įrangos inžinerijos užduotis. Po išleidimo „SWE-bench Verified“ suteikė stiprų gebėjimų pažangos signalą ir tapo standartine metrika, skelbiama išleidžiant priešakinius modelius. Šių gebėjimų pažangos stebėjimas ir prognozavimas taip pat yra svarbi „OpenAI“ Pasirengimo sistemos dalis. Iš pradžių kurdami „Verified“ lyginamąjį indeksą, bandėme išspręsti pradinio vertinimo problemas, dėl kurių tam tikrų užduočių buvo neįmanoma atlikti naudojant „SWE-bench“ duomenų rinkinį(atsidaro naujame lange).
Po pradinių šuolių pažangiausio lygio „SWE-bench Verified“ rezultatai sulėtėjo, per pastaruosius šešis mėnesius pagerėję(atsidaro naujame lange) nuo 74,9 proc. iki 80,9 proc. Kyla klausimas: ar likusios nesėkmės atspindi modelio apribojimus, ar paties duomenų rinkinio savybes?
Atlikę naują analizę, nustatėme dvi pagrindines „Verified“ rinkinio problemas, rodančias, kad lyginamasis indeksas nebetinkamas matuoti autonominės programinės įrangos inžinerijos gebėjimų pažangą priešakiniams pristatymams, esant dabartiniam našumo lygiui.
- Testai atmeta teisingus sprendimus: atlikome 27,6 proc. duomenų rinkinio dalies, kurių modeliams dažnai nepavykdavo išspręsti, auditą ir nustatėme, kad mažiausiai 59,4 proc. audituotų problemų turi ydingų testavimo atvejų, kurie atmeta funkciškai teisingus pateikimus, nepaisant mūsų dėtų visų pastangų tai pagerinti pradiniame „SWE-bench Verified“ kūrimo etape.
- Mokymas naudojant sprendimus: kadangi dideli priešakiniai modeliai gali išmokti informaciją iš savo mokymo, svarbu, kad jie niekada nebūtų mokomi naudojant problemas ir sprendimus, pagal kuriuos yra vertinami. Tai panašu į būsimo testo problemų ir sprendimų pasidalijimą su mokiniais prieš testą – jie gali neįsiminti atsakymo, bet mokiniai, kurie anksčiau matė atsakymus, tikrai pasieks geresnių rezultatų nei tie, kurie jų nematė. „SWE-bench“ problemos gaunamos iš atvirojo kodo saugyklų, kurias daugelis modelių teikėjų naudoja mokymo tikslais. Atlikę analizę nustatėme, kad visi mūsų išbandyti priešakiniai modeliai sugebėjo atkurti pradinį, žmogaus parašytą klaidos ištaisymą, naudojamą kaip etaloną, žinomą kaip etaloninę pataisą, arba pažodžiui pateikti konkrečias užduoties formuluotes, o tai rodo, kad visi jie per mokymą matė bent dalį problemų ir sprendimų.
Taip pat radome įrodymų, kad modeliai, matę problemas per mokymą, dažniau pasiekia rezultatų, nes turi papildomos informacijos, reikalingos išlaikyti nepakankamai apibrėžtus testus.
Tai reiškia, kad „SWE-bench Verified“ rezultatų pagerėjimas neatspindi reikšmingo modelių realių programinės įrangos kūrimo gebėjimų pagerėjimo. Vietoj to, tai vis labiau atspindi, kiek modelis buvo susidūręs su lyginamuoju indeksu per mokymą. Todėl nustojome skelbti „SWE-bench Verified“ rezultatus ir rekomenduojame kitiems modelių kūrėjams padaryti tą patį.
Kuriame naujus, neužterštus vertinimus, siekdami geriau sekti programavimo gebėjimus, ir manome, kad tai yra svarbi sritis, į kurią turėtų susitelkti platesnė tyrėjų bendruomenė. Kol jų neturime, „OpenAI“ rekomenduoja skelbti „SWE-bench Pro“ rezultatus.
Pradinis „SWE-bench“(atsidaro naujame lange) vertinimas buvo išleistas 2023 m. Kiekviena problema gaunama iš išspręstos „GitHub“ problemos vienoje iš 12 atvirojo kodo „Python“ saugyklų ir susiejama su atitinkama išsiuntimo užklausa (PR). Norint nustatyti, ar modelio sugeneruotas kodo pakeitimas yra teisingas, prie kiekvienos problemos pateikiami du testų rinkiniai:
- Testai, kurie nepavyksta nemodifikuotoje kodo bazėje, bet pavyksta teisingai išsprendus problemą
- Regresijos testai, kurie išlaikomi tiek prieš išsprendžiant problemą, tiek po to, siekiant užtikrinti, kad nesusijusios funkcijos liktų nepakitusios.
Modelis nemato testų. Jis turi sugeneruoti kodo pakeitimą, gavęs tik pradinį problemos tekstą ir saugyklos būseną prieš išsprendžiant problemą. Jis problemą išsprendžia tik tada, jei pritaikius kodo pakeitimą išlaikomi visi testai.
Šiame vertinime nustatėme daug problemų, dėl kurių modelių gebėjimai gali būti nepakankamai įvertinti.
- Kai kurie vienetiniai testai buvo pernelyg specifiški arba neatitiko užduoties, todėl teisingi sprendimai galėjo būti atmesti.
- Daugelis užduočių formuluočių buvo nepakankamai apibrėžtos, o tai galėjo lemti kelias pagrįstas interpretacijas, kai testai apėmė tik vieną konkrečią.
- Atsižvelgiant į aplinkos sąranką (pavyzdžiui, „Linux“ ar „Windows“, arba „Python“ versiją), kai kurie testai galėjo atsitiktinai nepavykti
Siekdami išspręsti šias problemas, 2024 m. sukūrėme „SWE-bench Verified“. Bendradarbiaudami su patyrusiais programinės įrangos inžinieriais peržiūrėjome 1 699 „SWE-bench“ problemas ir išfiltravome tas, kurios turėjo šių trūkumų. Kiekvieną problemą nepriklausomai peržiūrėjo trys ekspertai. Šio peržiūros proceso rezultatas – „SWE-bench Verified“, kuruotas 500 problemų rinkinys.
Nors „SWE-bench Verified“ yra didelis patobulinimas, palyginti su pradine versija, vis dar lieka problemų. Atlikome 138 „SWE-bench Verified“ problemų, kurių „OpenAI o3“ nuosekliai neišspręsdavo per 64 nepriklausomus vykdymus, auditą. Kiekvieną atvejį nepriklausomai peržiūrėjo bent šeši patyrę programinės įrangos inžinieriai. Ekspertui pažymėjus problemą, ją iš naujo patikrindavo papildoma komanda.
Nustatėme, kad 59,4 proc. iš 138 problemų turėjo esminių testų dizaino ir (arba) problemos aprašymo trūkumų, dėl kurių net ir pajėgiausiam modeliui ar žmogui jas išspręsti buvo itin sunku arba neįmanoma.
- 35,5 % audituotų užduočių turi griežtus testavimo atvejus, reikalaujančius konkrečių įgyvendinimo detalių, taip paneigiant daugelį funkciškai teisingų pateikimų, kuriuos mes vadiname siaurais testavimo atvejais.
- 18,8 % audituotų užduočių turi testus, kuriais tikrinamas papildomas veikimas, nenurodytas problemos aprašyme, kuriuos mes vadiname plataus masto testavimo atvejais.
- Likusios 5,1 proc. užduočių turėjo įvairių problemų, kurios nebuvo lengvai grupuojamos pagal šią taksonomiją.
Iliustratyvus pirmojo nesėkmės režimo pavyzdys yra pylint-dev__pylint-4551(atsidaro naujame lange), kur išsiuntimo užklausa pristato naują funkciją „get_annotation“ kaip bendro sprendimo dalį. Šis funkcijos pavadinimas neminimas problemos aprašyme, tačiau jis importuojamas tiesiogiai testų. Nors kai kurie modeliai gali intuityviai sukurti tokią funkciją, norint teisingai išspręsti problemą, nėra būtina įdiegti funkciją tokiu konkrečiu pavadinimu. Daugelis tinkamų sprendimų neatitinka testų dėl importavimo klaidų.
Problemos aprašymas
Išsiuntimo užklausos testo fragmentas
Išsiuntimo užklausos testo nesėkmės (sutrumpinta dėl skaitomumo)
Per plačių testavimo atvejų pavyzdys yra sympy__sympy-18199(atsidaro naujame lange). Ši užduotis buvo gauta iš išsiuntimo užklausos, kurioje buvo nagrinėjamos trys atskiros problemos, susijusios su funkcija „nthroot_mod“, konkrečiai #17373(atsidaro naujame lange), #17377(atsidaro naujame lange) ir #18212(atsidaro naujame lange). Tačiau „SWE-bench Verified“ užduoties aprašymas apima tik paskutinę problemą #18212(atsidaro naujame lange). Tai sukuria neatitikimą: išsiuntimo užklausų testai apima visas tris problemas, o aprašyme detalizuojama tik viena. Vykdant testus, modeliai dažnai teisingai įdiegia aprašytą pataisą ir tada neišlaiko testų, apimančių kitų dviejų problemų įgyvendinimą.
Pradinis išsiuntimo užklausos aprašymas (iš „GitHub“ išsiuntimo užklausos)
Problemos aprašymas nr. 18212
„SWE-bench Verified“ užduoties problemos aprašymas (paimtas tik iš nr. 18212)
„SWE-bench Verified“ ir saugyklos (kodų bazės bei laidos pastabos) yra atvirojo kodo, plačiai naudojami ir aptariami, todėl modelių kūrėjams sunku išvengti duomenų užterštumo.
Pirmiausia užterštumo požymių pastebėjome savo pačių modeliuose. Pavyzdžiui, kai GPT‑5.2 išsprendė 31 užduotį, kurias nustatėme kaip beveik neįmanomas išspręsti. django__django-14725(atsidaro naujame lange) testai reikalauja specifinio naujo parametro „edit_only“, kurio aiškiai nereikalauja problemos formuluotė. Spręsdamas problemą, GPT‑5.2 savo minčių grandinėje parodo, kad turi informacijos apie laidos pastabas, kuriose išsamiai aprašyti kodų bazės pakeitimai, ir teisingai nustato, kad „edit_only“ parametras buvo įvestas „Django 4.1“ versijoje.
GPT‑5.2 CoT
Siekdami plačiau įvertinti, koks reikšmingas yra užterštumas, sukūrėme automatizuotą testavimo spragoms nustatyti sąranką. Kiekvienam „SWE-bench Verified“ klausimui pavedėme „OpenAI GPT‑5“ patikrinti „GPT‑5.2‑Chat“, „Claude Opus 4.5“ ir „Gemini 3 Flash Preview“ dėl užterštumo. Šie modeliai buvo pasirinkti siekiant išskirti protavimo modelius, tačiau pripažįstame, kad tarp jų greičiausiai yra nemažas gebėjimų atotrūkis.
Siekdamas ištirti užterštumą, GPT‑5 gavo „SWE-bench Verified“ užduoties identifikatorių, aprašymą, etaloninę pataisą ir išsiuntimo užklausų testus. Per 15 raundų leidome „OpenAI GPT‑5“ keisti sistemos / kūrėjo užklausą, naudotojo užklausą, asistento išankstinį užpildymą ir skirtingas išgavimo strategijas. Po kiekvieno raundo teisėjavimo modelis pažymėjo, kiek atsirado naujos, su užduotimi susijusios informacijos, o kiekvienas atsakymas buvo pažymėtas pagal užterštumo sunkumą nuo „nėra“ iki „stiprus“. GPT‑5 buvo leista pritaikyti savo strategiją pagal ankstesnius raundus, siekiant iteratyviai atkurti konkrečias užduoties detales. Kiekvienam stipraus užterštumo pavyzdžiui su kitu teisėju patikrinome, ar GPT‑5 nenutekino per daug informacijos tiksliniam modeliui. Galiausiai rankiniu būdu peržiūrėjome „stiprius“ pavyzdžius, sudarančius šio įrašo stenogramas.
Toliau pateikti stipraus duomenų užterštumo skirtingų modelių teikėjų sistemose pavyzdžiai.
Gavęs trumpą fragmentą iš užduoties aprašymo, GPT‑5.2 išveda tikslią etaloninę pataisą. Visų pirma, jis žino tikslų klasės ir metodo pavadinimą ir įvestą naują išankstinio grąžinimo sąlygą if username is None or password is None.
Užduoties identifikatorius: django__django-11451(atsidaro naujame lange)
Užterštumo išgavimas
Etaloninė pataisa
„Opus“ geba ne tik prisiminti tikslų išsiuntimo užklausos įvestą keturių eilučių funkcinį pakeitimą, nurodydamas konkretų failo pavadinimą ir paveiktą metodą, bet ir pažodžiui cituoja įdėtąjį komentarą, buvusį skirtumų (angl. diff) dalyje.
Užduoties identifikatorius: astropy__astropy-13236(atsidaro naujame lange)
Užterštumo išgavimas
Etaloninė pataisa
Gavęs tik identifikatorių ir jokios papildomos informacijos apie užduotį, „Gemini 3 Flash“ geba pažodžiui pateikti išsamią informaciją iš užduoties aprašymo ir etaloninės pataisos. Tai apima naują reguliariojo reiškinio formulę naudotojo vardui patvirtinti ir tikslius pakeitimo eilučių numerius.
Užduoties identifikatorius: django__django-11099(atsidaro naujame lange)
Užterštumo išgavimas
Etaloninė pataisa
Šis „SWE-bench Verified“ auditas atskleidžia dvi platesnes vertinimo dizaino pamokas. Pirma, iš viešai prieinamos medžiagos gauti lyginamieji indeksai kelia duomenų užterštumo riziką, kai dėl mokymo duomenų poveikio rezultatai gali būti nepastebimai padidinti. Kuriant lyginamąjį indeksą naudojant viešai surinktus duomenis, modelių kūrėjai turėtų atlikti papildomus užterštumo testus. Viešai paskelbti lyginamieji indeksai ir net jų sprendimai gali atsidurti mokymo duomenyse. Reikėtų būti ypač atsargiems tiek skelbiant duomenų rinkinius (t. y. apsaugant slaptažodžiu), tiek filtruojant mokymo duomenis (t. y. griežtai laikantis kontrolinių eilučių).
Antra, sunku užtikrinti tinkamą automatizuotą vertinimą. Tobuli testavimo atvejai turėtų visiškai patikrinti tinkamą veikimą, nebūdami priklausomi nuo konkrečių nesvarbių įgyvendinimo detalių ir būdami atsparūs trumpesniems sprendimams. Šios problemos iš esmės yra sudėtingos ir sunkiai išsprendžiamos. Šioms problemoms nustatyti prireikė kelių didelės apimties žmonių atliekamo žymėjimo kampanijų.
Šiuos radinius įtraukėme į savo naujausius vertinimo darbus. Pastaraisiais mėnesiais nusprendėme skelbti viešosios „SWE-Bench Pro“ dalies rezultatus. Rekomenduojame kitiems modelių kūrėjams padaryti tą patį. „SWE-bench Pro“ nėra tobulas, bet empiriškai atrodo, kad jis mažiau susiduria su duomenų užterštumo problemomis. Mūsų užterštumo nustatymo konvejeris aptiko keletą užterštumo atvejų, tačiau jie buvo gerokai retesni ir ne tokie akivaizdūs kaip „SWE-bench Verified“, ir nė vienas modelis nesugebėjo pažodžiui sugeneruoti visos etaloninės pataisos.
Toliau investuosime į originalius, privačiai sukurtus lyginamuosius indeksus ir prašysime pramonės bei akademinės bendruomenės pagalbos daryti tą patį. Programoje „GDPVal“ užduotis privačiai kuria srities ekspertai, taip sumažindami poveikio riziką, o sprendimus holistiškai vertina išmokyti tikrintojai. Šis požiūris reikalauja daug išteklių, tačiau jis vis labiau būtinas norint išmatuoti tikrą gebėjimų pagerėjimą.


