Prompt engineering para producción: qué funciona y qué es mito

Cuando desplegamos por primera vez un LLM en un entorno de producción para un cliente industrial, tardamos tres semanas en entender por qué el modelo respondía a veces en inglés en lugar de castellano, por qué ignoraba el formato y por qué en uno de cada diez casos inventaba un número de la nada. Los tres problemas tenían la misma solución: un enfoque sistemático a los prompts — no intuición, no ensayo y error, sino una estructura contrastada.

El prompt engineering es hoy una de las disciplinas más mencionadas, pero también de las menos comprendidas en los proyectos de IA. Cuando preguntamos a directores técnicos qué esperan de él, la mayoría responde «mejores respuestas». Es cierto — pero solo hasta cierto punto. Este artículo desglosa qué puede hacer realmente el prompt engineering, cuáles son sus límites y qué pertenece a otro conjunto de herramientas.

Qué es realmente el prompt engineering

El prompt engineering es el diseño sistemático y el versionado de las entradas para un modelo de lenguaje con el objetivo de obtener salidas consistentes, predecibles y medibles. La palabra clave es consistentes — no «a veces excepcional».

En un sistema de producción no basta con que el prompt funcione en el 80 % de los casos. Si lo despliega en atención al cliente, ese 20 % de fallos es lo que los clientes recordarán. Si lo despliega en el procesamiento de facturas, un 20 % de errores es una catástrofe. El prompt engineering es, por tanto, menos creatividad y más disciplina de ingeniería: documentar, versionar, probar, medir.

Qué funciona — patrones probados

1. Instrucción clara con formato de salida explícito

El factor individual con mayor impacto en la calidad de la salida es la precisión con la que el modelo sabe qué debe producir. Una instrucción vaga como «resume este documento» genera resultados vagos. Una instrucción específica funciona dramáticamente mejor:

• Indique al modelo quién es el público objetivo de la salida
• Defina el formato exacto: número de puntos, longitud máxima, si la salida debe incluir conclusión o no
• Con datos estructurados, utilice siempre structured outputs y JSON mode — un modelo vinculado a un esquema alucina significativamente menos que uno con salida de texto libre

Hemos comprobado con clientes que solo el cambio de «extrae los datos de la factura» a «devuelve un objeto JSON con los campos: proveedor (string), NIF (string 8 caracteres), importe (número), fecha (ISO 8601)» redujo la tasa de error de extracción en decenas de puntos porcentuales.

2. Ejemplos few-shot — cuándo y cómo usarlos

El few-shot prompting (varios ejemplos entrada-salida directamente en el prompt) es una de las herramientas más fiables, pero solo cuando los ejemplos son representativos. Las reglas:

1. 1.Los ejemplos deben cubrir edge cases, no solo el happy path
2. 2.El formato de los ejemplos debe ser consistente — si una vez utiliza «Entrada:» y otra «Input:», el modelo lo detectará
3. 3.El número de ejemplos depende de la complejidad de la tarea — para una clasificación sencilla bastan 2–3, para razonamiento de varios pasos, 5–7
4. 4.Seleccione los ejemplos de datos reales, no inventados — los ejemplos sintéticos suelen tener propiedades estadísticas distintas a las de las entradas de producción

El few-shot es especialmente potente para el formato y para tareas con una estructura de referencia clara. Es menos eficaz cuando al modelo le falta contexto de dominio — en ese caso la respuesta es RAG o fine-tuning.

3. Rol y persona

Asignar un rol explícito funciona — no porque el modelo «crea» que es otro, sino porque el rol desplaza la distribución de probabilidad de las salidas hacia patrones más relevantes. «Eres un abogado sénior especializado en derecho laboral español» activa patrones lingüísticos distintos a «Eres un asistente».

Importante: el rol define el tono y el vocabulario, pero no sustituye al conocimiento. Un modelo con el rol «experto en directivas ATEX» puede seguir alucinando si no cuenta con suficientes datos de entrenamiento sobre las directivas ATEX. El rol es un filtro lingüístico, no una base de conocimiento.

4. Encadenamiento de pasos (Chain-of-Thought)

En tareas analíticas complejas — comparación, cálculo de varios pasos, toma de decisiones basada en condiciones — la instrucción explícita «razona paso a paso» o la división en varios subprompts mejora significativamente la fiabilidad. Los modelos cometen menos errores cuando pueden «pensar en voz alta» antes de la respuesta final.

En la práctica esto significa: no pida al modelo la conclusión directamente. Déjele primero descomponer el problema, identificar los factores relevantes y solo entonces formular la conclusión. El resultado es más fiable y, además, más fácil de verificar — puede ver cómo el modelo llegó a la conclusión.

5. Instrucciones negativas — qué no hacer

La mayoría de los prompts le indican al modelo qué hacer. Igual de importante es decirle qué no debe hacer. «Nunca comiences la respuesta con la frase "¡Por supuesto!"», «No uses anglicismos donde exista un equivalente en castellano», «Si no puedes responder a partir del contexto proporcionado, dilo explícitamente — no lo inventes». Las instrucciones negativas reducen la aparición de errores repetitivos concretos.

Qué no funciona — mitos

Mito 1: «Por favor» y recompensas mejoran los resultados

Respuesta corta: no. Frases como «recibirás 100 dólares por cada respuesta correcta» o el cortés «por favor, ayúdame con...» no tienen efecto medible sobre la calidad de la salida en producción. El modelo no responde a la manipulación social ni a las emociones — responde a los patrones estadísticos de los datos de entrenamiento. El tiempo invertido en «motivar» al modelo es tiempo perdido.

Mito 2: Un prompt más largo = mejor resultado

La longitud y la calidad son dos cosas distintas. Hemos visto prompts de sistema con miles de tokens que funcionaban peor que otros de cinco líneas. El problema es que los modelos tienden a «perder» instrucciones situadas en el centro de un contexto muy largo — efecto conocido como «lost in the middle». La estructura y la claridad son más importantes que el volumen. Si su prompt crece, es más bien síntoma de que está intentando resolver con el prompt un problema que pertenece al diseño del sistema.

Mito 3: Un buen prompt sustituye a la evaluación

Este es probablemente el mito más peligroso. Un prompt sin evaluación es una hipótesis, no una solución. En la práctica vemos equipos que pasan una semana ajustando el prompt, lo despliegan en producción y al mes descubren que el 15 % de las salidas son incorrectas — porque nunca midieron sistemáticamente.

La evaluación — valoración automatizada de las salidas sobre un conjunto de prueba — es un requisito previo del despliegue en producción, no un complemento opcional. Más información en cómo medir la calidad de una aplicación LLM.

Mito 4: El prompt engineering es una solución permanente

El prompt es un artefacto frágil. Cuando el proveedor lanza una nueva versión del modelo, su prompt puede comportarse de forma diferente — aunque usted no lo haya modificado. Hemos visto casos en que una actualización del modelo mejoró la calidad general pero rompió instrucciones de formato concretas que estaban «pegadas» al comportamiento de la versión anterior.

El prompt engineering es un trabajo iterativo, no puntual. Si no lo asume antes del despliegue, lo asumirá después.

Mito 5: El system prompt es un contenedor seguro para información sensible

El system prompt es una instrucción para el modelo, no una caja fuerte. La extracción de prompts (prompt extraction) es un ataque bien documentado — existen técnicas con las que un atacante puede extraer el contenido del system prompt a través de la interfaz de usuario normal. En el system prompt nunca deben figurar contraseñas, claves de API, tarifas internas, datos personales de empleados ni ninguna información cuya filtración suponga un problema. El system prompt es para instrucciones de comportamiento, no para secretos.

El prompt como código — versionado y gestión

En los equipos con los que trabajamos aparece repetidamente el mismo problema: el prompt está guardado en el código como una cadena hardcoded, nadie sabe quién lo cambió por última vez ni por qué, y cuando algo falla no hay historial al que volver.

El prompt es código. Se le aplican los mismos principios:

• Versionado en git — cada cambio del prompt es un commit con un commit message significativo
• Semantic versioning — versión mayor al cambiar un comportamiento de salida; menor al añadir; patch al corregir ortografía
• Conjunto de pruebas — para cada versión del prompt existe un conjunto de casos de prueba con salidas esperadas; un cambio de prompt se aprueba solo si los tests pasan en verde
• Registro de prompts — un lugar centralizado (puede ser un YAML sencillo en el repositorio, o una herramienta como Langfuse) donde se ve qué prompt está desplegado dónde, en qué versión y quién es el responsable

Herramientas como Promptfoo permiten probar automáticamente los prompts en la pipeline de CI/CD — cada pull request con una modificación de prompt lanza automáticamente el conjunto de pruebas antes del merge. Esta es la práctica que recomendamos a cualquier equipo que tenga más de un prompt activo en producción.

Cuándo el prompt no basta — y qué usar en su lugar

El prompt engineering es una herramienta potente en una franja estrecha de problemas. Es débil cuando:

Falta conocimiento — el modelo no sabe lo que necesita saber porque no está en los datos de entrenamiento. El prompt no puede añadir conocimiento. Solución: RAG (retrieval-augmented generation) para soporte factual, o fine-tuning para una adaptación profunda al dominio.

Falta un formato consistente — la salida debe regirse siempre por un esquema exacto. El prompt puede ayudar, pero la solución más fiable son los structured outputs (JSON schema vinculado al modelo). Más información en el artículo sobre structured outputs y JSON mode.

Falta seguridad — si el sistema procesa entradas no confiables (por ejemplo, mensajes de clientes, documentos externos), el prompt injection es un riesgo real. El prompt por sí solo no puede evitar su propia sobreescritura. Se necesitan guardrails arquitectónicos: validación de entradas, allowlists de acciones, sandboxing. Más detalle en el artículo sobre prompt injection y jailbreaks.

Falta medición — si no sabe si el prompt funciona, el prompt engineering es solo intuición. Sin evaluación no confíe ni en el mejor de los prompts.

Versionado práctico de prompts — cómo empezar

Para equipos que aún no tienen una gestión sistemática de prompts, recomendamos un procedimiento sencillo:

1. 1.Cree un directorio prompts/ en el repositorio con un archivo YAML por prompt
2. 2.Cada YAML contiene: name, version, description, system_prompt, user_prompt_template, model, temperature, test_cases
3. 3.Los cambios mediante pull request — revisión del prompt igual que revisión de código
4. 4.Antes de desplegar una nueva versión: ejecute el conjunto de pruebas en la versión actual y en la nueva, compare las métricas
5. 5.Tras el despliegue: monitorice los resultados en producción; las anomalías (aumento repentino de la tasa de error, cambio en la longitud de las salidas) son síntoma de regresión

Esto no es exagerado — es el mínimo. Los equipos que no lo hacen descubren los problemas en producción en lugar de en las pruebas.

Prompt engineering y modelos — qué cambia con el modelo

Algo importante que vemos ignorado con frecuencia: distintos modelos responden de forma diferente al mismo prompt. Un prompt optimizado para un modelo puede funcionar considerablemente peor en otro. Algunos patrones concretos:

• Seguimiento de instrucciones: los modelos frontier más recientes (clase Claude, GPT-4) son significativamente mejores siguiendo instrucciones explícitas que los modelos más antiguos o más pequeños
• Sensibilidad al few-shot: algunos modelos responden con fuerza a los ejemplos few-shot, otros menos — depende del tamaño y del procedimiento de entrenamiento
• Calidad lingüística: el castellano es un idioma de alta disponibilidad en datos de entrenamiento, pero los modelos open-weight pequeños pueden degradar en lenguas menos representadas — pruebe siempre en el idioma objetivo
• Temperature: en tareas deterministas (extracción, clasificación) establezca temperature=0 o muy bajo — las salidas serán más consistentes; en tareas generativas (escritura), algo más alto

Cuando cambie de modelo, ejecute siempre el conjunto de pruebas existente. No espere que el prompt «funcione igual».

Preguntas frecuentes

¿Merece la pena invertir tiempo en prompt engineering o es mejor ir directamente al fine-tuning?

El prompt engineering es el primer paso, el fine-tuning es el siguiente — no una alternativa. Si tiene un prompt bien diseñado y aún no está satisfecho con los resultados a pesar de los ejemplos few-shot y la estructura, examine si el problema no radica en conocimiento de dominio ausente (solución: RAG) o en la consistencia del estilo de salida (solución: fine-tuning). El fine-tuning sin un prompt bien diseñado y sin evaluación es tiempo y dinero desperdiciados.

¿Puedo usar prompt engineering para garantizar que el modelo nunca responda sobre ciertos temas?

No de forma fiable. Las defensas basadas únicamente en el prompt (instrucción «nunca respondas sobre X») son eludibles — esa es la conclusión principal de la investigación sobre prompt injection y jailbreaking. Para sistemas de producción son imprescindibles medidas arquitectónicas: filtrado de entradas antes de pasarlas al modelo, validación de salidas antes de mostrarlas, monitorización. La instrucción en el prompt es la primera capa, no la única.

¿Cómo sé que mi prompt es bueno?

Solo mediante medición. Defina un conjunto de pruebas (mínimo 20–50 casos para una tarea sencilla, más para las complejas) con salidas esperadas o criterios de evaluación. Ejecute el prompt sobre el conjunto de pruebas y mida la métrica relevante (precisión, formato, corrección lingüística, corrección factual). Sin número, «un buen prompt» es solo una sensación.

¿Cuántos tokens debería tener el system prompt?

No existe una respuesta universal, pero en la práctica los system prompts eficaces suelen situarse en el rango de 200–800 tokens. Los más cortos son insuficientemente específicos; los más largos empiezan a sufrir el efecto «lost in the middle» — el modelo pierde el rastro de las instrucciones ubicadas en el centro. Si su prompt supera los mil tokens sin un motivo claro, es momento de refactorizarlo o de pensar si alguna información no debería estar en el contexto RAG en lugar del system prompt.

¿Aplica lo mismo a los modelos open-weight desplegados localmente?

La mayoría de los principios aplica, pero con una advertencia importante: los modelos open-weight más pequeños (7B–13B parámetros) son menos robustos siguiendo instrucciones que los modelos frontier. Los ejemplos few-shot son más importantes, el formato del prompt debe ser más preciso y el conjunto de pruebas debe adaptarse a la familia de modelos concreta. Un prompt diseñado para modelos frontier puede no funcionar igual en Mistral 7B o modelos open-weight de tamaño similar — ni siquiera tras una optimización cuidadosa. El idioma además representa un desafío adicional para los modelos más pequeños — pruebe siempre en el idioma de producción.

*El prompt engineering es un oficio, no magia — y como todo oficio se puede aprender, sistematizar y medir. Si está abordando el despliegue de un LLM en producción y no sabe por dónde empezar, estaremos encantados de evaluar su caso concreto y ayudarle a establecer las bases sobre las que construir.*