📖 AgentBench for Elastic — Metodología del Benchmark

AgentBench for Elastic (v1.0) es un framework de evaluación end-to-end que mide cómo diferentes modelos de lenguaje (LLM) funcionan como agentes de IA dentro de Elastic Agent Builder 9.3. A diferencia de los benchmarks genéricos (MMLU, HumanEval, etc.) que evalúan capacidades aisladas del modelo, AgentBench evalúa el rendimiento agentic real — el modelo integrado en un stack de producción, con herramientas, datos y restricciones reales. Medimos:

• 🔧 Usar herramientas correctamente — elegir la tool adecuada (search, ES|QL, mapping...)
• 🎯 Dar respuestas correctas (Correctness) — verificadas contra un ground truth detallado mediante descomposición en claims con media geométrica (un solo error crítico lleva el score a 0)
• ⚓ Basar sus respuestas en datos reales (Groundedness) — cada afirmación se compara contra el output real de las tools con media aritmética (proporción justa de claims fundamentados)
• 📋 Seguir instrucciones — formato, filtros, restricciones específicas
• 🧠 Razonar en múltiples pasos — analizar, buscar, combinar resultados entre índices
• 💬 Mantener contexto — recordar turnos previos en conversaciones de hasta 5 turnos
• 🛡️ Resistir adversarial inputs — campos inexistentes, peticiones contradictorias, operaciones imposibles
• 🔀 Trabajar entre índices — correlacionar datos de múltiples fuentes (cross-index)
• 📐 Cumplir formatos estrictos — responder solo con JSON, solo un número, o exactamente N bullet points
• ⚡ Ser eficiente — responder rápido y a bajo coste

Paso a paso:

1. Se envía la pregunta al agente a través de la API de Kibana (POST /api/agent_builder/converse). En tests multi-turn, se envían múltiples turnos en la misma conversación.
2. El LLM decide qué hacer — razona, elige herramientas, ejecuta queries contra Elasticsearch. El agente tiene acceso a search, ES|QL, mappings y listado de índices.
3. Se captura todo — la respuesta, los tools usados (con sus outputs reales), la latencia (TTLT), los tokens (input/output), el coste real obtenido del proveedor vía OpenRouter.
4. El juez (GPT-5.2) descompone la respuesta en claims — cada afirmación atómica se evalúa individualmente para Correctness (vs ground truth) y Groundedness (vs output de tools), asignando veredictos y severidad. El juez recibe el output real de las tools (truncado a 6.000 chars) para verificar alucinaciones.
5. Se calculan las métricas localmente — Correctness con media geométrica (un error crítico lleva el score a 0), Groundedness con media aritmética (proporción justa de claims fundamentados), más métricas programáticas (latencia, coste, tool calling con overlap, error rate).
6. Se aplican pesos, dificultad y penalización por fallos — la puntuación final (★ Adjusted Overall) pondera por dificultad del test (easy ×0.7, medium ×1.0, hard ×1.3, expert ×1.6) y aplica una failure penalty que penaliza modelos con timeouts o errores. Todo se almacena en Elasticsearch con el campo model para seguimiento histórico.

🧑‍⚖️ ¿Por qué un LLM como juez?

Evaluar respuestas de IA no es trivial — no puedes comparar strings, porque una respuesta puede ser correcta de muchas formas diferentes. Utilizamos OpenAI GPT-5.2 como "LLM-as-Judge" porque:

• Puede entender semántica — si la respuesta dice lo mismo con palabras diferentes
• Puede evaluar matices — parcialmente correcto, formato adecuado pero datos incompletos
• Puede verificar alucinaciones — comparando la respuesta con el output real de los tools
• Puede descomponer en claims — extraer cada afirmación atómica y evaluarla individualmente

📦 ¿Qué recibe el juez?

Para cada test, GPT-5.2 recibe un prompt estructurado con:

• La pregunta original que se le hizo al agente
• Ground truth detallado — la respuesta correcta esperada con datos concretos verificados (cantidades exactas, nombres, valores)
• Exact answer (si aplica) — un valor numérico preciso que el agente debe proporcionar
• Output real de los tools — los datos que Elasticsearch devolvió, truncado a 6.000 chars con aviso de truncamiento
• La respuesta del agente — lo que finalmente dijo al usuario

🧩 Claim Decomposition — La clave de la evaluación

En lugar de pedir puntuaciones globales genéricas, el juez descompone la respuesta en claims atómicos — cada afirmación factual individual se evalúa por separado. Esto permite detectar:

• Errores parciales — una respuesta puede ser 90% correcta pero tener un dato crítico incorrecto
• Alucinaciones específicas — identificar exactamente qué afirmación no tiene soporte en los datos
• Claims periféricos vs centrales — un error en un detalle menor pesa menos que un error en el dato clave

Cada claim recibe dos evaluaciones independientes: Correctness (comparado contra el ground truth) y Groundedness (comparado contra el output real de los tools). Esto detecta tanto errores factuales como alucinaciones.

🏷️ Centralidad de cada claim

Cada claim se clasifica como:

• Central — Esencial para responder la pregunta del usuario (conteos, nombres, datos clave). Un error aquí es grave.
• Peripheral — Contexto adicional, notas de formato, consejos generales. Un error aquí pesa menos.

🎯 Correctness — ¿Es factualmente correcto? (vs Ground Truth)

Cada claim se compara contra el ground truth verificado para determinar si es correcto:

⚓ Groundedness — ¿Está basado en datos reales? (vs Tool Output)

Cada claim se compara contra lo que los tools realmente devolvieron, para detectar alucinaciones:

⚠️ Severity — Solo para CONTRADICTED o UNGROUNDED

Cuando un claim es incorrecto o no fundamentado, se asigna una severidad que modifica el impacto:

• critical — Números incorrectos, nombres erróneos, estados falsos. Podría causar decisiones erróneas.
• major — Error factual significativo pero menos impactante.
• minor — Pequeña imprecisión: redondeo, paráfrasis ligera.

Ejemplo: un claim "Hay 50 pedidos de Madrid" cuando el ground truth dice 49 → CONTRADICTED + severity "minor" (score 0.50 en central). Pero un claim "El cliente top es Juan García" cuando es "Hans Mueller" → CONTRADICTED + severity "critical" (score 0.0 en central).

📐 Format Score y 📝 Instruction Following Score

Además de los claims, el juez asigna dos puntuaciones simples (0–10):

• Format Score — ¿La respuesta está bien estructurada? ¿Usa markdown, tablas, listas cuando es apropiado?
• Instruction Following Score — ¿El agente respetó las restricciones específicas? (formato de tabla, número de bullets, filtros, índice concreto…)

📊 Relevance — Proporción de claims centrales

Se calcula automáticamente como la proporción de claims marcados como "central" sobre el total de claims. Un score alto indica que la respuesta es concisa y relevante — no tiene mucho "relleno" periférico.

⏱️ Latency Score

Basado en el tiempo total de respuesta (Time To Last Token). Interpolación lineal entre umbrales:

💰 Cost Score

Basado en el coste real en USD por query, obtenido del proveedor vía OpenRouter (precio real del provider, no el precio base):

🔧 Tool Calling Score (Overlap)

Mide si el modelo usó al menos una de las herramientas esperadas. Basado en overlap de conjuntos:

¿Por qué overlap y no F1? En la práctica, los modelos inteligentes a veces usan tools adicionales (ej: consultar el mapping antes de buscar). Esto es comportamiento proactivo y deseable, no un error. El enfoque overlap recompensa usar al menos una tool correcta sin penalizar tools extra.

🚫 Error Rate Score

Penaliza errores técnicos en la ejecución de tools (timeouts de tool, errores de API, etc.):

✅ Exact Answer Check

Para tests con respuesta numérica exacta (ej: "¿Cuántos pedidos hay?"), se verifica automáticamente si la respuesta del agente contiene el valor correcto:

📊 Fase 1: Media ponderada de métricas

Cada test recibe un overall_weighted basado en estos pesos:

🎚️ Fase 2: Ponderación por dificultad

Los tests difíciles pesan más en el score global del modelo. Cada dificultad tiene un multiplicador:

⚠️ Fase 3: Failure Penalty

Los modelos con timeouts o errores reciben una penalización proporcional a su tasa de fallos:

¿Por qué? Un modelo que falla en 3 de 30 tests no solo pierde esos 3 scores — también pierde credibilidad como agente fiable. La failure penalty refleja este riesgo operativo.

easy  Fácil — 6 tests  (peso ×0.7)

Un solo paso, una sola herramienta. Ejemplo: "Lista los índices disponibles", "Cuenta cuántos documentos hay", "Busca un producto inexistente".

medium  Medio — 9 tests  (peso ×1.0)

Requiere elegir la herramienta correcta, aplicar filtros, o seguir instrucciones de formato. Ejemplo: "Lista las categorías en formato tabla markdown", "Busca pedidos de clientes en Madrid", "Corrige el error de mi query anterior".

hard  Difícil — 10 tests  (peso ×1.3)

Multi-paso, multi-turn, queries analíticas complejas, o adversarial inputs. Ejemplo: "Basándote en el mapping, escribe una query para encontrar los top 3 clientes", "Busca pedidos que sean cancelled Y delivered a la vez".

expert  Experto — 5 tests  (peso ×1.6)

Análisis temporal, cálculos derivados complejos, cross-index, multi-turn de 5 turnos, y operaciones imposibles. Ejemplo: "Compara revenue Q3 vs Q4 por categoría", "Busca los pedidos de clientes Gold cruzando dos índices", "Analiza tendencias de cancelación por trimestre y método de pago en una conversación de 5 turnos".

¿Qué herramientas tiene el agente?

El agente de Elastic Agent Builder (elastic-ai-agent) tiene acceso a estas tools:

• platform.core.search — Buscar documentos en Elasticsearch. Puede generar y ejecutar queries ES|QL internamente.
• platform.core.execute_esql — Ejecutar queries ES|QL ya preparadas (no las escribe, solo las ejecuta).
• platform.core.generate_esql — Generar una query ES|QL a partir de lenguaje natural.
• platform.core.get_index_mapping — Ver el schema/mapping de un índice.
• platform.core.list_indices — Listar índices disponibles.

Nota importante: En la práctica, platform.core.search puede generar y ejecutar ES|QL internamente. Esto significa que cuando un test pide "usar ES|QL", el agente puede usar platform.core.search y aun así ejecutar ES|QL correctamente. Por ello, el benchmark acepta ambas tools como válidas en los tests de ES|QL.

¿Cómo se calcula el Tool Calling Score?

Se usa un enfoque de overlap (no F1) para ser justo con modelos inteligentes:

• Si el modelo usó al menos una de las tools esperadas → 10.0
• Si no usó ninguna de las tools esperadas → 0.0
• Tools extra (proactivas) → No se penalizan. Un modelo que consulta el mapping antes de buscar está siendo inteligente.

En el informe, si ves un 0.0 con un icono ≠, significa que el modelo usó una herramienta diferente a la esperada. Haz clic en la fila para ver el detalle: tools esperadas vs usadas y la evaluación del juez.

Métricas adicionales de Tools

• Tool Exec Rate — % de llamadas a tools que ejecutaron sin error técnico (API errors, timeouts de tool).
• Tokens/Tool Call — Media de tokens por llamada a tool (más bajo = más eficiente). Incluye el payload de la respuesta de la tool.
• Tool Retries — Número de veces que el agente reintentó una tool que falló (indicador de resiliencia).

💲 Quality / Dollar

¿Cuánta calidad obtienes por cada dólar gastado?

⚡ Quality / Second

¿Cuánta calidad obtienes por segundo de espera?

📊 Latencia dual

El informe muestra dos valores de latencia para evitar distorsiones:

• Avg Latency (OK) — Media solo de tests exitosos (sin timeouts). Refleja la velocidad real del modelo cuando funciona.
• Avg Latency (all) — Media incluyendo timeouts (registrados como 120s en lugar de 0s). Refleja la fiabilidad operativa real.

Los tests con timeout muestran ≥120s en la columna de latencia y — en la columna de coste (ya que no se completó la generación de tokens).

📈 Consistency (passed only)

Mide la estabilidad de las puntuaciones entre los tests que sí se completaron:

Se muestra la consistencia solo de tests exitosos para que los timeouts no distorsionen la métrica. La consistencia alta (σ bajo) indica que el modelo es predecible — sabes qué esperar.

🛡️ Reliability Score

Puntuación sintética que combina pass rate, consistencia y ausencia de errores:

📊 Tabla comparativa

La tabla principal ordena los modelos por ★ Adjusted Overall. Haz clic en el nombre del modelo para saltar a su card detallada. Las columnas muestran:

• ★ Adjusted — Puntuación final ajustada por dificultad y failure penalty (0–10)
• Correct — Correctness por claims (media geométrica)
• Ground — Groundedness por claims (media aritmética)
• Tool — Tool calling score (overlap)
• Lat (OK/all) — Latencia media (solo exitosos / incluyendo timeouts)
• Cost — Coste total de todos los tests
• Pass — Tests completados sin timeout ni error

🤖 Cards de modelo

Cada modelo tiene una card detallada con:

• Badges de fallos — ⏱ Timeouts (amber), 🔧 Tool mismatch (purple), ❌ Errors (rojo) — con conteos específicos
• KPIs principales — ★ Adjusted Overall, Pass Rate %, Avg Latency (OK y all), Coste total
• Barras de puntuación — Desglose visual de cada métrica: Correctness (geom.), Groundedness (arith.), Relevance, Tool Calling, Latency, Cost, Instruction Following, Error Rate
• Eficiencia — Quality/$, Quality/s, Tokens/tool, con fórmulas visibles al lado
• Consistencia — Std Dev σ, Min, Max, Median (solo tests exitosos). Muestra si el modelo es predecible o errático
• Tabla de tests — Cada test con todas sus puntuaciones, dificultad, y estado. Haz clic para desplegar el detalle completo

🔎 Panel de detalle de cada test

Al hacer clic en cualquier fila de test, se despliega un panel con:

• Pregunta original — La pregunta que se le hizo al agente (todos los turnos en multi-turn)
• Ground Truth — La respuesta correcta esperada con datos concretos
• Respuesta del agente — Lo que respondió (completo)
• Evaluación del juez — El razonamiento completo de GPT-5.2
• Claims Analysis — Cada claim individual con sus veredictos de Correctness y Groundedness, centralidad y explicación
• Tools — Expected vs Used, con icono ≠ si no coinciden
• Exact Answer Check — Si aplica, el valor esperado vs encontrado
• 🔗 Permalink — Enlace directo a cada test para compartir

📈 Gráficos

• 🎯 Comparativa de Puntuación Overall — Barras horizontales por modelo con ★ Adjusted Overall. Rápida comparación visual.
• 🕸️ Radar Multi-Dimensional — 10 dimensiones: Correctness, Groundedness, Tool Calling, Latency, Cost, Instruction Following, Error Rate, Relevance, Format, Reliability. Muestra el perfil completo de cada modelo.
• 📂 Puntuación por Categoría — ¿Qué modelo es mejor en analytics? ¿En cross-index? ¿En adversarial?
• 🎚️ Puntuación por Dificultad — ¿Cómo escala el rendimiento de easy → medium → hard → expert?
• ⚡ Latency vs Quality — Scatter plot (solo tests exitosos). Lo ideal: arriba-izquierda (rápido y bueno).