DeepSWE v1.1: qué mide un parche que supera su verificador y cuándo su pass@1 deja de demostrar que el agente resolvió la tarea

La cifra no pertenece solo al modelo

Una puntuación de DeepSWE v1.1 no describe una propiedad aislada de un modelo de lenguaje. Describe el resultado de una configuración experimental completa: un modelo servido por un proveedor, un nivel de esfuerzo de razonamiento cuando exista esa opción, un arnés de agente, un conjunto de herramientas, límites de contexto y tiempo, instrucciones, política de parada y un sistema de evaluación. La unidad observada es el parche comprometido por esa configuración al enfrentarse a una tarea concreta, no una respuesta textual del modelo ni una capacidad general medida fuera de ese entorno.

Esta distinción es particularmente importante al leer el leaderboard de DeepSWE. El sitio oficial indica que los modelos se ejecutan con mini-SWE-agent para buscar consistencia, pero esa decisión no elimina todas las variables. Una misma familia de modelos puede aparecer con distintos niveles de razonamiento o proveedores; además, una actualización del arnés, del prompt, de las herramientas o de la infraestructura puede cambiar el resultado sin que haya cambiado el modelo subyacente. Por ello, una comparación directa requiere comprobar que ambas filas usan condiciones equivalentes y la misma versión de evaluación.

El término pass@1 tampoco debe leerse como una garantía de que el agente resolverá la siguiente incidencia de un repositorio propio. En el artículo metodológico de DeepSWE, pass@1 se define como el promedio, por tarea, de la tasa de éxito obtenida en las ejecuciones. Es una agregación del desempeño observado en esta colección y con este protocolo. Sirve para resumir resultados experimentales, pero no identifica por sí sola la causa de cada éxito, de cada fallo o de una diferencia entre configuraciones.

Qué intenta medir DeepSWE

DeepSWE se presenta como un benchmark para agentes de ingeniería de software que trabajan en tareas originales de largo recorrido. La documentación de los autores describe 113 tareas distribuidas en 91 repositorios. Cada tarea combina un contexto de repositorio con una petición de cambio y mecanismos programáticos para verificar el comportamiento esperado. La pretensión no es recuperar una corrección ya publicada, sino producir una solución nueva para la tarea planteada.

Según la presentación de Datacurve, las soluciones de referencia se escribieron desde cero y no se copiaron ni adaptaron de una solicitud de cambios, un commit o un parche público existente. Algunas tareas pueden estar motivadas por problemas no resueltos, pero esa motivación no equivale a que exista una solución upstream utilizable como referencia. Esta es una alegación de diseño de los creadores; resulta relevante porque intenta reducir el solapamiento con benchmarks construidos a partir de incidencias históricas, pero no basta por sí misma para demostrar ausencia de contaminación en datos de entrenamiento o en herramientas externas.

El formato público del repositorio oficial resulta útil para una auditoría porque documenta componentes como metadatos, prompt, Dockerfile, pruebas o verificador y solución de referencia. Eso permite inspeccionar una tarea particular en vez de inferir su dificultad a partir del nombre del repositorio. Aun así, la disponibilidad de artefactos no convierte automáticamente toda conclusión en reproducible: para repetir una fila hacen falta también el commit, las imágenes o dependencias efectivamente usadas, las credenciales y versiones de las herramientas, y los registros de ejecución pertinentes.

El parche, el contenedor limpio y el verificador

En v1.1, Datacurve describe un procedimiento en el que se evalúa solamente el parche comprometido en un contenedor de verificación separado y limpio. El repositorio oficial también documenta la extracción del commit como parche y su aplicación en un entorno prístino desde esa versión. El diseño busca separar el resultado final de efectos transitorios que puedan haber ocurrido durante la trayectoria del agente, como cambios no comprometidos o manipulaciones del proceso de prueba dentro de su entorno de trabajo.

La documentación de v1.1 afirma que el informe CTRF registra por nombre cada prueba que define la tarea. Bajo ese planteamiento, eliminar pruebas o forzar una salida temprana debería aparecer como resultados ausentes o fallidos, no como un aprobado. También se presentan cambios para corregir deriva de dependencias y pruebas inestables. Son mejoras razonables en el objetivo de evaluar un parche transportable, pero deben leerse como decisiones de implementación del benchmark: un sistema de puntuación siempre incorpora supuestos sobre qué archivos restaurar, qué comandos ejecutar y qué evidencia cuenta como resultado.

La separación entre contenedor de agente y contenedor de verificación tiene una consecuencia práctica. Un parche puede funcionar durante una trayectoria concreta y fallar al reaplicarse de forma limpia; en ese caso, suspender expresa una falta de reproducibilidad del cambio final según el protocolo. En sentido inverso, un cambio que cumple la intención de la tarea puede suspender si el proceso de restauración, sustitución de archivos o detección de resultados interfiere con el comportamiento que debía verificarse. Distinguir ambos casos exige conservar artefactos suficientes para revisar el veredicto.

Qué puntúan pass@1 y pass@4, y qué debe declararse

El paper de DeepSWE define pass@1 como la media por tarea de la tasa de éxito, y pass@4 como la fracción de tareas resueltas en al menos uno de cuatro intentos. La diferencia importa: pass@1 informa del rendimiento de un intento individual bajo la distribución de ejecuciones usada; pass@4 refleja el beneficio de disponer de varios intentos. No son medidas intercambiables, y una clasificación por una de ellas puede ordenar de otra manera las configuraciones.

Los autores documentan aproximadamente cuatro rollouts por tarea e intervalos de confianza del 95 %. Esos intervalos ayudan a evitar una lectura excesiva de separaciones pequeñas, especialmente cuando configuraciones cercanas se solapan. Sin embargo, un intervalo no corrige una incompatibilidad metodológica. Si dos resultados proceden de distintos verificadores, políticas de reintento, plazos de ejecución o criterios de exclusión, su incertidumbre estadística no resuelve el cambio de objeto medido.

Una ficha de resultado responsable debe declarar, como mínimo, la versión de DeepSWE, el modelo y proveedor, la versión de mini-SWE-agent, el nivel de razonamiento, la cantidad de rollouts, la política de parada, los límites de tiempo y contexto, la fecha o versión de la infraestructura y el tratamiento de errores. También debe separar la puntuación calculada de los casos excluidos. Sin esa información, el lector no puede saber si una diferencia se debe a capacidad de resolución, disponibilidad del servicio, decisiones de presupuesto o cambios del evaluador.

Fallos que cuentan, errores excluidos y sesgo de selección

La metodología publicada por los autores indica que los timeouts cuentan como fallos. También señala que pueden excluirse errores de proveedor, de red o del verificador. Esta distinción tiene sentido operativo: un corte externo al agente no equivale necesariamente a una incapacidad para resolver el problema. Pero la exclusión introduce una obligación de transparencia, porque la clasificación de un evento determina qué denominador se usa en la puntuación publicada.

Un timeout puede revelar una limitación real del sistema que se pretende desplegar, incluso cuando no revela una limitación semántica del modelo. Por ello, una evaluación útil debería mostrar tanto la tasa principal bajo sus reglas como el número y la naturaleza de ejecuciones excluidas, además de los artefactos que justifican cada decisión. Agrupar bajo “infraestructura” un error reproducible en la preparación de la tarea, por ejemplo, impediría a terceros valorar si se trata de un defecto del benchmark o de una condición excepcional del entorno.

También conviene preguntar si una exclusión se decide antes de inspeccionar el parche y si la regla se aplica de igual modo a todos los modelos. Una política retrospectiva o poco documentada puede favorecer sin querer a una configuración. No hay evidencia aportada aquí para afirmar que eso ocurra en DeepSWE; es una condición de auditoría que debería verificarse antes de usar la puntuación para compras, selección de proveedores o decisiones de despliegue.

Por qué v1 y v1.1 no deben mezclarse sin reejecutar

Datacurve afirma que v1.1 conserva las mismas tareas, pero modifica la ejecución y la evaluación. Entre los cambios descritos figuran la verificación del parche comprometido en un contenedor limpio, el registro CTRF y correcciones relativas a dependencias y pruebas inestables. Aunque el conjunto de enunciados permanezca, una modificación del entorno de puntuación puede cambiar qué parches pasan y cuáles fallan.

Esto impide tratar una cifra de v1 y otra de v1.1 como puntos de una misma serie sin una advertencia clara. No sería válido atribuir toda diferencia a una mejora o regresión del modelo si también ha cambiado el modo de reconstruir el entorno o de comprobar las pruebas. La vía más sólida para comparar versiones es reejecutar la misma configuración con cada protocolo y publicar los resultados por tarea, junto con los cambios de veredicto.

La misma cautela vale para comparaciones dentro de v1.1 si el leaderboard evoluciona. Una tabla pública es un registro valioso de ejecuciones declaradas, no una prueba suficiente de equivalencia histórica. Quien necesite una decisión de alto impacto debería congelar un commit del benchmark y del arnés, conservar las imágenes de contenedor y ejecutar una matriz controlada de configuraciones.

El conflicto sobre las modificaciones de pruebas

La revisión independiente de Epoch AI plantea una limitación específica de DeepSWE v1.1. Según esa revisión, sus autores confirmaron manualmente al menos 23 falsos negativos entre las 113 tareas. Explican que 18 de esos casos se relacionan con agentes que modifican pruebas existentes y con una preparación posterior del verificador que restaura o sustituye archivos. El resultado señalado es que un agente puede haber producido un cambio funcionalmente correcto para la intención de la tarea y, aun así, recibir un suspenso debido a la interacción entre su parche y el protocolo de evaluación.

Este hallazgo debe atribuirse a Epoch AI y leerse en su alcance declarado. La revisión indica que se detuvo después de superar su umbral para considerar que el benchmark era defectuoso; por tanto, no ofrece una estimación definitiva de la tasa total de falsos negativos ni demuestra que cada resultado de DeepSWE sea inválido. Tampoco permite inferir, solo a partir de esa cifra, cuánto cambiarían las posiciones del leaderboard: para ello haría falta repetir los casos afectados bajo una versión corregida y publicar la reasignación de veredictos por configuración.

Existe además una tensión real entre dos objetivos. El evaluador quiere impedir que un agente consiga un aprobado alterando las pruebas de la tarea. Pero una regla que restaura o reemplaza archivos debe distinguir entre una manipulación que elude la comprobación y una edición de pruebas que forma parte de un cambio legítimo o que interactúa de manera no prevista con el verificador. La documentación oficial de v1.1 sostiene que el informe de pruebas detecta ausencias y salidas tempranas. La auditoría sugiere que esa salvaguarda no evita todos los falsos negativos identificados. Con las fuentes disponibles, ambas afirmaciones describen niveles distintos: el diseño pretendido y un conjunto de comportamientos observados en revisión.

Qué permite concluir una puntuación alta

Una puntuación alta en DeepSWE v1.1 es evidencia de que una configuración concreta consiguió producir parches que el protocolo aceptó en una colección de tareas originales de ingeniería de software. Cuando el resultado se acompaña de artefactos y de condiciones reproducibles, ofrece una señal útil para preseleccionar agentes destinados a tareas de reparación y desarrollo autónomo con repositorios, comandos y pruebas.

La señal es más informativa que una evaluación limitada a fragmentos de código aislados porque incluye navegación por un repositorio, modificaciones de varios archivos, uso de herramientas y una verificación funcional. También puede ayudar a detectar diferencias prácticas entre configuraciones que parecen similares en benchmarks más saturados. El valor, no obstante, es condicional: depende de que la población de tareas, las restricciones del arnés y el verificador se parezcan al caso de uso sobre el que se va a decidir.

La conclusión prudente no es que el agente “sabe mantener software en producción”, sino que ha mostrado capacidad medida para resolver una fracción de tareas de este benchmark bajo un protocolo definido. Esa formulación conserva información útil y evita trasladar un resultado experimental a ámbitos que DeepSWE no observa directamente.

Qué no permite concluir y cómo leer una fila del leaderboard

El benchmark no acredita por sí solo fiabilidad en el repositorio propio, seguridad de los cambios, calidad de una revisión de diseño, compatibilidad con políticas internas ni capacidad de depurar sistemas conectados a producción. Tampoco mide de forma completa el coste operativo: una puntuación comparable puede requerir distinto número de tokens, tiempo de pared, reintentos o supervisión humana. La autonomía empresarial exige además permisos, aislamiento, control de dependencias, revisión, observabilidad y procedimientos de reversión.

Una fila tampoco demuestra que el agente no haya encontrado una solución que explote un vacío del verificador, ni que todo suspenso represente una incapacidad de resolver el requisito. La revisión de Epoch AI hace esta última salvedad especialmente relevante en los casos que examinó. Por otro lado, una auditoría parcial de falsos negativos no permite concluir que el benchmark carezca de valor. La interpretación correcta es que el error de medición y el desacuerdo entre intención y veredicto deben formar parte del análisis de riesgo.

Para comparar Grok 4.6, DeepSeek V4.1 Flash u otros sistemas en DeepSWE, un comprador técnico debería primero filtrar filas por la misma versión, el mismo arnés y condiciones de inferencia equivalentes. Después debe revisar los intervalos, los errores excluidos y los artefactos de tareas límite. Finalmente, debería complementar la preselección con una evaluación interna en repositorios representativos, con políticas de seguridad y costes cercanos al despliegue previsto. DeepSWE puede ser una entrada de esa decisión, no su sustituto.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.