Signaalin erottaminen kohinasta koodausarvioinneissa

Malliemme kyvykkyyksien tarkka mittaaminen on tärkeää perusteltujen käyttöönotto- ja turvallisuuspäätösten kannalta, myös OpenAI:n Valmiuskehyksen⁠(avautuu uudessa ikkunassa) mukaisissa päätöksissä. Jokaisen mallijulkaisun yhteydessä raportoimme tuloksia useista ulkoisista ja sisäisistä vertailuarvioinneista mallien kehityksen seuraamiseksi. Kun arvioinneissa on tuloksiin vaikuttavia puutteita, ne voivat antaa väärän kuvan kyvykkyyksistä, vääristää turvallisuusperusteluja ja vaikuttaa tutkimusprioriteetteihin.

Tutkimme hiljattain, miten yhdessä käytetyimmistä koodausvertailuista, SWE-bench Verifiedissä, oli perustavanlaatuisia suunnittelu- ja kontaminaatio-ongelmia, ja havaitsimme, ettei arviointi enää tuottanut merkityksellistä signaalia ohjelmistokehityksen kyvykkyyksistä. Tuolloin kannustimme laajempaa yhteisöä siirtymään SWE-Bench Prohon.

SWE-Bench Pro⁠(avautuu uudessa ikkunassa) suunniteltiin parantamaan SWE-bench Verifiediä testaamalla malleja pidemmillä aikajänteillä ja realistisemmilla koodaustehtävillä, jotta agenttipohjaisen koodauksen kyvykkyyksiä voitaisiin seurata paremmin. Kuten SWE-bench Verifiedissä, tehtävät hankitaan ohjelmallisesti joukon julkisia ja yksityisiä repositorioita koskevasta ominaisuusmuutosten historiasta. Mallien on toteutettava ratkaisu, joka läpäisee ominaisuuden uudet testit rikkomatta olemassa olevaa toiminnallisuutta. 731 tehtävän julkisessa osajoukossa edistyneiden mallien läpäisyaste parani kahdeksassa kuukaudessa 23,3 prosentista 80,3 prosenttiin.

Olemme sittemmin tehneet samankaltaisen auditoinnin SWE-Bench Prolle ja tarkastelleet datajoukkoa datapisteiden analyysiputken avulla. Putki tarkasteli mallin tehtäväyrityksiä, tehtävän metatietoja ja epäonnistumisjälkiä merkitäkseen todennäköiset arviointipuutteet. Jokainen merkitty tehtävä arvioitiin sen jälkeen useiden tutkija-agenttikierrosten avulla ja viiden kokeneen ohjelmistoinsinöörin riippumattomassa arvioinnissa; erimielisyydet eskaloitiin lisätutkintaan.

Ongelmat jakautuivat pääosin neljään luokkaan:

• Liian tiukat testit¹ pakottavat noudattamaan tiettyjä toteutuksen yksityiskohtia, joita ei ole määritelty kehotteessa, ja mitätöivät monia toiminnallisesti oikeita ratkaisuja.
• Puutteellisesti määritellyt kehotteet² jättävät pois vaatimuksia, joita piilotetut testit edellyttävät ja joita ei voi kohtuudella päätellä.
• Heikon kattavuuden testit tarkistavat pyydetyn ominaisuuden liian suppeasti, joten puutteelliset korjaukset voivat mennä läpi.
• Harhaanjohtava kehote ohjaa malleja väärään toimintaan tai on ristiriidassa testien vaatimusten kanssa.

Havaintomme korostavat, miten vaikeaa on koota vaikeita mutta reiluja vertailuarviointeja, sekä agenttien kasvavaa hyötyä skaalautuvissa datan laatutarkistuksissa. Näiden tulosten perusteella arvioimme, että noin 30 % SWE-bench Pron tehtävistä on rikkinäisiä, ja suosittelemme mallikehittäjiä tarkastelemaan tuloksia huolellisesti.

Tavoitteemme on varmistaa, että tehtävien epäonnistumiset heijastavat todellisia mallin rajoituksia ja tehtävien onnistumiset täydellisiä ja päteviä ratkaisuja kehotteen vaatimuksiin. Arvioinnissa käytetyn datan laadun tarkistamiseksi loimme laadunvarmistusputken, joka arvioi, kuvastaako kukin datapiste tarkasti mallin kyvykkyyksiä.

Alustava automaattinen suodatin tarkastelee mallille annettuja ohjeita, mallin yrityksiä ratkaista tehtävä sekä testejä, joilla nämä yritykset arvostellaan, ja merkitsee todennäköisesti rikkinäiset tai ongelmalliset esimerkit. Tämä suodatin merkitsi 286 mahdollisesti rikkinäistä tehtävää. Teimme sitten tästä osajoukosta syvemmän tarkastelun kahdella tavalla: ihmisen valvoman agenttiarvioinnin, jossa tutkija-agentit tekevät laajoja tarkistuksia ja ihminen antaa lopullisen arvion, sekä ihmisten annotointikampanjan, jossa työskenteli kokeneita ohjelmistokehittäjiä.

Jokainen merkitty ongelma auditoidaan Codex-pohjaisilla tutkija-agenteilla, joille annettiin pääsy tehtävän repositorioon ja ympäristöön. Tämä auttaa niitä erottamaan kohtuullisen tehtävän monitulkintaisuuden, joka voidaan usein ratkaista tutkimalla läheistä koodia ja repositorion käytäntöjä, aidosta alimäärityksestä. Agentti voi ajaa testejä, tarkastaa repositorion tiedostoja sekä tutkia mallin yrityksiä ja niiden yleisiä epäonnistumistapoja tehtävässä. Useiden riippumattomien syvempien auditointien jälkeen tutkija kävi yhteenvedot läpi, teki lopullisen arvion ja merkitsi todennäköiset ongelmat.

Samanaikaisesti toteutimme ihmisten annotointikampanjan merkitylle osajoukolle. Työskentelimme kokeneiden ohjelmistoinsinöörien kanssa, jotka koulutettiin vertailuarvioinnin tavoitteisiin, ongelmataksonomiaan ja reunatapauksiin ennen tehtävien arviointia. Jokaisen tehtävän arvioi viisi insinööriä.

Arvioijat muodostivat riippumattoman arvion näkyvän ongelmankuvauksen, testitapausten ja todellisen oikean referenssiratkaisun (ns. gold patch) perusteella ennen kuin käyttivät putkianalyysiä tai transkriptiota tukevana kontekstina. Tämän jälkeen arvioijat antoivat tunnisteen ja vakavuusluokituksen konkreettisen näytön perusteella sekä eskaloivat erimielisyydet tai matalan varmuuden tapaukset lisäarviointiin.

Ihmisarvioijat merkitsivät tehtäviä rikkinäisiksi todennäköisemmin kuin tutkija-agentit. Kahden arviointipolun välillä oli myös jonkin verran erimielisyyttä luokista, mutta yhdessäkään merkityssä tehtävässä ”ei rikkinäinen” ei ollut yleisin ihmisten antama tunniste. Agenttiputken merkitsemissä luokissa arvioijien arviot menivät päällekkäin 74 prosentissa tapauksista.

Agenttiputkeen verrattuna ihmisarvioijat valitsivat myös todennäköisemmin useita tunnisteita yhdelle tehtävälle, mikä osoittaa, että heidän mukaansa tehtävät olivat rikkinäisiä useilla tavoilla tai eivät sopineet selkeästi yhteen luokkaan. Tämä viittaa siihen, että agentti- ja arvioijaputki tuotti konservatiivisia merkintöjä: se tavoitti samat laajat epäonnistumistavat, jotka ihmiset tunnistivat, mutta alilaski tapaukset, joissa arvioijat näkivät lisäongelmia tai päällekkäisiä ongelmia. Suurin ero oli heikon kattavuuden testeissä: ihmiset valitsivat ne yleisimmäksi ongelmaksi 9,4 prosentissa vertailuarvioinnista, kun agenttiputken osuus oli 4,1 %.

Tunnistamamme ongelmat yhdessä SWE-bench Verifiedissä havaittujen samankaltaisten tapausten kanssa korostavat vertailuarviointien perusteellisen tarkistamisen tärkeyttä. Avoimen lähdekoodin repositorioiden issuet ja pull-pyynnöt luotiin alun perin ihmisten väliseen yhteistyöhön, usein ylläpitäjien ja kontribuuttorien pitkien keskustelujen kautta. Tämän vuoksi ongelmankuvaukset, yhdistetty koodi ja yksikkötestit eivät aina sovi yhteen muodostaakseen siistejä, erillisiä tehtäviä mallien luotettavaan arviointiin. Erityisesti pull-pyyntöihin sisältyvät testit voivat olla liian tiukkoja, koska ne on kirjoitettu varmistamaan tietty muutos eikä määrittelemään toteutuksesta riippumatonta standardia tehtävän ratkaisemiseen.

Samalla arviointipuutteet on nyt helpompi havaita kuin vielä lyhyenkin aikaa sitten. Mallien kyvykkyyksien parantuessa voimme käyttää näitä malleja kehotteiden, testien, korjausten, jälkien ja reunatapausten tarkastamiseen paljon syvällisemmin ja johdonmukaisemmin, mikä auttaa nostamaan esiin vertailuarviointien ongelmia, joiden löytäminen laajassa mittakaavassa oli aiemmin kallista tai epäkäytännöllistä.

Toivomme, että laajempi arviointiyhteisö kehittää uusia vertailuarviointeja, jotka kokeneet ohjelmistokehittäjät rakentavat nimenomaan mallien kyvykkyyksien testaamiseen. Tämä lähestymistapa voi säilyttää korkean vaatimustason ja realismin, joilla haluamme mitata mallien kyvykkyyksiä, ja mahdollistaa paremman ihmisen valvonnan koko prosessin ajan. Tässä analyysissä paljastuneiden ongelmien vuoksi perumme aiemman suosituksemme ottaa SWE-Bench Pro käyttöön.

Viime kädessä arvioinnin pitäisi tuottaa merkityksellistä signaalia vertailuarvioinneilla, joita on vaikea manipuloida, joihin on helppo luottaa ja jotka todella kuvastavat mallin kyvykkyyttä tai linjassaoloa. Koska nämä tulokset vaikuttavat OpenAI:n käyttöönotto- ja turvallisuuspäätöksiin, seuraamiemme arviointien on oltava päteviä ja informatiivisia.