2026. gada 8. jūlijs

Signāla nošķiršana no trokšņa programmēšanas izvērtējumos

Detalizētā auditā konstatējam plašas uzdevumu problēmas SWE-Bench Pro un lēšam, ka aptuveni 30% uzdevumu ir bojāti.

Notiek ielāde…

Precīza mūsu modeļu spēju mērīšana ir svarīga pārdomātiem izvietošanas un drošības lēmumiem, tostarp lēmumiem saskaņā ar OpenAI Sagatavotības satvaru⁠(atveras jaunā logā). Ar katru modeļa laidienu mēs ziņojam rezultātus dažādiem ārējiem un iekšējiem etalontestiem, lai sekotu modeļa progresam. Ja izvērtējumos ir trūkumi, kas ietekmē rezultātus, tie var radīt maldīgu priekšstatu par spējām, sagrozot drošības pamatojumus un ietekmējot pētniecības prioritātes.

Mēs nesen izpētījām, kā vienam no plašāk izmantotajiem programmēšanas etalontestiem, SWE-bench Verified, bija būtiskas dizaina un kontaminācijas problēmas, un konstatējām, ka šis izvērtējums vairs nesniedz nozīmīgu signālu par programmatūras izstrādes spējām. Toreiz mēs mudinājām plašāku kopienu pāriet uz SWE-Bench Pro.

SWE-Bench Pro⁠(atveras jaunā logā) tika izstrādāts, lai uzlabotu SWE-bench Verified, pārbaudot modeļus ilgākos horizontos un reālistiskākos programmēšanas uzdevumos, tādējādi labāk sekotu autonomās programmēšanas spējām. Tāpat kā SWE-bench Verified, uzdevumi tiek programmatiski iegūti no funkciju izmaiņu vēstures publisku un privātu repozitoriju kopā. Modeļiem jāievieš risinājums, kas iztur jaunos funkcijas testus, nesabojājot esošo funkcionalitāti. Publiskajā sadalījumā ar 731 uzdevumu robežšķirtnes modeļi astoņu mēnešu laikā uzlaboja sekmīgas izpildes rādītāju no 23,3% līdz 80,3%.

Kopš tā laika mēs esam veikuši līdzīgu SWE-Bench Pro auditu, pārskatot datu kopu ar datu punktu analīzes konveijeru. Konveijers pārskatīja modeļa mēģinājumus izpildīt uzdevumu, uzdevuma metadatus un kļūmju pēdas, lai atzīmētu iespējamus izvērtējuma trūkumus. Katrs atzīmētais uzdevums pēc tam tika novērtēts vairākos pētnieka-aģenta pārskatīšanas ciklos un neatkarīgi pārskatīts piecu pieredzējušu programmatūras inženieru vadībā; domstarpības tika eskalētas turpmākai izmeklēšanai.

Ievērojamā datu kopas daļā konstatējam pierādījumus par bojātiem uzdevumiem. Mūsu datu punktu analīzes konveijers atzīmēja 200 (27,4%) bojātus uzdevumus, savukārt cilvēku anotēšanas kampaņa identificēja 249 (34,1%).

Problēmas galvenokārt iedalījās četrās kategorijās:

Pārmērīgi stingri testi¹ uzspiež konkrētas ieviešanas detaļas, kas nav norādītas uzvednē, tādēļ daudzi funkcionāli pareizi iesniegumi tiek atzīti par nederīgiem.
Nepietiekami precizētas uzvednes² izlaiž prasības, kuras slēptie testi uzspiež un kuras nav saprātīgi izsecināmas.
Testi ar zemu pārklājumu nepietiekami pārbauda pieprasīto funkciju, tāpēc nepilnīgi labojumi var izturēt pārbaudi.
Maldinoša uzvedne virza modeļus uz nepareizu darbību vai ir pretrunā ar to, ko prasa testi.

Mūsu secinājumi norāda uz grūtībām veidot sarežģītus, bet godīgus etalontestus un uz aģentu pieaugošo lietderību mērogojamās datu kvalitātes pārbaudēs. Ņemot vērā šos rezultātus, mēs lēšam, ka aptuveni 30% SWE-bench Pro uzdevumu ir bojāti, un iesakām modeļu izstrādātājiem rūpīgi pārbaudīt rezultātus.

Metodoloģija

Mūsu mērķis ir nodrošināt, lai uzdevumu neizpildes atspoguļotu patiesus modeļa ierobežojumus, bet uzdevumu izpildes — pilnīgus un derīgus risinājumus uzvednes prasībām. Lai pārbaudītu izvērtējumā izmantoto datu kvalitāti, mēs izveidojām kvalitātes nodrošināšanas konveijeru, kas novērtē, vai katrs datu punkts precīzi atspoguļo modeļa spējas.

Kvalitātes nodrošināšanas darbplūsma, kas apvieno automatizētu atlasi un cilvēka pārbaudi, lai novērtētu uzdevumu kvalitāti. — Sākotnējais datu kvalitātes konveijers atzīmē problēmas pārskatīšanai. Mēs validējam rezultātus ar padziļinātu, aģentu atbalstītu atzīmēto uzdevumu auditu un cilvēku anotēšanas kampaņu, kurā iesaistīti pieredzējuši inženieri.

Sākotnējais automatizētais filtrs pārskata modelim dotās instrukcijas, modeļa mēģinājumus atrisināt uzdevumu un testus, kas izmantoti šo mēģinājumu vērtēšanai, lai atzīmētu iespējami bojātus vai problemātiskus piemērus. Šis filtrs atzīmēja 286 potenciāli bojātus uzdevumus. Pēc tam mēs veicām šīs apakškopas padziļinātu pārbaudi divos veidos: cilvēka pārraudzītu aģentu pārbaudi, kurā plašas pārbaudes veic izmeklējoši aģenti un galīgo spriedumu pieņem cilvēks; un cilvēku anotēšanas kampaņu, kurā piedalījās pieredzējuši programmatūras izstrādātāji.

Cilvēka pārraudzīta aģentu pārbaude

Katru atzīmēto problēmu auditē Codex balstīti izmeklējoši aģenti, kuriem tika piešķirta piekļuve uzdevuma repozitorijam un videi. Tas palīdz tiem atšķirt saprātīgu uzdevuma neskaidrību, ko bieži var atrisināt, izpētot blakus esošo kodu un repozitorija konvencijas, no patiesas nepietiekamas specifikācijas. Aģents var palaist testus, pārbaudīt failus repo un izmeklēt modeļa mēģinājumus, kā arī to biežākos kļūmju veidus šajā uzdevumā. Pēc vairākiem neatkarīgiem šo padziļināto auditu atkārtojumiem pētnieks pārskatīja kopsavilkumus, pieņēma galīgo spriedumu un piešķīra etiķetes iespējamajām problēmām.

Cilvēku anotēšanas kampaņa

Paralēli mēs atzīmētajai apakškopai īstenojām cilvēku anotēšanas kampaņu. Mēs sadarbojāmies ar pieredzējušiem programmatūras inženieriem, kuri pirms uzdevumu pārskatīšanas tika apmācīti par etalontesta mērķiem, problēmu taksonomiju un robežgadījumiem. Katru uzdevumu pārskatīja pieci inženieri.

Pārskatītāji vispirms izveidoja neatkarīgu spriedumu, balstoties uz redzamo problēmas formulējumu, testa gadījumiem un patiesās atsauces risinājumu (pazīstamu kā zelta ielāps), un tikai pēc tam izmantoja konveijera analīzi vai transkriptu kā papildu kontekstu. Pēc tam pārskatītāji piešķīra etiķeti un smaguma vērtējumu, balstoties uz konkrētiem pierādījumiem, un eskalēja domstarpības vai zemas pārliecības gadījumus turpmākai pārskatīšanai.

Cilvēki pārskatītāji biežāk nekā izmeklējošie aģenti atzīmēja uzdevumus kā bojātus. Starp abiem pārbaudes ceļiem bija arī zināmas domstarpības par kategorijām, taču nevienā atzīmētā uzdevumā “nav bojāts” nebija biežākā cilvēku piešķirtā etiķete. No kategorijām, ko atzīmēja aģentu konveijers, pārskatītāju spriedumi sakrita 74% gadījumu.

Salīdzinājumā ar aģentu konveijeru cilvēki pārskatītāji arī biežāk vienam uzdevumam izvēlējās vairākas etiķetes, norādot, ka uzdevumi viņu ieskatā bija bojāti vairākos veidos vai neiederējās vienā skaidrā kategorijā. Tas liecina, ka aģentu un pārskatītāju konveijers radīja konservatīvu marķēšanu: tas aptvēra tos pašus plašos kļūmju veidus, ko identificēja cilvēki, vienlaikus par zemu uzskaitot gadījumus, kuros pārskatītāji saskatīja papildu vai pārklājošas problēmas. Lielākā atšķirība bija testos ar zemu pārklājumu: cilvēki tos izvēlējās kā biežāko problēmu 9,4% etalontesta gadījumu, salīdzinot ar 4,1% aģentu konveijerā.

Kļūmju veidi

Vairākos gadījumos uzdevuma uzvednē bija noteikta konkrēta ieviešana, bet slēptie testa gadījumi gaidīja atšķirīgu darbību.

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":

Nav

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":

Nav

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.

Diskusija

Mūsu identificētās problēmas kopā ar līdzīgiem gadījumiem SWE-bench Verified izceļ nepieciešamību etalontestus pārbaudīt īpaši rūpīgi. Problēmas un pull request pieprasījumi no atvērtā pirmkoda repozitorijiem sākotnēji tika veidoti cilvēku sadarbībai, bieži vien garās diskusijās starp uzturētājiem un līdzstrādniekiem. Tādēļ problēmu apraksti, sapludinātais kods un vienībtesti ne vienmēr sakrīt tā, lai veidotu tīrus, izolētus uzdevumus modeļu uzticamai izvērtēšanai. Jo īpaši pull request pieprasījumos iekļautie testi var būt pārmērīgi stingri, jo tie ir rakstīti, lai validētu konkrētas izmaiņas, nevis definētu no ieviešanas neatkarīgu standartu uzdevuma atrisināšanai.

Vienlaikus izvērtējuma trūkumus tagad ir vieglāk atklāt, nekā tas būtu bijis pat pavisam nesen. Uzlabojoties modeļu spējām, mēs varam izmantot šos modeļus, lai daudz dziļāk un konsekventāk pārbaudītu uzvednes, testus, ielāpus, pēdas un robežgadījumus, palīdzot atklāt etalontestu problēmas, kuras iepriekš būtu bijis dārgi vai nepraktiski atrast mērogā.

Mēs ceram, ka plašāka izvērtēšanas kopiena izstrādās jaunus etalontestus, ko veido pieredzējuši programmatūras izstrādātāji tieši modeļu spēju pārbaudei. Šāda pieeja var saglabāt augsto latiņu un reālismu, ko vēlamies izmantot modeļu spēju mērīšanai, un ļauj nodrošināt labāku cilvēka pārraudzību visā procesā. Ņemot vērā šajā analīzē atklātās problēmas, mēs atsaucam savu iepriekšējo ieteikumu pieņemt SWE-Bench Pro.

Galu galā izvērtējumam būtu jāsniedz nozīmīgs signāls, izmantojot etalontestus, kurus ir grūti apiet, kuriem ir viegli uzticēties un kuri patiesi atspoguļo modeļa spējas vai saskaņotību. Tā kā šie rezultāti ietekmē OpenAI izvietošanas un drošības lēmumus, izvērtējumiem, kuriem sekojam, jābūt derīgiem un informatīviem.