Jel és zaj szétválasztása kódolási értékelésekben

Modelljeink képességeinek pontos mérése fontos a megalapozott bevezetési és biztonsági döntésekhez, többek között az OpenAI Felkészültségi keretrendszere⁠(új ablakban nyílik meg) szerinti döntésekhez. Minden modellkiadásnál több külső és belső benchmark eredményeit közöljük, hogy nyomon kövessük a modellek fejlődését. Ha az értékelések eredményeket befolyásoló hibákat tartalmaznak, hamis képet adhatnak a képességekről, torzíthatják a biztonsági érveket és befolyásolhatják a kutatási prioritásokat.

Nemrég megvizsgáltuk, hogy az egyik legszélesebb körben használt kódolási benchmark, a SWE-bench Verified alapvető tervezési és kontaminációs problémákkal küzdött, és azt találtuk, hogy az értékelés már nem adott érdemi jelzést a szoftverfejlesztési képességekről. Akkor arra ösztönöztük a tágabb közösséget, hogy váltson a SWE-Bench Pro használatára.

A SWE-Bench Pro⁠(új ablakban nyílik meg) célja az volt, hogy a SWE-bench Verifiednél hosszabb időtávú és valósághűbb kódolási feladatokkal jobban mérje az ügynökalapú programozási képességeket. A SWE-bench Verifiedhez hasonlóan a feladatok nyilvános és privát adattárak funkcióváltozásainak történetéből, programozottan származnak. A modelleknek olyan megoldást kell megvalósítaniuk, amely átmegy az adott funkció új tesztjein anélkül, hogy elrontaná a meglévő működést. A 731 feladatból álló nyilvános részen az élvonalbeli modellek átmenési aránya nyolc hónap alatt 23,3%-ról 80,3%-ra nőtt.

Azóta hasonló auditot végeztünk a SWE-Bench Prón is, az adatkészletet adatpontonkénti elemzési folyamattal vizsgálva. A folyamat a modell feladatmegoldási kísérleteit, a feladat metaadatait és a hibanyomokat vizsgálta, hogy megjelölje a valószínű értékelési hibákat. Ezután minden megjelölt feladatot több vizsgáló ügynökös körben értékeltünk, majd öt tapasztalt szoftvermérnök függetlenül is felülvizsgált; a nézeteltéréseket további vizsgálatra továbbítottuk.

A problémák főként négy kategóriába estek:

• A túl szigorú tesztek¹ az utasításban nem szereplő konkrét megvalósítási részleteket kényszerítenek ki, így sok funkcionálisan helyes beküldést érvénytelenítenek.
• Az aluldefiniált utasítások² kihagynak olyan követelményeket, amelyeket a rejtett tesztek kikényszerítenek, és amelyek észszerűen nem következtethetők ki.
• Az alacsony lefedettségű tesztek nem ellenőrzik eléggé a kért funkciót, ezért hiányos javítások is átmehetnek.
• A félrevezető utasítás rossz viselkedés felé tereli a modelleket, vagy ellentmond annak, amit a tesztek elvárnak.

Eredményeink rámutatnak, milyen nehéz nehéz, de tisztességes benchmarkokat összeállítani, és hogy az ügynökök egyre hasznosabbak a skálázható adatminőségi ellenőrzésekben. Ezek alapján becslésünk szerint a SWE-bench Pro feladatainak ~30%-a hibás, ezért azt javasoljuk, hogy a modellfejlesztők körültekintően vizsgálják az eredményeket.

Célunk biztosítani, hogy a feladatbeli kudarcok valódi modellkorlátokat, a sikerek pedig az utasítás követelményeinek teljes és érvényes megoldását tükrözzék. Az értékelésben használt adatok minőségének ellenőrzésére minőségbiztosítási folyamatot hoztunk létre annak megítélésére, hogy minden adatpont pontosan tükrözi-e a modell képességeit.

Egy kezdeti automatizált szűrő áttekinti a modellnek adott utasításokat, a modell feladatmegoldási kísérleteit és az ezek pontozásához használt teszteket, hogy megjelölje a valószínűleg hibás vagy problémás példákat. Ez a szűrő 286 potenciálisan hibás feladatot jelölt meg. Ezután ezt a részhalmazt két módon vizsgáltuk mélyebben: ember által felügyelt ügynökös felülvizsgálattal, amely kiterjedt ellenőrzéseket végez vizsgáló ügynökökkel és végső emberi döntéssel; valamint tapasztalt szoftverfejlesztőkkel folytatott emberi annotációs kampánnyal.

Minden megjelölt problémát Codex-alapú vizsgáló ügynökök auditálnak, amelyek hozzáférést kaptak a feladat adattárához és környezetéhez. Ez segít megkülönböztetni az észszerű feladatbeli kétértelműséget, amely gyakran feloldható a közeli kód és az adattári konvenciók tanulmányozásával, a valódi aluldefiniáltságtól. Az ügynök futtathat teszteket, megvizsgálhat fájlokat a repóban, és feltárhatja a modell próbálkozásait és azok gyakori hibamódjait a feladaton. A mélyebb auditok több független ismétlése után egy kutató áttekintette az összefoglalókat, végső döntést hozott, és címkézte a valószínű problémákat.

Ezzel párhuzamosan emberi annotációs kampányt futtattunk a megjelölt részhalmazon. Tapasztalt szoftvermérnökökkel dolgoztunk, akik a feladatok áttekintése előtt képzést kaptak a benchmark céljairól, a problémataxonómiáról és a határesetekről. Minden feladatot öt mérnök vizsgált felül.

A felülvizsgálók a látható feladatleírás, a tesztesetek és a referencia-megoldás (az úgynevezett arany javítás) alapján alakítottak ki független ítéletet, mielőtt támogató kontextusként felhasználták volna a folyamat elemzését vagy az átiratot. Ezután konkrét bizonyítékok alapján címkét és súlyossági besorolást adtak, a nézeteltéréseket vagy alacsony bizalmú eseteket pedig további felülvizsgálatra továbbították.

Az emberi felülvizsgálók nagyobb valószínűséggel jelöltek hibásnak feladatokat, mint a vizsgáló ügynökök. A két felülvizsgálati út között kategóriákban is volt némi eltérés, de egyetlen megjelölt feladatnál sem a „nem hibás” volt a leggyakoribb emberi címke. Az ügynökös folyamat által megjelölt kategóriákban a felülvizsgálók ítéletei az esetek 74%-ában átfedtek.

Az ügynökös folyamathoz képest az emberi felülvizsgálók gyakrabban választottak több címkét egy feladathoz, jelezve, hogy a feladatok több módon is hibásak voltak, vagy nem illettek tisztán egyetlen kategóriába. Ez arra utal, hogy az ügynök-plusz-felülvizsgáló folyamat konzervatív címkézést eredményezett: ugyanazokat a tág hibamódokat ragadta meg, amelyeket az emberek azonosítottak, de alulszámolta azokat az eseteket, ahol a felülvizsgálók további vagy átfedő problémákat láttak. A legnagyobb különbség az alacsony lefedettségű teszteknél volt: ezt az emberek a benchmark 9,4%-ánál választották leggyakoribb problémának, szemben az ügynökös folyamat 4,1%-ával.

Az általunk azonosított problémák, valamint a SWE-bench Verified hasonló esetei rávilágítanak a benchmarkok alapos ellenőrzésének fontosságára. A nyílt forráskódú adattárak issue-it és pull requestjeit eredetileg emberi együttműködésre hozták létre, gyakran karbantartók és közreműködők hosszú egyeztetései során. Emiatt a problémaleírások, az összevont kód és az egységtesztek nem mindig állnak össze tiszta, elkülönített feladatokká a modellek megbízható értékeléséhez. Különösen a pull requestekben szereplő tesztek lehetnek túl szigorúak, mert egy konkrét változás validálására írták őket, nem pedig a feladat megoldásának megvalósításfüggetlen szabványaként.

Ugyanakkor az értékelési hibák ma könnyebben észlelhetők, mint akár rövid idővel ezelőtt lettek volna. A modellképességek javulásával ezeket a modelleket sokkal mélyebben és következetesebben használhatjuk utasítások, tesztek, javítások, nyomok és határesetek vizsgálatára, így felszínre kerülhetnek olyan benchmarkhibák, amelyeket korábban drága vagy gyakorlatilag lehetetlen volt nagy léptékben megtalálni.

Reméljük, hogy a tágabb értékelési közösség új, tapasztalt szoftverfejlesztők által kifejezetten a modellképességek tesztelésére készített benchmarkokat fejleszt. Ez a megközelítés megőrizheti azt a magas mércét és valósághűséget, amellyel a modellképességeket mérni szeretnénk, és jobb emberi felügyeletet tesz lehetővé a teljes folyamatban. Az elemzésben feltárt problémák miatt visszavonjuk korábbi ajánlásunkat a SWE-Bench Pro bevezetésére.

Végső soron egy értékelésnek olyan benchmarkokon keresztül kell érdemi jelzést adnia, amelyeket nehéz kijátszani, könnyű megbízhatónak tekinteni, és valóban tükrözik a modell képességét vagy igazodását. Mivel ezek az eredmények az OpenAI bevezetési és biztonsági döntéseit tájékoztatják, az általunk követett értékeléseknek érvényesnek és informatívnak kell lenniük.