Técnicas de prompt

Se conoce como prompt engineering, ingeniería de prompts, a la práctica de diseñar y formular instrucciones o preguntas de manera estratégica para obtener mejores respuestas de modelos de inteligencia artificial como DeepSeek, Claude oChatGPT. Aunque el término puede resultar tan pomposo que incluso despierte ciertos recelos, en realidad se trata de una habilidad esencial para interactuar de forma eficaz con estas herramientas.

Hay diferentes técnicas y enfoques para la ingenería de prompts. Vamos a explorar algunos de los más comunes.

1. Chain of Thought (CoT) y sus variantes

La técnica de Chain of Thought (CoT) consiste en guiar al modelo a través de un proceso de razonamiento paso a paso. Por ejemplo:

En el año 23 a.C., Augusto tenía 40 años, llevaba 11 años en el poder y acababa de sobrevivir una enfermedad grave. ¿Debería haber nombrado sucesor?

Piensa paso a paso

Es decir, en lugar de pedir una respuesta directa, se le solicita al modelo que explique su razonamiento o que descomponga el problema en partes más pequeñas y esto puede ayudar a mejorar la precisión y la coherencia de las respuestas, especialmente en tareas complejas. Es como si le dijeras a la IA: “No solo dame la respuesta, dime cómo llegaste a ella”, lo que autoenriquece el contexto y la comprensión del modelo.

Hay varias variantes de esta técnica:

1.1. Zero-shot CoT.

Es la que acabamos de ver, simplemente añadir “Piensa paso a paso” al final del prompt.

1.2. Few-shot CoT.

Consiste en incluir 2 o 4 ejemplos completos donde muestras tanto el razonamiento como la respuesta final. El modelo aprende el patrón de pensamiento, no solo el formato. Por ejemplo,

EJEMPLO: Pregunta: ¿Julio César fue un héroe o un tirano? Razonamiento: Expandió Roma y reformó el calendario, pero destruyó la república para conseguirlo. La respuesta depende de si valoras más el resultado o el método. 
Respuesta: Las dos cosas, dependiendo del criterio. 
Pregunta: ¿Napoleón fue un héroe o un tirano? 
Razonamiento:

Es como mostrarle al modelo cómo piensas tú, para que él pueda imitar ese proceso de pensamiento. Cuantos más ejemplos le des, mejor entenderá el patrón, aunque también hay que tener cuidado de no saturarlo con demasiada información.

1.3. Self-consistency CoT.

En lugar de generar una sola respuesta, se le pide al modelo que genere varias respuestas diferentes para el mismo prompt, y luego se selecciona la respuesta más común o consistente entre ellas.

Expresado de otra manera, pongamos por ejemplo que tenemos una pregunta difícil -por qué cayó el imperio Romano- y se la hacemos a cinco historiadores distintos por separado, sin que hablen entre ellos. Cada uno razona de forma diferente, hace énfasis en cosas distintas, y llega a su conclusión por su propio camino. Pero cuando se comparan las cinco respuestas, tres coinciden en que la causa principal fue económica. Un cuarto dice que fueron las invasiones bárbaras y el quinto que fue culpa al cristianismo. ¿En qué nos fiamos más? En lo que dijo el cuarto o el quinto, o en lo que dijeron tres de cinco, razonando de forma independiente? Self-consistency hace exactamente eso, pero con el mismo modelo.

Para entender cómo funciona esta técnica debemos saber antes qué es la temperatura en los modelos de lenguaje. La temperatura es un parámetro que controla la aleatoriedad de las respuestas generadas por el modelo. A temperaturas bajas (por ejemplo, 0.2), el modelo tiende a generar respuestas más conservadoras y predecibles, mientras que a temperaturas altas (por ejemplo, 0.8), las respuestas pueden ser más creativas y variadas. Para aplicar self-consistency, se suele configurar el modelo con una temperatura alta para fomentar la diversidad de respuestas, y luego se selecciona la respuesta más común o consistente entre ellas.

Está técnica se puede utilizar de dos maneras:

a) La primera es obvia. Si tenemos acceso a la API, lanzamos el mismo prompt varias veces programáticamente con temperatura alta y comparamos los resultados. El modelo no sabe que estamos haciendo self-consistency, simplemente responde cada vez.

b) La segunda es pidiéndole al modelo que simule el proceso internamente en una sola llamada:

Responde a esta pregunta tres veces seguidas, cada una razonando de forma independiente y por un camino distinto. 
Al final, dime qué respuesta apareció más veces y por qué.

Pregunta: ¿Cuál fue la causa principal de la caída  del Imperio Romano?

Esta técnica es interesante, sin embargo, presenta dos grandes problemas que es importante mencionar:

• Aumenta los costes de tiempo y tokens de cada respuesta.
• Que una respuesta se repita, no significa necesariamente que sea buena: cinco respuestas incorrectas siguen siendo incorrectas.

2. Tree of Thoughts (ToT)

Esta técnica me gusta mucho. En esencia, consiste en analizar varias posibilidades para ver cuál da mejor resultados. Y esto viene a resolver el principal problema de CoT: la primera decisión que se toma condiciona todas las demás. Es decir, con más o menos ejemplos, mediante CoT, el modelo razona así:

Paso 1 > Paso 2 > Paso 3 > Conclusión

Cada paso condiciona el siguiente y cierra otras alternativas. Es un camino lineal, sin vuelta atrás. Sin embargo, con ToT el modelo estudia distintas alternativas y se queda con la más convincente.

Volvamos al período final del imperio romano de Occidente para entender esto mejor con un ejemplo y pongamos que preguntamos esta cuestión:

Si fueras consejero del emperador Diocleciano en el 285 d.C., 
¿qué harías para salvar el imperio Romano?

Piensa paso a paso

Si en el primer paso, el modelo decide que el problema principal es militar, todo el razonamiento posterior girará en torno a soluciones militares y nunca explorará que quizás el problema era económico o administrativo o los tres a la vez con distinta prioridad.

Ahora bien, con ToT, cada camino se desarrolla un poco. Luego se evalúa cuál es más prometedor y se continúas por ese. Si se llega a un callejón sin salida, se retrocedes y se prueba otro. Y esto es exactamente lo que hace un buen historiador, un buen estratega, o un buen médico diagnosticando. No se comprometen con la primera hipótesis, sino que la exploran junto a otras y descartan por evidencia.

2.1. ¿Cómo se traduce en un prompt?

Hay tres ingredientes que se debe diseñar explícitamente:

1. Generar alternativas genuinamente distintas

Eres consejero de Diocleciano en el 285 d.C. El Imperio está en crisis. 
Genera tres estrategias para salvarlo. Cada una debe partir de un diagnóstico distinto del problema.
No deben ser variaciones de la misma idea.
[...]

La instrucción crítica es “partir de un diagnóstico distinto”. Sin ella el modelo puede generar tres versiones de la misma estrategia con nombres diferentes.

2. Evaluar cada camino antes de continuar

Forzamos a que analice cada estrategia añadiendo al prompt algo parecido a esto:

[...]
Para cada estrategia, evalúa:
- ¿Qué problema resuelve exactamente?
- ¿Qué problema ignora o empeora?
- ¿Qué necesitarías saber para confirmar que es el camino correcto?
[...]

3. Elegir y profundizar

Y terminamos diciéndole que escoja la que le parece más correcta.

[...]
¿Cuál de las tres estrategias tiene más probabilidad 
de haber funcionado dado lo que sabemos históricamente 
del Imperio en el 285 d.C.? Desarrolla solo esa.

De esta manera, con ToT, el modelo podría generar tres diagnósticos distintos. En el caso de DeepSeek, con ese prompt, primero analizó tres estrategias posibles:

• Estrategia 1: Reforma militar de choque externo.
• Estrategia 2: Reforma económica y monetaria radical.
• Estrategia 3: Descentralización confederada.

Y eso le permitió llegar a una conclusión donde entremezcla las distintas opciones para dar un resultado más sofisticado.

Recomendarías a Diocleciano una descentralización administrada: dividir el Imperio en dos o cuatro partes, pero mantener un cuerpo legal, fiscal y militar unificado nominalmente. Es decir, la tetrarquía que él mismo inventó tres años después (293). No era una confederación pura (Estrategia 3) ni un centralismo militar (Estrategia 1) ni solo economía (Estrategia 2). Era la mezcla pragmática: reconocer que el Imperio era ingobernable desde un punto, pero atarlo con unidad simbólica, monetaria y jurídica.

Si tuvieras que elegir solo una de las tres como consejero, elegirías la Estrategia 3 pero advirtiendo que necesita un emperador senior con poder de veto y un tesoro común. Lo que históricamente demostró ser la mejor respuesta a la crisis del 285 fue más descentralización que antes, pero menos que una confederación.

Vamos con la siguiente.

3. ReAct

Volvamos a Roma. Con ToT conseguimos explorar varias hipótesis sobre por qué cayó el Imperio, pero hay una pregunta que ninguna de las dos técnicas puede responder bien:

¿Qué evidencia arqueológica reciente apoya o contradice la teoría del colapso económico como causa principal?

CoT y ToT sirven para mejorar el razonamiento sobre lo que el modelo ya sabe, pero no permiten superar la fecha en la que fue entrenado. Es lo que se conoce como knowledge cutoff. Los modelos solo tienen datos hasta el momento en el que salieron de la fábrica, por lo que en nuestro caso no sabe qué se acaba de publicar este mes. No puede acceder a una base de datos de excavaciones. No puede leer un artículo que salió la semana pasada. El modelo es un sistema cerrado y todo su razonamiento opera sobre conocimiento estático congelado. Y aquí es donde cobra valor la técnica ReAct.

En esencia, ReAct consiste en alternar entre razonar (Reasoning) y actuar (acting). El modelo no razona solo con lo que sabe. Razona, decide que necesita algo que no tiene, va a buscarlo, incorpora lo que encontró, y continúa razonando desde ahí. Es un bucle en el que va afinando la respuesta final en función de lo que va investigando. Algo así:

1. Razona sobre lo que sabe.
2. Detecta qué le falta.
3. Usa una herramienta para obtenerlo.
4. Incorpora el resultado.
5. Repite el proceso si es necesario.

La estructura clásica se suele representar así:

Thought: [qué sé, qué me falta, qué haré]
Action: [herramienta a usar]
Observation: [resultado, lo que devuelve la herramienta]
Thought: [nuevo razonamiento incorporando la observación]
Action: [siguiente acción]
...
Answer: [respuesta final]

Pero esta representación es más pedagógica que literal. En sistemas reales, ese Thought no siempre aparece explícitamente, y muchas veces el razonamiento está implícito o parcialmente oculto. En cualquier caso, el Thought iterativo es lo más importante del esquema. Es más que un mero resumen de lo que el modelo acaba de leer, es razonamiento sobre qué implica lo que encontró y qué pregunta concreta sigue sin respuesta. Sin un Thought real, ReAct es simplemente un buscador con pasos extra.

De todas maneras, aunque ReAct nació como una técnica de prompting, hoy se entiende mejor como un patrón de agente. No es solo un prompt, sino una propuesta para conectar un LLM con el mundo exterior. Es un patrón de agente que combina un prompt específico con un bucle de ejecución. El prompt es solo una de las tres capas que articulan una arquitectura ReAct:

• Capa 1: El modelo. Genera razonamiento y decide qué acción necesita. Esto sí es prompting.
• Capa 2: El orquestador. Lee el output del modelo, detecta cuándo hay una acción, la ejecuta en el mundo real, y devuelve el resultado al modelo. Esto es código externo, no prompt.
• Capa 3: Las herramientas. Lo que el orquestador puede ejecutar realmente, como búsqueda web, base de datos, código, APIs.

En síntesis, se podría decir que ReAct equivale a pedirle al modelo que busque información para atender una cuestión y que valore si la información obtenida basta para formular una respuesta o debe seguir investigando. Sería como plantearle algo así:

Responde usando este formato exacto, alternando Thought y Action hasta tener suficiente información:

Thought: [qué sabes, qué te falta, qué harás]
Action: [Buscar en la web]
Observation: [resultado]
Thought: [nuevo razonamiento]
...
Answer: [respuesta final]

Pregunta: ¿Qué evidencia arqueológica reciente apoya o contradice la teoría del colapso económico como causa de la caída de Roma?

Ahora bien, en los chats de los modelos más populares, como DeepSeek, Claude, Gemini o ChatGPT, es complicado advertir como funciona. Deben tener activadas las herramientas y pueden no transparentar el proceso. Para ver más o menos cómo funcionaría, se puede simular el proceso.

Simula un proceso ReAct completo para responder esta pregunta. Inventa observaciones plausibles como si tuvieras acceso a búsqueda web. Las Observations serán ficticias — útil para entender el patrón, no para obtener información real.

Pregunta: ¿Qué evidencia arqueológica reciente apoya la teoría del colapso económico de Roma?

En cualquier caso, como decía, más que una técnica de prompting, lo importante es entender el mecanismo básico. ReAct es la base conceptual sobre la que se construyeron muchos frameworks de agentes modernos, como LangChain o LlamaIndex. Cuando un agente “busca en internet”, “ejecuta código” o “consulta una base de datos”, por dentro está siguiendo este mismo ciclo de razonar, actuar y observar.

ReAct tiene sin embargo dos limitaciones principales. La primera, claro está, es que incrementa en gran medida el consumo de tiempo y tokens. La segunda es que permite incorporar información actualizada. Pero no elimina el posible problema del conocimiento. Es decir, el modelo puede buscar información, pero puede buscarla mal, puede interpretarla mal o, incluso, puede ser errónea por la razón que sea.

Bueno, quedémonos de momento con que es un patrón de agente en el que intervienen tres componentes:

a. Modelo, genera decisiones (qué hacer, qué falta). b. Orquestador, interpreta esas decisiones y ejecuta acciones. c. Herramientas, web, bases de datos, código, APIs, etc.

4. Prompt Chaining

Hasta ahora hemos mejorado cómo el modelo razona dentro de una sola llamada. CoT, ToT, ReAct: todo ocurre en un único intercambio, por muy sofisticado que sea internamente. Pero hay tareas que ninguna técnica de una sola llamada resuelve bien. No por falta de razonamiento, sino por un límite físico: un prompt monolítico que intenta hacer demasiadas cosas a la vez produce resultados mediocres en todas ellas.

Aplicado a Roma:

Analiza las causas de la caída del Imperio Romano, evalúa qué teorías tienen más respaldo académico, 
identifica contradicciones entre ellas, sintetiza una teoría unificada, y escríbelo como un ensayo académico con estructura argumental clara.

Esto le pide al modelo cinco cosas distintas simultáneamente. El resultado será un texto que hace todas superficialmente en lugar de cada una bien. La técnica de Prompt Chaining resuelve esto dividiendo la tarea en pasos, donde el output, la salida, de cada paso se convierte en el input, la entrada, del siguiente.

La idea es, por lo tanto, dividir una tarea compleja en una cadena de tareas simples, cada una especializada en una sola cosa.

Así, en nuestro ejemplo, en vez de formular todo en un solo prompt monolítico, podríamos preparar algo así.

Prompt 1. Recopilar teorías:

Lista las principales teorías académicas sobre la caída del Imperio Romano. Para cada una indica:
- Autor o escuela principal
- Argumento central en una frase
- Qué evidencia la sostiene

Prompt 2. Evaluar contradicciones (usando el output del Prompt 1):

Aquí tienes las principales teorías sobre la caída de Roma: [output del Prompt 1]

Identifica qué teorías son mutuamente excluyentes y cuáles son complementarias. Explica por qué.

Prompt 3. Construir posición (usando output del Prompt 2):

Dadas estas relaciones entre teorías: [output Prompt 2]

¿Qué combinación de factores tiene más respaldo empírico? Construye un argumento jerarquizando causas en estructurales, aceleradoras y detonantes.

Prompt 4. Conclusión (usando output del Prompt 3):

Basándote en este argumento: [output Prompt 3]

Escríbelo como introducción de un ensayo académico. 
Tono riguroso, sin jerga innecesaria, máximo 300 palabras.

```md
Cada prompt tiene una sola responsabilidad. El modelo no está dividiendo su atención entre recopilar, evaluar y escribir simultáneamente, sino que hace cada cosa completamente antes de pasar a la siguiente. Y lo que es aún más interesante: un ser humano puede intervenir entre pasos (human in the loop). Si el output del Prompt 2 tiene un error, como clasificar como contradictorias dos teorías que en realidad son complementarias, el humano supervisor puede corregirlo antes de que ese error se propague al Prompt 3 y al 4. En un prompt monolítico, ese error está enterrado en el medio del proceso y no hay forma de interceptarlo.

Ahora bien, para que esta técnica funcione es fundamental controlar los formatos de salida, que son el eslabón que permite la continuidad de la cadena. El output de cada paso debe tener un formato que el siguiente paso pueda consumir limpiamente.

Por ejemplo, si el prompt 1 devuelve un texto fluido y desestructurado, el prompt 2 tiene que parsearlo antes de poder usarlo.:

```md
// ko
Las teorías sobre Roma son variadas y complejas. Gibbon argumentó en el siglo XVIII que el cristianismo tuvo un papel importante, mientras que historiadores más recientes como Peter Heather han enfatizado...

En cambio, si está estructurado, engancha mucho mejor con el siguiente.

// ok
1. Teoría del colapso económico
- Autor: Bryan Ward-Perkins
- Argumento: la contracción del comercio destruyó la base fiscal del ejército
- Evidencia: registros arqueológicos de cerámica y monedas en circulación

2. Teoría de las invasiones externas
- Autor: Peter Heather
[...]

Dicho de otra manera: la cadena es tan fuerte como su eslabón más débil. Y ese eslabón más débil casi siempre es el formato del output. Si no está diseñado para ser consumido por el siguiente paso, la cadena se rompe ahí.

5. Role Prompting

5.1. Puro teatro

Esta técnica es de las más conocidas y consiste en asignar al modelo una identidad con conocimiento, sesgos y prioridades concretas.

Cuanto más concreta y precisa sea esa identidad, más se advertirá el condicionamiento. Por ejemplo, algo así, sería demasiado genérico:

Eres un historiador experto en Roma. 
¿Por qué cayó el Imperio Romano?

Sin embargo, este otro prompt encauza en gran medida la respuesta hacia un camino en concreto.

Eres Peter Heather, historiador que lleva 30 años argumentando que las invasiones bárbaras fueron la causa principal de la caída de Roma. Acabas de leer un paper que atribuye el colapso principalmente al deterioro económico interno. Responde al paper defendiendo tu posición, reconociendo qué puntos son válidos y cuáles refutas.

De hecho, ChatGPT, saca toda su artillería de emoticonos ante algo así:

[...]
⚔️ Donde discrepo profundamente

El problema del paper es causal, no descriptivo.

El autor sugiere que la economía colapsa primero y que esto provoca la caída política. Yo sostengo lo contrario:
👉 la presión externa transforma las condiciones económicas hasta romperlas
[...]

Ojo, eso no significa que se deba asignar una identidad real, sino activar una simulación de estilo, conocimiento y prioridades asociadas a una identidad, que puede ser real o no. De esta manera, se reorganiza probabilísticamente el espacio de respuestas del modelo dentro de un marco narrativo o argumentativo.

En síntesis: cuando el modelo tiene una posición concreta que defender, una tensión real con evidencia contraria, y la obligación de razonar con matices. La respuesta es cualitativamente distinta.

5.2. Un buen role

Hay tres ingredientes clave para construir un role potente:

1. Perspectiva con sesgo conocido No “experto en X” sino alguien con una posición específica sobre X. El sesgo no es un problema, en este caso, sino todo lo contrario, el punto clave para que el modelo razone desde ese ángulo particular, no desde el centro.

2. Restricciones de comportamiento Lo que no hace un rol es tan importante como lo qué sí hace. Un buen role incluye limitaciones explícitas. Por ejemplo, así evitaríamos que el modelo rompa el rol continuamente haciendo referencias anacrónicas.

Eres un senador romano del siglo III d.C. Conoces la historia de Roma hasta ese momento pero no lo que ocurrirá después. No puedes hacer referencias a eventos posteriores al año 280 d.C.

3. Contexto de activación Es lo que en sistemas de prompts se llama motivación situacional o frame narrativo y sirve para que el rol no sea decorativo sino funcional dentro de una escena. Por qué este rol está respondiendo ahora, en este momento específico. Le da al modelo una razón concreta para adoptar la perspectiva en lugar de tratarla como decoración.

Acabas de leer un informe que contradice tu teoría principal.
Tienes que responder en un congreso académico delante de colegas escépticos.

6. Self-Critique

6.1. La versión básica

Todas las técnicas que hemos visto mejoran cómo el modelo genera una respuesta; esta otra técnica, que casi es mi favorita, ataca algo distinto: qué hace el modelo después de generarla. En esencia, lo que hace es que, en vez de que el modelo genere una respuesta sin más, le obligue a evaluar su propio output contra criterios específicos y revisarlo.

Y lo interesante es por qué funciona. Cuando el modelo genera una respuesta, activa ciertos patrones de su entrenamiento. Cuando luego se le pide que la critique, activa patrones distintos, los asociados a evaluación, detección de errores y pensamiento crítico. Es como un escritor que termina un párrafo y lo relee con distancia crítica encuentra errores que no vio mientras escribía. No porque sea más inteligente en la relectura, sino porque está en un modo distinto.

La versión más rudimentaria es responderle a una respuesta algo así como:

Critica tu respuesta.

Y algo más sofisticada, incorporar la crítica en el propio prompt.

Responde a esta pregunta:
¿Cuál fue la causa principal de la caída del Imperio Romano?

Luego critica tu respuesta. Busca específicamente:
- Afirmaciones que hiciste con más confianza de la justificada
- Perspectivas importantes que ignoraste
- Evidencia que contradice tu conclusión

Finalmente, reescribe la respuesta incorporando la crítica.

El ciclo es siempre el mismo: generar > criticar > revisar.

6.2. Versiones más avanzadas

Ya con algo tan sencillo se obtienen resultados interesantes, sin embargo, son mejores aún si añadimos criterios específicos. Por ejemplo, así sería sin más.

Critica tu respuesta. ¿Es completa? ¿Es precisa?

Pero, de esta otra manera, el modelo no puede esconderse en generalidades. Tiene que responder preguntas concretas sobre su propio output.

Critica tu respuesta evaluando exactamente esto:

1. ¿Distinguiste entre el Imperio Occidental y Oriental o trataste Roma como un bloque homogéneo?

2. ¿Jerarquizaste las causas o las listaste como si tuvieran el mismo peso?

3. ¿Hay alguna teoría académica relevante que ignoraste completamente?

4. ¿En qué afirmación fuiste más rotundo de lo que la evidencia justifica? 

Y si no queremos bajar a preparar un prompt con criterios ad hoc para cada tarea, podemos definir un conjunto fijo de principios reutilizables contra el que el modelo evalúa cualquier respuesta. Algo así como un manual de instrucciones de Self-Critique para determinadas materias, como la historia.

PRINCIPIOS DE ANÁLISIS HISTÓRICO RIGUROSO:
A. Distinguir causas estructurales de detonantes inmediatos
B. No atribuir a un solo factor lo que requiere varios
C. Considerar la perspectiva de distintos grupos sociales
D. Separar lo que se sabe con certeza de lo que se infiere
E. Reconocer explícitamente qué evidencia contradice la conclusión

Evalúa tu respuesta anterior contra cada uno de estos principios. Para cada uno indica si lo cumpliste, lo cumpliste parcialmente, o lo ignoraste.

Luego reescribe.