El Harness de Evals que Uso para Lanzar Agentes de IA Sin Miedo

Tabla de contenidos

Actualizado junio 2026.

TL;DR: La razón por la que puedo cambiar un prompt o intercambiar un modelo en un agente en vivo sin contener la respiración es una sola cosa: un harness de evals. Un conjunto fijo de casos de prueba calificados, puntuados automáticamente — aserciones duras donde puedo escribirlas, un juez LLM donde no puedo — ejecutado antes de cada cambio. Si la puntuación se mantiene, lanzo. Si baja, no lo hago. El conjunto de pruebas no es sintético; se construye a partir de fallos reales de producción, así que cada bug se convierte en una prueba de regresión permanente.

Lectura del operador: A lo largo de más de 100 agentes, la diferencia entre los que toco con confianza y los que me dan miedo es si tienen evals. Sin un harness de evals, cada ajuste de prompt es una apuesta. Un harness de evals convierte “creo que esto es mejor” en “esto es medible: 4 puntos mejor y no rompió nada.” Ese es todo el desbloqueo.

No lanzarías código sin pruebas. La gente lanza agentes sin evals constantemente, y luego se preguntan por qué un “diminuto ajuste de prompt” rompió producción. Un harness de evals es la suite de pruebas para software no determinista. Aquí está el que realmente ejecuto.

Empieza con un conjunto de pruebas construido a partir de fallos reales

El harness es tan bueno como sus casos de prueba, y los mejores casos de prueba vienen de producción, no de tu imaginación. Cada vez que un agente falla en el mundo real, capturo la entrada exacta (registro cada ejecución con un ID de traza — ver cómo depurar un agente en producción) y la convierto en un caso de eval:

interface EvalCase {
  id: string;
  input: AgentInput;        // la entrada exacta de producción
  expected?: string;        // verdad de referencia, cuando existe
  assertions: Assertion[];  // comprobaciones duras que deben pasar
  rubric?: string;          // para el juez LLM, cuando la salida es abierta
}

Dos prácticas importan aquí. Extrae de producción, para que tus evals prueben lo que realmente se rompe, no lo que adivinaste que podría. Y cubre el abanico — el camino feliz, los casos límite, las entradas adversariales y las entradas vacías/malformadas que causan fallos silenciosos. Un conjunto de pruebas de 30 a 50 casos bien elegidos atrapa mucho más que 500 perezosos. Prefiero tener 40 casos que cada uno represente un modo de fallo real que mil que prueben todos el mismo camino fácil.

Puntúa con aserciones primero, un juez LLM después

No toda salida necesita un modelo que la califique. Recurro al evaluador más barato que funcione.

Aserciones duras para todo lo estructurado. ¿La salida se parsea como JSON válido? ¿Contiene el campo requerido? ¿La fecha extraída está dentro del rango? ¿Llamó a la herramienta correcta con los argumentos correctos? Estas son deterministas, gratuitas e inequívocas — escribe tantas como puedas.

const assertions: Assertion[] = [
  (out) => isValidJSON(out),
  (out) => parse(out).category in ALLOWED_CATEGORIES,
  (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1,
];

Un juez LLM para el resto abierto — tono, utilidad, “¿esto realmente respondió la pregunta?”. Aquí le das a un modelo la entrada, la salida y una rúbrica, y le pides que puntúe. Dos reglas mantienen honesto al juez: haz la rúbrica específica (una escala de 1 a 5 con anclas descritas supera a “califica la calidad”), y usa un modelo fuerte como juez — juzgar es una tarea de razonamiento, así que este es un lugar donde con gusto pago por Sonnet incluso cuando el agente en sí corre con Haiku según las matemáticas de costos. Una rúbrica vaga o un juez débil te da ruido que parece señal.

Ejecuta el harness antes de cada cambio

El harness existe para responder una pregunta: ¿este cambio hizo al agente mejor o peor? Así que lo ejecuto antes de cada edición de prompt, intercambio de modelo o cambio de herramienta.

# línea base en main
npm run eval -- --suite=booking-agent > baseline.json

# haz el cambio, luego re-ejecuta
npm run eval -- --suite=booking-agent > candidate.json

# compara
npm run eval:diff baseline.json candidate.json

El diff muestra la puntuación agregada, el pasa/falla por caso y — crucialmente — qué casos específicos regresaron. Un agregado que sube mientras tres casos se rompen silenciosamente no es una mejora; es un trueque que quiero ver y aprobar, no uno que se cuela. Vigilar el diff por caso es como evitas “arreglé una cosa, rompí otras dos,” el modo de fallo que hace que la gente le tenga miedo a sus propios prompts.

Establece una compuerta de regresión y deja que bloquee

Una vez que confías en el harness, conéctalo al camino hacia producción como una compuerta. Mi regla es contundente: un cambio que baja la puntuación por debajo del umbral de la línea base no se lanza. No “lo revisaré después” — está bloqueado, igual que una prueba de CI que falla.

const PASS_THRESHOLD = 0.90; // el 90% de los casos debe pasar
if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) {
  throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`);
}

Esto es lo que convierte los evals de un lujo opcional en lo que te permite moverte rápido. La compuerta es lo que hace que “lanzar sin miedo” sea literalmente cierto: el peor caso para un mal cambio es una ejecución de eval en rojo, no un incidente en producción. Y como el conjunto de pruebas crece cada vez que algo se rompe, la compuerta se vuelve más estricta y más protectora con el tiempo por sí sola.

Ten en cuenta el no-determinismo en la puntuación

Una sutileza que hace tropezar a la gente: la misma entrada puede puntuar diferente entre ejecuciones porque el modelo muestrea de forma distinta. Si ejecutas cada caso una sola vez, verás regresiones fantasma — un caso que “se rompió” que en realidad es solo ruido de muestreo.

Dos mitigaciones. Ejecuta los evals a temperature: 0 para reducir la varianza (no la eliminará del todo). Y para los casos que has visto parpadear, ejecútalos N veces y toma la tasa de aprobación, no un único pasa/falla. Un caso que pasa 9 de 10 está en mejor forma que uno que pasa 5 de 10 aunque ambos puedan mostrar una sola ejecución en verde. Este es el mismo principio de volumen-sobre-anécdota que uso cuando depuro fallos intermitentes — una ejecución es una opinión, cincuenta ejecuciones son datos.

Cierra el ciclo con monitoreo de producción

El harness de evals prueba contra casos conocidos. Producción lanza casos novedosos. Así que el ciclo es: monitorea el comportamiento en vivo, atrapa un nuevo modo de fallo, conviértelo en un caso de eval, arréglalo, y ahora está permanentemente protegido. El lado del monitoreo — rastrear la tasa de éxito, la validez de la salida y el costo por ejecución en tráfico en vivo — es lo que cubro en cómo mido si un agente de IA realmente funciona. Los evals y el monitoreo son dos mitades del mismo sistema: el monitoreo encuentra los bugs, los evals se aseguran de que sigan muertos.

Ese ciclo de retroalimentación es el verdadero producto. Cualquier conjunto de evals individual se vuelve obsoleto; un proceso que convierte cada fallo de producción en una prueba permanente se vuelve más fuerte cada semana. Así es como un agente pasa de “da miedo tocarlo” a algo que refactorizaré un viernes por la tarde sin pestañear.

Preguntas frecuentes

¿Qué entra en un conjunto de evals para un agente de IA?

Entradas reales de producción convertidas en casos calificados — camino feliz, casos límite, entradas adversariales y malformadas — cada uno con aserciones duras y, para salidas abiertas, una rúbrica de juez LLM. De 30 a 50 casos extraídos de fallos reales superan a cientos de casos sintéticos que prueban todos el camino fácil.

¿Debería usar un LLM para calificar las salidas del agente?

Usa aserciones duras dondequiera que la salida sea estructurada (JSON válido, campo correcto, llamada a la herramienta correcta) — son gratuitas y deterministas. Reserva un juez LLM para cualidades abiertas como el tono y la utilidad, con una rúbrica específica y un modelo juez fuerte para obtener señal, no ruido.

¿Cómo evito que un cambio de prompt rompa producción silenciosamente?

Ejecuta el harness de evals antes de cada cambio y compara con una línea base, vigilando las regresiones por caso, no solo la puntuación agregada. Luego condiciona los despliegues al resultado para que cualquier cambio que baje del umbral de la línea base se bloquee como una prueba que falla.

¿Cómo manejo el no-determinismo en los evals?

Ejecuta a temperatura 0 para reducir la varianza, y para los casos que parpadean, ejecútalos varias veces y puntúa la tasa de aprobación en lugar de una sola ejecución. Un caso que pasa 9 de 10 veces está más sano que uno que pasa 5 de 10, incluso si una sola ejecución muestra ambos en verde.