Cómo evaluar agentes IA en producción: métricas, evals y observabilidad

Llevo meses viendo el mismo patrón en equipos que despliegan agentes en producción: el sistema pasa todos los tests, las llamadas al modelo tienen latencias aceptables, no hay excepciones en los logs, y aun así el agente falla silenciosamente en una fracción considerable de las tareas. Nadie lo sabe hasta que un usuario lo reporta, o hasta que alguien revisa manualmente un lote de outputs y descubre que algo está mal. El problema no es que los agentes fallen — es que fallan de formas que la infraestructura de monitorización convencional no detecta.

En este post explico cómo construir un sistema de evaluación para agentes IA en producción: qué métricas importan realmente, cómo estructurar evals que reflejen condiciones reales, cómo detectar la degradación antes del incidente, y qué necesitas mínimamente para tener visibilidad sin montar infraestructura compleja.

Por qué evaluar agentes no es lo mismo que evaluar modelos

Evaluar un modelo significa medir la calidad de un output dado un input: precisión, coherencia, relevancia, BLEU score. Es una relación directa entre entrada y salida. Evaluar un agente es distinto en su naturaleza: significa medir si una secuencia de decisiones encadenadas, cada una dependiente del estado generado por las anteriores, llega a un objetivo con fiabilidad medible en condiciones reales.

La diferencia no es de grado. Es cualitativa.

Cuando el agente falla en el paso 3 de 7, el modelo puede haber respondido perfectamente en todos los pasos. Cada llamada individual fue correcta sintácticamente. El problema fue la decisión de qué llamada hacer, con qué parámetros, en qué momento del flujo. Eso no aparece en las métricas de calidad de output del modelo.

La mayoría de equipos trasladan directamente la mentalidad de evaluación de modelos a los agentes porque es lo que conocen. Configuran alertas sobre latencia, tasa de errores HTTP y coste por token. Esas métricas miden el modelo subyacente, no el agente. El agente puede funcionar perfectamente a nivel de modelo y fallar completamente a nivel de objetivo.

Las métricas que importan en producción

Hay cinco métricas de agente que, en mi experiencia, dan señal real en producción. Ninguna es visible solo con los logs de las llamadas al modelo.

Task completion rate es la métrica principal: el porcentaje de tareas en las que el agente alcanzó el objetivo definido, no solo el porcentaje de tareas que completó sin error técnico. Un agente puede terminar sin excepciones habiendo tomado un camino alternativo que no era el correcto.

Step efficiency mide si el agente usó más pasos de los necesarios. Si una tarea que debería resolverse en 4 pasos regularmente toma 9, el agente está perdido, iterando sin convergir, o su system prompt no está priorizando el camino directo. Esta métrica también detecta bucles encubiertos antes de que consuman presupuesto.

Tool call accuracy mide cuántas de las llamadas a herramientas usaron la herramienta correcta con los parámetros correctos. Un agente que alucina nombres de herramientas o construye parámetros incorrectamente puede parecer activo sin generar ningún resultado útil.

Error recovery rate es el porcentaje de veces que el agente se recuperó exitosamente cuando un paso intermedio falló. Los agentes robustos fallan en pasos intermedios — lo que distingue a los buenos es que se recuperan.

Cost per task son los tokens consumidos por tarea completada, no por llamada. Un pico inusual en esta métrica suele ser la primera señal de un bucle o una degradación, a veces horas antes de que cualquier usuario reporte un problema.

Dimensión	Métrica de modelo	Métrica de agente	Cómo se mide
Calidad de output	Precisión, coherencia, relevancia	Task completion rate	% de tareas con objetivo alcanzado, verificado
Eficiencia	Latencia por llamada	Step efficiency	Pasos reales ÷ pasos mínimos necesarios
Uso de herramientas	N/A	Tool call accuracy	% de tool calls con herramienta + parámetros correctos
Resiliencia	N/A	Error recovery rate	% de recuperaciones exitosas tras fallo intermedio
Coste	Tokens por llamada	Cost per task	Tokens totales ÷ tareas completadas
Confiabilidad temporal	Evaluación puntual	Degradación silenciosa	Tendencia de métricas a lo largo del tiempo

Lo que no aparece en esta tabla también importa: la calidad semántica del resultado final — si el agente completó el objetivo en términos técnicos pero el output es inútil para el usuario. Para eso hacen falta evals.

Cómo construir evals para agentes

Un eval de agente no es un benchmark genérico descargado de internet. Es un conjunto de tareas representativas de producción real, con criterios de éxito definidos de forma objetiva y medible. Si los criterios no son medibles, el eval no sirve para detectar regresiones automáticamente.

La primera distinción que hay que hacer es entre evals deterministas y evals no deterministas.

Los evals deterministas tienen un resultado correcto verificable: la consulta SQL debe devolver exactamente estos registros, el fichero generado debe tener esta estructura JSON, la llamada a la API debe haberse realizado con estos parámetros. Se verifican programáticamente. Son los más valiosos porque no introducen subjetividad y pueden ejecutarse en CI sin coste adicional.

Los evals no deterministas tienen criterios de calidad evaluables pero no un resultado único correcto: el resumen debe contener estos puntos clave, la respuesta debe seguir las restricciones del contexto dado, el plan generado debe ser ejecutable. Para estos, la práctica más extendida es usar un LLM como juez con un rubric explícito.

import anthropic
from dataclasses import dataclass, field

@dataclass
class AgentTrace:
    task_id: str
    steps: list[dict] = field(default_factory=list)
    total_tokens: int = 0

    @property
    def step_count(self) -> int:
        return len(self.steps)

    @property
    def tool_calls(self) -> list[dict]:
        return [s for s in self.steps if s["type"] == "tool_use"]

def run_eval_task(task: dict, tools: list, client: anthropic.Anthropic) -> AgentTrace:
    """Ejecuta una tarea de eval capturando el trace TAO completo."""
    trace = AgentTrace(task_id=task["id"])
    messages = [{"role": "user", "content": task["input"]}]

    for _ in range(task.get("max_steps", 15)):
        response = client.messages.create(
            model="claude-opus-4-6",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        trace.total_tokens += response.usage.input_tokens + response.usage.output_tokens

        for block in response.content:
            trace.steps.append({"type": block.type, "data": block})

        if response.stop_reason != "tool_use":
            break

        tool_results = execute_tools(response.content)  # implementación específica del dominio
        messages += [
            {"role": "assistant", "content": response.content},
            {"role": "user", "content": tool_results},
        ]

    return trace

El trace captura cada paso del ciclo TAO: qué pensó el agente, qué herramienta llamó, qué observó. Con ese trace puedes calcular las cinco métricas anteriores sin instrumentación adicional.

Para los evals no deterministas, el LLM-as-judge funciona, pero hay que entender sus limitaciones antes de confiar en él.

RUBRIC_PROMPT = """\
Eres un evaluador de tareas de agente. Evalúa si el agente completó el objetivo.

OBJETIVO: {objective}

RESULTADO DEL AGENTE:
{agent_output}

CRITERIOS DE ÉXITO:
{criteria}

Responde ÚNICAMENTE con JSON válido usando este esquema exacto:
{{
  "success": true/false,
  "completeness": 0-10,
  "accuracy": 0-10,
  "reasoning": "justificación en una oración"
}}

IMPORTANTE: Evalúa el resultado final, no el proceso. No penalices un camino
ineficiente si el resultado es correcto. No apruebes un resultado plausible
que no cumpla los criterios explícitos."""

def llm_judge(
    objective: str,
    agent_output: str,
    criteria: list[str],
    client: anthropic.Anthropic,
) -> dict:
    prompt = RUBRIC_PROMPT.format(
        objective=objective,
        agent_output=agent_output,
        criteria="\n".join(f"- {c}" for c in criteria),
    )
    # Usar un modelo distinto al que se evalúa reduce el sesgo de autoafirmación
    response = client.messages.create(
        model="claude-opus-4-6",
        max_tokens=256,
        messages=[{"role": "user", "content": prompt}],
    )
    return json.loads(response.content[0].text)

El sesgo más importante del LLM-as-judge es la autoafirmación: si usas el mismo modelo que el agente como juez, tiende a aprobar los outputs que él mismo habría generado. Hay que usar un modelo distinto, o al menos una versión distinta con temperatura cero. El segundo sesgo relevante es la longitud: los LLMs tienden a preferir outputs más extensos, lo que puede dar puntuaciones infladas a respuestas largas aunque incompletas. El rubric explícito con criterios binarios mitigó esto en los proyectos donde lo probé.

Degradación silenciosa: tres causas, tres tipos de detección

Un agente que funciona bien en el lanzamiento puede degradarse sin que nadie lo note. He visto tres causas principales, y cada una requiere un tipo diferente de detección.Distributional shift: los inputs reales empiezan a diferir de los inputs con los que construiste los evals. El agente nunca fue diseñado para ese tipo de tarea, pero los usuarios lo intentan igualmente. La señal de detección es la caída en task completion rate combinada con un aumento en step count — el agente itera más porque no sabe cómo llegar al objetivo con esos inputs.

Model updates: el modelo subyacente cambia y el comportamiento del agente cambia con él. Esto es especialmente silencioso porque el proveedor no siempre notifica los cambios de comportamiento, solo los de versión. La detección requiere ejecutar tu eval suite completo contra cada nueva versión del modelo antes de actualizar, no después. En dos proyectos distintos he visto regresiones de tool call accuracy del 15-20% tras actualizaciones de modelo que mejoraban otras métricas.

Tool drift: las APIs o herramientas externas que usa el agente cambian su comportamiento. Una API que antes respondía en 200ms ahora tarda 2 segundos, lo que cambia las decisiones de timeout del agente. Un endpoint que devolvía un campo en el objeto de respuesta ahora lo mueve. La firma de este fallo es el aumento en error recovery rate con tool call accuracy estable — el agente llama bien las herramientas, pero las herramientas no se comportan como esperaba.

Los patrones de fallo más comunes tienen una característica compartida: no producen excepciones. El bucle infinito encubierto — el agente sigue iterando sin avanzar — se detecta por el pico en cost per task antes de que llegue a ningún resultado. La alucinación de tool calls — llamar a herramientas que no existen o con parámetros inventados — se detecta por el aumento en errores de herramienta en el trace. La cascada de errores silenciosa — el fallo del paso 3 propaga estado incorrecto al 4, que lo propaga al 5, y el agente entrega un resultado plausible pero incorrecto — es la más difícil de detectar porque el output final no parece erróneo sin verificación. Para esto hace falta muestreo humano periódico, no solo métricas automáticas.

Observabilidad mínima viable

No necesitas infraestructura compleja para tener visibilidad real sobre cómo se comporta tu agente en producción. Estos cuatro elementos son suficientes para empezar.

Tracing de cada ciclo TAO. Cada iteración del ciclo debe guardar: el input del paso, el output del modelo, las herramientas llamadas con sus parámetros, el resultado de cada herramienta, y el coste en tokens. Sin este trace, no puedes calcular ninguna de las métricas que importan ni depurar fallos en producción.

Alertas sobre cost per task. Configura una alerta cuando el coste por tarea suba más de un 50% respecto a la media de los últimos 7 días. Esta sola alerta detecta bucles encubiertos, distributional shift severo y degradaciones de eficiencia antes de que el impacto llegue a los usuarios.

Muestreo aleatorio para revisión humana. El 5-10% de las tareas completadas deben revisarse manualmente de forma periódica. No hay métrica automática que sustituya a alguien mirando si el resultado es realmente correcto. Es el único mecanismo que detecta la cascada de errores silenciosa y el problema de confianza excesiva.

Dashboard de task completion rate por tipo de tarea a lo largo del tiempo. No un número global — segmentado por tipo de tarea. Una degradación que afecta solo a un subset de inputs se enmascara en la media global. Ver la tendencia por categoría permite identificar dónde está el problema antes de que el impacto sea amplio.

Errores comunes al evaluar agentes

Medir métricas de modelo en lugar de métricas de agente

El error más frecuente y el más costoso. El equipo configura dashboards de latencia, tokens por llamada y tasa de errores HTTP — métricas reales que miden el modelo subyacente — y concluye que el sistema funciona bien. Mientras tanto, el task completion rate puede estar cayendo sin ninguna señal visible. La señal de este error es cuando el equipo solo descubre fallos del agente por reportes de usuarios, nunca por sus propias alertas.

El eval set que no representa producción

Construyes evals con los ejemplos más limpios, los casos más fáciles, las tareas que el agente ya maneja bien. El eval pasa al 98%. En producción, el agente encuentra las variaciones messy que nunca estaban en el eval set. La solución es construir los evals a partir de logs de producción reales desde el primer día que tengas tráfico real, no antes.

El juez que aprueba el estilo, no el contenido

El LLM-as-judge sin rubric explícito tiende a evaluar calidad de escritura en lugar de cumplimiento de criterios. Un output bien redactado que no cumple los criterios de éxito definidos puede obtener puntuaciones altas. El rubric debe listar criterios binarios verificables, no solicitar una evaluación holística de calidad. Si el juez no puede justificar su puntuación con evidencia del output, el rubric está mal escrito.

Ignorar el tool drift hasta el incidente

Las APIs externas cambian. Si no ejecutas tu eval suite periódicamente contra las herramientas reales en producción, descubrirás el tool drift cuando ya haya afectado a usuarios. Una ejecución semanal del subset determinista del eval suite, con alertas sobre cambios en tool call accuracy, es suficiente para detectarlo a tiempo.

Checklist de evaluación mínima antes de producción

Las métricas de agente (task completion rate, step efficiency, cost per task) están instrumentadas y visibles
El eval set incluye al menos 20 tareas representativas extraídas de casos de uso reales
Hay al menos un eval determinista por tipo de herramienta crítica que usa el agente
El LLM-as-judge (si se usa) tiene un rubric con criterios binarios explícitos y usa un modelo distinto al evaluado
El tracing cubre cada ciclo TAO: input, output, tool calls, tool results y coste en tokens
Hay una alerta configurada sobre cost per task que detecta anomalías de más del 50%
El proceso de muestreo humano periódico está definido: quién revisa, qué porcentaje, con qué frecuencia
El eval suite se ejecuta contra cada nueva versión del modelo antes de actualizar en producción

Preguntas Frecuentes

¿Qué diferencia hay entre un eval y un benchmark?

Un benchmark es un conjunto de tareas estandarizado diseñado para comparar modelos entre sí en condiciones genéricas. Un eval es un conjunto de tareas específicas de tu caso de uso, diseñado para medir si tu agente cumple tus criterios de éxito en condiciones de producción real. Los benchmarks públicos son útiles para elegir modelo base, pero no predicen el comportamiento de tu agente con tus herramientas, tu contexto y tus usuarios. Un agente puede puntuar alto en benchmarks y tener un task completion rate bajo en producción, y viceversa.

¿Cuándo usar LLM-as-judge y cuándo no?

LLM-as-judge es útil cuando el criterio de éxito requiere juicio semántico que no es verificable programáticamente: ¿el resumen captura los puntos clave?, ¿la respuesta sigue las restricciones del contexto dado? No es apropiado cuando el resultado tiene una respuesta correcta verificable — para eso usa aserciones deterministas, que son más rápidas, más baratas y no introducen sesgo. Tampoco uses LLM-as-judge como único mecanismo de evaluación. El muestreo humano periódico sigue siendo necesario para calibrar que el juez está evaluando lo que tú crees que está evaluando.

¿Qué hacer cuando no tienes datos de producción para construir evals?

Si todavía no tienes tráfico real, construye evals basados en los casos de uso que motivaron el agente: las tareas reales que los usuarios van a pedir. Entrevista a usuarios potenciales o al equipo que hará uso del agente. Genera variaciones sintéticas de esas tareas — no para reemplazar datos reales, sino como punto de partida. Lo importante es que los evals reflejen complejidad y variedad realistas, no solo los casos happy path. Desde el momento en que tienes los primeros 50 outputs de producción, empieza a migrar el eval set hacia datos reales. Los evals sintéticos tienen una vida útil corta.

¿Cómo priorizar qué métricas monitorizar primero si los recursos son limitados?

Si tienes que elegir una sola métrica: task completion rate segmentado por tipo de tarea. Es la métrica que más directamente mide si el agente hace su trabajo. Si puedes agregar una segunda: cost per task con alertas de anomalía — detecta bucles y degradaciones antes de que lleguen a los usuarios. Con esas dos métricas y un proceso de muestreo humano quincenal tienes el mínimo para no operar a ciegas. Las métricas de step efficiency y tool call accuracy son valiosas para debugging cuando ya sabes que hay un problema, pero su valor como señal temprana es menor que las dos anteriores.