Una puntuación de benchmark no es una reseña del modelo

Una ventaja de dos puntos en un benchmark de programación no significa que dos modelos vayan a rendir casi igual dentro de un repositorio real. La puntuación corresponde a un conjunto de tareas, una configuración de agente y una regla de evaluación. No indica cuánta supervisión necesita cada modelo, cuánto cuestan sus fallos ni si yo aceptaría su pull request.

DeepSWE ofrece un buen ejemplo. Luna Max obtiene un 67,2 % y Sol High un 69,4 %, aunque el coste mostrado de Luna es aproximadamente una sexta parte [2]. Ese resumen hace que Luna parezca la elección obvia. En la práctica, unas tasas de éxito parecidas pueden ocultar grandes diferencias en el tiempo que dedico a dirigir el modelo, comprobar sus supuestos y reparar su trabajo.

Algunos desarrolladores llaman a esa diferencia “big model smell”: la sensación de que un modelo más capaz entiende el trabajo 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 comprobar. Puedo contar cuántas veces tengo que redirigir el modelo, reparar su trabajo o rechazar un patch que pasó las pruebas.

¿Qué miden realmente el 67 % y el 69 %?

Los datos de DeepSWE v1.1 de Datacurve registran 301 intentos correctos de 448 para Luna Max y 313 de 451 para Sol High [1] [2]. Esos totales producen las puntuaciones del 67,2 % y el 69,4 %. Muestran una diferencia de 2,2 puntos porcentuales en esta prueba, pero no que los modelos rindan igual en el trabajo diario.

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ó cada patch frente al comportamiento requerido y posibles regresiones.

Estos controles hacen útil la comparación, pero 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 tarea por tarea, así que los datos no demuestran que la ventaja de 2,2 puntos de Sol sea repetible.

Las dos configuraciones también usan niveles de esfuerzo distintos: max para Luna y high para Sol. La clasificación cambia al usar 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 y la cobertura de tareas a Luna porque las dos mediciones responden a preguntas diferentes.

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)

La comparación completa me da motivos para probar ambos modelos, pero no para tratarlos como equivalentes. Todas las mediciones de la figura 1 proceden de las tareas y la configuración de agente de DeepSWE. Mi repositorio puede premiar otras capacidades y revelar otros fallos.

¿Por qué dos puntuaciones cercanas pueden sentirse tan distintas?

Dos modelos pueden resolver el mismo número de tareas y exigir cantidades de trabajo muy distintas al desarrollador. 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 reduce el resultado final a aprobado o suspenso, por lo que no evalú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 datos no dicen si esos pasos adicionales fueron útiles, pero muestran con claridad que los modelos no trabajaron del mismo modo.

El coste mostrado también necesita contexto. Las pruebas de Luna se ejecutaron el 7 de julio, 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 [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 hoy ese mismo consumo, pero no lo que Datacurve pagó al ejecutar la prueba.

El coste de API por intento también es distinto del 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.

Estas diferencias en el trabajo son lo que intenta describir la expresión “big model smell”. Las preguntas útiles son concretas: ¿Mantuvo el modelo todas las restricciones presentes? ¿Tomó decisiones sensatas para este repositorio? ¿Evitó cambios no relacionados, expresó la incertidumbre con claridad y falló de una forma fácil de detectar y revertir? Una sola tasa de aciertos no puede responder a ninguna de ellas.

¿Cuánto puede influir la configuración en la puntuación?

Un benchmark de programación evalúa un sistema completo, no solo el modelo. El prompt, las herramientas, la política de contexto, los límites del entorno, el número de intentos y el evaluador afectan al resultado. Cambiar cualquiera de ellos puede mover la puntuación aunque el modelo siga siendo exactamente el mismo.

El paper de SWE-agent publicado en NeurIPS ofrece un ejemplo controlado. 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 introduce ruido. Anthropic mantuvo constantes el modelo Claude, el harness y las tareas de Terminal-Bench 2.0, y solo cambió los límites de CPU, memoria y tiempo. La configuración sin límites estrictos 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.

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
Recursos estrictos → sin límite	No publicado	No publicado	unos +6 pp

Los cuatro cambios de la figura 2 superan la diferencia de 2,2 puntos entre Luna y Sol. Eso 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é se puede rechazar un patch que ha pasado las pruebas?

Pasar un benchmark significa que un patch superó las comprobaciones del benchmark. Es una prueba útil de que el código funciona, pero no equivale a una revisión de código. Las comprobaciones pueden aceptar 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.

EvalPlus 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 sobre la fiabilidad?

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 se derrumba en tareas largas ni si un intento fallido produce un diff pequeño y malo 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 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, se siente impredecible.

La duración de la tarea crea una separación parecida. METR evaluó agentes en 170 tareas, con unas ocho ejecuciones por pareja de modelo y tarea. La duración de tarea en la que un modelo acertaba el 80 % de las veces era entre cuatro y seis veces menor 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 comparo modelos para mi propio trabajo?

Uso los benchmarks públicos como filtro. Me indican qué modelos merecen tiempo y dinero, y una evaluación controlada como DeepSWE aporta mucha más información que una demostración de lanzamiento. La elección final sigue viniendo 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. Cuando la comparación está ajustada, 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.

Cuando evalúo la calidad del código, ocultaría el nombre 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 funciones 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.

El resultado de DeepSWE es una razón sólida para probar Luna Max en serio. Su tasa de éxito queda dentro de la incertidumbre de Sol High y su precio actual de API es mucho menor. Eso no convierte los modelos en intercambiables. Para decidir cuál es más barato y mejor para mi trabajo, también tengo que contar la dirección, la revisión, las reparaciones y los intentos fallidos que el leaderboard omite.