uutiset

OpenAI mansikkamalli on taas viivästynyt Mikä on SWE-bench Verified, joka julkaistaan ​​aikaisin aamulla?

2024-08-14

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Koneen sydänraportti

Toimittaja: Zhang Qian, Xiaozhou

Joku sanoi: "Odotimme mansikoita, mutta he julkaisivat lehtikaalin. Katsotaan mihin tätä "kaalia" käytetään.

Suurten mallien ohjelmointiominaisuudet ovat aina herättäneet paljon huomiota, ja supervoimakkaan tekoälyohjelmoijan Devinin ilmestyminen on nostanut aiheen "Voiko tekoäly korvata ohjelmoijat" etualalle. Äskettäin Devin on myös tuonut markkinoille uuden vastustajan - start-up-yrityksen Cosinen käynnistämän itsenäisen tekoälyohjelmoijan.Genie. Yhtiön mukaan Genie päihitti helposti Devinin saaden 30 % kolmannen osapuolen vertailuindeksin SWE-penkkiin, kun taas Devin sai vain 13,8 %.

Tämä SWE-Bench on vertailutietojoukko, jota käytetään arvioimaan LLM:n kykyä ratkaista todellisia ohjelmistoongelmia GitHubissa. Se kerää 2 294 Issue-Pull Request -paria 12 suositusta Python-tietovarastosta. Testauksen aikana LLM saa koodikannan ja ongelman kuvauksen ja luo sitten korjaustiedoston ongelmassa kuvatun ongelman ratkaisemiseksi. Tätä tietojoukkoa on käytetty laajalti tekoälyn ohjelmointiominaisuuksien arvioinnissa.

Tekoälyohjelmointiominaisuuksien kehittyessä myös tämä vertailukohta kehittyy. Aikaisin tänä aamuna verkossa raportoitu OpenAI "Strawberry" -malli viivästyi jälleen, mutta OpenAI julkaisi jotain uutta, joka on parannettu versio SWE-Benchistä - SWE-bench Verified.

OpenAI huomautti, että alkuperäisessä SWE-penkissä oli joitain ongelmia, jotka saattoivat aiheuttaa mallin itsenäisten ohjelmistokehitysominaisuuksien aliarvioinnin. Siksi parannusprosessin aikana he tekivät yhteistyötä SWE-Benchin alkuperäisen kirjoittajan kanssa suorittaakseen manuaalisen seulonnan ja parannukset varmistaakseen, että yksikkötestin laajuus oli asianmukainen ja ongelman kuvaus selkeä.

Uusissa SWE-bench Verified -testeissä monet AI-ohjelmointiagentit saivat aiempaa paremmat pisteet. Niiden joukossa UIUC:n Agentless-ratkaisu jopa kaksinkertaisti pisteet OpenAI:n mielestä tämän todistavan, että aiemmassa vertailussa on tekoälyn ohjelmointiominaisuuksien aliarviointi.

Mutta "Strawberrya" katsoville nettimiehille ympäri maailmaa tämä julkaisu on edelleen liian järjetön. Joku sanoi: "Odotimme mansikoita, mutta he vapauttivat lehtikaalin."



Taustatietoa SWE-penkistä

Jokainen SWE-penkkitestisarjan esimerkki luotiin GitHubin 12 avoimen lähdekoodin Python-koodivaraston ratkaistavasta GitHub-ongelmasta. Jokaiseen näytteeseen liittyy vetopyyntö (PR), joka sisältää ratkaisukoodin ja yksikkötestejä koodin oikeellisuuden tarkistamiseksi. Näitä yksikkötestejä kutsutaan FAIL_TO_PASS-testeiksi, koska ne epäonnistuvat ennen PR:n ratkaisukoodin lisäämistä ja läpäisevät sen lisäämisen jälkeen. Jokainen näyte sisältää myös PASS_TO_PASS-testejä, jotka läpäisevät ennen PR:n yhdistämistä ja sen jälkeen sen tarkistamiseksi, rikkooko PR muita koodikannan toimintoja, jotka eivät liity ongelmaan.

SWE-penkissä AI-agentti saa alkuperäisen tekstin GitHub-ongelmasta, joka on ongelman ilmaus, ja hänellä on pääsy koodipohjaan. Näiden tietojen perusteella agentin on muokattava koodikannan tiedostoja ongelman ratkaisemiseksi.

Tekoälyagentin tekemät muokkaukset arvioidaan suorittamalla FAIL_TO_PASS- ja PASS_TO_PASS-testit. Jos FAIL_TO_PASS-testi läpäisee, se tarkoittaa, että editori korjasi ongelman. Jos PASS_TO_PASS-testi läpäisee, se tarkoittaa, että muokkaus ei rikkonut koodipohjan ylimääräisiä osia. Alkuperäisen GitHub-ongelman ratkaisemiseksi täysin molempien testisarjojen on läpäistävä.

Kolme parannussuuntaa SWE-penkin kestävyyden ja luotettavuuden parantamiseksi

SWE-penkin kestävyyden ja luotettavuuden parantamiseksi. Kehitystiimi määritteli kolme pääasiallista parantamissuuntaa:

  • Yksikkötestit, joita käytetään ratkaisun oikeellisuuden arvioimiseen, ovat usein liian tarkkoja eivätkä toisinaan ole edes oleellisia ongelman kannalta. Tämä voi johtaa oikean ratkaisun hylkäämiseen.
  • Ongelmakuvaukset monissa näytteissä eivät olleet riittävän selkeitä, mikä johti epäselvyyteen siitä, mikä ongelma oli ja miten se pitäisi ratkaista.
  • SWE-penkkikehitysympäristön luominen agentille on joskus vaikeaa luotettavasti, mikä voi vahingossa aiheuttaa yksikkötestien epäonnistumisen ratkaisusta riippumatta. Tässä tapauksessa täysin pätevä ratkaisu voidaan arvioida virheelliseksi.

SWE-penkki Verified

Näiden ongelmien ratkaisemiseksi OpenAI käynnisti ammattimaisten ohjelmistokehittäjien manuaalisen huomautuskampanjan, joka seuloi jokaisen SWE-penkkitestisarjan näytteen varmistaakseen, että yksikkötestit olivat asianmukaisesti rajattuja ja ongelmakuvaukset selkeitä ja yksiselitteisiä.

Yhdessä SWE-benchin tekijöiden kanssa he julkaisivat SWE-bench Verified:n osajoukon alkuperäisestä SWE-penkin testisarjasta, joka sisältää 500 näytettä, jotka ihmisen annotaattorit ovat tarkistaneet. Tämä versio korvaa alkuperäiset SWE-penkki ja SWE-penkki Lite testisetit. Lisäksi he julkaisevat ihmismerkintöjä kaikille SWE-penkkitestinäytteille.

He tekivät myös yhteistyötä SWE-penkin tekijöiden kanssa kehittääkseen SWE-penkkiin uuden arviointityökalun, joka käyttää konttimuotoista Docker-ympäristöä tehdäkseen arvioinnista SWE-penkillä helpompaa ja luotettavampaa.

  • Työkalun osoite: https://github.com/princeton-nlp/SWE-bench/tree/main/docs/20240627_docker

Parannusmenetelmä

OpenAI työskenteli 93 Python-kokemuksen omaavan ohjelmistokehittäjän kanssa seuloakseen manuaalisesti SWE-penkkinäytteitä ja kommentoidakseen 1699 satunnaista näytettä SWE-penkkitestisarjassa. Lopulta saatiin SWE-penkki Verified.

Heidän lähestymistapansa on merkitä näytteet SWE-penkkitestisarjaan testin oikeudenmukaisuuden ja tarkkuuden varmistamiseksi. Tarkemmin sanottuna ne keskittyvät kahteen avainkohtaan: ensinnäkin sen arvioimiseen, onko ongelman kuvaus riittävän yksityiskohtainen, jotta liian epämääräinen kuvaus ei aiheuta epäreilua testausta, toiseksi tarkistaa, suodattaako FAIL_TO_PASS-yksikkötesti virheellisesti kelvolliset ratkaisut.

Jokaisella merkintäehdolla on tunniste välillä [0, 1, 2, 3], jonka vakavuus kasvaa. Tarrat 0 ja 1 ovat vähäisiä, ja ne osoittavat, että näyte on jollakin tavalla riittämätön ja se on hävitettävä.

Lisäksi OpenAI arvioi kunkin näytteen vaikeuden pyytämällä annotaattoreita arvioimaan, kuinka kauan kehittäjillä kestäisi päättää ratkaisusta ja toteuttaa se, olettaen, että näyte on ongelmaton. Lopuksi OpenAI tarjoaa vapaamuotoisen syöttövaihtoehdon, jolla voit merkitä kaikki muut näytteen tärkeimmät ongelmat.

Rakentaakseen SWE-bench Verifiedin OpenAI suodattaa pois kaikki näytteet alkuperäisestä testijoukosta ongelmailmoituksella tai FAIL_TO_PASS-yksikkötestin vakavuusasteella 2 tai enemmän ja suodattaa myös kaikki näytteet, joissa on muita vakavia ongelmia.

Merkitse tulokset

Uusien standardien mukaan suuri osa alkuperäisen SWE-penkin näytteistä on pätemättömiä. Kuten kuvasta näkyy, 38,3 % näytteistä merkittiin, koska ongelmailmoitus ei ollut tarpeeksi selkeä, ja 61,1 %, koska yksikkötestit saattoivat epäoikeudenmukaisesti merkitä kelvollisia ratkaisuja virheellisiksi (vakavuus 2, 3 Kaksi tasoa lasketaan yhteen) . Kaiken kaikkiaan heidän huomautusprosessinsa johti siihen, että 68,3 % SWE-penkkinäytteistä suodatettiin pois epäselvien ongelmailmoitusten, epäreilujen yksikkötestien tai muiden ongelmien vuoksi.







Alla olevassa kuvassa verrataan alkuperäisen SWE-penkkitietojoukon ja uuden SWE-bench Verified -tietojoukon vaikeusjakaumaa. He arvioivat SWE-penkin vaikeusjakauman 1699 näytteen satunnaisen osajoukon perusteella.

Kuten kuvasta näkyy, alkuperäisessä SWE-penkkitietojoukossa useimpien (77,8 %) näytteiden arvioitu valmistumisaika on kokeneelle ohjelmistosuunnittelijalle alle yksi tunti työtä. SWE-bench Lite ja uusi SWE-bench Verified -tietojoukko lisäävät tätä osuutta entisestään, sillä alle 10 %:n ongelmista ratkaiseminen kestää yli tunnin. Tämän muutoksen taustalla olevat mekanismit ovat kuitenkin melko erilaiset: SWE-bench Lite on alkuperäisen tietojoukon aliotos, joka helpottaa vertailua, kun taas SWE-bench Verified yrittää poistaa mahdottomia ominaisuuksia tietojoukon näytteestä.



Jokaisen edustajan suorituskyky SWE-penkillä Verified

Uudessa SWE-bench Verified -tietojoukossa kehitystiimi testasi GPT-4o:n suorituskykyä käyttämällä useita avoimen lähdekoodin telineitä, jotka menestyivät hyvin alkuperäisessä SWE-penkin tulostaulukossa.

Havaittiin, että GPT-4o:n suorituskyky parhaiten suoriutuneella telineellä saavutti 33,2 % SWE-penkissä Verified, mikä on yli kaksinkertainen alkuperäisen SWE-penkin 16 % pistemäärään verrattuna. Kaiken kaikkiaan tämä vahvistaa OpenAI:n alkuperäisen epäilyn, että alkuperäinen SWE-penkki aliarvioi agentin kyvyt.

On syytä huomata, että hyppy SWE-bench Litestä SWE-bench Verifiediin ei ole niin ilmeinen, koska suodatuksen jälkeen SWE-bench Lite on jo helpompi kuin koko tietojoukko.



Vaikeuden mukaan ositettu suorituskykyanalyysi

Suorituskyvyn parantuminen SWE-bench Verified -testillä arvioituna voi osittain johtua siitä, että testinäytteiden jakautuminen on vinossa kohti yksinkertaisempia näytteitä.

OpenAI tutki tätä piirtämällä suorituskykyä vaikeusasteittain. Jos uusi tietojoukko yksinkertaisesti muuttaa vaikeusjakaumaa niin, että se sisältää helpompia näytteitä, ositettu suorituskyky ei muutu kunkin luokan sisällä, kuten tapahtuu alkuperäisestä SWE-penkistä SWE-penkki Liteen.

Sitä vastoin OpenAI havaitsi, että agentin suorituskyky parani kaikissa vaikeusluokissa siirryttäessä SWE-bench Verified -järjestelmään, mikä vastaa odotettua vaikutusta mahdottomien näytteiden poistamiseen kaikista luokista sen sijaan, että vain siirrettäisiin Poista vaikeat näytteet.



Viitelinkki: https://openai.com/index/introducing-swe-bench-verified/