IBM Research y Artificial Analysis presentan ITBench-AA, el primer benchmark orientado a tareas agenticas de TI para entornos empresariales. Arranca con tareas de Site Reliability Engineering (SRE) sobre snapshots de Kubernetes y muestra que los modelos frontera aún tienen un rendimiento limitado: ninguno supera 50%.
Qué mide ITBench-AA y por qué importa
ITBench-AA evalúa la capacidad de modelos y agentes para diagnosticar incidentes reales de Kubernetes. Cada tarea entrega un snapshot con alerts, eventos, traces, métricas, logs y la topología de la aplicación. El objetivo es identificar el conjunto mínimo de entidades de Kubernetes que causan el incidente (Deployments, Services, Pods, NetworkPolicy, etc.).
¿Por qué esto es relevante? Porque en operaciones reales no basta con señalar síntomas: necesitas identificar la raíz mínima para aplicar un parche o un rollback. Ese tipo de razonamiento y búsqueda en evidencia es exactamente lo que ITBench-AA pone a prueba.
Metodología técnica (resumen práctico)
- 59 tareas SRE en total: 40 públicas y 19 nuevas, retenidas para evaluación.
- Los modelos se ejecutan en el arnés open source
Stirrup, con acceso a un filesystem sandbox y una interfaz shell para inspeccionar logs y artefactos. 100-turns máximo por tarea y 3 repeticiones por tarea. - Cada intento debe devolver un
JSONestructurado con la lista de entidades raíz propuestas.
Regla de scoring clave: se usa average precision at full recall. Si la predicción omite cualquier causa verdadera, esa repetición puntúa 0. Si identifica todas, la puntuación es su precisión (true positives/(true positives+false positives)). El puntaje final es el promedio sobre 59 tareas × 3 repeticiones.
Ese esquema penaliza fuertemente las respuestas prolijas que agregan causas irrelevantes. Mejor ser preciso y conciso que arrojar muchas hipótesis.
Resultados principales y costes
- Líderes del benchmark (SRE): Claude Opus 4.7 (Adaptive Reasoning, Max Effort) 47%, GPT-5.5 (xhigh) 46%, Qwen3.7 Max 42%. Ninguno supera 50%.
- Open weights destacados: GLM-5.1 (Reasoning) 40%, Gemma 4 31B (Reasoning) 37%, DeepSeek V4 Pro 38%.
- Comportamiento de turns: la longitud de la investigación no correlaciona con mejor precisión. GPT-5.5 (xhigh) promedia 31 turns con 46%, mientras que Gemini 3.1 Pro Preview promedia 83 turns con 30%.
- Costo por tarea varía mucho: Claude Opus lidera en puntaje pero cuesta alrededor de $5.38 por tarea; Gemma 4 31B alcanza 37% a $0.14 por tarea, mostrando un trade-off interesante entre rendimiento y precio.
Estas cifras muestran dos cosas: (1) la dificultad intrínseca de las tareas SRE agenticas y (2) el potencial práctico de modelos open weights que ofrecen mejor costo-beneficio en ciertos escenarios.
Un ejemplo concreto de tarea
En una tarea pública, el agente explora un snapshot con fallas de usuario en el camino frontend. El flujo de trabajo típico fue:
- Revisar alerts para determinar la ventana del incidente.
- Explorar traces y logs para localizar la ruta afectada: tráfico frontend.
- Consultar la topología para encontrar servicios relacionados.
- Inspeccionar manifests de Kubernetes y detectar una NetworkPolicy que bloquea tráfico:
otel-demo/NetworkPolicy/frontend-block-all-ports.
El diagnóstico correcto es exactamente esa entidad NetworkPolicy. Agregar la presencia de un controlador de inyección de fallos como causa adicional sería considerado una falsa positiva bajo la métrica de ITBench-AA.
Lecciones para investigadores y operadores
- Diseño de agentes: evita estrategias que sobreinvestiguen. Preguntar más no siempre ayuda; puede penalizar la precisión bajo la regla de recall-gated precision.
- Entrenamiento y fine-tuning: los datasets deben reforzar identificación mínima de causas y manejo de evidencia contradictoria.
- Harness reproducible: mantener
Stirrupconstante entre modelos permite comparaciones justas. Es un buen patrón para futuras evaluaciones agenticas. - Coste vs rendimiento: para adopciones empresariales tempranas, los modelos open weights ofrecen una relación rendimiento/costo atractiva. Para casos críticos, modelos más caros pueden rendir mejor, pero la mejora no es dramática.
Donde ITBench-AA puede empujar el campo
ITBench-AA no es solo una foto del estado actual; es una plataforma para mejorar. El plan es ampliar el suite a FinOps y tareas de CISO, lo que empujará a modelos a integrar evidencia heterogénea (logs, facturas, políticas) y a tomar decisiones más peligrosas con mayor responsabilidad.
Técnicamente, los retos claros son:
- Mejorar la calibración entre identificación y confianza. Un sistema que sabe cuándo abstenerse vale mucho.
- Diseñar agentes con políticas de búsqueda que prioricen minimalidad de causas.
- Integrar técnicas de grounding en traces y topologías para reducir falsos positivos.
Reflexión final
Si trabajas en SRE, IA aplicada o eres responsable de adoptar modelos en operaciones, ITBench-AA te da una radiografía cruda: los modelos están avanzando, pero aún no son sustitutos plenos para el juicio humano en incidentes complejos. Lo interesante es que la brecha no es solo técnica, es de enfoque: cómo estructuramos la búsqueda de evidencia y cómo penalizamos las hipótesis extras.
Para los desarrolladores de modelos, la invitación es clara: optimiza por precisión mínima y coste, no por número de pasos. Para operadores, evalúa la relación rendimiento/costo y considera pipelines híbridos donde la IA sugiere causas pero un humano verifica en los casos críticos.
Fuente original
https://huggingface.co/blog/ibm-research/itbench-aa
Más recursos citados en la nota: ITBench paper (arXiv), GitHub ITBench, ITBench-AA leaderboard, ITBench-AA en HuggingFace