Ingeniería de prompts para producción: más allá de la demostración

Hay una distancia entre un prompt que impresiona en una demostración y otro que funciona con miles de entradas reales. Muchos equipos pasan a producción sin reconocer que ahora están resolviendo un problema distinto.

En una demostración buscas que funcione con tus ejemplos.

En producción necesitas que funcione con entradas que todavía no conoces, incluidas las extrañas.

Esto es lo que cambia.

El problema de la distribución de entradas

Las entradas de una demostración están seleccionadas. Son las que se te ocurrieron, con el formato y la longitud que a ti te parecían naturales.

Las entradas reales pueden:

• Ser más cortas o más largas de lo esperado.
• Tener ambigüedades que no anticipaste.
• Mezclar idiomas.
• Contener erratas, contexto incompleto o referencias implícitas.
• Pedir algo fuera del alcance previsto.

Un prompt de producción necesita respuestas definidas y previsibles para esos casos, aunque no los resuelva todos. Los fallos silenciosos y las salidas confusas no deberían ser el comportamiento predeterminado.

Empieza a construir un conjunto de pruebas con entradas reales cuanto antes. Incluso treinta a cincuenta ejemplos pueden revelar problemas de distribución que las pruebas sintéticas no muestran.

Diseñar primero las restricciones

Los consejos habituales sobre prompts son correctos: sé claro, concreto y aporta ejemplos. Las restricciones añaden otra capa necesaria en producción.

Definen los límites del comportamiento:

You are a customer support assistant for Acme Inc.

CONSTRAINTS:
- Do not discuss competitor products
- Do not make pricing commitments not listed in the product catalog
- Do not provide legal or medical advice; redirect to appropriate resources
- If asked about topics outside your scope, say: "I can help with [X]. For [other topic], you'll want to contact [resource]."

Las instrucciones describen el caso esperado. Las restricciones ayudan cuando la entrada se sale de él. En producción ocurre con frecuencia.

Un ejercicio útil: escribe cinco cosas que el modelo nunca debería hacer y define una restricción explícita para cada una.

El formato ayuda a controlar los fallos

Un formato inconsistente provoca:

• Errores impredecibles al interpretar la salida.
• Lógica condicional adicional en la interfaz.
• Experiencias distintas entre peticiones.

Dos patrones para concretarlo:

1. Modo JSON con esquema explícito

Respond with valid JSON matching this schema:
{
  "intent": "<string: one of [search, navigate, create, edit, delete]>",
  "target": "<string: the object the user wants to act on>",
  "parameters": "<object: key-value pairs extracted from the request>",
  "confidence": "<string: one of [high, medium, low]>"
}

2. Plantilla de salida

Structure your response exactly as follows:

SUMMARY: [one sentence, max 20 words]
DETAIL: [2-3 sentences]
NEXT_STEP: [one actionable sentence or "None"]

La segunda sirve para respuestas destinadas a personas cuando no necesitas JSON. Ambos enfoques dan una estructura más clara que el texto completamente libre; sigue siendo necesario validarla.

Divide la tarea cuando aumente la complejidad

Un prompt que hace cinco cosas puede ser irregular en cada una. El modelo intenta equilibrar varios objetivos y puede priorizarlos de forma distinta según la entrada.

Divide un prompt complejo en una cadena de pasos sencillos, cada uno con una tarea clara.

Un solo prompt complejo:

Extract the user's intent, classify it, format the response according to their detected expertise level, and add a follow-up question if the query seems unresolved.

Cuatro prompts sencillos encadenados:

Step 1: Extract intent → structured output
Step 2: Classify expertise level → enum output
Step 3: Format response for that expertise level → formatted text
Step 4: Assess resolution → bool, generate follow-up if needed

Puedes probar cada paso por separado y localizar los fallos. El coste es la latencia de cuatro llamadas en vez de una. Evalúa si la mejora de fiabilidad lo compensa en tu caso.

Qué aportan los ejemplos few-shot

Los ejemplos few-shot muestran la distribución esperada de entradas y salidas: en qué espacio trabaja el modelo, qué consultas importan y qué respuestas esperas.

Errores habituales:

• Ejemplos demasiado parecidos: no cubren otras formas de entrada.
• Ausencia de casos difíciles: solo muestran el recorrido ideal.
• Estilo de salida desalineado: las respuestas de ejemplo no se parecen a lo que quieres obtener.

Un conjunto útil puede incluir:

• Dos o tres ejemplos del caso principal.
• Uno o dos casos difíciles conocidos.
• Un ejemplo que muestre cómo responder fuera del alcance permitido.

Mi punto de partida es mantenerlo en cinco o seis ejemplos y medir antes de añadir más. Un conjunto repetitivo puede fomentar respuestas demasiado ligadas a esos ejemplos.

Iterar mediante evaluaciones

Para saber si un cambio mejora el prompt necesitas medirlo:

1. Un conjunto representativo de pruebas, extraído de registros reales cuando sea posible.
2. Criterios de aceptación para cada caso.
3. Evaluación automatizada mediante reglas, un modelo evaluador o ambos.
4. Versiones que permitan comparar el antes y el después.

Sin eso, «me parece mejor» sigue siendo una conjetura.

Un flujo mínimo:

• Cincuenta casos repartidos entre uso principal, situaciones difíciles y fallos.
• Una salida esperada o criterio de aceptación por caso.
• Evaluaciones antes y después de cada cambio.
• Revisión de cualquier caída, incluso en métricas que no pretendías modificar, antes de desplegar.

Control de versiones de prompts

Los requisitos nuevos, los casos descubiertos y las actualizaciones del modelo obligan a cambiar prompts. Sin control de versiones pierdes:

• La posibilidad de deshacer una regresión.
• El motivo de cada cambio.
• Los resultados que validaron una versión.

Trátalos como parte del código:

• Guárdalos junto al código en control de versiones.
• Explica en cada commit qué cambió y por qué.
• Asocia las versiones con las evaluaciones que las aprobaron.
• Define cómo volver atrás durante un incidente.

Trabajar con prompts en producción exige controlar la variación de las entradas reales. Empieza por las pruebas, concreta las restricciones y el formato, divide las tareas complejas y mide el resultado.

La lista de comprobación de fiabilidad de IA en producción reúne más puntos sobre diseño de prompts, evaluaciones y fiabilidad.