Prompt engineering profesional: saca lo mejor de los modelos

Cuando dos profesionales usan el mismo modelo de lenguaje para la misma tarea y uno obtiene resultados que le ahorran horas de trabajo mientras el otro los descarta como inútiles, la diferencia casi siempre está en cómo han formulado sus instrucciones. El prompt engineering es la disciplina de diseñar las instrucciones que se dan a los modelos de lenguaje para obtener los mejores resultados posibles. No es magia ni arte oscuro: es una habilidad técnica que se puede aprender, practicar y sistematizar.

Lo que hace al prompt engineering especialmente valioso en contextos empresariales es que sus beneficios se multiplican con el volumen. Un prompt mal diseñado que se ejecuta una vez cuesta poco. Ese mismo prompt ejecutado miles de veces en un proceso de producción puede generar miles de resultados incorrectos, costosos o que requieren revisión manual extensa. Invertir tiempo en diseñar prompts robustos es una de las mejores relaciones coste-beneficio en proyectos de IA aplicada.

Los fundamentos: qué determina la calidad de un prompt

Un prompt de calidad comunica al modelo cuatro cosas con claridad: qué tarea debe realizar, en qué contexto debe interpretarla, qué formato debe tener la salida y qué restricciones debe respetar. La mayoría de los prompts mediocres fallan porque omiten uno o varios de estos elementos, obligando al modelo a hacer asunciones que no siempre son las correctas. El modelo no puede leer la mente del usuario: solo puede trabajar con la información que tiene disponible en el prompt.

El segundo principio fundamental es la especificidad. Los prompts vagos generan respuestas vagas. Cuanto más concreto seas sobre lo que quieres, más probable es que obtengas exactamente lo que necesitas. Esto no significa escribir prompts larguísimos indiscriminadamente: significa incluir los detalles que realmente importan para la tarea y omitir el ruido que puede distraer al modelo.

Técnica 1: Definición de rol y persona

Una de las técnicas más efectivas y más mal usadas es la asignación de un rol al modelo. Decirle al modelo que actúe como un experto en un dominio concreto no solo cambia el tono de sus respuestas, sino que activa el conocimiento especializado que el modelo tiene sobre ese dominio y lo pone en primer plano. La diferencia entre pedir una revisión de contrato "como si fueras un abogado especializado en derecho mercantil español con experiencia en contratos de distribución" y simplemente pedir una revisión de contrato es significativa y consistente.

Sin embargo, la técnica se usa mal cuando el rol asignado es demasiado genérico (eres un experto en IA) o cuando es contradictorio con la tarea (eres un redactor creativo, ahora dame el análisis financiero de esta empresa). El rol debe ser específico, relevante para la tarea y coherente con el nivel de expertise que necesitas en la respuesta. Para tareas técnicas o de dominio especializado, definir el rol con detalle es especialmente importante.

Técnica 2: Few-shot prompting con ejemplos de calidad

Mostrar al modelo ejemplos del resultado que esperas es significativamente más efectivo que describirlo en abstracto. El few-shot prompting consiste en incluir en el prompt entre dos y cinco ejemplos de pares entrada-salida que ilustren exactamente el formato, el tono y el nivel de detalle que quieres. Este enfoque es especialmente poderoso para tareas de clasificación, extracción de información estructurada y generación de contenido con un formato muy específico.

La calidad de los ejemplos es tan importante como su cantidad. Un ejemplo mal seleccionado puede confundir al modelo más que ayudarlo. Los mejores ejemplos son representativos de los casos típicos que encontrará el sistema en producción, cubren la variabilidad que existe en los inputs reales, muestran con claridad el razonamiento esperado (no solo el resultado) y están ordenados de menor a mayor complejidad cuando los ejemplos tienen niveles de dificultad distintos.

Técnica 3: Chain of thought para tareas de razonamiento

Para tareas que requieren razonamiento complejo (análisis de situaciones ambiguas, resolución de problemas de varios pasos, evaluación de opciones con múltiples criterios), pedir al modelo que muestre su proceso de razonamiento antes de dar la respuesta final mejora consistentemente la calidad de la respuesta. Esta técnica se llama Chain of Thought (CoT) y funciona porque obliga al modelo a articular explícitamente los pasos intermedios, lo que reduce la probabilidad de saltar a conclusiones incorrectas.

La implementación más sencilla es añadir al prompt instrucciones como "piensa paso a paso antes de dar tu respuesta" o "analiza los pros y contras antes de hacer tu recomendación". Una variante más sofisticada es el Zero-Shot CoT, que usa la instrucción mágica "vamos a pensar paso a paso" sin necesidad de proporcionar ejemplos. Para casos de uso en producción donde la latencia importa pero la calidad también, se puede usar CoT en el desarrollo del prompt para entender qué proceso de razonamiento lleva al mejor resultado, y luego destilar ese razonamiento en un prompt más conciso.

Técnica 4: Prompts de sistema vs. prompts de usuario

La mayoría de los modelos modernos distinguen entre el prompt de sistema (system prompt) y los mensajes de usuario. El system prompt se ejecuta antes de la conversación y establece el contexto, el rol, las instrucciones permanentes y las restricciones que deben mantenerse en toda la conversación. Los mensajes de usuario contienen la tarea específica de cada turno. Esta distinción es importante porque el modelo da más peso a las instrucciones del system prompt y las trata como más estables y autoritativas.

En aplicaciones de producción, el system prompt debe contener todo lo que es constante en todas las invocaciones del modelo: el rol, el contexto de la empresa o producto, las restricciones de comportamiento (no salgas del tema, no proporciones información médica, responde siempre en español), el formato de salida esperado y los ejemplos de few-shot si los hay. El prompt de usuario debe contener solo la tarea específica de cada invocación. Esta separación hace que el sistema sea más fácil de mantener y actualizar.

Técnica 5: Control del formato de salida

Para sistemas de producción que procesan la salida del modelo programáticamente, la consistencia del formato es crítica. Un modelo que a veces devuelve JSON y a veces texto libre, o que a veces incluye texto introductorio antes del JSON y a veces no, rompe los parsers del sistema que procesa esa salida. Las técnicas para asegurar formatos consistentes incluyen especificar el formato exacto en las instrucciones, proporcionar una plantilla vacía que el modelo debe rellenar, usar few-shot examples que muestren el formato exacto y pedir al modelo que responda directamente con el JSON sin texto previo.

La mayoría de los modelos actuales soportan structured outputs o JSON mode, que fuerzan al modelo a responder con JSON válido que sigue un esquema definido. Esta capacidad, disponible en GPT-4o con JSON schema, en Claude con sus herramientas de uso de tools y en Gemini con response_schema, es extremadamente valiosa para aplicaciones de producción porque elimina la necesidad de parsear y validar salidas de texto libre.

• Especifica el formato exacto: JSON, Markdown, lista numerada, tabla, etc. No dejes que el modelo elija.
• Usa structured outputs cuando el proveedor lo soporte: fuerza el esquema y elimina errores de parsing.
• Incluye ejemplos del formato esperado en el few-shot: mejor que cualquier descripción textual.
• Indica explícitamente si no quieres texto introductorio: "responde directamente con el JSON, sin texto previo ni posterior".
• Para longitud, sé específico: "en 3-5 párrafos de 4-6 frases cada uno" funciona mejor que "de forma concisa".
• Prueba el formato con casos extremos: qué pasa cuando el input está vacío, es ambiguo o está en otro idioma.

Técnica 6: Prompts autoverificados y reflexión

Una técnica avanzada pero muy efectiva es pedir al modelo que verifique su propia respuesta antes de entregarla. El patrón consiste en dos fases: primero el modelo genera su respuesta, luego se le pide que la revise críticamente según unos criterios específicos (¿está basada en hechos verificables?, ¿responde exactamente la pregunta planteada?, ¿hay alguna asunción no justificada?) y genere una versión mejorada si encuentra problemas.

Este patrón es especialmente útil para tareas de alta stakes donde un error tiene consecuencias significativas: análisis legal, revisión de código crítico, evaluación de riesgos. La desventaja es el coste adicional (más tokens, más latencia), por lo que debe reservarse para los casos donde el beneficio justifica ese coste. Una variante más eficiente en términos de coste es usar un segundo modelo más barato para la verificación del resultado del primer modelo.

Gestión de alucinaciones y respuestas no fundamentadas

Las alucinaciones, respuestas del modelo que son fluidas y convincentes pero factualmente incorrectas, son uno de los riesgos más importantes en aplicaciones de producción. El prompt engineering puede reducir significativamente su frecuencia aunque no eliminarla completamente. Las técnicas más efectivas son: pedir al modelo que indique su nivel de confianza en cada afirmación, instruirle explícitamente para que diga cuando no sabe algo en lugar de inventar, proporcionar las fuentes de información que debe usar (RAG) en lugar de depender de su conocimiento interno, y pedir citas o referencias para afirmaciones factuales.

Una instrucción que funciona bien en muchos contextos es: "si no estás seguro de un dato, indícalo explícitamente con frases como 'no tengo información verificada sobre esto' o 'esto debería verificarse con la fuente original'. Es preferible admitir incertidumbre que proporcionar información incorrecta". Esta instrucción calibra el comportamiento del modelo hacia la honestidad epistémica, lo que es especialmente valioso en contextos donde los usuarios podrían actuar directamente sobre la información proporcionada.

Diseño de prompts para diferentes modelos

Aunque muchas técnicas de prompt engineering son agnósticas al modelo, cada modelo tiene características propias que afectan al diseño óptimo del prompt. Claude (Anthropic) responde especialmente bien a instrucciones detalladas sobre el razonamiento esperado y tiende a ser más literal en seguir las instrucciones del system prompt. GPT-4o (OpenAI) tiene buenas capacidades de razonamiento con CoT y maneja bien los formatos JSON estructurados. Gemini 1.5 Pro destaca en tareas que requieren procesar contextos muy largos gracias a su ventana de contexto de un millón de tokens.

Los modelos open source como Llama 3.1 o Mistral Large requieren prompts más explícitos y estructurados para obtener resultados comparables a los modelos propietarios: son más sensibles a variaciones en el formato del prompt y menos tolerantes con instrucciones ambiguas. Si trabajas con modelos open source en producción, invertir más tiempo en el diseño y la evaluación del prompt es especialmente importante.

Versionado y gestión de prompts en producción

Los prompts de producción son activos de software que necesitan ser gestionados como tal: versionados, testados, desplegados y monitorizados. Un cambio en un prompt puede mejorar los resultados en algunos casos y degradarlos en otros. Sin un sistema de gestión, es imposible rastrear qué versión del prompt está en producción, revertir a una versión anterior si hay una regresión o comparar el rendimiento de diferentes variantes.

Herramientas como LangSmith, Langfuse o PromptLayer facilitan el versionado y la evaluación de prompts en producción. Para equipos que empiezan, incluso algo tan simple como guardar los prompts en un repositorio Git con convenciones de nomenclatura claras es infinitamente mejor que tener los prompts hardcodeados en el código de la aplicación sin ningún tipo de gestión. La disciplina de tratar los prompts como código es una de las prácticas que más diferencia a los equipos que operan sistemas de IA robustos.

Un prompt no es simplemente una pregunta: es una especificación de contrato con el modelo. Como cualquier especificación de software, su calidad determina directamente la calidad del resultado. Los equipos que tratan el diseño de prompts con la misma disciplina que el diseño de código obtienen resultados consistentemente superiores.

Evaluación sistemática: cómo medir si tu prompt es bueno

Sin métricas objetivas, la mejora de prompts es una actividad de ensayo y error sin dirección clara. Construir un conjunto de evaluación con al menos 30-50 casos de prueba representativos es el primer paso. Para cada caso, define qué constituye una buena respuesta: puede ser una respuesta de referencia exacta (para tareas con respuesta correcta única), una rúbrica de criterios (para tareas de generación) o métricas automáticas como la coincidencia de formato JSON, la inclusión de ciertos campos obligatorios o la ausencia de contenido prohibido.

Con este conjunto de evaluación, puedes comparar sistemáticamente diferentes variantes del prompt, medir el impacto de cada cambio y detectar regresiones antes de desplegar en producción. Este ciclo de evaluación-mejora-evaluación es lo que distingue el desarrollo profesional de prompts de la improvisación. Invertir una semana en construir un sistema de evaluación sólido devuelve ese tiempo muchas veces a lo largo de la vida del proyecto.