# Evals o no se entregó

Por qué me niego a llevar un agent a producción sin un set de evaluación held-out, qué hace que uno sea útil y el failure mode que sigo viendo cuando los equipos se lo saltan.

- **Author:** Fedor Chishchin
- **Published:** 2026-05-10
- **Tags:** agents, eval, methodology
- **Source:** https://fedorthinks.com/es/blog/evals-or-it-didnt-ship

---

El failure mode más común que veo en proyectos de AI es este: un equipo
entrega un demo, el demo funciona con los inputs que el equipo lleva
semanas mirando, y nadie sabe si el sistema realmente mejoró o empeoró
entre junio y agosto.

El arreglo es poco glamoroso: un set de evaluación held-out, ejecutado antes de cada merge,
que el agent nunca ve durante el desarrollo.

## Qué significa "held out" en la práctica

Si escribiste el agent y además viste los inputs de la eval, la eval
está contaminada. Lo mismo aplica a los ajustes de prompt: cada prompt que toco ve
el split de desarrollo. El split held-out queda bloqueado en el control de versiones,
lo lee CI, y solo lo inspeccionan humanos cuando el score se mueve lo
suficiente como para investigar. Eso es todo.

## Qué hace que una eval sea útil

Tres propiedades, en orden:

1. **Refleja el tráfico de producción.** Un benchmark ingenioso que armó
   otra persona es útil para comparar entre sistemas pero no te dice qué
   necesitan de verdad tus usuarios. Mineá los logs de producción, sampleá, anonimizá,
   curá. Repetí cada trimestre.
2. **Mide algo sobre lo que de verdad actuarías.** "Utilidad 4.2/5"
   no es accionable. "78% de los escenarios pasan el contrato de structured output"
   sí lo es.
3. **Es barata de correr.** Si la eval tarda seis horas, nadie la corre
   en un PR. Apuntá a cinco minutos para el smoke set, una hora para el
   completo.

## La forma de una buena suite de evals

Dos capas:

- Un smoke set pequeño (~30 escenarios) que corre en cada PR. Atrapa
  regresiones temprano.
- Un set held-out más grande (~300 escenarios) que corre en main, semanalmente. El
  set que el agent nunca ve durante el desarrollo.

Los benchmarks públicos van junto a estos, no en lugar de ellos — son
útiles para hablar con otros equipos, pero el contrato que importa es el
que tenés con tu propio tráfico de producción.

## Lo que dejé de aceptar

"Se veía bien en testing" no es un estado en el que deje entrar a los agents
a producción. Si la eval no existe, el agent no se entrega. Si
el score de la eval regresiona, el merge no ocurre hasta que entendemos
por qué.

Esto suena duro hasta que ves un sistema regresionar en silencio durante seis
sprints porque nadie estaba midiendo. Ahí suena obvio.