Por Canuto  

OpenAI puso en duda la validez de SWE-Bench Pro, uno de los benchmarks más citados para medir capacidades de programación en modelos de IA, tras concluir que cerca de un tercio de sus tareas presenta fallas de diseño, cobertura o especificación que distorsionan los resultados.
***

  • OpenAI estimó que aproximadamente el 30% de las tareas de SWE-Bench Pro están rotas tras una auditoría técnica y humana.
  • La revisión detectó cuatro fallas principales: pruebas excesivamente estrictas, avisos poco especificados, baja cobertura y avisos engañosos.
  • La empresa retiró su recomendación previa de adoptar SWE-Bench Pro y pidió cautela al interpretar resultados de modelos.

 

Medir con precisión lo que un modelo de inteligencia artificial puede hacer no es un detalle menor. En áreas como programación, seguridad y despliegue responsable, una evaluación defectuosa puede crear una imagen falsa sobre el nivel real de capacidad de un sistema.

Esa es la advertencia central de OpenAI en su más reciente análisis sobre SWE-Bench Pro, un benchmark ampliamente utilizado para probar agentes de software. La empresa concluyó que alrededor del 30% de las tareas del conjunto están rotas, por lo que sus resultados deben interpretarse con cuidado, informó la compañía en una publicación a través de su blog oficial.

El hallazgo es relevante porque estos bancos de pruebas suelen influir en la narrativa pública sobre avances de la IA. También pesan en decisiones internas sobre investigación, seguridad y despliegue de modelos cada vez más capaces.

En este caso, la revisión se enfocó en la división pública de 731 tareas de SWE-Bench Pro. Según el informe, los modelos de frontera habían mejorado en ese benchmark desde una tasa de aprobación de 23,3% hasta 80,3% en apenas ocho meses.

Sin embargo, OpenAI sostiene que una parte significativa de esa señal puede estar contaminada por defectos en las propias tareas. Por eso retiró su recomendación anterior de adoptar SWE-Bench Pro como reemplazo de SWE-Bench Verified.

Qué encontró la auditoría de OpenAI

La auditoría se diseñó para responder una pregunta básica: si un fallo en una tarea refleja una limitación real del modelo o un problema en la evaluación. Del mismo modo, buscó verificar si un resultado exitoso representa una solución completa y válida.

Para ello, la empresa construyó un pipeline de aseguramiento de calidad enfocado en revisar instrucciones, intentos de resolución, pruebas de calificación y rastros de errores. Ese filtro inicial marcó 286 tareas como potencialmente problemáticas.

Luego, OpenAI profundizó la revisión mediante dos rutas paralelas. La primera fue una auditoría supervisada por humanos con ayuda de agentes investigadores basados en Codex.

La segunda consistió en una campaña de anotación humana con ingenieros de software experimentados. Cada tarea fue revisada por cinco ingenieros, con escalamiento de desacuerdos o casos de baja confianza.

Los resultados finales apuntaron a un problema extendido. El pipeline de análisis marcó 200 tareas rotas, equivalentes a 27,4% del benchmark, mientras que la revisión humana identificó 249, es decir, 34,1%.

Con base en ambos métodos, la empresa estimó que aproximadamente el 30% de las tareas de SWE-Bench Pro están rotas. A la luz de esa cifra, recomendó a desarrolladores y evaluadores examinar con mucha cautela cualquier resultado obtenido en ese entorno.

Las cuatro categorías de fallas más comunes

OpenAI agrupó los problemas detectados en cuatro categorías principales. La primera corresponde a pruebas excesivamente estrictas, antes llamadas pruebas estrechas.

En estos casos, los tests exigen detalles de implementación específicos que no aparecen en el aviso entregado al modelo. Eso puede invalidar soluciones funcionalmente correctas, aunque resuelvan el problema planteado.

La segunda categoría son los avisos poco especificados, antes llamados pruebas amplias. Aquí faltan requisitos que luego sí son exigidos por las pruebas ocultas, aun cuando esos requisitos no son razonablemente inferibles.

La tercera categoría reúne pruebas de baja cobertura. En este escenario, los tests no verifican adecuadamente la función solicitada, lo que permite que soluciones incompletas pasen como correctas.

La cuarta y última categoría corresponde a avisos engañosos. Se trata de problemas donde la consigna empuja al modelo hacia una conducta incorrecta o incluso contradice lo que exigen las pruebas.

La combinación de esos defectos afecta tanto a falsos positivos como a falsos negativos. En otras palabras, algunas tareas castigan respuestas válidas y otras premian soluciones insuficientes.

Cómo se hizo la revisión técnica y humana

En la ruta supervisada por humanos, cada problema señalado fue auditado con agentes investigadores que tenían acceso al repositorio y al entorno de trabajo. Eso les permitió ejecutar pruebas, inspeccionar archivos y revisar intentos fallidos de los modelos.

Según explicó la empresa, esa capacidad ayuda a distinguir entre una ambigüedad razonable de la tarea y una verdadera especificación insuficiente. En muchos casos, el contexto del repositorio permite resolver dudas que no aparecen explícitamente en el aviso.

Tras varias pasadas independientes de estas auditorías más profundas, un investigador humano revisó los resúmenes y emitió un juicio final. Después etiquetó los problemas probables detectados en cada caso.

En paralelo, la campaña de anotación humana trabajó sobre el mismo subconjunto marcado. Los ingenieros participantes fueron entrenados en los objetivos del benchmark, la taxonomía de problemas y los casos límite antes de comenzar la revisión.

Cada revisor debía formar un juicio independiente a partir de la declaración visible del problema, los casos de prueba y la solución de referencia, conocida como parche oro. Solo después podía usar el análisis del pipeline o la transcripción como contexto adicional.

Los revisores humanos tendieron a marcar más tareas como rotas que los agentes investigadores. También fueron más propensos a asignar múltiples etiquetas a una misma tarea, lo que sugiere defectos superpuestos o modos de fallo que no encajan limpiamente en una sola categoría.

De acuerdo con OpenAI, las categorías sugeridas por el pipeline de agentes coincidieron con los juicios de revisores en 74% de los casos marcados. La mayor diferencia apareció en las pruebas de baja cobertura.

Los humanos seleccionaron esa falla como el problema más común en 9,4% del benchmark. El pipeline de agentes, en cambio, la detectó como principal en apenas 4,1%.

El ejemplo del espacio extra y por qué importa

Uno de los casos citados por la empresa ilustra bien el tipo de ruptura encontrada. La tarea consistía en normalizar entradas de una tabla de contenidos y volver a renderizarlas en Markdown mediante TocEntry.to_markdown().

Según el informe, el aviso especificaba la serialización hasta el nivel de espaciado de caracteres. Además, incluía ejemplos concretos como “ | Chapter 1 | 1”, “** | Chapter 1 | 1” y “ | Just title | ” con un solo espacio inicial.

No obstante, la prueba oculta test_to_markdown exigía una salida distinta. En esos asserts aparecían dos espacios iniciales antes de la barra vertical, no uno.

Esa diferencia de un solo carácter cambiaba el resultado completo de la evaluación. Si el modelo seguía correctamente el aviso visible, podía fallar la prueba oculta y ser marcado como incorrecto.

El ejemplo ayuda a entender por qué una métrica aislada no siempre equivale a capacidad real. En benchmarks complejos, pequeñas inconsistencias entre la consigna y el criterio de evaluación pueden alterar de forma sustancial el resultado.

Esto es particularmente importante en agentes de software, donde el rendimiento suele presentarse como una carrera numérica entre laboratorios. Si la base de medición está dañada, la comparación también queda comprometida.

Por qué OpenAI retiró su recomendación sobre SWE-Bench Pro

OpenAI recordó que anteriormente ya había investigado problemas de diseño y contaminación en SWE-Bench Verified. En ese momento, la empresa alentó a la comunidad a migrar hacia SWE-Bench Pro.

SWE-Bench Pro había sido presentado como una mejora frente a la versión anterior. Su objetivo era probar modelos en horizontes más largos y en tareas de programación más realistas para seguir mejor las capacidades de agentes de codificación.

Al igual que en SWE-Bench Verified, las tareas se obtienen de forma programática a partir del historial de cambios de funciones en repositorios públicos y privados. Los modelos deben implementar una solución que pase nuevas pruebas sin romper funcionalidad existente.

Sin embargo, tras esta nueva auditoría, la empresa concluyó que los problemas hallados socavan la utilidad del benchmark como señal confiable. Por ese motivo, retiró formalmente su recomendación previa de adoptarlo.

La conclusión no implica que toda la evaluación carezca de valor, pero sí que sus números ya no deberían tomarse como una medida limpia del progreso. Para una industria que depende cada vez más de tablas comparativas, esa matización pesa bastante.

La publicación Separating signal from noise in coding evaluations subraya que las evaluaciones utilizadas por OpenAI deben ser válidas e informativas, dado que esos resultados inciden en decisiones de seguridad y despliegue bajo su Preparedness Framework.

Qué significa esto para la industria de la IA

El caso deja una lección amplia para el ecosistema de inteligencia artificial. A medida que los modelos mejoran, no solo importa que resuelvan más tareas, sino que las tareas mismas midan lo que dicen medir.

La empresa señala que muchos issues, pruebas unitarias y solicitudes de extracción de repositorios abiertos fueron creados para colaboración humana. Por eso, no siempre están alineados para convertirse en tareas aisladas y justas de evaluación automatizada.

En varios repositorios, las pruebas se escribieron para validar un cambio específico y no para definir un estándar neutral de implementación. Esa diferencia puede ser menor para un desarrollador humano con contexto, pero no para un benchmark que pretende medir capacidad general.

Al mismo tiempo, OpenAI argumenta que los propios modelos ya pueden ayudar a detectar defectos en los datos con mayor profundidad y consistencia. Eso abre la puerta a auditorías de calidad más escalables en futuros benchmarks.

La firma dijo esperar que la comunidad desarrolle nuevos bancos de pruebas creados específicamente por desarrolladores de software experimentados. Ese enfoque, según su análisis, podría preservar realismo y dificultad sin perder supervisión humana durante el proceso.

En el fondo, el debate toca un tema central para toda tecnología emergente: la diferencia entre progreso real y progreso aparente. En IA, una mala métrica no solo confunde a investigadores y empresas, también puede distorsionar la conversación pública y las decisiones de riesgo.

Por eso, el mensaje final del informe es claro. Una evaluación útil debe ofrecer señal significativa mediante benchmarks difíciles de manipular, fáciles de confiar y genuinamente conectados con la capacidad o alineación del modelo.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados