Prompt engineering, medido: qué cambia la salida

Antes de las mediciones, un hecho que explica en silencio la mitad de lo que sigue.

El modelo no tiene memoria. Entre dos llamadas no conserva nada: ni tu última pregunta, ni su propia última respuesta, ni el archivo que adjuntaste, ni el hecho de que ya se lo hayas pedido dos veces. Cada llamada empieza desde una máquina vacía, y lo único que esa máquina sabe es la secuencia de tokens que acabas de entregarle.

Lo que parece memoria en una interfaz de chat es tu cliente reenviando toda la conversación, cada turno, desde el principio. El modelo lo lee todo otra vez desde cero, cada vez. El capítulo 13 midió lo que cuesta esa relectura en un forward pass; el capítulo 16 lo convierte en una línea de una factura. Lo que importa aquí es la consecuencia para el diseño: el prompt no es un mensaje a un sistema que tiene estado. Es el estado.

Eso jubila una familia de confusiones. «El modelo olvidó lo que le dije» suele significar que nunca se le envió. «Ignoró mi instrucción anterior» suele significar que la instrucción se salió de la ventana cuando se truncó el historial. «Se comportó de forma distinta en producción» suele significar que producción monta un prompt diferente del que probaste. Nada de esto es un problema del modelo, y nada se arregla reformulando nada.

La afirmación «este prompt es mejor» es una afirmación sobre una distribución, y no puedes ver una distribución mirando una salida. Lo que necesitas es aburrido: casos con respuestas conocidas, N variantes y un intervalo.

El harness son cincuenta líneas de TypeScript con la misma forma que el cliente del capítulo 14: una petición, un plazo, algo de concurrencia, un recuento. Reaparece en el capítulo 19 para evaluar un recuperador y en el capítulo 29 como golden set.

export type Case = { input: string; expected: string };
export type Variant = { name: string; build: (c: Case) => ChatMessage[] };

async function pooled<T, R>(xs: T[], n: number, f: (x: T) => Promise<R>) {
  const out: R[] = new Array(xs.length);
  let i = 0;
  await Promise.all(
    Array.from({ length: n }, async () => {
      while (i < xs.length) {
        const k = i++;
        out[k] = await f(xs[k]);
      }
    }),
  );
  return out;
}

export async function runVariant(v: Variant, cases: Case[], concurrency = 6) {
  const hits = await pooled(cases, concurrency, async (c) => {
    const answer = await complete(v.build(c));      
    return answer.trim().toLowerCase() === c.expected;
  });
  return { name: v.name, hits, k: hits.filter(Boolean).length, n: cases.length };
}

El número que vuelve no es el resultado. Esto sí:

/** 95 % Wilson score interval for a proportion. Chapter 4 derives it. */
export function wilson(k: number, n: number, z = 1.96) {
  const p = k / n;
  const d = 1 + (z * z) / n;
  const centre = (p + (z * z) / (2 * n)) / d;
  const half = (z * Math.sqrt((p * (1 - p)) / n + (z * z) / (4 * n * n))) / d;
  return [Math.max(0, centre - half), Math.min(1, centre + half)] as const;
}

El capítulo 4 planteó el argumento y este capítulo lo cobra. Diecisiete aciertos de veinte son un 85 %, y su intervalo del 95 % va del 64 % al 95 %. Una variante que puntúa 13 de 20 —65 %, que parece claramente peor— tiene un intervalo del 43 % al 82 %. Esos dos intervalos se solapan en casi toda su longitud. Veinte casos no pueden distinguir un buen prompt de uno mediocre, y la mayoría de los consejos publicados sobre prompts se validaron con menos.

Sesenta casos, que es lo que usa este capítulo, siguen sin ser muchos. Bastan para ver efectos grandes y son lo bastante honestos para admitir cuándo no pueden ver los pequeños; y eso se admitirá varias veces más abajo.

Tres bloques —las reglas R, el ticket T, la instrucción I— concatenados en un único mensaje de usuario. Las seis permutaciones, contenido idéntico byte a byte, sesenta casos cada una.

Del mejor al peor hay 28,3 puntos, y los intervalos no se solapan, así que esto no es una historia sobre ruido. Como cada brazo se puntúa sobre los mismos sesenta ítems, la pregunta más afilada es la emparejada: en los casos donde dos brazos discrepan, ¿qué tan desequilibrado está el reparto? Pasar del peor orden al mejor convirtió 21 casos en correctos y 4 en incorrectos: probabilidad emparejada exacta 0,0009.³

Lee la tabla por su forma, no por su ganador. Las dos mejores filas terminan con el ticket; las dos peores entierran la instrucción en medio o la arrastran después de los datos. Es el mismo fenómeno que Liu et al. llamaron Lost in the Middle: el material en los bordes de un prompt se usa con más fiabilidad que el material en el centro.⁴ El capítulo 16 pone precio a la ventana y el capítulo 24 mide el efecto correctamente en largo, donde el centro se hunde como se describe y la recuperación justo al final no reaparece. Aquí la regla práctica sale sola: tarea arriba, datos abajo, nada importante en medio.

Ahora mueve las mismas palabras entre turnos. El capítulo 11 estableció que la plantilla de chat no es decoración alrededor del modelo, sino parte de él: <|im_start|>system y <|im_start|>user son tokens reales que el modelo vio millones de veces durante el fine-tuning, exactamente en esas posiciones. Así que debería importar a qué lado de esos marcadores cae tu instrucción, y de hecho importa:

Mover las reglas y la instrucción al otro lado del límite de la plantilla compró 21,7 puntos —19 casos ganados, 6 perdidos, probabilidad emparejada 0,0146— sin cambiarles ni un carácter. Esta es la respuesta concreta a system prompt frente a user prompt: no son dos maneras de decir lo mismo. Son dos posiciones de token distintas en una estructura con la que se entrenó el modelo, y la posición del sistema es donde pertenecen las instrucciones que se aplican a toda la conversación.

Fíjate también en la tercera fila. Repetir la instrucción después del ticket —un truco ampliamente recomendado— puntuó por debajo de decirla una sola vez. En este modelo, en esta tarea, decirlo dos veces fue peor que decirlo una.

Mismo prompt, mejor colocación, sesenta casos. Lo único que cambia es lo que rodea el texto del ticket.

Dieciocho puntos de diferencia por puntuación. Pero mira los dos intervalos extremos: [73,9, 91,9] y [54,1, 77,3]. Se solapan. Según la lectura burda —compara las barras de error y, si se tocan, no digas nada— esta tabla no demuestra nada en absoluto.

La lectura burda aquí es incorrecta, y entender por qué vale más que la tabla. Cada variante se puntuó sobre los mismos sesenta tickets, así que las dos mediciones no son muestras independientes; están emparejadas. La mayor parte de la anchura de cada intervalo viene de una fuente de incertidumbre que ambos brazos comparten: si esos sesenta tickets son representativos. Y esa fuente se cancela cuando los comparas entre sí. Haz en cambio la pregunta emparejada y la respuesta es nítida: pasar de comillas dobles a la etiqueta XML convirtió 12 casos en correctos y 1 en incorrecto, probabilidad emparejada 0,0034. Esa es una diferencia real.

Y luego la misma prueba desinfla el titular. La etiqueta XML superó a la etiqueta simple Ticket: por 8,3 puntos, que es el número que un blog pondría en el título. Emparejado: 6 ganados, 1 perdido, probabilidad 0,1250. No establecido. Siete casos es todo lo que sostiene esa mejora famosa.

Así que hay dos preguntas con dos instrumentos distintos, y confundirlas es la forma en que los consejos sobre prompts se equivocan en ambas direcciones a la vez:

El hallazgo general —que los modelos son muy sensibles, y de forma impredecible, a elecciones de formato que no cargan contenido semántico— no es nuevo. Sclar et al. variaron solo separadores, espaciado y mayúsculas/minúsculas en decenas de tareas y encontraron dispersiones de precisión lo bastante amplias como para invertir rankings de modelos publicados.⁵ La consecuencia práctica no es «usa etiquetas XML». Es que el formato es un hyperparameter, no cuesta nada barrerlo, y cualquier comparación entre dos modelos que fija un formato compara formatos tanto como modelos.

In-context learning —mostrar al modelo ejemplos resueltos en el prompt y hacer que generalice a partir de ellos sin ninguna actualización de pesos— es la capacidad que hizo famoso a GPT-3.⁶ La pregunta práctica nunca es si funciona. Es cuántos ejemplos pagar.

Los ejemplos entran como turnos previos reales, alternando usuario y asistente, porque esa es la estructura con la que se entrenó la plantilla. Cada k se ejecutó con cinco extracciones aleatorias distintas de un pool disjunto de dieciséis tickets etiquetados:

Dos ejemplos compraron siete puntos. Los seis ejemplos siguientes no compraron nada medible: 83,7, luego 81,7, luego 83,7, una secuencia que deambula dentro de su propio ruido. Dieciséis compraron otros cinco puntos y medio. La curva no es una subida suave; es un escalón, una meseta y un escalón.

La columna que más importa es la última. En k = 8, qué ocho ejemplos elegiste por casualidad movió la precisión 10 puntos, más que toda la ganancia de pasar de dos ejemplos a ocho. Y la fila inferior es la versión más nítida: en k = 16 el pool se agota, así que las cinco ejecuciones contienen exactamente los mismos dieciséis ejemplos, con la única diferencia del orden en que aparecen. Solo el orden movió la precisión 8,3 puntos.

Ese es el resultado que reportaron Lu et al. y sobrevive allí donde se ha buscado: el orden de los ejemplos es un hyperparameter genuino con efectos comparables al número de ejemplos.⁷ Así que el consejo honesto sobre few-shot prompting no es un número. Es:

Ahora el folclore. Cada una de estas es una sola frase antepuesta a un system prompt que por lo demás es idéntico, sobre los mismos sesenta casos.

Cuatro de las cinco no hicieron nada. No «hicieron un poco»; nada que sesenta casos emparejados puedan ver. La persona experta y el soborno puntuaron ambos por debajo de la línea base intacta, e incluso esas caídas no superan la prueba emparejada: son ruido apuntando cuesta abajo.

La tercera fila es la que conviene digerir. «Esto es muy importante para mi carrera» produjo exactamente la misma precisión, 46 de 60, y cambiaron diez de las sesenta respuestas, cinco en cada dirección. La estadística resumen era idéntica y el comportamiento no. Si tu evaluación es un único número sobre un conjunto pequeño, un cambio que reescribe una sexta parte de tus salidas puede parecer un cambio que no hizo nada, y lo lanzarás creyendo que era gratis.

Y luego la amenaza, que es la única frase que movió la aguja y la movió 35 puntos hacia abajo, convirtiendo 24 casos de correctos a incorrectos. No es un artefacto de redondeo; es un comportamiento de modelo distinto. La lección no es «nunca amenaces a un modelo». Es que el encuadre emocional no es inerte. Desplaza la distribución, a veces con fuerza, en una dirección que nadie puede predecir leyendo la frase; precisamente por eso hay que medirlo en lugar de razonar sobre ello.

Una salvedad que este capítulo te debe: estas cinco frases se probaron en un modelo pequeño y una tarea. Algunas tienen respaldo publicado en otros sitios: «respira hondo» salió de un paper que buscó instrucciones con alta puntuación en vez de inventarlas, lo cual es una afirmación distinta y mejor que la que circuló después.⁸ Lo que generaliza no son las frases. Es que la lista que sobrevivió en posts de blog y la lista que sobrevive a la medición son dos listas distintas, y la única forma de saber cuál tienes delante es ejecutar el banco.

Una regla que todo el mundo repite —di lo que quieres, no lo que no quieres— con la ausencia habitual de un número. Aquí está el número. El mismo requisito de formato, escrito de tres formas, con el modelo generando libremente para que pueda observarse el cumplimiento:

Tres prohibiciones rindieron peor que una instrucción y llevaron al modelo a escribir cinco veces más texto: lo contrario exacto de las tres a la vez. Añadir de nuevo la frase positiva lo rescató hasta el 68 %.

El mecanismo no es misterioso si recuerdas el capítulo 8. El modelo elige un siguiente token de una distribución condicionada por todo lo anterior, y una prohibición mete lo prohibido dentro de ese condicionamiento. No hay un operador de negación; hay un contexto en el que ahora aparece una palabra.

Y eso se puede medir directamente. Toma el prompt base y añade una línea: Do not use the shipping queue for software problems. Luego mira solo los cuarenta y cinco tickets que no son de envíos:

Nombrar una cola para descartarla hizo que el modelo la eligiera tres veces más a menudo, casi triplicó la masa de probabilidad que le asignaba y costó 25 puntos de precisión global: 16 casos perdidos frente a 1 ganado, probabilidad emparejada 0,0003.

No pienses en un elefante, medido. La reescritura es siempre la misma: sustituye la prohibición por la regla positiva que la vuelve innecesaria. No «no uses envíos para problemas de software», sino «usa envíos solo cuando haya un paquete físico implicado».

El capítulo 12 construyó chain of thought correctamente —primero como técnica de prompting,⁹¹⁰ luego como algo entrenado con recompensas verificables— y terminó con una advertencia que aplazó hasta este capítulo: decirle a un modelo que piense paso a paso deja de ayudar cuando el modelo razona por sí solo, y puede perjudicar. Aquí está esa advertencia con una tabla debajo, en una tarea donde es fácil asumir que pensar más debe ser mejor.

Ambos brazos se leen con el mismo instrumento en la misma posición. La única diferencia es si una chain of thought que escribió el propio modelo se sienta antes en el contexto.

La precisión bajó y el coste subió, y la propia regla de este capítulo se aplica al propio resultado de este capítulo: la caída es 7 casos ganados frente a 10 perdidos, probabilidad emparejada 0,629, lo que no queda establecido. Lo que sí queda establecido es que produjo noventa y ocho tokens de salida extra por llamada y no compró nada medible con ellos. La incertidumbre está por completo en el lado del beneficio. La factura es segura.

Una cadena que falla enseña más que una que funciona. Al pedirle que razonara sobre «Tu integración de Slack dejó de publicar mensajes después del martes», el modelo escribió:

1. Check if the issue persists on Monday.
2. Verify if there are any updates or changes in your Slack setup that
   might affect message posting.
3. If no update has been made since Tuesday, check for any recent system
   restarts or downtime affecting Slack functionality.
4. If you have recently installed new software or updated your
   environment, ensure it's compatible with Slack version.
5. Contact Slack support for further assistance or troubleshooting steps.

Eso es un consejo competente de resolución de problemas y no es la tarea. Cuando se le pidió pensar, el modelo derivó hacia el género al que más se parece «piensa paso a paso sobre este ticket de soporte» en sus datos de entrenamiento, y luego respondió a una pregunta de clasificación con quinientos caracteres de razonamiento no relacionado en su propio contexto. Chain of thought ayuda en problemas con estado intermedio que merece la pena calcular: aritmética, búsquedas de varios saltos, satisfacción de restricciones. Enrutar una frase a uno de cuatro cubos no tiene estado intermedio. No hay nada que la cadena deba sostener, así que lo único que hace es añadir texto plausible que la decisión final tiene que sobrevivir.

Dos corolarios prácticos. Primero, para un modelo entrenado para razonar —los modelos RLVR del capítulo 12— la instrucción es peor que redundante: puede sustituir la cadena larga que el modelo habría producido por una corta, con forma de prompt. Y muestrear varias cadenas y votar, que es lo que hace self-consistency,¹¹ no puede rescatar una tarea sin nada sobre lo que discrepar: multiplica el coste por el número de muestras para deshacer empates que no existen. El capítulo 12 midió ese intercambio donde sí aplica. Segundo, fíjate en lo que costó el propio andamiaje de comparación. Forzar la respuesta a una línea Final queue: bajó el brazo sin razonamiento del 76,7 % al 61,7 %. Quince puntos, pagados para hacer comparables los dos brazos. La estructura que existe para tu comodidad tampoco es gratis.

Una última medición, porque es la pregunta que todo el mundo hace después del primer resultado sorprendente. Sesenta prompts, greedy decoding, ejecutados repetidamente:

• La misma llamada repetida con todo fijo devolvió probabilidades idénticas bit a bit. Determinista.
• La misma llamada agrupada en batch con vecinos distintos —tamaños de batch 1, 4, 12, 30 y 60— devolvió probabilidades que diferían hasta 0,0128. La etiqueta elegida no cambió nunca, en 0 de 60 casos.

La etiqueta sobrevivió porque tenía margen: entre los sesenta casos, la brecha más estrecha entre las dos colas principales fue 0,0459, tres veces y media la deriva. La estabilidad no era una propiedad del algoritmo. Era un margen, y los márgenes se acaban. El capítulo 17 es donde vive la razón aritmética y donde se desmontan los mandos de muestreo que ensanchan y estrechan esas brechas. La razón para plantarlo aquí es que limita lo que puede significar cualquier medición de prompts: el banco mide un sistema reproducible solo hasta una tolerancia, y una diferencia de dos puntos entre variantes cae dentro de esa tolerancia en un mal día.

Todo lo anterior es un humano eligiendo una variante y una máquina puntuándola. El siguiente paso obvio es dejar que la máquina elija también las variantes.

APE hace exactamente eso: un modelo propone instrucciones candidatas, se puntúan sobre ejemplos retenidos y las mejores sobreviven.⁸ Las instrucciones que encuentra a menudo son cosas que ningún humano escribiría, que es precisamente la cuestión: la búsqueda es sobre lo que puntúa, no sobre lo que suena profesional.

DSPy va más lejos y es la idea más útil para un producto.¹² Declaras qué toma y devuelve cada paso de un pipeline, y el framework lo compila en prompts, selecciona demostraciones y optimiza instrucciones contra tu métrica. Cambias de modelo y recompilas en lugar de reescribir. El prompt deja de ser código fuente que alguien ajusta a mano y se convierte en un artefacto generado contra una métrica, que es lo que debería haber sido desde el principio.

Ninguno elimina la necesidad del banco. Ambos lo convierten en lo único que necesitas, porque un optimizador sin métrica no optimiza nada.

Queda la disciplina. Los prompts pertenecen al control de versiones, en archivos, junto al código que los envía; no en una fila de base de datos que alguien editó un martes. Necesitan un identificador de versión almacenado junto a cada salida que produjeron, o el día que algo regrese no podrás averiguar qué cambió. Necesitan el banco en integración continua, porque un prompt es la única parte de tu sistema que un proveedor puede invalidar en silencio desplegando un modelo nuevo. Y necesitan casos: no cien casos ingeniosos, solo los veinte aburridos que se rompieron el trimestre pasado, guardados para siempre. El banco es el entregable. El prompt es un subproducto suyo.

Todo lo de este capítulo se midió en precisión. Cada una de esas variantes también tiene un precio.

El system prompt que compró 21,7 puntos se envía en cada llamada, para siempre. Los dos ejemplos que compraron siete puntos se envían en cada llamada, para siempre. Los dieciséis que compraron doce se envían en cada llamada, para siempre, y son aproximadamente diez veces más largos que la pregunta que hizo realmente el usuario. La chain of thought que no compró nada produjo noventa y ocho tokens extra por petición, y los tokens de salida son los caros.

Nada de eso es visible en una tabla de precisiones, y todo es visible en una factura.

El capítulo 16 trata de la unidad en la que realmente se denominan esas decisiones. El token como unidad de facturación, la context window como presupuesto en lugar de memoria, por qué una conversación de cuarenta turnos cuesta mucho más que cuarenta veces el primer turno, qué paga y qué no paga el prompt caching, y por qué el orden de tu prompt decide si la caché acierta siquiera; lo que resulta ser una segunda razón, totalmente económica, para poner primero el material estable y al final el material variable.

El banco y todas las tablas se produjeron con Qwen/Qwen2.5-0.5B-Instruct bajo greedy decoding, así que se reproducen exactamente. La documentación de Hugging Face sobre plantillas de chat es la referencia de a qué se expanden realmente los marcadores de plantilla del capítulo 11, y del hecho de que un modelo enviado con la plantilla equivocada es un fallo real y recurrente. Para los efectos de posición y formato a escala de producción en lugar de escala de laboratorio, las citas anteriores son las fuentes primarias; las guías de prompting de los proveedores son útiles por sus ejemplos y conviene leerlas sabiendo que ninguna publica un intervalo.