Todos los equipos con los que hemos trabajado empezaron con un conjunto de evaluación y terminaron reconstruyéndolo tras el primer incidente en producción. La primera versión suele probar que el demo todavía funciona. No prueba que el producto pueda seguir funcionando después de nuevos usuarios, nuevos documentos, nuevo comportamiento del modelo y nuevos tickets de soporte.
La solución es tratar el arnés de evaluación como una superficie de producto, no como un fixture de tests.
Trata la evaluación como un producto
El arnés tiene usuarios: ingenieros depurando regresiones, dueños de producto decidiendo si un release puede salir, líderes de soporte decidiendo si una falla bloquea y responsables de finanzas mirando el costo del modelo. Esos usuarios tienen flujos y los datos tienen un esquema. Si te los saltas, tendrás un set de evaluación que nadie confía dentro de un trimestre.
La falla es predecible: la primera evaluación es una hoja con ejemplos felices, el producto sale, soporte encuentra bordes y nadie sabe si los nuevos ejemplos van al set bloqueante, al monitoreo o al backlog. Para entonces, la evaluación ya se trata como fixture de tests y no como superficie de producto.
Los tres sets que separamos
El primer error es poner todos los ejemplos en un solo set bloqueante. Los ejemplos de producción no cumplen todos la misma función.
- Set bloqueante: pequeño, estable y severo. Si falla, el release se detiene.
- Set de monitoreo: más grande y más ruidoso. Si deriva, alguien investiga, pero no todo fallo bloquea un release.
- Set de backlog: fallas reales que todavía no se entienden lo suficiente como para convertirse en gate.
Esa separación importa porque la confianza en la evaluación es frágil. Si el set bloqueante contiene ejemplos ambiguos, los ingenieros aprenden a ignorar runs rojos. Si el set de monitoreo es demasiado pequeño, la calidad del producto deriva sin que nadie lo note. Si el backlog nunca madura hacia un gate, producción vuelve a descubrir la misma falla.
Qué incluye la fábrica hoy
- Un dataset versionado guardado junto al código.
- Una rúbrica con umbrales explícitos para bloquear un release.
- Una revisión semanal donde las nuevas regresiones se priorizan antes de acumularse.
- Un generador de fixtures para bordes recurrentes: fuentes malas, registros obsoletos, tool calls mal formados, pedidos inseguros y momentos de "necesita humano".
- Un presupuesto de costo y latencia junto al umbral de calidad.
- Ownership: una persona que puede decidir cuándo una falla de producción se convierte en bloqueador de release.
Qué entra en la primera versión
- Inputs reales de usuarios, no ejemplos inventados para el prompt.
- Respuestas esperadas, casos de rechazo y casos de "necesita humano".
- Un set adversarial pequeño para las fallas que el negocio no puede tolerar.
- Un presupuesto de costo y latencia junto al umbral de calidad.
- Un owner que pueda decidir cuándo una falla de producción bloquea el siguiente release.
Qué todavía no pertenece
No toda falla rara de producción pertenece al eval bloqueante el día que aparece. Algunas fallas necesitan primero juicio de producto. Algunas revelan un estado de workflow que falta. Algunas son problemas de calidad de datos antes del modelo. Algunas deben pasar por monitoreo antes de convertirse en gate.
La revisión de evaluación existe para tomar esa decisión deliberadamente. Si no, el arnés se convierte en un cajón de anécdotas alarmantes y el equipo deja de confiar en él.
El estándar de handover
En el handover, tu equipo debería poder responder cinco preguntas sin nosotros:
- Qué casos bloquean un release.
- Qué ejemplos se monitorean pero no bloquean.
- Cómo una nueva falla de producción se convierte en caso de evaluación.
- Quién es dueño de los cambios de umbral.
- Qué presupuesto de costo y latencia debe respetar cada ruta de modelo.
El punto no es hacer una evaluación enorme. El punto es que sea lo bastante confiable para que un run verde signifique algo y uno rojo detenga el release.