Resulta que OpenAI acaba de tirar una bomba que nadie vio venir: auditaron SWE-Bench Pro —el benchmark que reemplazó a SWE-Bench Verified después de que también resultó estar mal diseñado— y descubrieron que aproximadamente el 30% de las tareas están rotas. Tests demasiado estrictos, prompts mal especificados, tests con cobertura mínima, prompts que te mandan por el camino equivocado. O sea, las métricas con las que toda la industria viene comparando modelos de IA para programación eran, en gran parte, basura.
El problema de fondo
Si eres de los que sigue los lanzamientos de modelos de IA, sabes que cada vez que sale uno nuevo, aparece una tabla con porcentajes de SWE-Bench. 23,3% a 80,3% en ocho meses, decían. Impresionante, ¿cierto?Excepto que si el 30% de las tareas están mal hechas, ese número no significa nada. Un modelo podría pasar la mitad de los tests simplemente porque los tests no prueban lo que deberían probar. Y otro podría fallar porque el prompt le pide una cosa y el test evalúa otra distinta.
Esto no es un detalle menor. Estas métricas se usan para decidir seguridad, despliegue y prioridades de investigación. Si crees que tu modelo es mejor de lo que realmente es porque el benchmark está roto, tomas decisiones equivocadas. Y no hablo de decisiones chiquitas: hablo de decidir si un modelo está listo para producción, si es seguro liberarlo, qué tan confiable es para que te ayude en la pega.
La ironía de los benchmarks de IA
Lo más irónico de todo esto es que OpenAI recomendó SWE-Bench Pro como reemplazo del anterior, que también estaba roto. Es como cambiar de doctor y que el nuevo también te diagnotique mal, pero por razones distintas. ¿Cuántas veces más va a pasar esto antes de que la industria acepte que los benchmarks automatizados para IA tienen un problema estructural?
El asunto es que crear benchmarks difíciles pero justos es mucho más complejo de lo que parece. Necesitas tareas que sean desafiantes, pero con instrucciones claras. Tests que verifiquen lo que se pide, ni más ni menos. Prompts que no contradigan los tests. Y todo esto a escala, con cientos de tareas generadas automáticamente desde repos reales. Cuando automatizas todo, se te cuelan los errores.
Lo que me preocupa de verdad
OpenAI usó agentes investigadores basados en Codex para auditar las tareas, complementados con cinco ingenieros humanos. Encontraron que el pipeline automatizado marcó 200 tareas rotas (27,4%) y los humanos encontraron 249 (34,1%). O sea, ni siquiera los humanos se ponen de acuerdo con los agentes sobre qué tan roto está todo.
Esto me hace pensar: si ni siquiera podemos medir confiablemente qué tan bueno es un modelo para programar, ¿cómo pretendemos medir cosas más abstractas como razonamiento, alineación o seguridad? Si el 30% de un benchmark de código está mal, ¿qué porcentaje de los benchmarks de seguridad están mal? Y esos son los que supuestamente nos dicen si es seguro liberar un modelo al público.
Mi take
Como ingeniero, esto me parece un llamado de atención que la industria necesita hace rato. Estamos operando con grados de confianza que no nos hemos ganado. Cada vez que veo un paper o un blog post que dice «nuestro modelo supera a X en Y%», me pregunto: ¿y quién auditó Y?¿Quién verificó que Y mide lo que dice medir?
La respuesta, casi siempre, es nadie. Y cuando alguien finalmente lo hace —como OpenAI acá— descubre que el 30% estaba mal. Es como construir un puente con materiales que nadie certificó y esperar que no se caiga.
OpenAI al menos tuvo la honestidad de retractarse y admitir el error. Eso vale. Pero el problema es más grande que un benchmark. Es la confianza ciega en métricas automatizadas que nadie verifica. Y mientras sigamos así, cada nuevo récord en SWE-Bench (o lo que venga después) debería leerse con una buena dosis de escepticismo.
Fuente de inspiración: Separating signal from noise in coding evaluations | OpenAI
