Prompt engineering desde cero: técnicas para mejores instrucciones

Es el conjunto de técnicas para escribir las instrucciones, llamadas prompts, que se le dan a un modelo de lenguaje, con el objetivo de obtener resultados mejores y más confiables. Su fundamento es que un mismo modelo, con el mismo conocimiento, puede dar una respuesta inservible o una excelente según cómo se lo instruya, de modo que aprender a formular bien las instrucciones tiene un impacto enorme sobre la calidad de lo que se obtiene. El prompt engineering convierte esa diferencia en algo sistemático y reproducible, en lugar de dejarla librada a la suerte. Sus técnicas principales incluyen dar contexto y un rol claros, mostrar ejemplos del resultado deseado, pedir razonamiento paso a paso en tareas que lo requieren, forzar un formato de salida cuando otra parte del sistema va a procesar la respuesta, y descomponer las tareas complejas. Por encima de todas está la práctica de iterar midiendo el resultado contra casos reales, que es lo que distingue el trabajo serio del ensayo y error.

La guía sobre cómo escribir buenos prompts está orientada al uso cotidiano de los asistentes de inteligencia artificial: cómo pedirle a una herramienta como ChatGPT o Gemini que resuma un texto, redacte un correo o responda una consulta de la mejor manera posible. Es la introducción práctica para quien usa estas herramientas en su día a día. Esta guía, en cambio, sistematiza las técnicas de prompt engineering pensando en quien construye aplicaciones sobre modelos de lenguaje, donde el prompt deja de ser un mensaje suelto y pasa a ser parte del código: se versiona, se prueba, se optimiza y se mide. Aquí el foco está en entender por qué funciona cada técnica —contexto y rol, ejemplos, razonamiento paso a paso, formato de salida, descomposición— y en cómo iterar de forma medible. La recomendación es empezar por la guía de uso cotidiano para lo general, y usar esta cuando se necesite integrar un modelo en un producto o automatización de forma profesional.

Son dos de las técnicas más potentes del prompt engineering, y ambas se apoyan en que estos modelos aprenden de patrones. Few-shot, que significa con pocos ejemplos, consiste en no limitarse a describir lo que uno quiere, sino en mostrar dentro del prompt uno o varios ejemplos de entrada junto con su salida deseada, para que el modelo imite ese patrón; suele funcionar mejor que cualquier explicación, especialmente cuando importa el formato o el estilo, que son difíciles de poner en palabras. Cuando no se dan ejemplos, se habla de zero-shot. Chain-of-thought, o cadena de pensamiento, consiste en pedirle al modelo que razone paso a paso antes de dar la respuesta final; esto mejora notablemente la precisión en tareas que requieren pensar, como problemas de lógica, matemática o decisiones que involucran varios factores, porque obliga al modelo a desplegar el razonamiento en lugar de saltar a una conclusión. En cambio, para tareas de simple recuperación de datos aporta poco y solo alarga la respuesta.

Conviene siempre que la respuesta del modelo no la vaya a leer una persona, sino que la vaya a consumir otra parte del sistema, como un programa que necesita extraer datos concretos de ella. Si un modelo responde en texto libre, ese texto es impredecible en su estructura y resulta frágil y complicado de procesar automáticamente. En cambio, si se le exige explícitamente que devuelva, por ejemplo, un objeto JSON con campos fijos y sin ningún texto adicional, la salida se vuelve predecible y un programa puede interpretarla de forma confiable. Muchos modelos ofrecen además un modo de salida estructurada que garantiza que la respuesta cumpla un esquema definido, lo cual es aún más robusto que pedirlo solo en el texto del prompt. En resumen, cuando hay una persona del otro lado, el texto natural está bien; cuando hay código del otro lado, forzar un formato estricto es casi obligatorio para construir una aplicación fiable.

Porque sin medición, mejorar un prompt es una ilusión. Un prompt casi nunca sale perfecto a la primera, y la tentación natural es cambiar algunas palabras, mirar una respuesta y quedarse con la impresión de que ahora funciona mejor. El problema es que esa impresión es engañosa: al ajustar el prompt para arreglar un caso, es muy fácil romper otros sin darse cuenta, porque solo se miró un ejemplo. La forma correcta de mejorar un prompt es probarlo contra un conjunto de casos reales y representativos, y medir de forma objetiva si el resultado global mejoró o empeoró. Esto es evaluación de aplicaciones con modelos de lenguaje, y es exactamente lo que distingue el prompt engineering serio del ensayo y error a ciegas. La analogía con la programación es directa: cambiar un prompt sin medir es como modificar código sin pruebas, confiando en que la única vez que se probó representa todos los casos, cuando casi nunca es así.

Las reduce y las gestiona, pero no las elimina, y es importante tener esto claro para no confiar de más. Las alucinaciones son respuestas que el modelo presenta con seguridad pero que son incorrectas o inventadas, y provienen de la naturaleza misma de cómo funcionan estos modelos, que generan texto plausible sin una noción de verdad. Un buen prompt engineering puede disminuir su frecuencia: pedir que el modelo cite sus fuentes, que indique cuándo no está seguro, que se base solo en un texto proporcionado en lugar de en su memoria, o que razone paso a paso, ayuda a acotar el problema. Para tareas donde la exactitud factual es crítica, la técnica más efectiva es combinar el prompt con la recuperación de información desde fuentes confiables, un enfoque conocido como RAG, de modo que el modelo responda apoyándose en documentos reales. Pero incluso con todas estas precauciones, la salida de un modelo debe validarse cuando es crítica, porque ninguna técnica de prompt garantiza la ausencia total de errores.