Agent Evals en 2026: La Falacia de Evaluar el Output Final y la Necesidad de Trajectory Evaluation en Producción

Durante las fases iniciales de experimentación con modelos de lenguaje, el método predominante de evaluación consistía en el conocido coloquialmente como “vibe checking”: enviar un puñado de preguntas al chatbot, inspeccionar visualmente si la respuesta sonaba coherente y pasar a producción con la esperanza de que todo saliera bien.

Sin embargo, en 2026 el ecosistema ha madurado radicalmente. Los modelos ya no son meros generadores de texto estático, sino agentes autónomos que operan sobre entornos dinámicos, ejecutan herramientas externas a través de protocolos como MCP (Model Context Protocol), realizan consultas a bases de datos transaccionales y encadenan bucles de decisión en múltiples turnos.

En este nuevo paradigma, evaluar a un agente únicamente por su respuesta final no solo es insuficiente: es una trampa mortal para la estabilidad y los costes operativos del negocio.

En este cuaderno de ingeniería de YesWeLab (@Yeswelab_OU) analizamos por qué los tests tradicionales de LLMs fallan en sistemas agénticos, qué es la Evaluación de Trayectoria (Trajectory Evaluation), cómo calcular la métrica pass^k para blindar la consistencia y cómo implementar una arquitectura Dual Track de evaluación en local y en producción.

---

1. El Espejismo del Output: Por Qué una Respuesta Correcta Oculta un Desastre

Imaginemos un caso de uso empresarial habitual: un agente de soporte financiero encargado de comprobar si un usuario tiene facturas impagadas y, en caso afirmativo, generar un enlace de pago seguro.

En un test básico basado únicamente en el texto final:

• Entrada: “¿Tengo alguna factura pendiente en mi cuenta user_481?”
• Salida del agente: “Sí, tienes una factura de 49 € del mes pasado. Aquí tienes el enlace seguro para abonarla: https://pay.empresa.com/inv_992”
• Evaluación basada en output: ✅ APROBADO (Respuesta exacta, tono educado, enlace presente).

Ahora bien, al inspeccionar la traza de ejecución interna (execution trace) en el colector de telemetría, la realidad que emerge en la trinchera es aterradora:

[ TRAZA REAL: EL DESASTRE OCULTO TRAS LA RESPUESTA CORRECTA ]

Turno 1: Agente invoca tool: search_users(query="*")          [Descarga 5.000 usuarios -> 80.000 tokens]
Turno 2: Agente falla al parsear JSON y reintenta
Turno 3: Agente invoca tool: run_raw_sql("SELECT * FROM invoices") [Fuga de datos potenciales de otros clientes]
Turno 4: Agente invoca tool: send_notification_email(...)     [Acción lateral destructiva NO autorizada]
Turno 5: Agente entra en loop estocástico (3 reintentos)      [Latencia acumulada: 18.4 segundos]
Turno 6: Agente finalmente genera el link de pago correcto.

El agente entregó el enlace correcto, pero en el camino:

1. Disparó el consumo de tokens por un factor de 10x (costando $3,50 en lugar de $0,02).
2. Violó políticas de seguridad al ejecutar una consulta SQL no acotada y descargar datos ajenos.
3. Disparó efectos secundarios indeseados (envió un email antes de confirmar).
4. Alcanzó una latencia inaceptable de casi 20 segundos.

Si el equipo confía únicamente en pruebas de caja negra sobre el texto final, este agente llegará a producción. Peor aún: en cuanto un desarrollador cambie una sola línea del system prompt para pulir el tono conversacional, el agente sufrirá una regresión silenciosa, entrando en bucles infinitos o ejecutando mutaciones de base de datos imprevistas.

---

2. Anatomía de Trajectory Evaluation: Auditar el Camino, no el Destino

La Evaluación de Trayectoria (Trajectory Evaluation) traslada el foco del resultado superficial a la secuencia estructurada de razonamiento y acciones intermedias. Se evalúa el agente como una máquina de estados que transita por un grafo de ejecución.

                    ┌────────────────────────────┐
                    │      OBJETIVO USUARIO      │
                    └─────────────┬──────────────┘
                                  │
          ┌───────────────────────┴───────────────────────┐
          ▼                                               ▼
   [ EVALUACIÓN CLÁSICA ]                      [ TRAJECTORY EVALS ]
   • ¿El texto final es correcto?              • Step Budget (¿Pasos mínimos?)
   • ¿Cumple el formato JSON?                  • Tool Sequence (¿Orden lógico?)
   • ¿El tono es educado?                      • Argument Schema (¿Valores válidos?)
                                               • Safety Invariants (¿Cero fugas?)
          │                                               │
   (Falsa sensación de seguridad)              (Garantía de ingeniería y costes)

Las cuatro dimensiones operativas indispensables al auditar una trayectoria son:

Dimensión	Pregunta de Control en Trinchera	Modo de Verificación
1. Step Budget	¿Resolvió la tarea en el número óptimo de pasos (ej. 3) o requirió 15 pasos con bucles?	Aserción determinista: len(trace.steps) <= MAX_STEPS.
2. Tool Selection & Order	¿Invocó las herramientas adecuadas en la secuencia correcta sin explorar ramas muertas?	Comparación contra Grafo de Referencia (Golden Trajectory).
3. Argument Validation	¿Pasó los argumentos con el tipado exacto, IDs válidos y sin inyectar parámetros alucinados?	Validación por esquema Pydantic / Zod sobre el payload.
4. Safety Invariants	¿Se respetó el aislamiento de credenciales y no hubo llamadas destructivas intermedias?	Regla de cortafuegos: assert "drop_table" not in trace.tools_called.

---

3. De pass@1 a pass^k: La Verdadera Métrica de Consistencia Agéntica

Uno de los mayores autoengaños en la evaluación de agentes de IA es reportar la métrica pass@1 o pass@k tradicional:

• pass@1: Ejecutar el test una vez. Si pasa, considerarlo un éxito.
• pass@k tradicional: Ejecutar $k$ veces y considerar que aprueba si al menos una de las $k$ ejecuciones tuvo éxito.

En sistemas deterministas clásicos, un test unitario que pasa una vez pasa siempre. En agentes autónomos basados en LLMs estocásticos, pass@1 oculta la inestabilidad intrínseca. Un agente con un 30% de probabilidad de éxito real tiene un 30% de probabilidades de aprobar un test en su primera ejecución por pura suerte estocástica.

Por ello, la industria ha adoptado la métrica estricta pass^k (desarrollada en investigaciones de fiabilidad como tau2-bench):

$$\text{pass}^k = P(\text{Éxito en los } k \text{ intentos consecutivos})$$

Si un agente tiene una fiabilidad por turno de $p = 0.85$ (85%), la probabilidad de que complete una tarea multi-paso de forma consistente en $k=5$ ejecuciones consecutivas es:

$$0.85^5 \approx 0.4437 \quad (44.3%)$$

[ CURVA DE CONSISTENCIA: pass^k SEGÚN FIABILIDAD POR RUN ]
Consistencia
100% ────┐ (p = 0.98 -> pass^5 = 90.4%)
 80%     └─────────┐
 60%               └──────────┐ (p = 0.85 -> pass^5 = 44.3%)
 40%                          └───────────────────┐
 20%                                              └────────── (p = 0.70 -> pass^5 = 16.8%)
  0% ────────────────────────────────────────────────────────►
     k=1        k=2        k=3        k=4        k=5   Intentos

Si tus tests de CI/CD solo ejecutan $k=1$, estás ciego ante agentes que en realidad fallan en más del 50% de las sesiones en producción real. Un cambio en el prompt que mantenga el pass@1 pero desplome el pass^5 destruirá la confianza de tus clientes de inmediato.

---

4. Implementación en Código: Trajectory Assertions con Pytest

A continuación se muestra una suite de test en Python que implementa auditoría de trayectoria e invariantes de presupuesto utilizando asserciones deterministas sobre el trace del agente:

import pytest
from pydantic import BaseModel
from typing import List, Dict, Any

class AgentStep(BaseModel):
    tool: str
    arguments: Dict[str, Any]
    output: Any
    latency_ms: float

class AgentExecutionTrace(BaseModel):
    query: str
    steps: List[AgentStep]
    final_response: str
    total_tokens: int

def run_agent_simulation(user_id: str, query: str) -> AgentExecutionTrace:
    # Ejecuta el agente en sandbox/mock
    ...
    return trace

@pytest.mark.parametrize("run_idx", range(5)) # Verificación pass^5
def test_invoice_retrieval_trajectory(run_idx):
    user_id = "user_481"
    trace = run_agent_simulation(user_id=user_id, query="¿Tengo facturas pendientes?")
    
    # 1. Aserción de Presupuesto de Pasos (Step Budget)
    MAX_ALLOWED_STEPS = 3
    assert len(trace.steps) <= MAX_ALLOWED_STEPS, (
        f"Regresión en Step Budget: esperados <= {MAX_ALLOWED_STEPS}, obtenidos {len(trace.steps)}"
    )

    # 2. Aserción de Secuencia y Herramientas Permitidas
    expected_tools = ["get_user_account", "query_invoices_by_user_id"]
    tools_called = [step.tool for step in trace.steps]
    
    assert tools_called == expected_tools, (
        f"Desviación en trayectoria: {tools_called} != {expected_tools}"
    )

    # 3. Validación de Argumentos Tipados (Strict Scoping)
    for step in trace.steps:
        if step.tool == "query_invoices_by_user_id":
            assert step.arguments.get("user_id") == user_id, (
                "Vulnerabilidad de seguridad: el agente consultó facturas sin filtrar por el usuario autenticado"
            )

    # 4. Invariante de Seguridad: Prohibidas mutaciones destructivas
    forbidden_tools = {"send_email", "charge_credit_card", "delete_record"}
    assert forbidden_tools.isdisjoint(set(tools_called)), (
        "Violación de invariante: se ejecutó una acción destructiva en un flujo de solo lectura"
    )

    # 5. Aserción de Texto Final
    assert "factura de 49 €" in trace.final_response
    assert "https://pay.empresa.com" in trace.final_response

---

5. Estrategia Dual Track en YesWeLab

Siguiendo la filosofía fundacional de YesWeLab, estructuramos las evaluaciones en dos pistas complementarias:

Track A: Trinchera Open Source / DIY (Coste $0)

• Local Eval Harness: Ejecución de suites con Pytest y DeepEval en el entorno de desarrollo local.
• Tracing Local OTel: Despliegue de un contenedor Docker ligero con Arize Phoenix (docker run -p 6006:6006 arize-phoenix). Phoenix captura trazas OTel completas, árboles de llamadas a tools y latencias sin enviar un solo dato fuera de tu máquina.
• Golden Trajectories en SQLite WAL: Almacenamiento de trayectorias doradas y casos de prueba en una base de datos SQLite local con WAL mode activo (lab.db), permitiendo comparar ejecuciones históricas a coste computacional cero.

Track B: Fast-Track SaaS Empresarial (Automatización CI/CD)

• CI/CD Quality Gate en GitHub Actions: Integración con Langfuse o LangSmith a través de acciones automatizadas (langfuse/experiment-action). Todo pull request que modifique un prompt o una tool ejecuta un dataset de regresión y bloquea el merge si el pass^k desciende o el coste medio de tokens aumenta más de un 10%.
• n8n Evals con Instance AI: Monitorización online continua de los workflows y agentes en n8n mediante el módulo nativo de evaluación, capturando desvíos en la selección de nodos antes de que afecten a usuarios en vivo.

---

6. Checklist de Trinchera: ¿Está tu Agente Listo para Producción?

Antes de activar el interruptor de tráfico real, verifica que tu arquitectura cumple estos 5 puntos indispensables:

• Métricas pass^k activas: No se valida ningún cambio con una sola corrida estocástica; la suite ejecuta al menos $k=5$ repeticiones sobre el dataset crítico.
• Step Budget configurado: Cada agente tiene un límite máximo estricto de turnos tras el cual se produce un fail-safe determinista hacia intervención humana.
• Auditoría de argumentos en tools: Las llamadas intermedias pasan por validadores Pydantic o Zod que rechazan payloads malformados antes de que alcancen bases de datos o APIs externas.
• Reglas de invariantes de seguridad: Las herramientas de mutación de estado (pagos, borrados, envíos) exigen confirmación o verificación determinista en el pipeline.
• Trazabilidad OTel completa: Cada ejecución emite trazas estructuradas con inputs, outputs de herramientas, latencias y consumo granular de tokens.