Evals para agentes: más allá de '¿esto funciona?'

La mayoría de los equipos mide al agente con “corrí 10 prompts y parecen ok”. Eso no es eval — es demo testing. Eval verdadero es estadístico, repetible, detecta regresión, y cuesta poco.

Este post cubre el diseño de suite de eval que funciona para agentes en producción.

Por qué “parece ok” falla

Tres razones por las que demo testing engaña:

1. Confirmation bias. Testeas escenarios donde crees que el agente funciona. Edge cases quedan afuera.

2. No captura regresión. Cuando cambias el prompt en la semana siguiente, no tienes cómo saber si algo que funcionaba dejó de funcionar.

3. No permite comparación. “Versión A vs B” exige métrica numérica, no impresión.

Los 4 niveles de eval

Nivel 1 · Unit test de prompt

50-200 entradas representativas, con output esperado (o criterio programático). Corre en CI antes de cualquier cambio de prompt o modelo.

Ejemplo de entrada:

- input: "Estoy frustrado, esto no funciona"
  expect:
    - sentiment_detected: "negative"
    - escalation_suggested: true
    - tone: "empathic"

Validador puede ser regex, LLM-as-judge, o métrica determinística.

Nivel 2 · Regression suite

Crece automáticamente del failure corpus. Cada bug en producción se vuelve test — no puede volver a fallar.

Schema:

- id: REG-042
  introduced: 2026-04-12
  cause: "Agente sugirió cancelación de plan antes de ofrecer downgrade"
  input: "No estoy satisfecho con el plan"
  must_not_output: ["cancele", "cancelación"]
  must_output: ["downgrade", "alternativa"]

Cuanto más el sistema corre, más la suite crece. Buena señal.

Nivel 3 · Behavioral eval (LLM-as-judge)

Para cualidades subjetivas (tono, naturalidad, completitud), usa otro LLM como juez. Patrón:

[INPUT] [Output del agente]
[JUDGE] Evalúa de 1-5 en las dimensiones:
  - Tono (¿formal apropiado?)
  - Completitud (¿resuelve el pedido?)
  - Seguridad (¿reveló info sensible?)

Cuidado: LLM-as-judge tiene sesgo (modelos prefieren outputs del propio modelo, o más largos). Calibra con sample humano antes de confiar.

Nivel 4 · Production canary

Corre en 1-5% del tráfico real, compara salidas con versión anterior. Detecta drift sutil que sintético no pesca.

Estructura típica:

• 95-99% tráfico → versión estable.
• 1-5% → versión candidata.
• Métrica: aceptación humana, retentativas, tiempo hasta resolución.
• Promote o rollback después de volumen mínimo (1.000-5.000 turns).

Métricas que importan

Métrica	Lo que mide	Cuándo importa
Pass rate	% de tests pasados	Cambio de prompt/modelo
Regression count	Cuántos regresaron	Antes de deploy
Behavioral score	Calidad subjetiva	Evaluación periódica
Production acceptance	% aceptado por el usuario	Canary
Cost per task	$ medio por interacción	Optimization
Latency p99	Cola lenta	UX crítico

El insight contra-intuitivo

Pass rate de 100% es sospechoso. Significa que tu suite es muy fácil, o que el modelo memorizó los tests (leakage). Apunta a 70-90% pass rate en suite bien diseñada — los 10-30% que fallan es donde aprendes.

Patrón que funciona

Inspirado en prácticas de runtime governance:

1. Semana 1-2: monta unit suite de 50 entradas. Corre en todo deploy.
2. Semana 3-12: alimenta regression suite a partir de failures reales.
3. Mes 3+: agrega LLM-as-judge para dimensiones subjetivas.
4. Mes 6+: production canary para cambios no triviales.

No saltes pasos. Production canary sin unit suite es lotería.

Anti-patrones comunes

1. Eval idéntico al prompt. Suite que reusa ejemplos del system prompt mide memorización, no capacidad. Usa entradas inéditas.

2. Métrica única. Pass rate solo engaña. Combina con cost, latency, behavioral.

3. Eval que solo corre en laptop del dev. Tiene que correr en CI, con snapshot de los resultados versionado.

4. Eval que no testea edge case locales. Acento, jerga regional, formato de identificación, fechas. Modelo global puede fallar sin que notes.

Dónde profundizar

Para el framework de runtime governance que evals validan: Harness Stack.