Cómo evaluar agentes de IA en producción: evals, no "vibes"

Evaluar un agente de IA es medir, de forma sistemática y repetible, si hace lo que debe: llama a las herramientas correctas, con los argumentos correctos, en los pasos correctos, y completa la tarea del usuario. A eso lo llamamos evals. La alternativa —probar el agente "a ojo", desplegar y esperar a que nadie se queje— es lo que en el sector se conoce, medio en broma, como vibes-based development. Funciona en una demo. No sobrevive a producción.

Si ya tienes un agente conectando con varias herramientas vía MCP, este es el siguiente problema serio que vas a tener: ¿cómo sabes que sigue funcionando después de cambiar un prompt, un modelo o una herramienta? Este artículo es una guía práctica para montar evals de verdad.

Por qué un agente no se testea como software normal

El testing clásico asume determinismo: misma entrada, misma salida. Un agente LLM rompe esa premisa. La misma pregunta puede producir respuestas distintas, rutas de razonamiento distintas y secuencias de llamadas a herramientas distintas. No puedes afirmar "la salida debe ser exactamente X" para la mayoría de los casos.

Eso obliga a un enfoque por capas. Las métricas que importan se agrupan en cuatro áreas:

1. Tool calling (llamada a herramientas): ¿llama a la herramienta correcta, con los argumentos correctos, sin pasos redundantes?
2. Planning (planificación): ¿descompone la tarea en una secuencia razonable?
3. Task completion (finalización): ¿logra el objetivo real del usuario de extremo a extremo?
4. Reasoning (razonamiento): ¿la cadena de decisiones es coherente y justificada?

Lo determinista primero: barato, rápido y fiable

El error más común es tirar de un LLM-juez para todo. Es caro, lento y, paradójicamente, menos fiable en lo que un simple assert resuelve mejor.

Empieza por checks deterministas, basados en código, para todo lo que tenga una respuesta objetiva:

• Tool correctness: ¿se llamó a las herramientas esperadas? Comparación exacta de nombres.
• Argument correctness: ¿los argumentos coinciden con lo esperado (o con un esquema válido)?
• Step efficiency: ¿hubo llamadas redundantes o bucles innecesarios?

# Eval determinista de tool-calling: ni un LLM a la vista
def eval_tool_call(trace, expected_tool, expected_args):
    calls = [s for s in trace.spans if s.type == "tool_call"]
    assert len(calls) >= 1, "El agente no llamó a ninguna herramienta"
    first = calls[0]
    assert first.name == expected_tool, f"Esperaba {expected_tool}, llamó a {first.name}"
    assert first.args == expected_args, f"Args incorrectos: {first.args}"
    return True

Estos tests corren en milisegundos, cuestan cero en tokens y atrapan el 80% de las regresiones reales (un cambio de prompt que rompe el formato de los argumentos, una herramienta renombrada, un bucle infinito de reintentos).

LLM-as-a-judge: solo donde hace falta criterio

Reserva el LLM-juez para lo que no tiene una respuesta objetiva única: calidad del razonamiento, si la respuesta final cumple el objetivo abierto del usuario, tono, completitud. Aquí un humano daría una nota, no un sí/no binario, y ahí es donde un juez bien calibrado aporta.

La regla, dicha sin rodeos: usa métricas deterministas para comprobaciones exactas (tool correctness) y LLM-as-a-judge para criterios que requieren juicio, contexto o la salida real del agente.

Dos cautelas con el LLM-juez:

• Calíbralo contra humanos. Un juez sin revisión humana periódica deriva. Toma una muestra, anótala a mano y comprueba que el juez puntúa parecido.
• No lo conviertas en oráculo. Si el juez decide y nadie lo audita, has cambiado "vibes del desarrollador" por "vibes del modelo".

Criterio a medir	Método correcto	Por qué
¿Llamó a la herramienta correcta?	Determinista (código)	Respuesta objetiva, comparación exacta
¿Argumentos válidos?	Determinista (esquema)	Verificable contra un schema
¿Pasos eficientes?	Mixto	El conteo es objetivo; "óptimo" requiere juicio
¿Completó el objetivo?	LLM-as-a-judge	Objetivo abierto, sin única respuesta válida
¿Razonamiento coherente?	LLM-as-a-judge + humano	Subjetivo, necesita calibración

Trace-based evals: del "falla algo" al "falla aquí"

La pieza que separa un eval de juguete de uno de producción es el tracing. Un agente es una secuencia de pasos (spans): recibe la petición, planifica, llama a una herramienta, recibe el resultado, vuelve a razonar, responde. Si solo mides la salida final, cuando algo falla te quedas adivinando qué componente lo rompió.

Con evals basadas en trazas, cada métrica se ancla a un span concreto. Cuando una falla, recorres la traza desde la salida final hasta el span exacto que se rompió, en lugar de especular. Esto convierte el "el agente a veces se equivoca" en "el agente llama a la API de búsqueda con el filtro de fecha mal formado en el 12% de los casos". Lo primero no es accionable; lo segundo, sí.

Cómo montarlo sin sobreingeniería

No necesitas una plataforma enorme el primer día. Una secuencia que funciona:

1. Dataset de regresión vivo. Empieza con 20–50 casos reales (incluidos los fallos que ya viste en producción). Cada bug nuevo entra como caso de test. El dataset crece con tus failure modes.
2. Capa determinista en CI. Tool/argument correctness y límites de pasos corren en cada PR. Si un cambio de prompt rompe el tool-calling, lo sabes antes de mergear.
3. Juez para lo subjetivo, fuera del path crítico. Task completion y calidad de razonamiento, sobre el dataset, con revisión humana de una muestra.
4. Muestreo en producción. Captura trazas reales, detecta deriva y alimenta el dataset. El comportamiento en real nunca es idéntico al del banco de pruebas.

Es la misma disciplina de observabilidad que defendíamos para apps móviles, aplicada al comportamiento no determinista de los modelos. Y conecta directamente con la seguridad de agentes y MCP: una buena traza es también tu registro de auditoría cuando un agente hace algo que no debía.

Cuándo NO montar evals (todavía)

Para no caer en el extremo contrario:

• Un prototipo desechable que no va a producción no necesita un harness de evals. Mídelo a ojo y descártalo.
• Si tu "agente" es una sola llamada a un LLM con un prompt fijo y salida estructurada, no es un agente: testéalo como una función con validación de esquema y ya.
• No inviertas en un LLM-juez antes de tener cubierta la capa determinista. El orden importa: lo barato y fiable primero.

El umbral es simple: en cuanto el agente toma decisiones (qué herramienta, en qué orden) y eso llega a usuarios reales, necesitas evals.

Conclusión

Evaluar agentes no es testing clásico, pero tampoco es magia: es una pirámide. Comprobaciones deterministas en la base —baratas, rápidas, en CI—; LLM-as-a-judge calibrado en la cima, solo para lo subjetivo; y trazas que lo atan todo a un punto concreto del flujo. Lo que no se mide, no se mejora, y "funciona en mi demo" no es una métrica.

En Dribba llevamos agentes de IA y pipelines de RAG a producción con equipo 100% senior in-house, desde la integración con MCP hasta el discovery del producto. Si tienes un agente que funciona "casi siempre" y necesitas que funcione siempre, hablemos.