Un eval de discovery —la suite de casos con la que decides si el sistema pasa o no— no es un entregable. Es el instrumento que decide si el build debe existir, y a veces la respuesta honesta es no construir. Cuando lo es, lo correcto es decirlo y devolver el fee en la semana dos, antes de que nadie haya tocado el presupuesto del build. Así es como debería funcionar.
Qué forma tiene el proyecto antes de escribir el eval
Un equipo llega con un problema real y un presupuesto real. La versión más frecuente suena así: «RAG sobre nuestros documentos internos para que soporte, ventas u operaciones dejen de hacer las mismas preguntas». Presupuesto aprobado. Sponsor ejecutivo. Y la demo de algún vendor ya dando vueltas por la sala.
No empezamos escribiendo prompts. Empezamos escribiendo el eval.
Días 1 a 9: preguntas, no prompts
Nos sentamos con quienes van a usar el sistema de verdad. No con el sponsor ejecutivo: con los agentes, los analistas, los operadores. A cada uno le pedimos entre treinta y cincuenta preguntas que esperaría que el sistema respondiera bien. Recogemos también sus respuestas honestas, incluidas las que llevan números, fechas o un juicio de criterio.
Ese conjunto es el eval. Inputs reales. Outputs esperados. Casos de rechazo («aquí el sistema debería decir que no sabe»). Y los casos en que la respuesta correcta es «esto se escala a un humano».
Para el día nueve ya hemos medido lo que existe —la demo del vendor, el prototipo interno, una llamada baseline al LLM— contra el eval que escribieron los propios usuarios.
Cuando las cuentas matan al build
Cuando un eval mata un build, el resultado no está cerca. Piensa en una tasa de aprobación estricta rondando el veintitantos por ciento y una indulgente en el cuarenta y pico: el tipo de brecha que ningún prompt engineering cierra.
La tasa de aprobación por sí sola no es la señal de cancelación. La señal está en la economía unitaria que esa tasa implica. Si el bot se equivoca en tres de cada cuatro respuestas y cada respuesta equivocada genera una escalación, el bot no resuelve tickets: los fabrica. El build no necesita salir más barato. El build necesita no ocurrir.
Llevamos el eval, los modos de fallo y esa economía unitaria a la reunión de steering. Recomendamos no construir. Devolvemos el fee de discovery.
Qué decide en realidad el eval
El eval hace bastante más que controlar la calidad: decide si los próximos noventa días de ingeniería llegan a existir. Casi todos los equipos lo descubren cuando ya se gastaron el presupuesto del build. Nuestra regla es descubrirlo en las dos primeras semanas, a nuestro riesgo y no al tuyo.
Cuando el eval sale limpio, el build es simple: en verde mergea, en rojo no, y el sistema operativo se sostiene solo. Cuando el eval directamente no se puede escribir, ninguna dosis de prompt engineering va a volver honesto al sistema. Ese es el proyecto que no tomamos.