Una evaluación de discovery no es un entregable. Es el instrumento con el que decidimos si el build debe existir. Dos veces en los últimos dieciocho meses nos dijo que no construyéramos, y devolvimos el fee de discovery en ese momento. Así fueron esas semanas.
La forma del proyecto antes de escribir la evaluación
Un equipo llega con un problema real y un presupuesto real. La versión más común es algo como "RAG sobre nuestros documentos internos para que soporte / ventas / operaciones deje de hacer las mismas preguntas." Presupuesto aprobado. Sponsor ejecutivo. Una demo de vendor ya en la sala.
No empezamos escribiendo prompts. Empezamos escribiendo la evaluación.
Días 1–9: preguntas, no prompts
Nos sentamos con las personas que de verdad van a usar el sistema. No con el sponsor ejecutivo — con los agentes, los analistas, los operadores. Le pedimos a cada uno que escriba entre treinta y cincuenta preguntas que esperaría que el sistema respondiera correctamente. Recogemos sus respuestas honestas, incluidas las que contienen números, fechas o decisiones de criterio.
Ese set es la evaluación. Inputs reales. Outputs esperados. Casos de rechazo ("el sistema debería decir que no sabe"). Los casos donde la respuesta correcta es "escalar a un humano".
Para el día nueve evaluamos lo que ya existe — la demo del vendor, el prototipo interno, una llamada baseline al LLM. Lo evaluamos contra la evaluación que escribieron los usuarios.
Cuando la matemática mata al build
En los dos casos en los que nos retiramos, el score no estuvo cerca. La tasa de aprobación estricta quedó en torno al alto veinte por ciento. La tasa indulgente quedó en los cuarentas.
La tasa de aprobación por sí sola no es la señal de cancelación. La señal es la economía unitaria que implica esa tasa. Si el bot se equivoca en tres de cada cuatro respuestas y una respuesta equivocada genera una escalación, el bot está generando tickets, no resolviéndolos. El build no necesita ser más barato. El build necesita no ocurrir.
Llevamos la evaluación, los modos de falla y la economía unitaria implícita a la reunión de steering. Recomendamos no construir. Devolvemos el fee de discovery.
Qué decide en realidad la evaluación
La evaluación no es una puerta de calidad. Es el instrumento que decide si los próximos noventa días de ingeniería existen. La mayoría de los equipos lo descubre solo después de gastar el presupuesto de build. La regla de la fábrica es que lo descubrimos en las primeras dos semanas, a nuestro riesgo, no al tuyo.
Cuando la evaluación está limpia, el build es directo — evaluación verde se mergea, roja no, el sistema operativo se sostiene solo. Cuando la evaluación no se puede escribir, ninguna cantidad de prompt engineering hará que el sistema sea honesto. Ese es el proyecto que no vamos a tomar.