2026 m. liepos 8 d.

Atskiriant signalą nuo triukšmo programavimo vertinimuose

Atlikę išsamų auditą, SWE-Bench Pro randame plačiai paplitusių užduočių problemų ir vertiname, kad ~30 % užduočių yra neveikiančios.

Įkeliama...

Tiksliai matuoti mūsų modelių gebėjimus svarbu pagrįstiems diegimo ir saugos sprendimams, įskaitant sprendimus pagal OpenAI Pasirengimo sistemą⁠(atsidaro naujame lange). Išleisdami kiekvieną modelį, pateikiame įvairių išorinių ir vidinių etalonų rezultatus, kad stebėtume modelių pažangą. Kai vertinimuose yra rezultatams įtakos turinčių trūkumų, jie gali klaidingai parodyti gebėjimus, iškreipti saugos argumentus ir paveikti tyrimų prioritetus.

Neseniai ištyrėme, kaip vienas plačiausiai naudojamų programavimo etalonų, SWE-bench Verified, turėjo esminių dizaino ir taršos problemų, ir nustatėme, kad šis vertinimas nebeteikia prasmingo signalo apie programinės įrangos kūrimo gebėjimus. Tuo metu raginome platesnę bendruomenę pereiti prie SWE-Bench Pro.

SWE-Bench Pro⁠(atsidaro naujame lange) buvo sukurtas patobulinti SWE-bench Verified: testuoti modelius ilgesnio horizonto ir realistiškesnėmis programavimo užduotimis, kad būtų geriau stebimi agentinio programavimo gebėjimai. Kaip ir SWE-bench Verified, užduotys programiškai imamos iš funkcijų pakeitimų istorijos viešų ir privačių saugyklų rinkinyje. Modeliai turi įgyvendinti sprendimą, kuris išlaiko naujus funkcijos testus ir nesugadina esamos funkcijos. 731 užduoties viešame poaibyje priešakiniai modeliai per aštuonis mėnesius pagerėjo nuo 23,3 % iki 80,3 % išlaikymo rodiklio.

Nuo tada atlikome panašų SWE-Bench Pro auditą, peržiūrėdami duomenų rinkinį duomenų taškų analizės konvejeriu. Konvejeris peržiūrėjo modelių bandymus atlikti užduotį, užduočių metaduomenis ir nesėkmių pėdsakus, kad pažymėtų tikėtinus vertinimo trūkumus. Kiekviena pažymėta užduotis tada buvo įvertinta per kelis tyrimo agentų patikrinimus ir nepriklausomai peržiūrėta penkių patyrusių programinės įrangos inžinierių, o nesutarimai perduoti tolesniam tyrimui.

Didelėje duomenų rinkinio dalyje radome neveikiančių užduočių požymių. Mūsų duomenų taškų analizės konvejeris pažymėjo 200 (27,4 %) neveikiančių užduočių, o žmogaus anotavimo kampanija nustatė 249 (34,1 %).

Problemos daugiausia pateko į keturias kategorijas:

Pernelyg griežti testai¹ reikalauja konkrečių įgyvendinimo detalių, nenurodytų užklausoje, todėl daugelis funkcionaliai teisingų pateiktų sprendimų tampa negaliojantys.
Nepakankamai apibrėžtos užklausos² praleidžia reikalavimus, kuriuos užtikrina paslėpti testai ir kurių negalima pagrįstai numanyti.
Mažos aprėpties testai nepakankamai patikrina prašomą funkciją, todėl nepilni pataisymai gali būti priimti.
Klaidinanti užklausa nukreipia modelius į netinkamą elgseną arba prieštarauja tam, ko reikalauja testai.

Mūsų išvados rodo, kaip sunku kurti sudėtingus, bet teisingus etalonus, ir vis didesnę agentų naudą mastelio požiūriu plečiamiems duomenų kokybės patikrinimams. Atsižvelgdami į šiuos rezultatus, vertiname, kad ~30 % SWE-bench Pro užduočių yra neveikiančios, ir patariame modelių kūrėjams atidžiai nagrinėti rezultatus.

Metodika

Mūsų tikslas – užtikrinti, kad užduočių nesėkmės atspindėtų tikrus modelio ribotumus, o sėkmės – išsamius ir tinkamus užklausos reikalavimų sprendimus. Norėdami patikrinti vertinimui naudojamų duomenų kokybę, sukūrėme kokybės užtikrinimo konvejerį, vertinantį, ar kiekvienas duomenų taškas tiksliai atspindi modelio gebėjimus.

Kokybės užtikrinimo darbo eiga, derinanti automatinę patikrą ir žmogaus peržiūrą užduočių kokybei įvertinti. — Pradinis duomenų kokybės konvejeris pažymi problemas peržiūrai. Patikriname jas atlikdami išsamesnį agento padedamą pažymėtų užduočių auditą ir žmogaus anotavimo kampaniją su patyrusiais inžinieriais.

Pradinis automatinis filtras peržiūri modeliui duotas instrukcijas, modelio bandymus išspręsti užduotį ir testus, kuriais vertinami šie bandymai, kad pažymėtų tikėtinai neveikiančius ar probleminius pavyzdžius. Šis filtras pažymėjo 286 galimai neveikiančias užduotis. Tada atlikome išsamesnę šio poaibio peržiūrą dviem būdais: žmogaus prižiūrimą agentų peržiūrą, kurioje atliekami išsamūs patikrinimai su tyrimo agentais ir galutinį sprendimą priima žmogus; ir žmogaus anotavimo kampaniją su patyrusiais programinės įrangos kūrėjais.

Žmogaus prižiūrima agentų peržiūra

Kiekvieną pažymėtą problemą audituoja „Codex“ pagrindu veikiantys tyrimo agentai, kuriems suteikta prieiga prie užduoties saugyklos ir aplinkos. Tai padeda jiems atskirti pagrįstą užduoties dviprasmiškumą, kurį dažnai galima išspręsti nagrinėjant gretimą kodą ir saugyklos konvencijas, nuo tikro nepakankamo apibrėžtumo. Agentas gali vykdyti testus, tikrinti failus saugykloje ir tirti modelių bandymus bei jų įprastus nesėkmių režimus konkrečioje užduotyje. Po kelių nepriklausomų šių išsamesnių auditų pakartojimų tyrėjas peržiūrėjo santraukas, priėmė galutinį sprendimą ir pažymėjo tikėtinas problemas.

Žmogaus anotavimo kampanija

Lygiagrečiai vykdėme žmogaus anotavimo kampaniją pažymėtame poaibyje. Dirbome su patyrusiais programinės įrangos inžinieriais, kurie prieš peržiūrėdami užduotis buvo apmokyti apie etalono tikslus, problemų taksonomiją ir ribinius atvejus. Kiekvieną užduotį peržiūrėjo penki inžinieriai.

Prieš naudodami konvejerio analizę ar stenogramą kaip papildomą kontekstą, recenzentai susidarė nepriklausomą nuomonę iš matomo problemos aprašymo, testavimo atvejų ir etaloninio tiesos sprendimo (vadinamo auksiniu pataisymu). Tada recenzentai priskyrė etiketę ir sunkumo įvertį pagal konkrečius įrodymus, o nesutarimus ar mažo pasitikėjimo atvejus perdavė tolesnei peržiūrai.

Žmonės recenzentai dažniau nei tyrimo agentai žymėjo užduotis kaip neveikiančias. Tarp dviejų peržiūros kelių taip pat buvo nesutarimų dėl kategorijų, tačiau nė vienoje pažymėtoje užduotyje „neveikianti nėra“ nebuvo dažniausia žmogaus priskirta etiketė. Iš agentų konvejerio pažymėtų kategorijų recenzentų sprendimai sutapo 74 % atvejų.

Palyginti su agentų konvejeriu, žmonės recenzentai taip pat dažniau rinkosi kelias etiketes vienai užduočiai, o tai rodo, kad jie matė užduotis kaip neveikiančias keliais būdais arba netelpančias į vieną kategoriją. Tai leidžia manyti, kad agentų ir recenzentų konvejeris žymėjo konservatyviai: jis užfiksavo tuos pačius plačius nesėkmių režimus, kuriuos nustatė žmonės, bet nepakankamai suskaičiavo atvejus, kai recenzentai matė papildomas ar persidengiančias problemas. Didžiausias skirtumas buvo mažos aprėpties testuose: žmonės juos pasirinko kaip dažniausią problemą 9,4 % etalono užduočių, palyginti su 4,1 % agentų konvejeryje.

Nesėkmių režimai

Keliais atvejais užduoties užklausoje buvo nurodytas konkretus įgyvendinimas, tačiau paslėpti testavimo atvejai tikėjosi kitokios elgsenos.

This task involves normalizing table-of-contents entries and rendering them back to Markdown via TocEntry.to_markdown(). The task prompt specifies serialization down to character-level spacing, describing how exact spacing and pipes are enforced, and gives examples such as " | Chapter 1 | 1" and "** | Chapter 1 | 1":

Nėra

1"[space]| Chapter 1 | 1"
2"**[space]| Chapter 1 | 1"
3"[space]| Just title | "

The hidden test_to_markdown assertions instead require " | Chapter 1 | 1" and "** | Chapter 1 | 1":

Nėra

1"[space][space]| Chapter 1 | 1"
2"**[space][space]| Chapter 1 | 1"
3"[space][space]| Just title | "

There are two leading spaces in the hidden tests, but the example given to the model only contains one leading space. If a model rightly follows the given prompt, that one-character difference would fail the hidden test cases and the task would be marked incorrect.

Aptarimas

Mūsų nustatytos problemos, kartu su panašiais atvejais SWE-bench Verified, pabrėžia kruopštaus etalonų tikrinimo svarbą. Problemos ir pull request’ai iš atvirojo kodo saugyklų iš pradžių buvo kuriami žmonių bendradarbiavimui, dažnai per ilgą palaikytojų ir prisidėjusiųjų dialogą. Todėl problemų aprašymai, sulietas kodas ir vienetų testai ne visada susidėlioja į aiškias, izoliuotas užduotis, tinkamas patikimai vertinti modelius. Ypač pull request’uose esantys testai gali būti pernelyg griežti, nes jie rašomi konkrečiam pakeitimui patvirtinti, o ne nuo įgyvendinimo nepriklausomam užduoties sprendimo standartui apibrėžti.

Kartu vertinimo trūkumus dabar aptikti lengviau, nei būtų buvę dar visai neseniai. Gerėjant modelių gebėjimams, galime naudoti tuos modelius daug giliau ir nuosekliau tikrinti užklausas, testus, pataisas, pėdsakus ir ribinius atvejus, padėdami atskleisti etalonų problemas, kurias anksčiau rasti dideliu mastu buvo brangu ar nepraktiška.

Tikimės, kad platesnė vertinimo bendruomenė kurs naujus etalonus, kuriuos patyrę programinės įrangos kūrėjai sukurs specialiai modelių gebėjimams testuoti. Toks požiūris gali išlaikyti aukštą kartelę ir realistiškumą, kurių reikia modelių gebėjimams matuoti, ir leidžia geriau prižiūrėti žmogui viso proceso metu. Atsižvelgdami į šioje analizėje atskleistas problemas, atšaukiame ankstesnę rekomendaciją naudoti SWE-Bench Pro.

Galiausiai vertinimas turėtų teikti prasmingą signalą per etalonus, kuriuos sunku apeiti, kuriais lengva pasitikėti ir kurie tikrai atspindi modelio gebėjimus ar suderinimą. Kadangi šie rezultatai informuoja OpenAI diegimo ir saugos sprendimus, mūsų stebimi vertinimai turi būti pagrįsti ir informatyvūs.