Oddělování signálu od šumu v hodnocení programování

Přesné měření schopností našich modelů je důležité pro rozumná rozhodnutí o nasazení a bezpečnosti, včetně rozhodnutí podle rámce připravenosti⁠(otevře se v novém okně) OpenAI. S každým vydáním modelu uvádíme výsledky v řadě externích i interních benchmarků, abychom sledovali pokrok modelů. Když mají evaluace chyby, které ovlivňují výsledky, mohou vytvářet zkreslený obraz schopností modelů, zkreslit posouzení bezpečnosti a ovlivňovat výzkumné priority.

Nedávno jsme zkoumali, jak jeden z nejpoužívanějších benchmarků pro kódování, SWE-bench Verified, trpěl zásadními problémy v návrhu a kontaminací, a zjistili jsme, že tato evaluace už neposkytuje smysluplný signál o schopnostech ve vývoji softwaru. Tehdy jsme širší komunitu vyzvali k přechodu na SWE-Bench Pro.

SWE-Bench Pro⁠(otevře se v novém okně) byl navržen jako vylepšení SWE-bench Verified: testuje modely na delších horizontech a realističtějších úlohách kódování, aby lépe sledoval schopnosti agentního kódování. Stejně jako v SWE-bench Verified jsou úlohy získávány programem z historie změn funkcí v sadě veřejných a soukromých úložišť. Modely musí implementovat řešení, které projde novými testy dané funkce, aniž by narušilo stávající funkcionalitu. Na veřejné části s 731 úlohami se průkopnické modely během osmi měsíců zlepšily z úspěšnosti 23,3 % na 80,3 %.

Od té doby jsme provedli podobný audit SWE-Bench Pro a datovou sadu jsme zkontrolovali pomocí pipelinu pro analýzu datových bodů. Pipeline kontroloval pokusy modelů o řešení úlohy, metadata úloh a stopy selhání, aby označil pravděpodobné nedostatky evaluace. Každá označená úloha byla poté posouzena v několika průchodech vyšetřovacích agentů a nezávisle zkontrolována pěti zkušenými softwarovými inženýry; neshody byly eskalovány k dalšímu prošetření.

Problémy spadaly především do čtyř kategorií:

• Příliš přísné testy¹ vynucují konkrétní implementační detaily, které nejsou v promptu specifikovány, a tím zneplatňují mnoho funkčně správných odevzdaných řešení.
• Nedostatečně specifikované prompty² vynechávají požadavky, které skryté testy vynucují a které nejsou rozumně odvoditelné.
• Testy s nízkým pokrytím nedostatečně kontrolují požadovanou funkci, takže neúplné opravy mohou projít.
• Zavádějící prompt směruje modely k nesprávnému chování nebo odporuje tomu, co vyžadují testy.

Naše zjištění ukazují, jak obtížné je vytvářet náročné, ale férové benchmarky, a také rostoucí užitečnost agentů pro škálovatelné kontroly kvality dat. S ohledem na tyto výsledky odhadujeme, že přibližně 30 % úloh SWE-bench Pro je chybných, a doporučujeme vývojářům modelů, aby výsledky pečlivě prověřovali.

Naším cílem je zajistit, aby selhání v úlohách odrážela skutečná omezení modelu a úspěchy v úlohách aby odrážely úplná a platná řešení podle požadavků promptu. Abychom zkontrolovali kvalitu dat použitých v evaluaci, vytvořili jsme pipeline zajištění kvality, který posuzuje, zda každý datový bod přesně odráží schopnosti modelu.

Počáteční automatický filtr kontroluje instrukce zadané modelu, pokusy modelu o vyřešení úlohy a testy použité k hodnocení těchto pokusů, aby označil pravděpodobně chybné nebo problematické příklady. Tento filtr označil 286 potenciálně chybných úloh. Poté jsme tuto podmnožinu podrobněji zkontrolovali dvěma způsoby: kontrolou agentem pod dohledem člověka, kde rozsáhlé kontroly provádí vyšetřovací agenti a proces končí posouzením člověkem, a kampaní lidských anotací zkušených softwarových vývojářů.

Každý označený problém auditují vyšetřovací agenti založení na Codexu, kteří dostali přístup k úložišti a prostředí úlohy. To jim pomáhá rozlišit přiměřenou míru nejednoznačnosti úlohy, kterou lze často vyřešit studiem okolního kódu a konvencí úložiště, od skutečné nedospecifikovanosti. Agent může spouštět testy, prohlížet soubory v repozitáři a zkoumat pokusy modelu i jejich běžné režimy selhání u dané úlohy. Po několika nezávislých opakováních těchto hlubších auditů shrnutí zkontroloval výzkumník, který učinil koneční rozhodnutí a označil pravděpodobné problémy.

Souběžně jsme nad označenou podmnožinou spustili kampaň lidských anotací. Spolupracovali jsme se zkušenými softwarovými inženýry, kteří byli před kontrolou úloh vyškoleni v cílech benchmarku, taxonomii problémů a hraničních případech. Každou úlohu zkontrolovalo pět inženýrů.

Recenzenti si nejprve vytvořili nezávislý úsudek na základě viditelné formulace problému, testovacích případů a referenčního řešení ground truth (známého jako gold patch) a teprve poté použili analýzu pipelinu nebo transkript jako podpůrný kontext. Recenzenti poté přiřadili štítek a hodnocení závažnosti podle konkrétních důkazů a eskalovali neshody nebo případy s nízkou jistotou k další kontrole.

Lidští recenzenti označovali úlohy jako chybné častěji než vyšetřovací agenti. Mezi oběma kontrolními postupy panovala také určitá neshoda v kategoriích, ale u žádné označené úlohy nebyl nejčastějším lidským štítkem „není chybné“. U kategorií označených agentním pipelinem se úsudky recenzentů překrývaly v 74 % případů.

Ve srovnání s agentním pipelinem lidští recenzenti také častěji vybírali pro úlohu více štítků, což naznačuje, že podle nich byly úlohy chybné více způsoby nebo nezapadaly čistě do jedné kategorie. To naznačuje, že pipeline kombinující agenta a recenzenta vedl ke konzervativnímu štítkování: zachytil stejné široké režimy selhání, které identifikovali lidé, ale podhodnocoval případy, kdy recenzenti viděli další nebo překrývající se problémy. Největší rozdíl byl u testů s nízkým pokrytím, které lidé vybrali jako nejčastější problém u 9,4 % benchmarku, zatímco agentní pipeline u 4,1 %.

Problémy, které jsme identifikovali, spolu s podobnými případy v SWE-bench Verified zdůrazňují význam důsledné kontroly benchmarků. Issue a pull requesty z open-source úložišť původně vznikaly pro lidskou spolupráci, často prostřednictvím dlouhé komunikace mezi správci a přispěvateli. Popisy problémů, sloučený kód a jednotkové testy proto ne vždy dohromady tvoří čisté, izolované úlohy pro spolehlivé hodnocení modelů. Zejména testy zahrnuté v pull requestech mohou být příliš přísné, protože jsou psány k ověření konkrétní změny, nikoli k definování implementačně neutrálního standardu pro řešení úlohy.

Zároveň je dnes snazší odhalit vady evaluací, než by bylo ještě před nedávnem. Jak se schopnosti modelů zlepšují, můžeme tyto modely používat k mnohem hlubší a konzistentnější kontrole promptů, testů, patchů, stop a hraničních případů, což pomáhá odhalovat problémy benchmarků, které dříve bylo nákladné nebo nepraktické hledat ve velkém měřítku.

Doufáme, že širší evaluační komunita vyvine nové benchmarky vytvořené zkušenými softwarovými vývojáři přímo pro testování schopností modelů. Takový přístup může zachovat vysokou laťku a realističnost, jaké při měření schopností modelů potřebujeme, a zároveň umožňuje lepší lidský dohled nad celým procesem. Vzhledem k problémům odhaleným v této analýze bereme zpět naše dřívější doporučení zavést používání SWE-Bench Pro.

Evaluace by nakonec měla poskytovat smysluplný signál prostřednictvím benchmarků, které je těžké obejít, kterým lze důvěřovat a které skutečně odrážejí schopnosti nebo sladění modelu. Protože tyto výsledky jsou významným vstupem pro rozhodování OpenAI o nasazení a bezpečnosti, musí být evaluace, které sledujeme, validní a informativní.