Tu agente pasó los tests. Falló en producción.
Tu pipeline de CI está verde. El deploy sale. Y cuatro días después recibes un mensaje de un cliente: "el agente dejó de extraer el IVA correctamente".
No hubo error visible. No hubo excepción en los logs. El modelo simplemente empezó a comportarse diferente en producción cuando actualizaste de una versión a otra, o cuando cambiaste tres líneas del prompt.
Ese es el problema que los evals resuelven. Y la mayoría de equipos que construyen agentes IA en 2026 todavía no los tienen.
Por qué los tests normales no funcionan para LLMs
Con código determinista, el contrato es claro: parseFecha("2026-07-03") devuelve siempre la misma estructura. Escribes el assert, pasa o no pasa.
Con un LLM el contrato es probabilístico. Misma entrada, distribución de salidas diferente. Cambias el modelo, el sistema prompt o las herramientas disponibles, y el comportamiento cambia en los márgenes: no en el caso principal que siempre testeas, sino en los casos de borde que el cliente encuentra cada semana.
El test clásico asegura que el código hace lo que dices. Un eval asegura que el comportamiento del agente cumple los criterios que defines. Son dos niveles distintos.
Los cuatro escenarios de regresión silenciosa más habituales
En los proyectos de integración de agentes IA que hacemos en DAILYMP, estos son los casos que aparecen repetidos:
- Actualización de modelo: pasas de claude-sonnet-4-5 a claude-sonnet-4-6 y el agente ahora formatea las fechas diferente, o prefiere llamar a una herramienta secundaria en vez de la principal.
- Cambio de prompt de sistema: editas una instrucción para mejorar la extracción de un campo y sin querer cambias cómo el modelo prioriza otro.
- Nueva herramienta añadida: el agente empieza a preferirla para casos donde antes usaba la herramienta correcta.
- Cambio en temperatura o parámetros: ajustes de latencia que modifican la distribución de respuestas.
Ninguno de estos cambios lanza una excepción. El código compila. Los tests de integración pasan. El daño es invisible hasta que el cliente lo nota.
Tres patrones de eval para agentes en producción
1. Dataset de casos dorados con criterios binarios
Empieza con 20-50 casos reales tomados de producción, cada uno con los criterios de éxito que debe cumplir, no con la salida exacta esperada:
interface EvalCase {
id: string;
input: string;
criteria: {
toolsCalled: string[]; // herramientas que debe invocar
fieldsExtracted: string[]; // campos que deben aparecer en el output
mustNotCall?: string[]; // herramientas que no debe invocar
};
}
const goldenDataset: EvalCase[] = [
{
id: "invoice-vat-extraction",
input: "Crea una factura de 500€ con IVA al 21% para ACME Corp",
criteria: {
toolsCalled: ["create_invoice"],
fieldsExtracted: ["amount", "vatRate", "customerId"],
mustNotCall: ["send_email"], // no debe enviar email sin confirmación
}
},
{
id: "ambiguous-customer-lookup",
input: "Factura para García",
criteria: {
toolsCalled: ["search_customer"], // debe buscar antes de asumir
fieldsExtracted: ["customerId"],
mustNotCall: ["create_invoice"], // no debe crear sin confirmar cliente
}
}
];
Este tipo de eval no testea el texto de la respuesta. Testea las decisiones del agente: qué tools llamó, qué campos extrajo, qué evitó hacer. Eso es lo que de verdad importa en un agente de negocio.
2. LLM-as-judge para outputs difíciles de cuantificar
Cuando la salida no es estructurada — una respuesta de atención al cliente, un resumen, una explicación — necesitas otro modelo que la evalúe según criterios concretos:
async function judgeAgentResponse(
scenario: string,
agentResponse: string,
criteria: string[]
): Promise<{ score: number; failures: string[] }> {
const prompt = `Evalúa la siguiente respuesta de un agente IA.
Escenario: ${scenario}
Respuesta del agente: ${agentResponse}
Criterios a evaluar:
${criteria.map((c, i) => `${i + 1}. ${c}`).join('\n')}
Para cada criterio, indica si se cumple (true/false) y por qué.
Responde en JSON: { "results": [{ "criterion": string, "pass": boolean, "reason": string }] }`;
const response = await anthropic.messages.create({
model: 'claude-haiku-4-5-20251001', // modelo rápido y barato para evals
max_tokens: 512,
messages: [{ role: 'user', content: prompt }],
});
const parsed = JSON.parse(extractJSON(response.content[0].text));
const failures = parsed.results
.filter((r: any) => !r.pass)
.map((r: any) => r.criterion);
return {
score: parsed.results.filter((r: any) => r.pass).length / criteria.length,
failures,
};
}
Coste estimado: 0,001–0,003 € por eval con Haiku. Ejecutar 50 casos cuesta menos de 15 céntimos.
3. CI de regresión con umbral de calidad
Integra los evals en el pipeline de CI bloqueando el merge si el score cae:
# .github/workflows/agent-evals.yml
name: Agent Evals
on:
pull_request:
paths:
- 'src/agents/**'
- 'src/prompts/**'
- 'src/tools/**'
jobs:
eval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- name: Run eval suite
run: npm run evals -- --threshold 0.90
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
El script de evals retorna exit code 1 si el score cae del umbral. El merge se bloquea. El autor del PR ve exactamente qué casos fallaron y por qué.
Lo que separa el prototipo del sistema mantenible
Un agente sin evals es un sistema que solo funciona mientras nadie lo toca. En cuanto añades una herramienta, ajustas el prompt o cambias el modelo, navegas a ciegas.
Con un dataset de 30-50 casos bien elegidos y un job de CI que corre en 3 minutos, tienes una red de seguridad real. No es cobertura del 100% — los LLMs no funcionan así — pero sí es suficiente para atrapar el 90% de las regresiones antes de que lleguen a producción.
En los proyectos de integración IA que construimos en DAILYMP, el eval suite se diseña en la primera semana, no cuando ya hay un fallo en producción. Añadirlo como parche después del primer incidente es más caro, más difícil de calibrar y siempre llega tarde.
Si tienes un agente en producción que no tiene evals — o que tiene tests de integración pero no evaluaciones de comportamiento — hay una probabilidad alta de que ya haya regresiones que no estás viendo: