Prompt engineering

Definición

El prompt engineering —ingeniería de prompts— es la disciplina práctica de diseñar las instrucciones que se envían a un LLM para que produzca respuestas con la calidad, formato y comportamiento deseados. Combina técnica, intuición lingüística y muchísima iteración empírica.

Aunque el nombre suena impresionante, en esencia es saber pedirle bien las cosas a un LLM. Pero un buen prompt vs uno mediocre pueden tener un impacto de 2-10× en calidad del output, sin cambiar nada más del sistema. Es la habilidad práctica de IA con mejor ROI para la mayoría de personas.

Es discutible si "ingeniería" es la palabra correcta — algunos lo ven más como un arte. Pero en producción seria, el prompt es código: se versiona, se prueba, se mide, se itera. Tan código como cualquier otra parte del stack.

Componentes de un buen prompt

Un prompt sólido en producción típicamente tiene varios bloques bien diferenciados:

1. Rol y contexto del sistema (system prompt):

   • Quién es el modelo (rol).
   • Qué hace (capabilities).
   • Qué no debe hacer (constraints).
   • Tono y estilo esperado.

2. Instrucciones específicas de la tarea:

   • Qué se debe producir.
   • Formato exacto (JSON, markdown, prosa, etc.).
   • Restricciones (longitud, idioma).

3. Ejemplos (few-shot):

   • 2-5 pares (input → output ideal).
   • Cubrir casos típicos y edge cases.

4. Contexto/datos:

   • Información del usuario.
   • Resultados de RAG.
   • Datos relevantes para el caso.

5. Input del usuario:

   • La consulta actual claramente delimitada.

6. Pista del formato esperado al final:

   • "Responde en JSON con las claves...".
   • "Comienza directamente con el resumen, sin introducción".

Técnicas con más impacto en calidad

Ordenadas por impacto típico:

1. Ser específico y concreto: vago = vago. "Resume" da peor resultado que "Resume en 3 bullets de máximo 15 palabras cada uno enfocados en acciones concretas para mejorar el negocio".

2. Dar ejemplos (few-shot): 2-5 ejemplos del input/output esperado mejoran la consistencia drásticamente. Es la técnica con mejor ROI.

3. Definir el rol explícito: "Eres un experto en finanzas industriales con 20 años de experiencia. Tu trabajo es..." moldea el estilo.

4. Pedir razonamiento explícito (Chain of Thought): "Piensa paso a paso" antes de la respuesta.

5. Formato estructurado: JSON schema, XML tags, markdown explícito. Reduce ambigüedad y errores de parseo.

6. Restricciones positivas + negativas: "Haz X, Y, Z. No hagas A, B, C". Las restricciones negativas son particularmente útiles para evitar fallos típicos.

7. Anclar con tags XML (especialmente útil en Claude): <contexto>...</contexto>, <input>...</input>. Ayuda al modelo a estructurar mentalmente las partes.

8. Reservar el final para énfasis: lo último del prompt tiende a influir más. Coloca las instrucciones más críticas al final.

9. Pedir "si no estás seguro, di no lo sé": reduce algo de alucinaciones.

10. Iterar con eval real: prueba 3-5 versiones del prompt sobre 20+ casos representativos y mide.

Ejemplo práctico

Imagina un asistente de IMDICA que clasifica emails entrantes.

Prompt malo:

Clasifica este email.
{email}

Output: a veces texto largo, a veces JSON malo, sin consistencia.

Prompt bueno:

Eres un asistente que clasifica emails entrantes de IMDICA, distribuidor industrial.

Categorías posibles:
- PRESUPUESTO: petición de cotización
- PEDIDO: orden de compra firme
- INCIDENCIA: problema con pedido recibido
- INFO: pregunta sobre producto sin intención de compra inmediata
- ADMIN: facturación, contabilidad, otros administrativos

Devuelve siempre JSON con esta estructura exacta:
{
  "categoria": "<una de las 5 anteriores>",
  "urgencia": "alta|media|baja",
  "cliente_potencial": true|false,
  "resumen": "<máximo 1 frase>"
}

Ejemplos:

Email: "Hola, ¿me podéis mandar precio de 50 destornilladores Makita 18V?"
Output: {"categoria": "PRESUPUESTO", "urgencia": "media", "cliente_potencial": true, "resumen": "Solicita precio de 50 destornilladores Makita 18V"}

Email: "El pedido llegó incompleto, faltan 3 cajas de tornillería."
Output: {"categoria": "INCIDENCIA", "urgencia": "alta", "cliente_potencial": false, "resumen": "Pedido recibido incompleto, faltan 3 cajas"}

Ahora clasifica este email:
{email}

Output:

Output: consistente, parseable, accionable.

La diferencia es brutal en calidad y consistencia, sin cambiar modelo ni infraestructura.

Patrones de prompting modernos

Más allá de lo básico, técnicas específicas:

• Persona forte: "Eres uno de los mejores ingenieros del mundo en X. Tienes un estándar de excelencia muy alto..." → respuestas más rigurosas.
• Anti-sycophancy: "Sé directo. No empieces con frases tipo '¡Excelente pregunta!'. Si algo está mal en mi planteamiento, dilo claro."
• Verificación interna: "Antes de responder, revisa tu respuesta por errores aritméticos y de lógica. Solo si está correcta, pásamela."
• Two-pass: pedir una primera respuesta + autocrítica + versión final mejorada.
• Output constraints: "Responde en máximo 80 palabras. No uses listas. No uses emoji."
• Self-consistency: para tareas críticas, ejecutar el mismo prompt 3-5 veces y elegir la respuesta más común.
• Plantillas con variables: prompts parametrizados que cambian según contexto/usuario.

Prompt engineering en producción

Hace 2 años "prompt engineering" se hacía en chat web. Hoy en sistemas serios:

• Prompts versionados: en código, con git, en archivos .md o .yaml.
• Prompt templates: con motor tipo Jinja para inyectar variables seguras.
• Eval framework: dataset de tests, métricas, comparación de versiones (Braintrust, Langsmith, internos custom).
• A/B testing: comparar versiones de prompts en tráfico real.
• Observabilidad: ver qué prompts producen qué outputs y cuáles fallan.
• Prompt review en PR: cambiar un prompt es como cambiar código.

Errores comunes en prompt engineering

• Asumir que más palabras = mejor: prompts de 2.000 palabras llenos de redundancia funcionan peor que 500 bien escogidas.
• No dar ejemplos: el coste/beneficio de añadir 2-3 ejemplos casi siempre compensa.
• Mezclar instrucciones y contexto sin estructura: dificulta al modelo distinguir qué es directiva y qué es dato.
• No iterar con datos reales: los prompts que funcionan en 2 ejemplos pueden fallar en el 30% del tráfico real.
• Subestimar el coste de tokens: prompts grandes inflan factura. Comprimir es optimización legítima.
• Cambiar prompts en producción sin medir: rompes lo que funcionaba sin saberlo.
• Esperar prompt perfecto al primer intento: 5-10 iteraciones es lo normal para un prompt de producción.
• Confundir prompt engineering con magia: hay límites duros — un prompt no puede hacer que un modelo pequeño razone como uno grande.

Cuándo importa el prompt engineering

Sí, inviértele tiempo cuando:

• Construyes producto basado en LLM.
• El comportamiento del modelo es crítico para la UX.
• Necesitas consistencia y formato fiable.
• Quieres optimizar coste o calidad sin migrar de modelo.

Es menos central cuando:

• Estás explorando casualmente las capacidades del modelo.
• Tu uso es 1-a-1 con verificación manual constante.
• Vas a hacer fine-tuning que sustituirá parte del prompting.

Referencias

• OpenAI · Prompt engineering guide — referencia oficial con muchas técnicas
• Anthropic · Prompt engineering for Claude — guía oficial de Anthropic, especialmente útil para Claude
• Lilian Weng · Prompt Engineering blog post — artículo de referencia académica con técnicas avanzadas