Saltar al contenido
Kevin Davila mascotkevindavila.dev> SOFTWARE ENGINEEREN
AI•4 min de lectura

Evals: los 3 tipos, y cómo saber si tu agente mejoró

Durante semanas creí que mi agente mejoraba. Cambiaba el prompt, probaba dos o tres casos, quedaba convencido y lo dejaba así. Hasta que un día noté que había empeorado en lo que antes hacía bien: había optimizado para los casos que estaba mirando y roto los demás. Sin evals, cada cambio es una opinión, y las opiniones no detectan regresiones.

Esta pieza es lo que uso hoy: los 3 tipos de eval, cómo se escribe una y cómo saber si de verdad mejoraste.

Por qué necesitas evals (y no solo "probé y funcionó")

Los modelos son no deterministas: el mismo prompt puede dar resultados distintos. Eso significa que "lo probé una vez y salió bien" no es información: es una anécdota. Peor aún, cuando cambias algo (prompt, contexto, modelo) no tienes forma de saber si mejoraste, empeoraste o moviste el problema a otro caso.

La evidencia de que esto es el cuello de botella está en las herramientas: Google ADK incluye evaluación como parte del framework, con criterios, simulación de usuario, simulación de entorno y métricas propias; el AI SDK documenta evaluación como parte de su core. - Source: Evaluation - Google ADK y Evaluation - Vercel AI SDK

Los 3 tipos (mi taxonomía práctica)

Hay varias formas de clasificarlas; esta es la que uso porque cada tipo se escribe distinto y falla distinto.

1. Evals deterministas (aserciones). Comprobaciones binarias sobre el output: ¿es JSON válido?, ¿cumple el esquema?, ¿llamó a la tool correcta?, ¿el precio está dentro del rango?, ¿el test pasa? Son baratas, rápidas y no tienen criterio: no discuten. Empieza por aquí: la mayoría de los fallos de producción son de este tipo.

2. LLM como juez (con rúbrica). Un modelo evalúa la calidad de la respuesta contra criterios explícitos ("¿la explicación cita el archivo correcto?", "¿el tono es el pedido?"). Sirve para lo subjetivo, y es peligroso si lo usas solo: un juez sin rúbrica es otra opinión. Se usa con ejemplos calibrados y, cuando se puede, se compara con juicios humanos.

3. Evals de tarea (end-to-end). ¿Se resolvió la tarea, no la respuesta? El ticket quedó resuelto, el bug se arregló, el archivo quedó válido. Es la que importa para un agente, porque un agente no entrega texto: entrega resultados.

Otra fuente con un marco distinto (y complementario) es The Three Types Of Evals de AI Hero.

Cómo se escribe una eval (sin framework)

Lo importante no es la herramienta, es el formato: casos + criterio + resultado esperado.

// evals/run.ts
// Cada caso: entrada real + verificación. Sin magia.
const cases = [
  { input: "Se cayó el pago con tarjeta", expect: { category: "billing", priority: "high" } },
  { input: "¿Cómo cambio mi contraseña?", expect: { category: "account", priority: "low" } },
  { input: "El bot responde en inglés y lo quiero en español", expect: { category: "bug" } },
  // 10-30 casos reales, incluyendo los que ya fallaron una vez
];

let pass = 0;
for (const c of cases) {
  const out = await runAgent(c.input);
  if (matches(out, c.expect)) pass++;
  else console.log("FALLA:", c.input, "→", out);
}
console.log(`${pass}/${cases.length} pasan`);

Tres reglas de oro: usa casos reales (no inventados), incluye los fallos (cada bug encontrado se convierte en un caso) y guarda el porcentaje para poder compararlo mañana.

Cómo saber si mejoró (el diff de evals)

  • Baseline primero. Antes de tocar nada, corre las evals y guarda el número: 22/30.
  • Un cambio, una medición. Si cambias prompt y modelo a la vez, no sabes qué ayudó.
  • Mira los casos que se rompieron, no solo el total: subir de 22 a 24 bajando 3 casos que antes pasaban es una regresión disfrazada de mejora.
  • Ojo con las evals que siempre pasan. Si tu suite da 30/30 desde el día uno, no está midiendo nada; endurece los criterios.
  • Automatiza en CI. Una eval que no corre sola se convierte en una eval que no corre. → Observabilidad y trazas

Lo que ya traen las herramientas

  • ADK: criterios de evaluación, simulación de usuario, simulación de entorno y métricas personalizadas, con herramienta de optimización. Es la suite más completa que he visto integrada en un framework de agentes. - Source: Evaluation - Google ADK
  • AI SDK: evaluación como parte del core, útil cuando tu app ya vive en TypeScript. - Source: Evaluation - Vercel AI SDK
  • Evalite (de AI Hero): runner liviano con scorers incluidos, pensado para iterar rápido. - Source: Evalite v1 Preview - AI Hero

Lo que haría esta semana

  1. Escribe 10 casos reales de tu agente, con el resultado esperado de cada uno.
  2. Corre el baseline y anota el número. Ese es tu punto de partida.
  3. Convierte cada bug en un caso nuevo (regla: nunca dos veces el mismo fallo).
  4. Elige 3 casos de tarea (end-to-end) para no medir solo el formato.
  5. Mete la suite en CI con un umbral mínimo que no se puede bajar.

Las evals son la pieza 9 del harness: sin ellas, las otras ocho se optimizan a ciegas. El marco completo está en Harness Engineering y en la guía AI Engineering.

¿Tienes evals de tu agente o confías en la sesión que probaste ayer? Cuéntame en los comentarios.

Referencias

> Más posts