Diagrama del benchmark ITBench-AA SRE
Diagrama del benchmark ITBench-AA SRE

Artificial Analysis y el IBM Software Innovation Lab anunciaron ITBench-AA, una nueva serie de benchmarks que evalua modelos resolviendo tareas agenticas de IT empresarial. La primera entrega aborda Site Reliability Engineering (SRE) y los resultados son severos: ningun modelo frontera supera el 50% de aciertos. El dataset base lo desarrollo IBM con su experiencia en operaciones IT corporativas; Artificial Analysis trabajo seis meses con ese equipo para adaptarlo a la evaluacion de modelos frontera, partiendo por SRE y con planes de expandir a Financial Operations (FinOps) y Chief Information Security Officer (CISO).

¿Que mide exactamente ITBench-AA SRE?

El benchmark tiene 59 tareas en total: 40 publicas y 19 nuevas reservadas como held-out. Cada tarea entrega un snapshot de un incidente real en Kubernetes con alertas, eventos, trazas, metricas, logs y la topologia de la aplicacion. El modelo debe identificar el conjunto minimo de entidades Kubernetes (deployments, services, pods, etc.) que son la causa raiz independiente del incidente.

Los fallos cubren los modos tipicos de SRE: agotamiento de cuotas de recursos, rollouts fallidos, agotamiento de pools de conexion, particiones de red, fallas de infraestructura y errores inyectados por chaos engineering. Cada tarea se resuelve dentro de Stirrup, el harness agentico open source de Artificial Analysis, con acceso shell a un filesystem sandbox que contiene los logs y snapshots relevantes. El tope es de 100 turnos por tarea, con tres repeticiones cada una.

Tabla comparativa: top 8 modelos en ITBench-AA SRE

ModeloScoreCosto por tarea
Claude Opus 4.7 (Adaptive, Max Effort)47%USD 5.38
GPT-5.5 (xhigh)46%n/d
Qwen3.7 Max42%n/d
GLM-5.1 (Reasoning)40%USD 1.23
Gemini 3.5 Flash (high)40%USD 1.70
DeepSeek V4 Pro (Reasoning, Max Effort)38%n/d
Gemma 4 31B (Reasoning)37%USD 0.14
Gemini 3.1 Pro Preview30%USD 2.23

¿Por que mas turnos no significan mejor resultado?

Una observacion contraintuitiva: el numero de turnos varia casi 3 veces entre modelos y las trayectorias largas no se traducen en mayor precision. GPT-5.5 (xhigh) promedia 31 turnos por tarea con 46% de aciertos, mientras Gemini 3.1 Pro Preview promedia 83 turnos y queda en 30%.

Comparativa turnos vs score por modelo
Comparativa turnos vs score por modelo

La razon es metodologica. El sistema de scoring usa average precision at full recall: si un modelo no identifica todas las causas raiz, saca 0.0 en esa repeticion. Si las identifica todas, recibe un score igual a su precision, es decir, la fraccion de entidades que envio que son causas raiz reales. Los modelos que sobre-investigan terminan sumando como falsos positivos mecanismos upstream (por ejemplo, un controlador de chaos-mesh) o sintomas co-ocurrentes que no son la causa raiz. Gemma 4 31B con 58 turnos saca 37%, superando a Gemini 3.1 Pro Preview que duplica los turnos para quedar siete puntos atras.

Los open weights estan en la frontera de costo

Curva de costo vs score con modelos open weights destacados
Curva de costo vs score con modelos open weights destacados

Los pesos abiertos quedan bien parados en la relacion costo-rendimiento. Gemma 4 31B (Reasoning) saca 37% a USD 0.14 por tarea, superando a Gemini 3.1 Pro Preview (USD 2.23 por tarea, 30%) tanto en score como en costo. GLM-5.1 (Reasoning) saca 40% a USD 1.23, empatado con Gemini 3.5 Flash (high) (USD 1.70) en score pero a menor costo. Claude Opus 4.7 lidera el leaderboard pero es 38 veces mas caro por tarea que Gemma 4 31B.

¿Como se hace en la practica una tarea SRE?

En una de las tareas publicas el agente recibe sintomas de fallas en el frontend. Usa comandos shell para inspeccionar el snapshot offline: revisa alertas para identificar la ventana del incidente, despues trazas y logs para acotar la falla al trafico del frontend. La topologia apunta a los servicios afectados y los manifiestos Kubernetes revelan una NetworkPolicy bloqueando el frontend. El diagnostico exitoso identifica la entidad responsable: otel-demo/NetworkPolicy/frontend-block-all-ports.

Ejemplo de tarea SRE resuelta paso a paso
Ejemplo de tarea SRE resuelta paso a paso

¿Que significa para el mercado LatAm?

Para equipos chilenos y latinoamericanos que operan plataformas SaaS sobre Kubernetes, el dato relevante no es solo cual modelo lidera, sino que el agente mas barato resuelve el 79% del problema del mas caro al 2.6% del costo. Una empresa con 1.000 incidentes mensuales podria pagar USD 140 con Gemma 4 31B contra USD 5.380 con Claude Opus 4.7, sacrificando 10 puntos de precision. Decisiones de tooling de SRE asistido pueden empezar a apoyarse en numeros publicos, no en demos.

El paper academico de ITBench esta en arXiv: arxiv.org/abs/2502.05352. El codigo y dataset estan en GitHub y en el repo Hugging Face. El leaderboard se actualiza en artificialanalysis.ai/evaluations/itbench-aa.