Oddelenie signálu od šumu v hodnoteniach programovania

Presné meranie schopností našich modelov je dôležité pre správne rozhodnutia o nasadení a bezpečnosti vrátane rozhodnutí podľa Rámca pripravenosti⁠(otvorí sa v novom okne) OpenAI. Pri každom vydaní modelu zverejňujeme výsledky na rôznych externých aj interných benchmarkoch, aby sme sledovali pokrok modelu. Keď majú hodnotenia chyby, ktoré ovplyvňujú výsledky, môžu vytvoriť mylný obraz o schopnostiach, skresliť bezpečnostné argumenty a ovplyvniť výskumné priority.

Nedávno sme skúmali, ako jeden z najpoužívanejších benchmarkov programovania, SWE-bench Verified, trpel zásadnými problémami návrhu a kontaminácie, a zistili sme, že hodnotenie už neposkytuje zmysluplný signál o schopnostiach vývoja softvéru. Vtedy sme širšej komunite odporúčali prejsť na SWE-Bench Pro.

SWE-Bench Pro⁠(otvorí sa v novom okne) bol navrhnutý tak, aby zlepšil SWE-bench Verified testovaním modelov na dlhších horizontoch a realistickejších programátorských úlohách, čím by lepšie sledoval schopnosti agentického programovania. Rovnako ako v SWE-bench Verified sa úlohy získavajú programovo z histórie zmien funkcií v súbore verejných a súkromných repozitárov. Modely musia implementovať riešenie, ktoré prejde novými testami funkcie bez narušenia existujúcej funkcionality. Na verejnom rozdelení so 731 úlohami sa prelomové modely za osem mesiacov zlepšili z úspešnosti 23,3 % na 80,3 %.

Odvtedy sme vykonali podobný audit SWE-Bench Pro a preskúmali sme dátový súbor pomocou pipelineu na analýzu dátových bodov. Pipeline preskúmal pokusy modelu o vyriešenie úlohy, metadáta úlohy a stopy zlyhaní, aby označil pravdepodobné chyby hodnotenia. Každá označená úloha sa potom posúdila cez viacero priechodov agentov-vyšetrovateľov a nezávisle ju skontrolovalo päť skúsených softvérových inžinierov, pričom nezhody boli postúpené na ďalšie preskúmanie.

Problémy spadali najmä do štyroch kategórií:

• Príliš prísne testy¹ vynucujú konkrétne implementačné detaily neuvedené v príkaze, čím zneplatňujú mnohé funkčne správne odovzdané riešenia.
• Nedostatočne špecifikované príkazy² vynechávajú požiadavky, ktoré skryté testy vynucujú a ktoré nemožno primerane odvodiť.
• Testy s nízkym pokrytím nedostatočne kontrolujú požadovanú funkciu, takže neúplné opravy môžu prejsť.
• Zavádzajúci príkaz smeruje modely k nesprávnemu správaniu alebo odporuje tomu, čo vyžadujú testy.

Naše zistenia poukazujú na náročnosť zostavovania ťažkých, no spravodlivých benchmarkov a na rastúci prínos agentov pri škálovateľných kontrolách kvality dát. Vzhľadom na tieto výsledky odhadujeme, že približne 30 % úloh v SWE-bench Pro je chybných, a odporúčame vývojárom modelov, aby výsledky starostlivo preskúmali.

Naším cieľom je zabezpečiť, aby zlyhania úloh odrážali skutočné obmedzenia modelu a úspechy úloh úplné a platné riešenia požiadaviek príkazu. Na kontrolu kvality dát použitých v hodnotení sme vytvorili pipeline zabezpečenia kvality, ktorý posudzuje, či každý dátový bod presne odráža schopnosti modelu.

Úvodný automatizovaný filter kontroluje pokyny zadané modelu, pokusy modelu vyriešiť úlohu a testy použité na hodnotenie týchto pokusov, aby označil pravdepodobne chybné alebo problematické príklady. Tento filter označil 286 potenciálne chybných úloh. Potom sme vykonali hlbšiu kontrolu tejto podmnožiny dvoma spôsobmi: kontrolou agentom pod ľudským dohľadom, ktorá vykonáva rozsiahle overenia pomocou agentov-vyšetrovateľov a končí ľudským rozhodnutím; a kampaňou ľudskej anotácie so skúsenými softvérovými vývojármi.

Každý označený problém auditujú agenti-vyšetrovatelia založení na Codexe, ktorí dostali prístup k repozitáru úlohy a prostrediu. Pomáha im to rozlíšiť primeranú nejednoznačnosť úlohy, ktorú možno často vyriešiť štúdiom okolitého kódu a konvencií repozitára, od skutočnej nedostatočnej špecifikácie. Agent môže spúšťať testy, kontrolovať súbory v repozitári a skúmať pokusy modelu aj ich bežné režimy zlyhania pri danej úlohe. Po niekoľkých nezávislých opakovaniach týchto hlbších auditov výskumník skontroloval zhrnutia, urobil konečné rozhodnutie a označil pravdepodobné problémy.

Súbežne sme na označenej podmnožine spustili kampaň ľudskej anotácie. Spolupracovali sme so skúsenými softvérovými inžiniermi, ktorí boli pred kontrolou úloh vyškolení v cieľoch benchmarku, taxonómii problémov a hraničných prípadoch. Každú úlohu skontrolovalo päť inžinierov.

Recenzenti si najprv vytvorili nezávislý úsudok na základe viditeľného zadania problému, testovacích prípadov a referenčného riešenia považovaného za pravdivé (známeho ako gold patch), až potom použili analýzu pipelineu alebo prepis ako podporný kontext. Recenzenti potom priradili štítok a hodnotenie závažnosti na základe konkrétnych dôkazov a nezhody alebo prípady s nízkou istotou postúpili na ďalšiu kontrolu.

Ľudskí recenzenti označovali úlohy za chybné častejšie než agenti-vyšetrovatelia. Medzi oboma kontrolnými postupmi sa vyskytli aj určité nezhody v kategóriách, no pri žiadnej označenej úlohe nebol najčastejším ľudským štítkom „bez chyby“. Pri kategóriách, ktoré označil agentský pipeline, sa úsudky recenzentov prekrývali v 74 % prípadov.

V porovnaní s agentským pipelineom ľudskí recenzenti častejšie vyberali pre úlohu viacero štítkov, čo naznačuje, že úlohy považovali za chybné viacerými spôsobmi alebo ich nebolo možné jednoznačne zaradiť do jednej kategórie. To naznačuje, že pipeline kombinujúci agenta a recenzenta viedol ku konzervatívnemu štítkovaniu: zachytil rovnaké široké režimy zlyhania, ktoré identifikovali ľudia, no podhodnotil prípady, v ktorých recenzenti videli ďalšie alebo prekrývajúce sa problémy. Najväčší rozdiel bol pri testoch s nízkym pokrytím, ktoré ľudia vybrali ako najčastejší problém pri 9,4 % benchmarku, v porovnaní so 4,1 % z agentského pipelineu.

Problémy, ktoré sme identifikovali, spolu s podobnými prípadmi v SWE-bench Verified zdôrazňujú dôležitosť dôkladnej kontroly benchmarkov. Issues a pull requesty z open-source repozitárov boli pôvodne vytvorené na spoluprácu medzi ľuďmi, často prostredníctvom dlhých výmen medzi správcami a prispievateľmi. V dôsledku toho sa opisy problémov, zlúčený kód a jednotkové testy nie vždy zosúladia do čistých, izolovaných úloh na spoľahlivé hodnotenie modelov. Najmä testy zahrnuté v pull requestoch môžu byť príliš prísne, pretože sú napísané na overenie konkrétnej zmeny, nie na definovanie implementačne nezávislého štandardu riešenia úlohy.

Zároveň sa dnes chyby v hodnoteniach dajú odhaliť ľahšie, než by to bolo ešte pred krátkym časom. Ako sa schopnosti modelov zlepšujú, môžeme tieto modely používať na oveľa hlbšiu a konzistentnejšiu kontrolu príkazov, testov, patchov, stôp a hraničných prípadov, čo pomáha odhaľovať problémy benchmarkov, ktorých hľadanie vo veľkom rozsahu bolo predtým nákladné alebo nepraktické.

Dúfame, že širšia evaluačná komunita vyvinie nové benchmarky vytvorené skúsenými softvérovými vývojármi špecificky na testovanie schopností modelov. Takýto prístup môže zachovať vysokú latku a realizmus, ktoré chceme pri meraní schopností modelov, a umožňuje lepší ľudský dohľad počas celého procesu. Vzhľadom na problémy odhalené v tejto analýze sťahujeme naše skoršie odporúčanie prijať SWE-Bench Pro.

V konečnom dôsledku by evaluačný test mal poskytovať zmysluplný signál prostredníctvom benchmarkov, ktoré sa ťažko obchádzajú, dá sa im ľahko dôverovať a skutočne odrážajú schopnosti alebo zarovnanie modelu. Keďže tieto výsledky ovplyvňujú rozhodnutia OpenAI o nasadení a bezpečnosti, hodnotenia, ktoré sledujeme, musia byť platné a informatívne.