Evals o no se entregó

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.