Problema
Muchos equipos escriben un benchmark antes de comprender cómo falla su producto con IA. Terminan optimizando una puntuación cómoda mientras usuarios reales encuentran errores que la suite nunca imaginó.
Ocurre así: se redactan cincuenta preguntas razonables, el modelo obtiene un 92 % y el piloto recibe luz verde. Dos semanas después aparecen los fallos verdaderos. El agente usa la herramienta correcta con parámetros equivocados, responde bien sobre una premisa falsa o entrega una recomendación válida a la persona equivocada.
El benchmark no mintió. Se le pidió medir un producto que todavía no se conocía.
Tesis
El prototipo no es solo una demo. Es el instrumento que descubre el benchmark. Primero se observan outputs y se nombran los fallos; después se automatizan las comprobaciones que de verdad discriminan calidad.
Por eso eval-driven development no significa comenzar escribiendo evals. Significa permitir que la evaluación dirija el desarrollo desde el primer contacto con comportamiento real. El orden importa: descubrir, formalizar, automatizar y mantener.
Principio operativo: una eval útil es memoria de un fallo que el equipo decidió no volver a pagar.
Framework
La secuencia correcta es prototipo -> taxonomía de fallos -> jueces -> calibración humana -> gate de release.
- Prototipo: produce suficiente variedad para que el sistema muestre sus bordes. No se busca demostrar valor; se busca encontrar conducta inesperada.
- Taxonomía: agrupa fallos por mecanismo, no por anécdota. Alucinación, mala selección de herramienta, argumento inseguro y escalado tardío necesitan dueños distintos.
- Jueces: asigna el control más barato que siga siendo fiable. Una expresión regular comprueba formato; no evalúa criterio.
- Calibración: compara jueces automáticos con expertos y estudia desacuerdos. El objetivo no es que el juez parezca inteligente, sino saber cuándo deja de serlo.
- Gate: impide liberar una versión que reabre fallos críticos, aunque mejore la media global.
Airbnb describe una práctica parecida al evaluar GenAI a escala: combinar comprobaciones programáticas, jueces LLM y revisión humana, incluida la conducta de herramientas en sistemas agentivos.
Señal medible: porcentaje de incidentes de producción que ya estaba representado en el set de evaluación.
Por que importa ahora
Los modelos y agentes cambian rápido; una evaluación congelada envejece antes que el producto. El activo duradero no es una cifra, sino un proceso que incorpora nuevos fallos y recalibra criterios con expertos.
Un agente complica además la unidad de análisis. La respuesta final puede ser correcta aunque el razonamiento operativo haya sido peligroso: quizá consultó datos innecesarios, reintentó cinco veces o estuvo a punto de ejecutar una acción irreversible. Evaluar solo la frase entregada equivale a aprobar un viaje mirando la fotografía del destino.
La suite debe cubrir outcome y trayectoria. No necesita inspeccionar pensamiento privado; sí debe registrar selección de herramientas, argumentos, permisos, costes, latencia y escalados observables.
Anti-ejemplo
“Nuestro agente tiene un 92 % de éxito.” Sin definición de éxito, distribución de casos y revisión de errores, la cifra es decoración ejecutiva.
Peor aún es celebrar la media cuando el 8 % restante concentra los casos de mayor riesgo. Un 99 % puede ser insuficiente para pagos y un 80 % puede ser extraordinario para una herramienta de ideación. La severidad manda sobre el promedio.
Protocolo (3 pasos)
- Muestrea primero. Revisa una tanda diversa de outputs del prototipo.
- Nombra fallos. Convierte patrones repetidos en casos con severidad y owner.
- Automatiza después. Usa reglas, jueces y humanos según coste y riesgo.
Añade a cada caso cinco campos: input, contexto relevante, comportamiento esperado, severidad y evidencia de aceptación. Sin ellos, el dataset es una colección de ejemplos; con ellos, empieza a ser un sistema de calidad.
| Tipo de control | Sirve para | No sustituye |
|---|---|---|
| regla | formato y límites | criterio semántico |
| juez LLM | escala y matiz | calibración humana |
| experto | riesgo y contexto | cobertura continua |
Relacionado
- Eval Flywheel: los agentes en producción no se arreglan con prompts
- AI Evaluation Stack 2026: medir sin teatro
Fuentes consultadas
Proximo paso
Revisa cien ejecuciones recientes, agrupa los fallos y añade al menos un caso por patrón. Solo entonces decide qué parte merece un juez automático.