Separar el senyal del soroll en les avaluacions de codi

Mesurar amb precisió les capacitats dels nostres models és important per prendre decisions sòlides de desplegament i seguretat, incloses les decisions d'acord amb el Marc de preparació⁠(s'obre en una finestra nova) d’OpenAI. Amb cada llançament de model, informem de resultats en diversos benchmarks externs i interns per seguir el progrés del model. Quan les avaluacions tenen defectes que afecten els resultats, poden donar una idea falsa de les capacitats, distorsionar els arguments de seguretat i influir en les prioritats de recerca.

Fa poc vam investigar com un dels benchmarks de programació més utilitzats, SWE-bench Verified, tenia problemes fonamentals de disseny i contaminació, i vam constatar que l’avaluació ja no aportava un senyal significatiu sobre les capacitats de desenvolupament de programari. Aleshores vam animar la comunitat en general a passar-se a SWE-Bench Pro.

SWE-Bench Pro⁠(s'obre en una finestra nova) es va dissenyar per millorar SWE-bench Verified provant els models en horitzons més llargs i tasques de programació més realistes, per seguir millor les capacitats de programació agentiva. Com a SWE-bench Verified, les tasques s’obtenen programàticament de l’historial de canvis de funcionalitats d’un conjunt de repositoris públics i privats. Els models han d’implementar una solució que superi noves proves per a una funcionalitat sense trencar la funcionalitat existent. En la partició pública de 731 tasques, els models d’avantguarda van millorar del 23,3 % al 80,3 % de taxa d’aprovació en vuit mesos.

Des d’aleshores hem dut a terme una auditoria similar de SWE-Bench Pro, revisant el conjunt de dades amb una canalització d’anàlisi de punts de dades. La canalització va revisar els intents del model en la tasca, les metadades de la tasca i les traces de fallada per marcar possibles defectes d’avaluació. Després, cada tasca marcada es va avaluar mitjançant diverses passades d’investigadors-agents i va ser revisada de manera independent per cinc enginyers de programari experimentats; els desacords es van escalar per a una investigació addicional.

Els problemes es van concentrar principalment en quatre categories:

• Les proves excessivament estrictes¹ imposen detalls d’implementació concrets que no s’especifiquen a la indicació, cosa que invalida moltes entregues funcionalment correctes.
• Les indicacions insuficientment especificades² ometen requisits que les proves ocultes imposen i que no es poden inferir raonablement.
• Les proves de baixa cobertura comproven de manera insuficient la funcionalitat sol·licitada, de manera que correccions incompletes poden passar.
• Una indicació enganyosa orienta els models cap a un comportament equivocat o contradiu el que exigeixen les proves.

Les nostres conclusions apunten a la dificultat de crear benchmarks difícils però justos, i a la utilitat creixent dels agents per fer comprovacions escalables de qualitat de dades. A la llum d’aquests resultats, estimem que aproximadament el 30 % de les tasques de SWE-bench Pro són defectuoses i recomanem als desenvolupadors de models que examinin els resultats amb cura.

El nostre objectiu és garantir que els fracassos en les tasques reflecteixin limitacions reals del model, i que els èxits reflecteixin solucions completes i vàlides als requisits de la indicació. Per comprovar la qualitat de les dades utilitzades en l’avaluació, vam crear una canalització d’assegurament de la qualitat per valorar si cada punt de dades reflecteix amb precisió les capacitats del model.

Un filtre automatitzat inicial revisa les instruccions donades al model, els intents del model de resoldre la tasca i les proves utilitzades per qualificar aquests intents, per marcar exemples probablement defectuosos o problemàtics. Aquest filtre va marcar 286 tasques potencialment defectuoses. Després vam fer una revisió més profunda d’aquest subconjunt de dues maneres: una revisió d’agents supervisada per humans, que fa comprovacions exhaustives amb agents investigadors i un judici humà final; i una campanya d’anotació humana amb desenvolupadors de programari experimentats.

Cada problema marcat s’audita amb agents investigadors basats en Codex que van rebre accés al repositori i a l’entorn de la tasca. Això els ajuda a distingir l’ambigüitat raonable de la tasca, que sovint es pot resoldre estudiant el codi proper i les convencions del repositori, de la veritable manca d’especificació. L’agent pot executar proves, inspeccionar fitxers del repositori i investigar els intents del model i els seus modes de fallada comuns en la tasca. Després de diverses repeticions independents d’aquestes auditories més profundes, un investigador va revisar els resums, va emetre un judici final i va etiquetar els problemes probables.

En paral·lel, vam dur a terme una campanya d’anotació humana sobre el subconjunt marcat. Vam treballar amb enginyers de programari experimentats, que van rebre formació sobre els objectius del benchmark, la taxonomia de problemes i els casos límit abans de revisar les tasques. Cinc enginyers van revisar cada tasca.

Els revisors es van formar un criteri independent a partir de l’enunciat visible del problema, els casos de prova i la solució de referència veritable (coneguda com a "gold patch") abans d’utilitzar l’anàlisi de la canalització o la transcripció com a context de suport. Després, els revisors van assignar una etiqueta i una qualificació de gravetat basades en proves concretes, i van escalar els desacords o els casos de baixa confiança perquè es revisessin més a fons.

Els revisors humans eren més propensos que els agents investigadors a marcar tasques com a defectuoses. També hi va haver algun desacord sobre les categories entre les dues vies de revisió, però en cap tasca marcada "no defectuosa" va ser l’etiqueta humana més freqüent. De les categories marcades per la canalització d’agents, els judicis dels revisors van coincidir en el 74 % dels casos.

En comparació amb la canalització d’agents, els revisors humans també eren més propensos a seleccionar diverses etiquetes per a una tasca, cosa que indica que trobaven que les tasques eren defectuoses de diverses maneres o no encaixaven clarament en una sola categoria. Això suggereix que la canalització d’agents més revisors va donar lloc a un etiquetatge conservador: capturava els mateixos grans modes de fallada que identificaven els humans, però infraestimava els casos en què els revisors veien problemes addicionals o superposats. La diferència més gran es va donar en les proves de baixa cobertura, que els humans van seleccionar com el problema més comú en el 9,4 % del benchmark, en comparació amb el 4,1 % de la canalització d’agents.

Els problemes que hem identificat, juntament amb casos similars a SWE-bench Verified, destaquen la importància de comprovar rigorosament els benchmarks. Les incidències i pull requests de repositoris de codi obert es van crear originalment per a la col·laboració humana, sovint mitjançant llargues converses d’anada i tornada entre mantenidors i contribuïdors. Per això, les descripcions dels problemes, el codi fusionat i les proves unitàries no sempre encaixen per formar tasques netes i aïllades que permetin avaluar els models de manera fiable. En particular, les proves incloses en pull requests poden ser excessivament estrictes perquè s’escriuen per validar un canvi concret, no pas per definir un estàndard independent de la implementació per resoldre la tasca.

Alhora, ara és més fàcil detectar defectes d’avaluació que no ho hauria estat fins i tot fa poc temps. A mesura que milloren les capacitats dels models, podem utilitzar aquests models per inspeccionar indicacions, proves, pedaços, traces i casos límit amb molta més profunditat i coherència, cosa que ajuda a fer aflorar problemes dels benchmarks que abans eren costosos o impracticables de trobar a escala.

Esperem que la comunitat d’avaluació en general desenvolupi nous benchmarks creats per desenvolupadors de programari experimentats específicament per provar les capacitats dels models. Aquest enfocament pot preservar el nivell d’exigència i el realisme que volem per mesurar les capacitats dels models, i permet una millor supervisió humana al llarg de tot el procés. Atesos els problemes descoberts en aquesta anàlisi, retirem la nostra recomanació anterior d’adoptar SWE-Bench Pro.

En última instància, una avaluació ha d’aportar un senyal significatiu mitjançant benchmarks difícils de manipular, en què és fàcil confiar i que reflecteixin realment la capacitat o l’alineament del model. Com que aquests resultats informen les decisions de desplegament i seguretat d’OpenAI, les avaluacions que seguim han de ser vàlides i informatives.