Todos los equipos con los que hemos trabajado empezaron con un eval —la suite de casos que decide si el sistema pasa— y acabaron rehaciéndolo tras el primer incidente en producción. La primera versión suele demostrar que la demo sigue funcionando. No demuestra que el producto aguante usuarios nuevos, documentos nuevos, un comportamiento nuevo del modelo y tickets de soporte nuevos.
La salida es tratar el arnés de evaluación como una superficie de producto, no como un fixture de tests.
Trata el eval como un producto
El arnés tiene usuarios: ingenieros que depuran regresiones, dueños de producto que deciden si un release puede salir, líderes de soporte que deciden si un fallo bloquea, y gente de finanzas mirando el costo del modelo. Esos usuarios tienen flujos, y los datos tienen un schema. Si te saltas eso, en un trimestre tendrás un eval en el que nadie confía.
El fallo es previsible: el primer eval es una hoja de cálculo con ejemplos felices, el producto sale, soporte encuentra los bordes y nadie sabe si los ejemplos nuevos van al set bloqueante, al de monitoreo o al backlog. Para entonces el eval ya se trata como un fixture de tests y no como una superficie de producto.
Los tres sets que mantenemos separados
El primer error es meter todos los ejemplos en un único 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: fallos reales que aún no se entienden lo bastante como para convertirlos en gate.
Esa separación importa porque la confianza en el eval es frágil. Si el set bloqueante tiene ejemplos ambiguos, los ingenieros aprenden a ignorar las ejecuciones en rojo. Si el set de monitoreo es demasiado pequeño, la calidad deriva sin que nadie se entere. Y si el backlog nunca madura hasta ser un gate, producción vuelve a descubrir el mismo fallo una y otra vez.
Qué incluye hoy nuestro estándar
- Un dataset de eval versionado y guardado junto al código.
- Un scorecard con umbrales explícitos para bloquear un release.
- Una revisión semanal donde las regresiones nuevas se priorizan antes de acumularse.
- Un generador de fixtures para los bordes que se repiten: fuentes malas, registros obsoletos, tool calls mal formadas, peticiones inseguras y momentos de «esto lo decide un humano».
- Un presupuesto de costo y latencia al lado del umbral de calidad.
- Un dueño: una persona que puede decidir si un fallo de producción pasa a bloquear releases.
Qué entra en la primera versión
- Inputs reales de usuarios, no ejemplos inventados para lucir el prompt.
- Respuestas esperadas, casos de rechazo y casos de «esto lo decide un humano».
- Un set adversarial pequeño para los fallos que el negocio no puede tolerar.
- Un presupuesto de costo y latencia al lado del umbral de calidad.
- Un dueño que pueda decidir cuándo un fallo de producción bloquea el siguiente release.
Qué todavía no entra
No todo fallo raro de producción entra en el eval bloqueante el día que aparece. Algunos necesitan primero un juicio de producto. Otros revelan un estado del workflow que falta. Otros son problemas de calidad de datos, río arriba del modelo. Y otros deberían pasar por monitoreo antes de convertirse en gate.
La revisión del eval existe para tomar esa decisión a conciencia. Si no, el arnés acaba siendo un cajón de sastre lleno de anécdotas inquietantes y el equipo deja de confiar en él.
El estándar del handover
En el handover, tu equipo tiene que poder responder cinco preguntas sin nosotros:
- ¿Qué casos bloquean un release?
- ¿Qué ejemplos se monitorean pero no bloquean?
- ¿Cómo se convierte un fallo nuevo de producción en un caso del eval?
- ¿Quién es dueño de los cambios de umbral?
- ¿Qué presupuesto de costo y latencia debe respetar cada ruta de modelo?
La idea no es tener un eval enorme. La idea es que sea lo bastante confiable como para que una ejecución en verde signifique algo y una en rojo detenga el release.