Separar señal de ruido en evaluaciones de codificación

Medir con precisión las capacidades de nuestros modelos es importante para tomar decisiones sólidas de implementación y seguridad, incluidas las decisiones bajo el Marco de preparación⁠(se abre en una nueva ventana) de OpenAI. Con cada lanzamiento de modelo, informamos resultados de diversos benchmarks externos e internos para hacer seguimiento del progreso de los modelos. Cuando las evaluaciones tienen fallas que afectan los resultados, pueden dar una idea equivocada de las capacidades, distorsionar los argumentos de seguridad e influir en las prioridades de investigación.

Hace poco investigamos cómo uno de los benchmarks de codificación más usados, SWE-bench Verified, tenía problemas fundamentales de diseño y contaminación, y descubrimos que la evaluación ya no ofrecía una señal significativa sobre las capacidades de desarrollo de software. En ese momento, alentamos a la comunidad en general a pasar a SWE-Bench Pro.

SWE-Bench Pro⁠(se abre en una nueva ventana) se diseñó para mejorar SWE-bench Verified mediante la evaluación de modelos en horizontes más largos y tareas de codificación más realistas, con el fin de medir mejor las capacidades de codificación con agentes. Al igual que en SWE-bench Verified, las tareas se obtienen de forma programática a partir del historial de cambios de funciones en un conjunto de repositorios públicos y privados. Los modelos deben implementar una solución que supere pruebas nuevas para una función, sin afectar la funcionalidad existente. En la partición pública de 731 tareas, los modelos de vanguardia mejoraron su tasa de aprobación de 23,3 % a 80,3 % en ocho meses.

Desde entonces realizamos una auditoría similar de SWE-Bench Pro, revisando el conjunto de datos con un pipeline de análisis de datapoints. El pipeline revisó los intentos del modelo en la tarea, los metadatos de la tarea y los rastros de falla para marcar posibles fallas de evaluación. Luego, cada tarea marcada se evaluó mediante varias pasadas de investigadores-agentes 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 específicos que no se indican en el prompt, lo que invalida muchas entregas funcionalmente correctas.
• Los prompts con especificaciones insuficientes² omiten requisitos que las pruebas ocultas hacen cumplir y que no se pueden inferir razonablemente.
• Las pruebas de baja cobertura verifican de forma insuficiente la función solicitada, por lo que correcciones incompletas pueden aprobar.
• 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 curar benchmarks exigentes pero justos y la utilidad creciente de los agentes para realizar controles escalables de calidad de datos. A la luz de estos resultados, estimamos que alrededor de 30 % de las tareas de SWE-bench Pro están rotas y recomendamos que los desarrolladores de modelos examinen los resultados con cuidado.

Nuestro objetivo es asegurar que las fallas en las tareas reflejen limitaciones reales del modelo y que los aciertos reflejen soluciones completas y válidas para los requisitos del prompt. Para verificar la calidad de los datos usados en la evaluación, creamos un pipeline de control de calidad que evalúa 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 por 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. Luego realizamos una revisión más profunda de ese subconjunto de dos formas: una revisión de agentes con supervisión humana, que realiza verificaciones 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 les dio acceso al repositorio y al entorno de la tarea. Esto les ayuda a distinguir la ambigüedad razonable de la 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 en el repo e investigar los intentos del modelo y sus modos de falla comunes en la tarea. Después de 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, ejecutamos una campaña de anotación humana sobre el subconjunto marcado. Trabajamos con ingenieros de software experimentados que recibieron capacitació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 formaron un juicio independiente a partir del enunciado visible del problema, los casos de prueba y la solución de referencia considerada correcta (conocida como gold patch) antes de usar el análisis del pipeline o la transcripción como contexto de apoyo. Luego, los revisores asignaron una etiqueta y una calificación de gravedad con base en evidencia concreta, 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 sobre las categorías entre las dos rutas de revisión, pero en ninguna tarea marcada “no rota” fue la etiqueta humana más común. De las categorías marcadas por el pipeline de agentes, los juicios de los revisores coincidieron en 74 % de los casos.

En comparación con el pipeline de agentes, los revisores humanos también fueron más propensos a seleccionar varias etiquetas para una tarea, lo que indica que encontraron tareas rotas de múltiples maneras o que no encajaban claramente en una sola categoría. Esto sugiere que el pipeline de agentes más revisores produjo un etiquetado conservador: capturó los mismos modos de falla generales que identificaron los humanos, pero subestimó los casos en que los revisores vieron problemas adicionales o superpuestos. La mayor diferencia se dio en las pruebas de baja cobertura, que los humanos seleccionaron como el problema más común en 9,4 % del benchmark, frente a 4,1 % según el pipeline de agentes.

Los problemas que identificamos, junto con casos similares en SWE-bench Verified, resaltan la importancia de verificar rigurosamente los benchmarks. Los issues y 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 se alinean para formar tareas claras y aisladas que permitan evaluar modelos de manera confiable. En particular, las pruebas incluidas en pull requests pueden ser demasiado estrictas porque se escriben para validar un cambio específico, no para definir un estándar independiente de la implementación para resolver la tarea.

Al mismo tiempo, las fallas de evaluación son más fáciles de detectar ahora de lo que habrían sido incluso hace poco tiempo. A medida que mejoran las capacidades de los modelos, podemos usarlos para inspeccionar prompts, pruebas, parches, rastros y casos límite con mucha mayor profundidad y consistencia, lo que ayuda a revelar problemas de benchmarks que antes era costoso 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 evaluar las capacidades de los modelos. Ese enfoque puede preservar el alto estándar y el realismo que queremos para 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 ofrecer una señal significativa mediante benchmarks difíciles de manipular, fáciles de confiar y que reflejen genuinamente la capacidad o alineación del modelo. Como estos resultados informan las decisiones de implementación y seguridad de OpenAI, las evaluaciones que seguimos deben ser válidas e informativas.