El problema
Un equipo de ingeniería modifica el system prompt de un agente de triaje para reducir el gasto en tokens — reemplazando un bloque de instrucciones extenso por uno más conciso. En producción, nadie nota anomalías durante tres semanas. Hasta que un cliente estratégico recibe una respuesta que ignora por completo una política de reembolsos vigente desde hace dos años. El equipo no tenía forma de prever la falla porque carecía de un método para medir empíricamente si "el agente sigue cumpliendo los requisitos" antes de desplegar el cambio.
Esto no es un problema de redacción de prompts. Es un problema de evidencia empírica. Sin una evaluación automatizada (eval), cada cambio en un agente es una apuesta a ciegas: puede mejorar o empeorar el sistema, y la única forma de saberlo es esperar a que los usuarios reporten incidentes.
El concepto central
Una eval es un conjunto fijo de casos representativos — con entradas conocidas y criterios de éxito verificables — que se ejecutan contra el agente antes de que cualquier cambio pase a producción. No es idéntica a una prueba unitaria determinista, porque las respuestas de un modelo no son byte a byte idénticas. Tampoco es una inspección cualitativa informal ("pedirle a Claude que lea la respuesta y diga si quedó bien"), porque las revisiones subjetivas no generan métricas comparables entre versiones.
Una eval mínima pero efectiva consta de tres componentes:
- Un conjunto fijo de casos de prueba: incluye ejemplos representativos de los modos de fallo históricos y casos límite reales — no solo escenarios triviales.
- Criterios de éxito verificables: comprobaciones programáticas (validar campos requeridos, verificar cumplimiento de políticas) o evaluaciones basadas en modelos con rúbricas explícitas, nunca juicios vagos de "se ve bien".
- Métricas cuantitativas a lo largo del tiempo: registrar la tasa de acierto en el conjunto, transformando impresiones subjetivas en evidencia de ingeniería comparable.
El error más común es confundir evaluación con depuración puntual. Ejecutar el agente una vez, leer la salida y asumir que funciona es depuración aislada — útil para entender un caso puntual, pero inútil para garantizar que el cambio no rompió otros 40 casos que ya funcionaban.
Desacoplar la generación de la evaluación
Un requisito arquitectónico fundamental es separar la fase que genera la respuesta de la fase que la revisa. Si el mismo agente que produjo la respuesta evalúa su propia exactitud, se introduce un sesgo de confirmación: los modelos tienden a racionalizar y defender sus propias salidas. Una fase de revisión independiente — mediante otro prompt o validador enfocado estrictamente en criterios objetivos, sin acceso a la cadena de razonamiento original — detecta alucinaciones que el generador jamás admitiría.
Esto define las compuertas de despliegue (release gates): los despliegues no se aprueban por percepciones del equipo, sino por métricas objetivas — "la tasa de acierto general no cayó por debajo del umbral acordado y la suite de regresión (casos de fallo históricos) presenta cero errores". Un agente puede alcanzar un 95% en la eval general y, aun así, haber fallado en el caso exacto que provocó un incidente el trimestre pasado. Por ello, la suite de regresión debe ampliarse cada vez que se detecta un bug real en producción.
Ponlo en práctica
En el laboratorio de esta lección construirás un flujo de eval mínimo en Python: un conjunto fijo de casos, validadores de aserciones programáticas y una fase de revisión independiente que evalúa respuestas frente a rúbricas de referencia — aplicando la separación arquitectónica que elimina el sesgo de autoevaluación.