El problema
"Resume este informe de forma profesional". Parece un prompt razonable, pero es un contrato lo bastante ambiguo como para fallar de múltiples maneras: el modelo puede resumir en exceso y omitir una cifra clave, mantener un formato inconsistente con el resto del documento o interpretar "profesional" de un modo totalmente distinto al esperado. Ninguno de estos casos constituye un fallo del modelo en sí — es el prompt el que no definió qué cuenta como éxito.
Un prompt de producción no es una instrucción en lenguaje natural esperando buena voluntad. Es un contrato de ingeniería: criterios de éxito explícitos, formato esperado y las subtareas que componen el resultado final. Los escenarios de arquitectura evalúan precisamente esto — no si sabes redactar con buena prosa, sino si sabes transformar una solicitud ambigua en un contrato verificable.
Criterios de evaluación antes del prompt
El orden importa: define cómo vas a verificar si la salida es correcta antes de escribir la instrucción que la genera. Si no puedes formular el criterio con claridad, el prompt trasladará esa ambigüedad a la respuesta del modelo.
Los criterios de evaluación útiles son específicos y verificables: "el resumen preserva todos los valores numéricos citados en el documento original" es verificable. "El resumen es bueno" no lo es. Un criterio verificable se convierte, además, en un caso de prueba automatizable — permitiendo comprobar programáticamente si los datos coinciden, sin depender de juicios subjetivos recurrentes.
Descomponer en subtareas verificables
Una tarea ambigua rara vez es una sola tarea — suele ser un conjunto de tareas superpuestas sin límites definidos. "Analiza estos datos de ventas y dime qué hacer" oculta al menos tres subtareas: extraer las cifras relevantes, identificar patrones en esos números y recomendar una acción basada en el patrón detectado.
Descomponer estas subtareas aporta dos ventajas fundamentales:
- Verificación aislada: Cada subtarea es lo bastante acotada como para tener su propio criterio de éxito. "Las cifras extraídas coinciden con la fuente" es verificable de forma independiente, lo que facilita evaluar la recomendación final una vez confirmada la base de datos.
- Localización de la incertidumbre: La descomposición expone dónde reside realmente la incertidumbre cognitiva. La extracción es mecánica y determinista; la recomendación final implica un juicio que requiere criterios explícitos o revisión humana.
Los ejemplos fijan el estándar de juicio
Las instrucciones descriptivas ("sé conciso", "utiliza un tono formal") dejan la calibración del límite a criterio del modelo, el cual puede discrepar del tuyo. Incluir uno o dos ejemplos representativos del formato y del estándar de juicio esperado fija el comportamiento de forma mucho más confiable que los adjetivos.
La ventaja de los ejemplos es mayor donde el matiz cualitativo resulta difícil de describir — un ejemplo de "respuesta cortés pero firme, sin sonar pasivo-agresiva" comunica en dos líneas lo que requeriría párrafos de instrucciones y aún dejaría margen para la ambigüedad.
El distractor común
Un escenario típico ofrece la opción de "reescribir el prompt con instrucciones más claras" cuando el problema real radica en la falta de datos de contexto o en la ausencia de casos de prueba para validar el resultado. Pulir la redacción no soluciona la carencia de información fuente ni la falta de criterios de aceptación verificables. Antes de modificar el texto del prompt, diagnostica si la causa raíz es la claridad de la instrucción o un contrato mal especificado.
Ponlo en práctica
El laboratorio de esta lección implementa un validador de contratos de prompts: a partir de un conjunto de criterios de éxito y una salida candidata, verifica qué criterios se cumplen y alerta si la descomposición dejó requerimientos sin mecanismo de validación — el mismo marco analítico que aplicarás al convertir requerimientos ambiguos en contratos explícitos para tus prompts.