Resumen Técnico: ORCA-BENCH: ¿Qué tan listos están los agentes de modelos de lenguaje para las guardias (oncall)?

Planteamiento del Problema

Si bien los Grandes Modelos de Lenguaje (LLM) han demostrado competencia en la escritura, el parcheo y la búsqueda de código dentro de repositorios estáticos, aún no han demostrado ser capaces de gestionar la fiabilidad de sistemas de producción en vivo. El Análisis de Causa Raíz (RCA) en un contexto de Ingeniería de Fiabilidad de Sitios (SRE) difiere fundamentalmente de los benchmarks tradicionales de ingeniería de software. En producción, un ingeniero de guardia recibe un reporte ambiguo en lenguaje natural (por ejemplo, "los usuarios están teniendo problemas") horas después de que comienza un incidente. Debe razonar sobre una pila ruidosa y dinámica de métricas, registros (logs) y trazas de una malla de microservicios en vivo para identificar la falla específica de una característica, despliegue o componente. Los benchmarks existentes no logran capturar esta complejidad porque a menudo dependen de fallas sintéticas, carecen de acceso a interfaces de telemetría bruta o al código fuente, o no varían sistemáticamente la especificidad de los reportes de usuario y el tiempo de detección (TTD).

Metodología

Los autores presentan ORCA-bench, un benchmark diseñado para evaluar agentes de codificación de propósito general en un entorno de guardia con fidelidad de producción. La metodología consta de cuatro componentes principales:

1. El Entorno (La Pila Completa de Evidencia)

ORCA-bench utiliza un sistema de microservicios con instrumentación OpenTelemetry (el "Astronomy Shop") que ejecuta seis días de carga de usuario simulada continua. A diferencia de trabajos previos que proporcionan CSVs brutos o herramientas personalizadas, ORCA-bench expone la pila completa de evidencia a través de interfaces realistas:

• Métricas: Accedidas vía Prometheus.
• Registros (Logs): Accedidos vía OpenSearch.
• Trazas: Accedidas vía Jaeger.
• Interfaz: Toda la telemetría se consulta a través de una API de Grafana.
• Código Fuente: Se proporciona acceso total al código fuente del sistema a través de una terminal.
  El conjunto de datos comprende 50 GB de datos a lo largo de seis días, cubriendo 19 microservicios escritos en 13 lenguajes diferentes.

2. Generación de Tareas y Programación

El benchmark genera 1,079 tareas de RCA activando 11 interruptores de funciones (feature flags) reales en lugar de inyectar fallas sintéticas. Las tareas se estructuran en torno a un programa de seis días con 13 escenarios, incluyendo tipos de fallas aisladas, independientes, conflictivas, en cascada y secuenciales.

• Especificidad Variable: Las tareas varían en "especificidad del problema" (Fácil, Medio, Difícil), que van desde mensajes de error precisos hasta reportes vagos como "los usuarios informan problemas en el sitio".
• Tiempo de Detección (TTD): El tiempo entre el inicio del incidente y el comienzo de la investigación varía de 15 minutos a 24 horas.
• Tiempo del Reporte: El tiempo en que el usuario reporta el problema está parametrizado (exacto, rango exacto, rango amplio) para simular la ambigüedad del mundo real.
• Tareas de Control: 195 tareas son "de control", donde no hay ningún incidente activo, probando la capacidad del agente para identificar correctamente la ausencia de un problema.

3. Curación de la Verdad Fundamental (Ground Truth)

La verdad fundamental es curada y validada por expertos en SRE.

• Síntomas: Los síntomas en el frontend se verifican reproduciendo los interruptores de funciones en un navegador. Los síntomas de telemetría (métricas, logs, trazas) se recolectan mediante un flujo de trabajo semiautomático validado por dos expertos en SRE.
• Causas Raíz: Para cada tarea, la verdad fundamental se define como el conjunto de causas raíz plausibles (interruptores de funciones activos durante la ventana) que podrían explicar el problema visto por el usuario.
• Verificación: Un subconjunto de 40 tareas ("ORCA-bench Verified") tiene cada etiqueta de verdad fundamental y cada puntuación por modelo confirmada manualmente por humanos.

4. Marco de Evaluación

La evaluación utiliza un LLM-como-juez (GPT-5.4) para calificar los reportes de los agentes, con una re-calificación humana en el subconjunto "Verified" para asegurar la alineación (Cohen's $\kappa_w = 0.90$).

• Rúbrica de Calificación: Los reportes se califican en una escala de 0 a 3 por cada causa raíz plausible, evaluando si el agente confirmó los síntomas, identificó señales de telemetría específicas y nombró correctamente el mecanismo.
• Métricas:
  • Precisión de RCA: La fracción de tareas donde el agente nombra cada una de las causas raíz plausibles listadas.
  • Profundidad de RCA: La puntuación media (0–3) a través de todas las rúbricas, que indica qué tan lejos progresó el agente hacia la causa raíz.
  • Tasa de Alucinación: La fracción de reportes no vacíos donde el agente nombra una causa raíz que no coincide con ninguna de las causas plausibles.

Resultados Clave

El artículo evalúa cinco agentes de frontera (Opus 4.7, Sonnet 4.6, GPT-5.5, GLM-5, DeepSeek-V4-Pro) en el benchmark.

• Bajo Rendimiento General: Incluso los modelos con mejor desempeño tienen dificultades. En las tareas de dificultad Media (la configuración de entrada realista), la mejor Precisión de RCA es del 25.3%. En las tareas Difíciles, la precisión cae al 10.0%.
• Altas Tasas de Alucinación: Los agentes frecuentemente alucinan causas raíz implausibles. La tasa de alucinación oscila entre el 7% (DeepSeek-V4-Pro) y el 40% (GLM-5).
• Impacto de la Eliminación de Contexto: Eliminar el acceso al código fuente degrada el desempeño en todas las métricas. La Precisión de RCA cae entre 9 y 16 puntos porcentuales, y las tasas de alucinación aumentan significamente.
• Problemas de Recuperación de Telemetría: Los agentes luchan por consultar la telemetría de manera efectiva. Hasta el 40% de las llamadas de telemetría resultan en error o devuelven resultados vacíos. GPT-5.5 es el más eficiente, mientras que otros suelen fallar al intentar recuperar los datos necesarios.
• Modos de Falla: Los agentes tienden a distraerse con el ruido de fondo (síntomas ruidosos pero irrelevantes) y tienen dificultades para encontrar exhaustivamente todas las causas raíz cuando ocurren múltiples problemas simultáneamente. También fallan al cuantificar consistentemente los aumentos de severidad o al atribuirlos a eventos distintos.
• Claude Fable 5: En un subconjunto de tareas, Claude Fable 5 logró puntuaciones más altas (58.2% de profundidad, 40.6% de precisión en tareas Verified), pero aun así no alcanzó una fiabilidad perfecta, con ganancias observadas principalmente en tareas Medianas en lugar de las Fáciles.

Significado y Reivindicaciones

Los autores posicionan a ORCA-bench como el primer benchmark de SRE que expone a los agentes de modelos de lenguaje a un sistema de extremo a extremo con instrumentación OpenTelemetry, combinando interfaces de telemetría reales, señales brutas y código fuente bajo la ambigüedad típica de la producción.

La principal afirmación del artículo es que los agentes de codificación de frontera aún no están listos para las guardias (oncall). El desempeño reportado (por ejemplo, 25.3% de precisión en tareas Medianas) se presenta como un límite inferior de la inversión de ingeniería requerida antes de que los agentes puedan ser confiados de manera segura con la fiabilidad de la producción. Los autores argumentan que los sistemas de producción reales son órdenes de magnitud más grandes, más dinámicos e idiosincrásicos que el banco de pruebas de 50 GB utilizado aquí. Además, las simplificaciones en el benchmark (código base fijo, tareas aisladas, sin bucle de acción) significan que la brecha real en escenarios del mundo real es probablemente aún mayor.

El trabajo destaca que los agentes actuales carecen de la capacidad de razonar sobre datos de telemetría multimodales y ruidosos en conjunto con el código fuente para manejar reportes de incidentes ambiguos y con retraso en el tiempo, un requisito crítico para la fiabilidad autónoma de los sistemas.