Fundamentos de ingeniería de prompts que siguen importando

La ingeniería de prompts tiene un problema de reputación. La mitad de los consejos en internet son folclore: frases mágicas y rituales que funcionaron una vez en un modelo y se generalizaron hasta convertirse en ley. La otra mitad es genuinamente útil y aburrida. Esta guía trata de la mitad aburrida: los fundamentos que siguen funcionando entre modelos y versiones porque reflejan cómo estos sistemas usan realmente el texto que les das.

Por qué los fundamentos superan a los trucos

Un modelo de lenguaje genera una respuesta condicionada por todo lo que hay en su contexto: tus instrucciones, los ejemplos y la entrada. El "prompting" no es más que el arte de organizar ese contexto para que la continuación más probable sea la respuesta que quieres. Los trucos atados a las peculiaridades de un modelo específico se rompen cuando el modelo cambia. Los fundamentos —ser claro, dar ejemplos, estructurar la tarea— siguen funcionando porque hacen más probable la salida deseada para cualquier modelo capaz. Optimiza para los fundamentos y rara vez necesitarás los trucos.

1. Sé específico sobre la tarea y la salida

El fallo más común es la subespecificación. "Resume esto" deja una docena de decisiones al modelo: cuán largo, para quién, en qué tono, centrándose en qué. Cada decisión sin especificar es un lanzamiento de moneda. Di lo que realmente quieres: "Resume esto en tres viñetas para un gerente no técnico, centrándote en el coste y el riesgo". La especificidad no es verbosidad: es eliminar los lanzamientos de moneda.

Lo mismo aplica al formato de salida. Si necesitas una estructura particular —una lista, una tabla, JSON, un conjunto específico de campos— enúncialo explícitamente y muestra la forma. Un modelo no puede leerte la mente sobre el formato más de lo que puede sobre el contenido.

2. Muestra, no solo digas

Los ejemplos son la herramienta de mayor apalancamiento en el prompting. Uno o dos ejemplos resueltos de entrada-y-salida-deseada comunican más que un párrafo de instrucciones, porque demuestran el patrón en lugar de describirlo. Esto se llama a menudo prompting con pocos ejemplos (few-shot), y funciona por una razón simple: un ejemplo claro hace que el patrón objetivo sea la continuación obvia.

Dos notas prácticas. Haz que tus ejemplos sean representativos de las entradas reales, incluidos los casos complicados: los ejemplos que solo cubren el camino fácil enseñan el camino fácil. Y mantén los ejemplos coherentes entre sí; los ejemplos contradictorios confunden más de lo que ayudan.

3. Dale al modelo espacio para pensar

Para cualquier cosa que implique razonamiento —problemas de varios pasos, análisis, decisiones— pedir la respuesta de inmediato a menudo produce una peor respuesta que pedirle al modelo que la trabaje primero. Dejar que un modelo razone paso a paso antes de comprometerse con una respuesta final tiende a mejorar la calidad precisamente en las tareas donde la calidad es difícil. El mecanismo es intuitivo: un modelo que se compromete con una respuesta en su primer token no puede revisar; uno que razona primero sí puede.

La versión práctica: para tareas difíciles, pide el razonamiento y luego la conclusión, en lugar de la conclusión sola. Para tareas fáciles, sáltatelo: los pasos de razonamiento cuestan tokens y latencia, y una búsqueda simple no los necesita.

4. Pon las instrucciones donde aterricen

La estructura importa. Separa tus instrucciones de la entrada con claridad —con encabezados, delimitadores o secciones etiquetadas— para que el modelo pueda distinguir qué es un comando y qué son datos a procesar. Cuando un prompt mezcla instrucciones y contenido en un solo muro de texto, el modelo tiene que adivinar qué es qué, y a veces adivina mal. Un poco de estructura elimina la ambigüedad.

Las instrucciones a nivel de sistema (rol, reglas, restricciones) generalmente van por delante y enunciadas con claridad. La entrada a procesar va claramente marcada como entrada. Esta separación también protege contra una clase de fallos en los que el contenido de la entrada se lee accidentalmente como una instrucción.

5. Restringe el modo de fallo

Un modelo responderá incluso cuando no debería. Si tu tarea tiene un caso de "sin respuesta" —la información no está presente, la petición está fuera de alcance— dilo explícitamente: "Si el texto no contiene la respuesta, responde que no está indicado". Sin esa instrucción, el modelo rellena el vacío con una suposición plausible. Nombrar el modo de fallo que quieres convierte una fabricación segura en un honesto "no encontrado".

6. Itera contra ejemplos reales

La mayor diferencia entre el folclore y la ingeniería es la medición. No juzgues un prompt por una salida impresionante. Reúne un puñado de entradas reales y variadas, ejecuta tu prompt sobre todas ellas y lee los resultados. Cambia una sola cosa a la vez. Conserva la versión que rinde mejor sobre el conjunto, no la que produjo la mejor demo aislada. Esto es poco glamoroso y es todo el juego: un prompt que gana en veinte casos reales supera a uno que deslumbró una vez.

Lo que puedes ignorar en su mayoría

Mucho del consejo que circula es ruido: "personajes" elaborados que añaden longitud sin claridad, frases supersticiosas y plantillas rígidas copiadas entre tareas no relacionadas. Ninguno de estos es fiable. Si una técnica no puede explicarse en términos de hacer más probable la salida deseada, trátala como folclore hasta que tu propia evaluación demuestre lo contrario.

En resumen

El buen prompting no es una bolsa de trucos. Es claridad (di exactamente lo que quieres y en qué forma), demostración (muestra ejemplos), estructura (separa las instrucciones de la entrada) y medición (itera contra casos reales). Estos fundamentos han sobrevivido a varias generaciones de modelos porque funcionan con la forma en que los sistemas usan el contexto, no contra ella. Apréndelos bien y rara vez necesitarás algo más sofisticado.