Presentem SWE-bench Verified

Actualitzat el 24 de febrer de 2025

Com a part del nostre Entorn de treball de preparació⁠, OpenAI desenvolupa una sèrie de mètriques per fer el seguiment, avaluar i preveure la capacitat dels models d'actuar de manera autònoma. La capacitat de completar autònomament tasques d'enginyeria de programari és un component clau del nostre nivell de risc mitjà dins de la categoria de risc d'Autonomia del model. Avaluar aquestes capacitats és difícil per la complexitat de les tasques d'enginyeria de programari, la dificultat d'avaluar amb precisió el codi generat i el repte de simular escenaris de desenvolupament del món real. Per això, el nostre enfocament de Preparedness també ha d'implicar un examen acurat de les mateixes avaluacions, per reduir el potencial d'infraestimar o sobreestimar el rendiment en categories de risc importants.

Una de les suites d'avaluació més populars per a l'enginyeria de programari és SWE-bench⁠(s'obre en una finestra nova)¹—un benchmark per avaluar la capacitat dels grans models de llenguatge (LLM) de resoldre problemes de programari del món real extrets de GitHub. El benchmark consisteix a donar als agents un repositori de codi i una descripció del problema, i plantejar-los el repte de generar un pedaç que resolgui el problema descrit. Els agents de programació han avançat de manera impressionant a SWE-bench: segons el rànquing de SWE-bench⁠(s'obre en una finestra nova), a 5 d'agost de 2024, els agents amb millor puntuació obtenien un 20% a SWE-bench i un 43% a SWE-bench Lite.

Les nostres proves van identificar algunes tasques de SWE-bench que poden ser difícils o impossibles de resoldre, fet que porta SWE-bench a infraestimar de manera sistemàtica les capacitats autònomes d'enginyeria de programari dels models. Hem col·laborat amb els autors de SWE-bench per abordar aquests problemes en una nova versió del benchmark que hauria de proporcionar avaluacions més precises.

Cada mostra del conjunt de prova de SWE-bench es crea a partir d'una incidència resolta de GitHub en un de 12 repositoris Python de codi obert a GitHub. Cada mostra té associada una sol·licitud d'extracció (PR), que inclou tant el codi de la solució com proves unitàries per verificar la correcció del codi. Aquestes proves unitàries fallen abans d'afegir el codi de la solució de la PR, però passen després, i per això s'anomenen proves FAIL_TO_PASS. Cada mostra també té associades proves PASS_TO_PASS, que passen tant abans com després que la PR es fusioni, i s'utilitzen per comprovar que la PR no ha trencat funcionalitats existents no relacionades del codi base. 

Per a cada mostra de SWE-bench, als agents se'ls proporciona el text original de la incidència de GitHub, conegut com a enunciat del problema, i se'ls dona accés al codi base. A partir d'això, els agents han d'editar els fitxers del codi base per resoldre la incidència. Les proves no es mostren a l'agent.

Una edició proposada s'avalua executant tant les proves FAIL_TO_PASS com les PASS_TO_PASS. Si les proves FAIL_TO_PASS passen, això vol dir que l'edició resol la incidència. Si les proves PASS_TO_PASS passen, aleshores l'edició no ha trencat involuntàriament seccions no relacionades del codi base. Tots dos conjunts de proves han de passar perquè l'edició resolgui completament la incidència original de GitHub.

Atesa la rellevància potencial de SWE-bench per a l'Entorn de treball de preparació, el nostre objectiu era trobar maneres de millorar la robustesa i la fiabilitat del benchmark. Vam identificar tres grans àrees de millora²: 

1. Les proves unitàries utilitzades per avaluar la correcció d'una solució sovint són massa específiques i, en alguns casos, fins i tot no tenen relació amb la incidència. Això pot fer que es rebutgin solucions correctes. 
2. Moltes mostres tenen una descripció de la incidència poc especificada, cosa que genera ambigüitat sobre quin és el problema i com s'hauria de resoldre.
3. De vegades és difícil configurar de manera fiable els entorns de desenvolupament de SWE-bench per als agents, cosa que provoca involuntàriament que les proves unitàries fallin independentment de la solució. En aquests casos, solucions perfectament vàlides es podrien qualificar d'incorrectes.

A continuació es mostra un exemple que il·lustra el primer d'aquests problemes.

La mostra de SWE-bench scikit-learn__scikit-learn-14520 encarrega a un agent resoldre una incidència al repositori scikit-learn⁠(s'obre en una finestra nova). Aquest enunciat del problema informa que un usuari podia especificar l'argument copy d'una funció, però que la biblioteca l'ignorava (el comportament, en canvi, està codificat de manera fixa dins de la funció):

Un agent que abordés el problema anterior primer hauria de fer front a l'ambigüitat sobre si el comportament de la funció és l'esperat o un error, i després fer canvis al codi base per resoldre el problema. Segons la configuració de SWE-bench, qualsevol solució que proposi l'agent ha de passar després la prova següent, extreta de la PR que originalment va resoldre el problema⁠(s'obre en una finestra nova):

Aquesta prova comprova explícitament que la solució ha de generar un DeprecationWarning sempre que s'utilitzi el paràmetre copy, tot i que l'enunciat original del problema al text de la incidència de més amunt no transmet aquest requisit. A més, encara que l'agent s'adonés que s'hauria de generar un DeprecationWarning, la prova també exigeix que l'agent coincideixi exactament amb el missatge de desús, al qual només es va arribar després d'alguna discussió a la PR, a la qual l'agent no té accés.

Tingueu en compte que a l'agent només se li dona la descripció del problema del text principal de la incidència i no té visibilitat sobre les proves que ha de passar. Amb aquesta configuració, seria gairebé impossible que un agent resolgués aquest exemple a SWE-bench.

Per abordar aquests problemes, vam llançar una campanya d'anotació humana amb desenvolupadors de programari professionals per revisar cada mostra del conjunt de prova de SWE-bench i comprovar si les proves unitàries tenien un abast adequat i si les descripcions de les incidències estaven ben especificades.

Juntament amb els autors de SWE-bench, publiquem SWE-bench Verified: un subconjunt del conjunt de prova original de SWE-bench, format per 500 mostres verificades pels nostres anotadors humans com a no problemàtiques. Aquesta versió substitueix els conjunts de prova originals de SWE-bench i SWE-bench Lite. A més, publiquem les nostres anotacions humanes per a totes les mostres de prova de SWE-bench. Aquestes anotacions permeten segmentar el conjunt de dades per dificultat. El subconjunt «fàcil» està format per 196 tasques de correcció de menys de 15 minuts, mentre que el subconjunt «difícil» està format per 45 tasques de més d'1 hora.

També vam col·laborar amb els autors de SWE-bench per desenvolupar un nou marc d'avaluació per a SWE-bench⁠(s'obre en una finestra nova) que fa servir entorns Docker en contenidors per fer que l'avaluació sobre SWE-bench sigui més fàcil i fiable.

A SWE-bench Verified, GPT‑4o resol el 33,2% de les mostres³, i amb la millor estructura de codi obert, Agentless, duplica la seva puntuació anterior del 16% a SWE-bench.

Vam treballar amb 93 desenvolupadors de programari amb experiència en Python per revisar manualment mostres de SWE-bench i avaluar-ne la qualitat. Vam anotar 1.699 mostres aleatòries del conjunt de prova de SWE-bench per produir SWE-bench Verified. L'anàlisi següent es basa en aquestes 1.699 mostres.

Anotem les mostres per captar:

• Si considerem que la descripció del problema està poc especificada i, per tant, és injust que es faci servir per a l'avaluació.
• Si les proves unitàries FAIL_TO_PASS descarten solucions vàlides.

Cada criteri d'anotació té una etiqueta entre [0, 1, 2, 3] en ordre creixent de gravetat. Les etiquetes 0 i 1 són menors; les etiquetes 2 i 3 són greus i indiquen que la mostra és inadequada d'alguna manera i s'hauria de descartar. Triem anotar amb quatre categories ordinals en lloc d'una sola etiqueta binària de greu/no greu per captar un nivell de detall més fi.

A més, valorem la dificultat de cada mostra demanant als anotadors que estimin quant de temps trigaria un desenvolupador a decidir i implementar la solució, assumint que la mostra no és problemàtica. Finalment, oferim una opció de text lliure per assenyalar qualsevol altre problema important de la mostra (per exemple, si les proves unitàries FAIL_TO_PASS es poden enganyar fàcilment, això podria fer que una solució invàlida es marqués com a correcta).

El nostre equip d'enginyers primer va etiquetar manualment 50 mostres amb un alt grau de confiança per fer-les servir a les proves d'incorporació dels anotadors. Per participar en la campanya d'anotació, cada anotador potencial havia de superar les nostres proves d'incorporació. Vam proporcionar comentaris detallats a cada anotador durant tot el procés d'incorporació per formar-los millor per a la tasca.  Els anotadors no eren necessàriament experts previs en els codis base rellevants per a SWE-bench, però se'ls va donar temps per familiaritzar-se amb cada codi base amb què treballaven.

Per garantir un conjunt de dades d'alta qualitat, cada mostra s'etiqueta 3 vegades per anotadors diferents. És fàcil passar per alt possibles problemes accidentalment, i els mateixos problemes poden ser ambigus, de manera que combinem les anotacions de manera conservadora prenent l'etiqueta de gravetat més alta entre els 3 anotadors.

El text complet de la nostra rúbrica d'anotació es pot trobar aquí⁠(s'obre en una finestra nova).

Per construir SWE-bench Verified, filtrem qualsevol mostra del conjunt de prova original en què o bé l'enunciat del problema o bé les proves unitàries FAIL_TO_PASS tinguin una etiqueta combinada de gravetat 2 o superior. També filtrem totes les mostres que tinguin assenyalats altres problemes greus. Atès el nostre mètode de combinació, això equival a filtrar les mostres en què qualsevol dels tres anotadors hagi assenyalat un problema amb la mostra. Aquest enfocament comporta una taxa més alta de falsos positius en l'eliminació de mostres, però ajuda a augmentar la nostra confiança en la qualitat de les mostres del conjunt de dades final. 

Incloem tantes mostres com sigui possible amb una dificultat d'1-4 hores i >4 hores, i després mostregem aleatòriament la resta fins a arribar a les 500 mostres que constitueixen SWE-bench Verified.

Els resultats de les nostres anotacions són els següents:

Observem que el 38,3% de les mostres es van marcar per enunciats del problema poc especificats, i el 61,1% es van marcar per proves unitàries que poden assenyalar injustament solucions vàlides com a incorrectes. En conjunt, el nostre procés d'anotació va fer que es descartés el 68,3% de les mostres de SWE-bench a causa d'especificació insuficient, proves unitàries injustes o altres problemes. Com s'ha comentat anteriorment, és probable que aquest procés de filtratge sigui excessivament sever, però ens permet tenir una gran confiança en la viabilitat de les mostres no filtrades.

A continuació presentem alguns exemples de mostres i de les seves anotacions, seleccionats expressament per il·lustrar la diversitat en la qualitat de les mostres:

Amb el nostre nou conjunt de dades SWE-bench Verified, vam provar el rendiment de GPT‑4o fent servir diverses estructures de codi obert que havien obtingut bons resultats als rànquings originals de SWE-bench⁴.

Vam trobar que el rendiment de GPT‑4o amb l'estructura amb millor resultat arriba al 33,2% a SWE-bench Verified, més del doble de la seva puntuació del 16% a l'SWE-bench original. En general, això valida la nostra sospita inicial que el conjunt de dades original de SWE-bench infraestima les capacitats dels agents. Tingueu en compte que el salt de SWE-bench Lite a SWE-bench Verified no és tan significatiu, perquè SWE-bench Lite ja estava filtrat d'una manera que el fa més fàcil⁠(s'obre en una finestra nova) que el conjunt de dades complet, tot i que aquell procés no captaria completament els mateixos problemes que el nostre procediment de filtratge.

L'augment del rendiment en avaluar sobre SWE-bench Verified es pot explicar en part per un desplaçament de la distribució cap a mostres més fàcils (com es mostra en anàlisis anteriors). Tanmateix, el nostre objectiu no és inflar les puntuacions del benchmark, sinó assegurar-nos que el benchmark representa fidelment la capacitat del model a qualsevol nivell de dificultat.

Ho investiguem representant gràficament el rendiment estratificat per dificultat. Si el nostre nou conjunt de dades simplement hagués desplaçat la distribució de dificultat per incloure més mostres fàcils, el rendiment estratificat dins de cada categoria no canviaria, com sembla passar en passar de l'SWE-bench original a SWE-bench Lite. En canvi, observem que el rendiment augmenta dins de de categories individuals de dificultat en passar a SWE-bench Verified, fet que és coherent amb l'efecte previst d'eliminar mostres impossibles de totes les categories en lloc d'eliminar mostres difícils. L'efecte es veu amb més claredat en els dos trams més fàcils de dificultat, on tenim més mostres.

Fem servir SWE-bench com una de diverses avaluacions que fan el seguiment del nivell de risc mitjà de la categoria de risc d'Autonomia del model dins del nostre Entorn de treball de preparació. Fer el seguiment dels nivells de risc catastròfic mitjançant avaluacions depèn de garantir que podem confiar en els resultats de les avaluacions i que estem ben calibrats sobre què impliquen les puntuacions.

La nostra experiència suggereix que hauríem de:

Invertir a entendre profundament els nostres benchmarks. Tot i que SWE-bench es va dissenyar amb cura, infraestima les capacitats dels models a causa dels problemes esmentats en aquesta entrada del blog. A mesura que els nostres sistemes s'acosten a l'AGI, cal avaluar-los amb tasques cada cop més difícils. Això també eleva el nivell d'expertesa i cura necessari per seleccionar i verificar benchmarks, per garantir que siguin prou exigents i robustos (en aquest sentit, treballs com CriticGPT⁠, que explora maneres en què la IA pot ajudar en els processos d'anotació, poden ser útils).

Tenir en compte el progrés de l'ecosistema. El progrés liderat per la comunitat en l'estructuració d'agents posa de manifest la necessitat de considerar possibles millores externes d'un model a l'hora d'avaluar-ne el risc. Si observem la diferència entre les estructures amb pitjor i millor rendiment per a un model determinat als rànquings de SWE-bench⁠(s'obre en una finestra nova), podem veure que, per exemple, el rendiment de GPT‑4 a SWE-bench Lite varia entre el 2,7% amb una estructura primerenca basada en RAG i el 28,3% amb CodeR. Per tant, l'Entorn de treball de preparació demana que les avaluacions s'executin de manera contínua i tan sovint com calgui per identificar qualsevol canvi no trivial de capacitat; això inclou abans, durant i fins i tot després de l'entrenament, quan els models poden millorar-se mitjançant la integració amb sistemes externs. A més, la selecció d'avaluacions és un esforç de tot l'ecosistema, i esperem continuar col·laborant amb investigadors per construir avaluacions fiables i d'alta qualitat.

Ser conscients de les limitacions. Les avaluacions basades en conjunts de dades estàtics tenen limitacions inherents, i SWE-bench no n'és cap excepció. Atès que el benchmark està compost per extraccions de repositoris públics de GitHub, és probable que els grans models fundacionals preentrenats amb text d'internet estiguin contaminats en aquestes tasques. A més, SWE-bench només cobreix una distribució estreta del nivell de risc mitjà per a l'autonomia del model, i per tant s'ha de complementar amb altres avaluacions. 

Creiem en un enfocament empíric i científic per fer el seguiment i protegir-nos del risc catastròfic. Construir i millorar contínuament les avaluacions és un element clau d'aquest treball. Encara queda molta feina per fer i ens agradaria veure més contribucions de la comunitat en forma de benchmarks valuosos com SWE-bench. 

SWE-bench Verified es pot descarregar aquí⁠(s'obre en una finestra nova); el conjunt complet de les nostres anotacions és aquí⁠(s'obre en una finestra nova), i la nostra rúbrica d'anotació és aquí⁠(s'obre en una finestra nova).