La mayoría de las fallas de flujos de trabajo de IA en la primera semana no son sorpresas. Son predecibles. El equipo simplemente nunca las documentó antes de lanzar.
Un paquete de evaluación cambia eso. Es un conjunto estructurado de entradas representativas, salidas esperadas y criterios de aprobación/falla ensamblado antes de que un flujo de trabajo entre en producción. No es una suite de pruebas unitarias. No es un benchmark contra un dataset público. Es una colección pequeña y deliberada de casos que refleja tu entorno de producción real.
Construirlo toma unas pocas horas. Omitirlo cuesta días.
Qué es realmente un paquete de evaluación
Una prueba unitaria verifica si el código se ejecuta correctamente. Un benchmark mide el rendimiento contra una tarea estandarizada. Un paquete de evaluación no hace ninguna de esas cosas.
Responde una sola pregunta: ¿este flujo de trabajo se comporta correctamente con las entradas que realmente va a recibir?
El paquete contiene tres elementos por cada caso:
- Entrada: un prompt, registro o documento realista que el flujo de trabajo procesará
- Salida esperada: cómo se ve el comportamiento correcto — una etiqueta de clasificación, un campo estructurado, un resumen con elementos requeridos específicos
- Criterio de aprobación/falla: una regla concreta para decidir si la salida califica
El criterio es la parte que la mayoría de los equipos omite. "Suficientemente bueno" no es un criterio. "Contiene el nombre de la cuenta y una recomendación de siguiente paso" sí lo es.
Cómo seleccionar los 15–20 casos correctos
Quince a veinte casos es el tamaño adecuado para un paquete previo al despliegue. Con menos se pierde varianza real. Con más, el paquete se vuelve costoso de mantener y lento de ejecutar.
El objetivo es cubrir el 80% de la varianza de producción con esos casos. Así se encuentran.
Empieza con el caso limpio
Uno o dos casos donde todos los campos requeridos están presentes y la entrada es inequívoca. Este es tu baseline. Si el flujo de trabajo falla aquí, nada más importa.
Agrega entradas de borde
Entradas que son técnicamente válidas pero inusuales. Un nombre de empresa con caracteres especiales. Un campo de fecha en un formato inesperado. Un campo de texto libre que es 10 veces más largo de lo típico. Estos exponen parsing frágil y sensibilidad al prompt.
Agrega casos con campos faltantes
Los datos de producción reales son incompletos. Elige los tres campos con mayor probabilidad de estar ausentes y construye un caso para cada uno. El flujo de trabajo necesita un comportamiento definido cuando esos campos faltan — no un crash, no un valor alucinado.
Agrega clasificaciones ambiguas
Si el flujo de trabajo toma alguna decisión de clasificación — industria, intención, prioridad, sentimiento — encuentra dos o tres entradas que estén en la frontera entre categorías. Estos son los casos donde el juicio del modelo importa más y donde el drift aparece primero.
Agrega patrones adversariales conocidos
Cada dominio los tiene. Para flujos de trabajo de ventas outbound, podría ser un registro de contacto donde el título es "CEO" pero la empresa tiene dos empleados. Para procesamiento de documentos, podría ser un PDF donde los datos relevantes están en el pie de una tabla. Recoge estos de tu equipo antes del despliegue, no después.
Ejecutar el paquete como gate de despliegue
Un paquete de evaluación solo funciona si es obligatorio. Si es opcional, se omitirá bajo presión de deadline — que es exactamente cuando más importa.
La integración es simple. Agrega la ejecución del eval como un ítem de checklist antes de que cualquier flujo de trabajo pase a producción. El ítem tiene dos campos:
- Puntuación baseline: el porcentaje de casos que el flujo de trabajo aprobó en la primera ejecución
- Umbral mínimo: la puntuación requerida para lanzar
Establece el umbral antes de ejecutar el paquete. Establecerlo después de ver la puntuación anula el propósito.
Un umbral inicial razonable para la mayoría de los flujos de trabajo es 85%. Eso significa que 17 de 20 casos pasan. Las tres fallas se documentan — no necesariamente se corrigen, pero se documentan — para que el equipo sepa qué no maneja aún el flujo de trabajo.
Qué hacer con las fallas
No toda falla bloquea el despliegue. Algunas fallas revelan casos de borde que el flujo de trabajo nunca fue diseñado para manejar. Esos se registran como limitaciones conocidas.
Algunas fallas revelan que el flujo de trabajo está equivocado en casos que sí debería manejar. Esos bloquean el despliegue.
La distinción se hace antes de ejecutar el paquete, cuando el equipo decide qué casos están dentro del alcance y cuáles fuera. Esa decisión es parte de construir el paquete, no de interpretar los resultados.
Volver a ejecutar el paquete
El paquete no es un artefacto de una sola vez. Ejecútalo de nuevo después de cualquier cambio de prompt, actualización de modelo o cambio en el schema de datos upstream. La puntuación baseline de la primera ejecución se convierte en el piso. Si una ejecución posterior puntúa más bajo, algo regresó.
Este es el ciclo de retroalimentación que mantiene un flujo de trabajo estable a lo largo del tiempo sin requerir una auditoría completa cada vez que algo cambia.
El beneficio operacional
Los equipos que construyen paquetes de evaluación antes del despliegue encuentran problemas de producción en horas, no en días. También tienen un registro concreto de contra qué fue probado el flujo de trabajo — útil cuando un stakeholder pregunta por qué un caso específico fue manejado de cierta manera.
El paquete no garantiza un flujo de trabajo perfecto. Garantiza un flujo de trabajo que fue verificado contra condiciones reales antes de tocar datos reales.
Ese es un punto de partida diferente al que tiene la mayoría de los equipos.
Si estás construyendo o auditando un flujo de trabajo de IA y quieres un segundo par de ojos sobre tu enfoque de evaluación, inicia una conversación →