Prompt engineering básico

Ya vimos en el capítulo anterior que un modelo base no tiene “sentido de la ocasión” — continúa cualquier patrón que el prompt sugiera, sin garantía de que sea el que tú quieres. La forma más rápida y barata de mejorar el comportamiento de un modelo —sin tocar ni un peso, sin nada de gradient descent— es diseñar mejor las instrucciones que le das. A esto se le llama prompt engineering, la primera y más accesible capa de todas las técnicas de esta parte.

Por qué el prompt engineering es la primera línea de defensa

Volviendo a la tabla de límites del capítulo anterior: RAG, fine-tuning, agentes, y prompt engineering no cuestan lo mismo, ni se implementan a la misma velocidad, ni se deshacen con la misma facilidad si algo sale mal. Antes de escalar a cualquiera de las técnicas más pesadas de esta parte del compendio, vale la pena entender con precisión por qué el prompt engineering casi siempre debe intentarse primero — y también, con la misma precisión, cuándo deja de ser la respuesta correcta.

Costo: qué hay que construir para cada opción

Cambiar un prompt no requiere construir nada. Compáralo con lo que exige cada alternativa:

RAG necesita una base de datos vectorial, un pipeline de embeddings, una estrategia de chunking, y un proceso para mantener esos datos actualizados — infraestructura real que hay que diseñar, desplegar, y mantener (Capítulo 5: RAG y 5b: Bases de datos vectoriales).
Fine-tuning necesita cómputo (GPU), un dataset curado de ejemplos de calidad, y un proceso de evaluación para confirmar que realmente mejoró algo (Capítulo 4 y 4b: LoRA vs. QLoRA).
Prompt engineering necesita, literalmente, cambiar el texto de una variable en tu código. Cero infraestructura nueva, cero cómputo de entrenamiento, cero pipeline de datos.

Velocidad de iteración: minutos contra semanas

Técnica	Tiempo típico para ver el primer resultado
Prompt engineering	Minutos — cambias el texto, vuelves a llamar a la API, ves el resultado de inmediato
RAG	Días — hay que preparar documentos, generar embeddings, montar la base vectorial, y probar la recuperación
Fine-tuning (incluso con LoRA/QLoRA)	Días a semanas — recolectar y curar datos, entrenar, evaluar, iterar si el resultado no convence

Esta diferencia de velocidad no es un detalle menor — es la razón principal por la que un buen ingeniero prueba primero lo más rápido de probar, no lo más “sofisticado” o lo primero que se le ocurre.

Reversibilidad: el costo hundido que no quieres pagar dos veces

Si un cambio de prompt no funciona, lo deshaces sin ninguna pérdida — nunca gastaste cómputo, nunca comprometiste infraestructura. Si un fine-tuning sale mal (datos de mala calidad, overfitting, un comportamiento no deseado que se “horneó” en los pesos), ya gastaste el cómputo del entrenamiento, y corregirlo significa repetir ese gasto, no simplemente deshacer un cambio de texto.

Un ejemplo trabajado: dónde el prompt engineering funciona, y dónde encuentra su techo

Retomemos el límite de “falta de precisión y consistencia” del capítulo anterior, con un caso concreto: un sistema que debe extraer, de reseñas de clientes, si el producto tuvo un defecto de fabricación.

Intento 1 (prompt ingenuo): “¿Este producto tuvo un defecto de fabricación? Reseña: [texto]” — el modelo responde con explicaciones largas, a veces “sí”, a veces “parece que sí”, a veces un párrafo entero sin una respuesta clara. Inconsistente, difícil de procesar automáticamente.

Intento 2 (prompt mejorado, con formato y criterio explícito): “Responde ÚNICAMENTE con ‘SI’ o ‘NO’. Considera ‘defecto de fabricación’ solo si la reseña menciona explícitamente que el producto llegó roto, no funcionó desde el primer uso, o tiene un problema presente en múltiples unidades reportadas por otros clientes en el mismo texto. Reseña: [texto]” — con un criterio explícito y un formato forzado, la consistencia mejora dramáticamente. Este es el prompt engineering funcionando exactamente como debería.

Dónde se topa con su techo: si le pides al mismo sistema que identifique si el defecto corresponde a un modelo específico de producto que fue descontinuado antes de que el modelo se entrenara, ningún prompt —por bien diseñado que esté— puede resolver eso. El conocimiento simplemente no está en los pesos del modelo. Aquí el problema ya no es de instrucciones, es de conocimiento del dominio — y ese es exactamente el límite que RAG existe para resolver, no prompt engineering. Ninguna cantidad de ingeniería de instrucciones sustituye información que el modelo nunca vio.

El matiz que casi nadie menciona: el prompt engineering no siempre es gratis a escala

Aquí está la parte verdaderamente importante, y la razón por la que “primera línea de defensa” no significa “siempre la mejor opción”: un prompt few-shot elaborado, con varios ejemplos y instrucciones extensas, consume más tokens en cada llamada — y ese costo se paga una y otra vez, en cada solicitud, para siempre.

Compáralo con el fine-tuning: el costo de entrenar es alto, pero se paga una sola vez. Después de eso, el modelo afinado puede responder correctamente con un prompt mucho más corto — porque el comportamiento ya está “horneado” en los pesos, no necesita que se lo expliques de nuevo en cada llamada.

Esto significa que la ecuación cambia con el volumen: para un sistema que hace mil llamadas al día, el prompt largo es indiscutiblemente más barato que fine-tunear. Pero para un sistema que hace millones de llamadas al día, ese costo recurrente por token, multiplicado por cada llamada, puede terminar superando ampliamente el costo de entrenamiento — que se pagó una sola vez. Esta es, precisamente, una de las razones legítimas para escalar a fine-tuning que ya vimos en el Capítulo 4: no porque el prompting “no funcione”, sino porque a suficiente escala, deja de ser la opción más barata. Conecta directo, también, con el trilema de costo/latencia/throughput de Parte III — el mismo tipo de decisión de ingeniería, aplicada aquí a diseño de prompts en vez de a infraestructura de inferencia.

El criterio de decisión completo

¿El problema es de instrucciones poco claras o formato inconsistente? → Prompt engineering. Empieza aquí, casi siempre.
¿El problema es de conocimiento que el modelo no tiene? → RAG, no importa qué tan bien redactes el prompt.
¿El problema persiste después de un prompt bien diseñado, Y el volumen de llamadas es alto? → Ahí sí, evalúa fine-tuning — tanto por consistencia de comportamiento como por el ahorro de costo recurrente a esa escala.

El espectro de disparos: zero-shot vs. few-shot

Cero disparos (zero-shot): le pides al modelo que haga algo directamente, sin ejemplos.

Clasifica esta opinión de producto como positiva, negativa o neutra:
"El portátil está bien, pero esperaba más."

El problema: esto es genuinamente subjetivo. Para algunas empresas es neutra, para otras negativa — el modelo tiene que adivinar tu criterio sin que se lo hayas comunicado.

Pocos disparos (few-shot): le das ejemplos explícitos, calibrando su criterio antes de la pregunta real.

Ejemplo 1: "Superó mis expectativas" -> Positiva
Ejemplo 2: "Está bien, pero le faltan funciones" -> Negativa
Ahora clasifica: "El portátil está bien, pero esperaba más."

El modelo ahora responde “Negativa” con más seguridad — no porque “entendió” tu política en abstracto, sino porque el segundo ejemplo establece un patrón textual parecido a la pregunta real.

Por qué funciona, conectando con Parte I: ningún peso cambia entre zero-shot y few-shot. Lo único que cambió es qué tokens hay en el contexto. Los ejemplos se vuelven contexto adicional que la atención puede consultar directamente — la misma atención causal de la anatomía del transformer, con más información disponible para que la query de la posición final “encuentre” un patrón relevante entre las keys de los ejemplos. Esto se llama aprendizaje en contexto (in-context learning) — radicalmente distinto del fine-tuning: sin backpropagation, sin actualización de pesos.

¿Cuándo usar cada uno?

	Zero-shot	Few-shot
Cuándo conviene	La tarea es común y poco ambigua (“traduce esto al inglés”)	El criterio es subjetivo, específico de tu empresa, o el formato de salida es inusual
Costo	Ninguno adicional	Cada ejemplo ocupa tokens del contexto — cuesta dinero y espacio en cada llamada
Riesgo si se omite	El modelo puede adivinar mal un criterio ambiguo	—
Cuántos ejemplos usar	—	Pocos ejemplos bien elegidos suelen bastar; agregar muchos más rara vez ayuda tanto como se piensa, y consume contexto valioso que podría usarse para el resto del prompt

Técnicas avanzadas de razonamiento

Cadena de pensamiento (Chain of Thought, CoT)

Obligar al modelo a escribir su razonamiento paso a paso antes de la respuesta final.

Por qué funciona mecánicamente: un LLM genera un token a la vez, y cada token generado se vuelve contexto para el siguiente. Si el modelo salta directo a la respuesta, tiene que producirla en un solo paso de cómputo. Si genera pasos intermedios, cada paso se convierte en contexto adicional que los pasos siguientes pueden consultar — más espacio de cómputo repartido entre más tokens, en vez de comprimir todo el razonamiento en un solo token de respuesta.

Ejemplo resuelto, mostrando la diferencia real:

Pregunta: “Un tren sale a las 14:20 y el viaje dura 3 horas y 45 minutos, pero se detiene 20 minutos en una estación intermedia que no está incluida en la duración del viaje. ¿A qué hora llega?”

Respuesta directa (sin CoT): un modelo puede responder apresuradamente “18:05” — sumó 3h45m a 14:20 pero olvidó los 20 minutos de la parada, un error común cuando se le pide “solo la respuesta”.
Respuesta con CoT (“piensa paso a paso”): “Primero sumo la duración del viaje: 14:20 + 3:45 = 18:05. Luego sumo la parada de 20 minutos, que no está incluida: 18:05 + 0:20 = 18:25. Respuesta: 18:25.”

Al forzar al modelo a exponer cada paso, cada suma intermedia queda “anclada” en el contexto antes de calcular la siguiente — reduciendo la probabilidad de saltarse un paso, exactamente como haría una persona resolviendo el problema en papel en vez de intentar hacerlo todo de cabeza.

Dos variantes, con nombre propio:

Zero-shot CoT: simplemente agregar una frase activadora como “Piensa paso a paso y no te saltes ningún paso”, sin ningún ejemplo de cómo razonar. Kojima et al. (2022, “Large Language Models are Zero-Shot Reasoners”) mostraron que esta sola instrucción, sin ejemplos, ya mejora notablemente el rendimiento en tareas de razonamiento respecto a pedir la respuesta directa.
Few-shot CoT: además de pedir el razonamiento, se muestran uno o dos ejemplos completos con su cadena de pensamiento ya escrita (como el ejemplo del tren de arriba, usado como ejemplo dentro del prompt). Suele funcionar mejor en tareas más difíciles, porque el modelo tiene un patrón completo de “cómo se ve un buen razonamiento” para imitar, no solo la instrucción de razonar.

Encadenamiento de prompts (prompt chaining)

Dividir una tarea gigante en una secuencia de prompts más pequeños, donde la salida de uno alimenta al siguiente.

Ejemplo — un correo de soporte al cliente:

Prompt 1: extraer los problemas clave del mensaje del cliente.
Prompt 2: generar un esquema estructurado de respuesta, con base en esos problemas.
Prompt 3: redactar el correo final con el tono de la empresa.

Esto permite depurar el sistema con precisión — si el correo final sale mal, puedes ver en qué eslabón ocurrió el problema, algo imposible con un prompt monolítico. Este principio de descomposición reaparece con más fuerza en los flujos agénticos: un agente es, en buena medida, una forma más dinámica de encadenar prompts, donde el modelo mismo decide cuándo pasar al siguiente paso.

Resumen del capítulo

Zero-shot funciona bien para tareas comunes y poco ambiguas; few-shot calibra el criterio del modelo con ejemplos, a costa de tokens adicionales en cada llamada.
Ninguna de las dos técnicas cambia pesos del modelo — ambas son aprendizaje en contexto, aprovechando la atención sobre lo que ya está en el prompt.
Chain-of-Thought (zero-shot o few-shot) mejora el razonamiento de múltiples pasos, exponiendo el trabajo intermedio en vez de saltar directo a la respuesta — la técnica concreta que resuelve el límite de “razonamiento de múltiples pasos” que vimos en el capítulo anterior.
El encadenamiento de prompts descompone tareas complejas en pasos verificables por separado — el mismo principio que reaparece, a mayor escala, en los flujos agénticos.

En el próximo capítulo veremos cómo saber, de forma sistemática y no solo por intuición, si un cambio de prompt realmente mejoró algo: los jueces LLM y la evaluación de prompts.