Por qué puntuaciones de IA similares ocultan modelos distintos

Dos puntuaciones similares en un benchmark pueden ocultar modelos que trabajan de forma muy distinta en un repositorio real. DeepSWE sitúa a Luna Max 2,2 puntos por detrás de Sol High, pero Luna usa casi tres veces más pasos del agente. La tasa de éxito no revela cuánta supervisión requiere un modelo ni si aceptaría su pull request.

¿Qué mide una puntuación del 67 % frente a otra del 69 %?

Mide el éxito por intento dentro de una configuración concreta de DeepSWE. El 69,4 % de Sol High superó el 67,2 % de Luna Max por 2,2 puntos, pero esa diferencia es menor que la incertidumbre entre ejecuciones que muestran los mismos datos [2]. El resultado me da motivos para probar ambos modelos, no una reseña completa de cada uno.

Medición	Luna Max	Sol High
Éxito por intento, %	67,2	69,4
Intervalo del 95 % entre ejecuciones	63,2–71,2 %	68,0–70,8 %
Intentos puntuados	448	451
Tareas con ≥1 acierto, %	90,3 (El mejor valor de la fila)	86,7
Coste medio por intento, $	0,61 (El mejor valor de la fila)	3,47
Tokens de salida por intento, miles	73,4	28,5 (El mejor valor de la fila)
Pasos del agente por intento	101,7	36,9 (El mejor valor de la fila)

Los datos de DeepSWE v1.1 publicados por Datacurve registran 301 intentos correctos de 448 para Luna Max y 313 de 451 para Sol High [1] [2]. Esos totales producen las puntuaciones principales de la figura 1.

DeepSWE mantiene constantes varias variables importantes. Sus 113 tareas proceden de 91 repositorios de código abierto y abarcan TypeScript, Go, Python, JavaScript y Rust [1]. Las tareas se escribieron para esta evaluación en vez de copiarse de incidencias antiguas de GitHub. Todos los modelos usaron además mini-swe-agent con la misma herramienta bash y el mismo prompt base [5], y un contenedor nuevo comprobó que cada patch tuviera el comportamiento requerido y no causara regresiones.

Estos controles hacen útil la comparación, aunque el resultado sigue teniendo incertidumbre. Datacurve asigna a Luna un intervalo del 95 % entre el 63,2 % y el 71,2 %, mientras que el de Sol va del 68,0 % al 70,8 % [2]. Los intervalos se solapan, por lo que la diferencia de 2,2 puntos es menor que la variación observada entre ejecuciones. Datacurve no publica una comparación estadística de ambos modelos sobre las mismas tareas, así que los datos no establecen que la ventaja de Sol pueda repetirse.

Las dos configuraciones también usan niveles de esfuerzo distintos: max para Luna y high para Sol. La clasificación cambia cuando uso la medida empírica Pass@4 de Datacurve, que pregunta si al menos uno de los intentos registrados resolvió cada tarea. Con esa medida, Luna cubre el 90,3 % de las 113 tareas y Sol el 86,7 % [2]. El éxito por intento favorece a Sol, mientras que la cobertura de tareas favorece a Luna, porque ambas mediciones responden a preguntas diferentes.

Todas las mediciones de la figura 1 pertenecen a las tareas y la configuración de agente de DeepSWE. Mi propio repositorio puede premiar otras capacidades y revelar otros fallos, por eso ahora importa ver cómo llega cada modelo al resultado.

Por qué unas puntuaciones cercanas pueden ocultar casi el triple de pasos

La tasa de éxito ignora cómo llegó el modelo al patch, así que dos puntuaciones similares pueden exigir al desarrollador cantidades de trabajo muy distintas. Me fijo en si el modelo encuentra los archivos correctos, conserva el diseño existente, pregunta antes de asumir algo arriesgado, se recupera tras un comando fallido y se detiene cuando termina el cambio solicitado. DeepSWE no puntúa esos comportamientos por separado.

Los datos sin procesar de DeepSWE ofrecen una pista. Luna Max usó de media 101,7 pasos del agente y 73.400 tokens de salida por intento, frente a 36,9 pasos y 28.450 tokens de Sol High [2]. Luna necesitó así unas 2,8 veces más pasos y 2,6 veces más tokens de salida para alcanzar una tasa de éxito parecida. Los modelos no trabajaron de la misma forma.

El coste mostrado también necesita contexto. Las pruebas de Luna se ejecutaron el 7 de julio de 2026, cuando el consumo de tokens registrado costaba unos 3,03 dólares por intento [2] [3]. OpenAI redujo el precio de los tokens de Luna un 80 % el 30 de julio de 2026 [4], y DeepSWE recalculó el consumo antiguo con la tarifa nueva. Así es como 3,03 dólares se convirtieron en los 0,61 dólares mostrados. La cifra inferior estima correctamente lo que costaría ahora ese mismo consumo, pero no lo que Datacurve pagó al ejecutar la prueba.

El coste de API por intento tampoco es el coste de conseguir un cambio aceptado. El precio del leaderboard no incluye repeticiones, tiempo de revisión, ediciones manuales, esperas ni un segundo modelo utilizado para inspeccionar o reparar el trabajo del primero. Un intento puede costar una sexta parte y aun así salir más caro en total si un ingeniero tiene que supervisar cada decisión.

Algunos desarrolladores llaman a estas diferencias en la forma de trabajar “big model smell”: la sensación de que un modelo más capaz entiende el encargo con menos explicaciones y toma menos decisiones que después hay que deshacer. La expresión es informal, pero la experiencia que describe se puede medir. Puedo contar cuántas veces redirijo el modelo, reparo su trabajo o rechazo un patch que pasó las pruebas.

Esa impresión se convierte así en preguntas concretas. ¿Recordó el modelo todas las restricciones, tomó decisiones sensatas para este repositorio y evitó cambios no relacionados? Cuando falló, ¿era fácil detectar y revertir el problema? Una sola tasa de éxito no puede responder a esas preguntas.

¿Cuánto puede cambiar la configuración la puntuación?

En los ejemplos publicados a continuación, los cambios en la configuración movieron las puntuaciones entre unos 5 y 15 puntos porcentuales sin cambiar el modelo [6] [7]. Es más que la diferencia de 2,2 puntos entre Luna y Sol. Un benchmark de programación mide el prompt, las herramientas, los límites de ejecución, el número de intentos y el evaluador junto con el modelo.

El paper de SWE-agent publicado en NeurIPS ofrece un ejemplo claro. Con el mismo GPT-4 Turbo en SWE-bench Lite, una interfaz limitada a la shell resolvió el 11 % de las tareas, mientras que la interfaz completa de SWE-agent resolvió el 18 % [6]. Cuando los investigadores sustituyeron los resultados repetidos de búsqueda por una herramienta que los resumía, la puntuación subió del 12 % al 18 %. Limitar el visor a 100 líneas en vez de devolver el archivo entero la llevó del 12,7 % al 18 %. Estos cambios de interfaz añadieron entre cinco y siete puntos porcentuales sin cambiar el modelo.

El número de intentos cambia aún más el titular. Seis ejecuciones de la misma combinación de GPT-4 y SWE-agent promediaron un 17,94 % en el primer intento. Si una tarea contaba como resuelta cuando cualquiera de seis intentos pasaba, la cobertura subía al 32,67 % [6]. Ese aumento de 14,73 puntos puede ser útil si un sistema de producción ejecuta seis candidatos y sabe identificar el correcto. Resulta engañoso si aparece junto a una medición de un solo intento sin una etiqueta clara.

La infraestructura también puede introducir ruido. Anthropic mantuvo constantes el modelo Claude, el harness y las tareas de Terminal-Bench 2.0, y después cambió los límites de CPU, memoria y tiempo de ejecución. La configuración sin límites puntuó unos seis puntos porcentuales más, mientras que los errores de infraestructura bajaron del 5,8 % al 0,5 % [7]. Por eso conviene leer cada fila de un leaderboard como el resultado de un sistema evaluado, no como un número permanente unido al nombre del modelo.

Los cuatro cambios de configuración siguientes movieron las puntuaciones más que la diferencia principal entre Luna y Sol.

Cambio del sistema	Antes	Después	Cambio
Solo shell → interfaz SWE-agent	11,0 %	18,0 %	+7,0 pp
Archivo completo → visor de 100 líneas	12,7 %	18,0 %	+5,3 pp
Uno → seis intentos	17,94 %	32,67 %	+14,73 pp
Tiempo limitado → sin límite	No publicado	No publicado	unos +6 pp

Esto no vuelve inútiles los benchmarks, pero sí convierte la configuración en parte del resultado. Antes de comparar dos puntuaciones, compruebo que usen la misma versión de las tareas, configuración de agente, recursos, número de intentos y regla de evaluación.

¿Por qué un patch que pasa las pruebas puede fallar la revisión?

Pasar un benchmark significa que un patch superó sus comprobaciones. Es una prueba útil de que el código funciona, pero no equivale a una revisión de código. Las comprobaciones pueden pasar por alto una solución incompleta y quizá no consideren la mantenibilidad, el encaje con la arquitectura existente, los cambios no relacionados o el trabajo necesario antes del merge.

El paper de EvalPlus publicado en NeurIPS mostró hasta qué punto las pruebas elegidas pueden afectar al resultado. Los investigadores multiplicaron aproximadamente por 80 las suites de pruebas de HumanEval y evaluaron 26 modelos. Con las pruebas más exigentes, las tasas de éxito de los modelos más afectados cayeron entre 19,3 y 28,9 puntos porcentuales, y algunas clasificaciones se invirtieron [8]. Las respuestas no cambiaron, las suites mayores simplemente detectaron más errores.

Los benchmarks de repositorios tienen el mismo problema. En febrero de 2026, OpenAI auditó 138 tareas de SWE-bench Verified que o3 falló de manera irregular a lo largo de 64 ejecuciones. Encontró problemas importantes en el 59,4 % de ese grupo seleccionado, incluidas pruebas que rechazaban soluciones válidas y otras que exigían un comportamiento no mencionado en la incidencia [9]. Como la auditoría se centró deliberadamente en tareas sospechosas, el 59,4 % no describe las 500 tareas. Sí demuestra que los errores en tareas y pruebas pueden distorsionar las diferencias entre modelos muy capaces.

El error contrario importa tanto como el anterior: un patch puede pasar las pruebas automáticas y seguir sin estar listo para merge. METR pidió a mantenedores que revisaran 296 pull requests generadas por IA en tres repositorios y 95 tareas. Su tasa de aceptación fue 24,2 puntos porcentuales menor que la puntuación automatizada de SWE-bench [10]. Rechazaron patches por fallos de funcionalidad central, roturas no relacionadas, mala calidad del código y otros problemas de integración. Una puntuación binaria oculta todos esos motivos tras la misma etiqueta de aprobado o suspenso.

más pruebas en EvalPlus

80×

algunas clasificaciones se invirtieron

problemas en una auditoría dirigida

59,4 %

no representa las 500 tareas

brecha entre automatización y mantenedores

24,2 pp

METR revisó 296 pull requests

En conjunto, estos resultados muestran que la calidad de las pruebas y la revisión humana responden a preguntas distintas. “El patch pasó” es una prueba que merece conservarse, pero no me dice si quiero que ese modelo haga cambios a diario en mi rama.

¿Qué oculta un promedio? Repetibilidad y tareas largas

Una tasa media combina todos los éxitos y fallos en un solo número. No muestra si el modelo acierta de forma constante, si su fiabilidad cae en tareas largas ni si un intento fallido produce un pequeño diff incorrecto o daña el estado de trabajo. Esas diferencias importan cuando uso el modelo repetidamente en vez de probarlo una sola vez.

El paper de tau-bench publicado en arXiv hace visible el problema de la repetibilidad con pass^k, que pregunta si un agente resuelve la misma tarea todas las veces a lo largo de varios ensayos. GPT-4o obtuvo un 61,2 % en tareas de comercio minorista al mirar un solo ensayo, pero su pass^8 quedó por debajo del 25 % [11]. Un modelo que funciona tres veces y falla la cuarta puede conservar un promedio respetable. Como colaborador diario, me resulta impredecible.

La duración de la tarea crea una diferencia parecida. METR evaluó agentes en 170 tareas, con unas ocho ejecuciones por pareja de modelo y tarea. Las tareas que un modelo resolvía el 80 % de las veces eran entre cuatro y seis veces más cortas que su horizonte de éxito al 50 % [12]. Así, un modelo puede recibir crédito por tareas impresionantes de dos horas con un umbral del 50 % y seguir siendo fiable solo en trabajos mucho más cortos.

Esto ayuda a explicar por qué las impresiones prácticas pueden discrepar de un leaderboard. El uso diario incluye tareas repetidas, contexto del repositorio fácil de pasar por alto, comandos rotos, requisitos ambiguos, ciclos de revisión y las consecuencias de los peores intentos fallidos. Las impresiones personales también pueden equivocarse porque una respuesta pulida o un solo fallo desastroso pueden dominar mi recuerdo. En vez de elegir entre benchmarks e intuición, necesito medir las partes de mi flujo de trabajo que crearon esa impresión.

¿Cómo debería comparar modelos para mi trabajo?

Uso los benchmarks públicos como filtro. Me indican qué modelos merecen tiempo y dinero, y una evaluación controlada como DeepSWE aporta una base mucho más sólida que una demostración de lanzamiento. La elección final depende de una pequeña evaluación construida con mi propio trabajo.

Anthropic recomienda empezar la evaluación de un agente con entre 20 y 50 tareas tomadas de comprobaciones manuales, fallos comunes, informes de bugs y peticiones reales de desarrollo [13]. Ese tamaño basta para descubrir incompatibilidades grandes sin fingir que produce un leaderboard universal. Si los resultados están muy igualados, ejecutaría las mismas tareas varias veces manteniendo fijos el entorno, las herramientas, los prompts, el nivel de esfuerzo y el presupuesto.

Antes de ver los resultados, definiría qué significa aceptar el trabajo. Las pruebas van primero, pero no forman toda la rúbrica. También registraría:

• si el resultado se aceptó al primer intento;
• el tiempo total hasta un resultado aceptado, con revisión y reparación;
• los minutos de revisión activa, separados de la latencia del modelo;
• las aclaraciones, redirecciones, reinicios y ediciones manuales;
• los archivos innecesarios modificados y las infracciones de las convenciones del repositorio;
• los fallos graves, como regresiones de seguridad, riesgo de pérdida de datos o roturas no relacionadas;
• los tokens y el coste de API del resultado completo y aceptado.

Para evaluar la calidad del código, ocultaría los nombres de los modelos y revisaría los patches rivales en orden aleatorio siempre que fuera práctico. Publicaría los resultados por tipo de tarea en vez de mezclar correcciones de bugs, revisiones, refactors y desarrollo de funcionalidades largas en un solo total. Si dos modelos siguen cerca tras repetir las tareas, elegiría el más barato. Sin embargo, si su mayor coste de revisión consume el ahorro de API, no es el modelo más barato para mi flujo de trabajo.

DeepSWE ha hecho lo suficiente para que Luna Max entre en mi lista de pruebas. En mi próxima comparación mantendría fijas las tareas y las herramientas, y después contaría todo el camino hasta un patch aceptado: redirecciones, revisión, reparación e intentos fallidos. Si el menor precio de API de Luna mantiene su ventaja tras esos costes, será más barata para mi trabajo. Si no, el precio del leaderboard no es el precio que pago.