Benchmark · agentic
Multi-SWE-bench
Multi-SWE-bench mide si un agente de codificación con IA puede resolver issues reales de GitHub en muchos repositorios y lenguajes de programación, no solo Python. La métrica principal es la tasa de resolución (resolution rate): el porcentaje de instancias cuya corrección hace pasar el conjunto de pruebas oculto.
Leer más
- Ejemplo
- Una tarea representativa: dado un informe de error o solicitud de función real de un proyecto de código abierto escrito en un lenguaje como Java, Go, Rust, TypeScript, JavaScript, C o C++, junto con el repositorio en el commit anterior a la corrección, el agente debe generar un parche que resuelva el problema descrito.
- Puntuación
- Cada instancia se califica como aprobada/reprobada mediante ejecución. El parche del agente se aplica al repositorio y se ejecutan las pruebas del proyecto; la instancia se considera resuelta solo si las pruebas designadas FAIL_TO_PASS ahora pasan y todas las pruebas PASS_TO_PASS siguen pasando. La puntuación informada es la tasa de resolución (instancias resueltas ÷ total), normalmente a pass@1, y puede desglosarse por lenguaje y por dificultad anotada por expertos (easy/medium/hard).
- Verificación
- La aceptación se basa por completo en la ejecución dentro de una imagen Docker por instancia que reproduce exactamente la cadena de herramientas del lenguaje y las dependencias. El parche generado debe aplicarse sin conflictos y luego se ejecutan las pruebas fail-to-pass y pass-to-pass; no hay evaluación mediante LLM ni comparación textual con el parche de referencia del desarrollador.
- Por qué importa
- SWE-bench resultó influyente pero solo abarca Python, mientras que la ingeniería de software real utiliza muchos lenguajes. Multi-SWE-bench prueba si los agentes de codificación generalizan entre lenguajes en issues auténticos, con etiquetas de dificultad de expertos, ofreciendo una señal más difícil, realista y menos saturada de la capacidad práctica de ingeniería de software.
Ejemplo resuelto
Tarea
Instancia ilustrativa en el formato de Multi-SWE-bench — lenguaje: Go, una pequeña biblioteca de colecciones genéricas. problem_statement: «Stack.Pop() en una pila vacía devuelve el valor cero con un error nil, ocultando silenciosamente errores en quien lo llama; en su lugar debería devolver el centinela ErrEmpty». Se te entrega el repositorio en el commit base con el fallo y la prueba que falla. FAIL_TO_PASS: TestPopEmptyReturnsError. PASS_TO_PASS: TestPushThenPop, TestLen. Envía un parche que haga pasar la prueba que falla sin romper las que pasan.
Solución
--- a/stack.go
+++ b/stack.go
@@ func (s *Stack[T]) Pop() (T, error) {
+ if len(s.items) == 0 {
+ var zero T
+ return zero, ErrEmpty
+ }
n := len(s.items)
v := s.items[n-1]
s.items = s.items[:n-1]
return v, nil
}Explicación
La corrección añade a Pop una comprobación de vacío que devuelve el centinela ErrEmpty (junto con el valor cero del tipo) exactamente como espera TestPopEmptyReturnsError, dejando sin cambios la ruta normal de extracción para que TestPushThenPop y TestLen sigan pasando. La calificación es puramente por ejecución: el arnés aplica el parche en la imagen Docker de la instancia y la marca como resuelta solo si la prueba FAIL_TO_PASS pasa a aprobar y ninguna prueba PASS_TO_PASS retrocede.
Aún no hay puntuaciones verificadas para este benchmark.