Separar la señal del ruido en evaluaciones de código

Medir con precisión las capacidades de nuestros modelos es importante para tomar decisiones sólidas de despliegue y seguridad, incluidas las decisiones conforme al Marco de preparación⁠(se abre en una ventana nueva) de OpenAI. Con cada lanzamiento de un modelo, informamos de los resultados en diversos benchmarks externos e internos para seguir el progreso del modelo. Cuando las evaluaciones tienen fallos que afectan a los resultados, pueden dar una idea falsa de las capacidades, tergiversar los argumentos de seguridad y afectar a las prioridades de investigación.

Investigamos recientemente cómo uno de los benchmarks de programación más usados, SWE-bench Verified, presentaba problemas fundamentales de diseño y contaminación, y concluimos que la evaluación ya no ofrecía una señal significativa sobre las capacidades de desarrollo de software. En aquel momento, animamos a la comunidad en general a pasarse a SWE-Bench Pro.

SWE-Bench Pro⁠(se abre en una ventana nueva) se diseñó para mejorar SWE-bench Verified probando los modelos en horizontes más largos y tareas de programación más realistas, con el fin de seguir mejor las capacidades de programación con agentes. Como en SWE-bench Verified, las tareas se extraen programáticamente del historial de cambios de funciones en un conjunto de repositorios públicos y privados. Los modelos deben implementar una solución que supere nuevas pruebas para una función sin romper la funcionalidad existente. En la partición pública de 731 tareas, los modelos de vanguardia mejoraron de una tasa de aprobación del 23,3 % al 80,3 % en ocho meses.

Desde entonces hemos realizado una auditoría similar de SWE-Bench Pro, revisando el conjunto de datos mediante una canalización de análisis de datapoints. La canalización revisó los intentos del modelo en la tarea, los metadatos de la tarea y las trazas de fallo para marcar posibles fallos de evaluación. Después, cada tarea marcada se evaluó mediante varias pasadas de agentes investigadores y fue revisada de forma independiente por cinco ingenieros de software experimentados; los desacuerdos se escalaron para una investigación adicional.

Los problemas se agruparon principalmente en cuatro categorías:

• Las pruebas demasiado estrictas¹ imponen detalles de implementación concretos no especificados en el prompt, lo que invalida muchas entregas funcionalmente correctas.
• Los prompts insuficientemente especificados² omiten requisitos que las pruebas ocultas imponen y que no se pueden inferir razonablemente.
• Las pruebas de baja cobertura no comprueban suficientemente la función solicitada, de modo que pueden darse por válidas correcciones incompletas.
• Un prompt engañoso orienta a los modelos hacia el comportamiento equivocado o contradice lo que exigen las pruebas.

Nuestros hallazgos señalan la dificultad de preparar benchmarks difíciles pero justos y la utilidad creciente de los agentes para hacer controles escalables de calidad de datos. A la luz de estos resultados, estimamos que alrededor del 30 % de las tareas de SWE-bench Pro están rotas y aconsejamos a los desarrolladores de modelos que examinen los resultados con atención.

Nuestro objetivo es garantizar que los fallos en las tareas reflejen limitaciones reales del modelo y que los éxitos reflejen soluciones completas y válidas a los requisitos del prompt. Para comprobar la calidad de los datos usados en la evaluación, creamos una canalización de aseguramiento de la calidad para evaluar si cada datapoint refleja con precisión las capacidades del modelo.

Un filtro automatizado inicial revisa las instrucciones dadas al modelo, los intentos del modelo de resolver la tarea y las pruebas usadas para calificar esos intentos, con el fin de marcar ejemplos probablemente rotos o problemáticos. Este filtro marcó 286 tareas potencialmente rotas. Después realizamos una revisión más profunda de ese subconjunto de dos maneras: una revisión de agentes con supervisión humana, que efectúa comprobaciones exhaustivas con agentes investigadores y un juicio humano final; y una campaña de anotación humana con desarrolladores de software experimentados.

Cada problema marcado se audita con agentes investigadores basados en Codex a los que se dio acceso al repositorio y al entorno de la tarea. Esto les ayuda a distinguir la ambigüedad razonable de una tarea, que a menudo puede resolverse estudiando el código cercano y las convenciones del repositorio, de una verdadera falta de especificación. El agente puede ejecutar pruebas, inspeccionar archivos del repo e investigar los intentos del modelo y sus modos de fallo habituales en la tarea. Tras varias repeticiones independientes de estas auditorías más profundas, un investigador revisó los resúmenes, emitió un juicio final y etiquetó los problemas probables.

En paralelo, llevamos a cabo una campaña de anotación humana sobre el subconjunto marcado. Trabajamos con ingenieros de software experimentados que recibieron formación sobre los objetivos del benchmark, la taxonomía de problemas y los casos límite antes de revisar las tareas. Cada tarea fue revisada por cinco ingenieros.

Los revisores se formaron un juicio independiente a partir del enunciado visible del problema, los casos de prueba y la solución de referencia validada (conocida como «gold patch») antes de usar el análisis de la canalización o la transcripción como contexto de apoyo. Después, los revisores asignaron una etiqueta y una valoración de gravedad basadas en pruebas concretas, y escalaron los desacuerdos o los casos de baja confianza para una revisión adicional.

Los revisores humanos fueron más propensos que los agentes investigadores a marcar tareas como rotas. También hubo cierto desacuerdo entre las dos vías de revisión sobre las categorías, pero en ninguna tarea marcada fue «no rota» la etiqueta humana más común. En las categorías marcadas por la canalización de agentes, los juicios de los revisores coincidieron en el 74 % de los casos.

En comparación con la canalización de agentes, los revisores humanos también fueron más propensos a seleccionar varias etiquetas para una tarea, lo que indica que consideraron que las tareas estaban rotas de varias maneras o no encajaban limpiamente en una sola categoría. Esto sugiere que la canalización con agentes y revisores dio lugar a un etiquetado conservador: captó los mismos modos generales de fallo identificados por los humanos, pero infracontabilizó los casos en los que los revisores vieron problemas adicionales o solapados. La mayor diferencia se dio en las pruebas de baja cobertura, que los humanos seleccionaron como el problema más común en el 9,4 % del benchmark, frente al 4,1 % de la canalización de agentes.

Los problemas que hemos identificado, junto con casos similares en SWE-bench Verified, subrayan la importancia de comprobar rigurosamente los benchmarks. Las incidencias y las pull requests de repositorios de código abierto se crearon originalmente para la colaboración humana, a menudo mediante largos intercambios entre mantenedores y colaboradores. Como resultado, las descripciones de problemas, el código fusionado y las pruebas unitarias no siempre encajan para formar tareas limpias y aisladas que permitan evaluar modelos de forma fiable. En particular, las pruebas incluidas en las pull requests pueden ser demasiado estrictas porque se escriben para validar un cambio concreto, no para definir un estándar independiente de la implementación para resolver la tarea.

Al mismo tiempo, los fallos de evaluación son ahora más fáciles de detectar de lo que habrían sido incluso hace poco tiempo. A medida que mejoran las capacidades de los modelos, podemos usar esos modelos para inspeccionar prompts, pruebas, parches, trazas y casos límite con mucha más profundidad y coherencia, lo que ayuda a sacar a la luz problemas de los benchmarks que antes era caro o poco práctico encontrar a escala.

Esperamos que la comunidad de evaluación en general desarrolle nuevos benchmarks creados por desarrolladores de software experimentados específicamente para probar las capacidades de los modelos. Ese enfoque puede preservar el alto nivel y el realismo con los que queremos medir las capacidades de los modelos, y permite una mejor supervisión humana durante todo el proceso. Dados los problemas descubiertos en este análisis, retiramos nuestra recomendación anterior de adoptar SWE-Bench Pro.

En última instancia, una evaluación debe aportar una señal significativa mediante benchmarks difíciles de manipular, en los que es fácil confiar y que reflejen de verdad la capacidad o el alineamiento del modelo. Como estos resultados informan las decisiones de despliegue y seguridad de OpenAI, las evaluaciones que seguimos deben ser válidas e informativas.