Una evaluación de discovery 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 gastado el presupuesto del build. Así es como debería funcionar.
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
Cuando la evaluación mata un build, el score no está cerca. Imagina una tasa de aprobación estricta en torno al alto veinte por ciento y una indulgente en los cuarentas — 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 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 hace más que controlar la calidad: decide si los próximos noventa días de ingeniería existen siquiera. 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.