Prompt engineering, medido: que cambia a saída

Antes das medicións, un feito que explica discretamente a metade do que vén.

O modelo non ten memoria. Entre dúas chamadas non conserva nada: nin a túa última pregunta, nin a súa última resposta, nin o ficheiro que anexaches, nin o feito de que xa llo preguntaras dúas veces. Cada chamada comeza nunha máquina baleira, e o único que esa máquina sabe é a secuencia de tokens que acabas de lle entregar.

O que parece memoria nunha interface de chat é o teu cliente reenviando toda a conversa, cada quenda, desde o principio. O modelo volve lelo todo desde cero, cada vez. O capítulo 13 mediu o que custa esa relectura nun forward pass; o capítulo 16 convérteo nunha liña da factura. O que importa aquí é a consecuencia para o deseño: o prompt non é unha mensaxe para un sistema que ten estado. É o estado.

Iso retira unha familia de confusións. «O modelo esqueceu o que lle dixen» adoita significar que nunca se lle enviou. «Ignorou a miña instrución anterior» adoita significar que a instrución caeu fóra da ventá cando se truncou o historial. «Comportouse distinto en produción» adoita significar que produción monta un prompt distinto do que probaches. Ningún destes é un problema do modelo, e ningún se arranxa reescribindo nada.

A afirmación «este prompt é mellor» é unha afirmación sobre unha distribución, e non podes ver unha distribución mirando unha soa saída. O que precisas é aburrido: casos con respostas coñecidas, N variantes e un intervalo.

O harness son cincuenta liñas de TypeScript coa mesma forma ca o cliente do capítulo 14: unha solicitude, un prazo, algo de concorrencia, un reconto. Reaparece no capítulo 19 para avaliar un retriever e no 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 };
}

O número que volve non é o resultado. Isto si:

/** 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;
}

O capítulo 4 formulou o argumento e este capítulo cóbrao. Dezasete acertos de vinte son 85 %, e o seu intervalo do 95 % vai do 64 % ao 95 %. Unha variante que acada 13 de 20 —65 %, que parece claramente peor— ten un intervalo do 43 % ao 82 %. Eses dous intervalos solápanse en case toda a súa lonxitude. Vinte casos non poden distinguir un bo prompt dun mediocre, e a maior parte dos consellos publicados sobre prompts validouse con menos.

Sesenta casos, que é o que usa este capítulo, seguen sen ser moitos. Son suficientes para ver efectos grandes e o bastante honestos para admitir cando non pode ver os pequenos; e admitirao varias veces máis abaixo.

Tres bloques —as regras R, o ticket T, a instrución I— concatenados nunha mensaxe de usuario. As seis permutacións, contido idéntico byte a byte, sesenta casos cada unha.

Do mellor ao peor hai 28,3 puntos, e os intervalos non se solapan, así que isto non é unha historia sobre ruído. Como cada brazo se puntúa cos mesmos sesenta elementos, a pregunta máis precisa é a emparellada: nos casos nos que dous brazos discrepan, que tan desequilibrado é o reparto? Pasar da peor orde á mellor cambiou 21 casos a correcto e 4 a incorrecto: probabilidade emparellada exacta 0,0009.³

Le a táboa pola súa forma, non polo seu gañador. As dúas mellores filas rematan co ticket; as dúas peores soterran a instrución no medio ou déixana despois dos datos. É o mesmo fenómeno que Liu et al. chamaron Lost in the Middle: o material nos bordos dun prompt úsase con máis fiabilidade ca o material no centro.⁴ O capítulo 16 pon prezo á ventá e o capítulo 24 mide o efecto correctamente en lonxitude, onde o medio colapsa como se describe e a recuperación ao final de todo non reaparece. Aquí a regra práctica sae soa: tarefa arriba, datos abaixo, nada importante no medio.

Agora move as mesmas palabras entre quendas. O capítulo 11 estableceu que o template de chat non é decoración arredor do modelo senón parte del: <|im_start|>system e <|im_start|>user son tokens reais que o modelo viu millóns de veces durante fine-tuning, exactamente nesas posicións. Así que debería importar de que lado deses marcadores cae a túa instrución, e importa:

Mover as regras e a instrución a través da fronteira do template comprou 21,7 puntos —19 casos gañados, 6 perdidos, probabilidade emparellada 0,0146— sen cambiarlles un carácter. Esta é a resposta concreta a system prompt fronte a user prompt: non son dúas maneiras de dicir o mesmo. Son dúas posicións de token distintas nunha estrutura na que o modelo foi adestrado, e a posición de sistema é onde pertencen as instrucións que se aplican a toda a conversa.

Fíxate tamén na terceira fila. Repetir a instrución despois do ticket —un truco amplamente recomendado— puntuou por debaixo de dicila unha vez. Neste modelo, nesta tarefa, dicilo dúas veces foi peor ca dicilo unha.

O mesmo prompt, a mellor colocación, sesenta casos. O único que cambia é o que rodea o texto do ticket.

Unha dispersión de dezaoito puntos por puntuación. Pero mira os dous intervalos extremos: [73,9, 91,9] e [54,1, 77,3]. Solápanse. Coa lectura basta —comparar as barras de erro, e se se tocan, non dicir nada— esta táboa non proba absolutamente nada.

A lectura basta aquí está equivocada, e entender por que vale máis ca a táboa. Cada variante puntuouse nos mesmos sesenta tickets, así que as dúas medicións non son mostras independentes; están emparelladas. A maior parte da anchura de cada intervalo vén dunha fonte de incerteza compartida polos dous brazos: se estes sesenta tickets son representativos. Esa fonte cancélase cando os comparas entre si. Fai a pregunta emparellada e a resposta é nítida: pasar das comiñas dobres á etiqueta XML cambiou 12 casos a correcto e 1 a incorrecto, probabilidade emparellada 0,0034. Iso é unha diferenza real.

E despois a mesma proba desinfla o titular. A etiqueta XML superou a etiqueta simple Ticket: por 8,3 puntos, que é o número que unha publicación de blog poñería no título. Emparellado: 6 gañados, 1 perdido, probabilidade 0,1250. Non establecido. Sete casos é o que sostén esa mellora famosa.

Así que hai dúas preguntas con dous instrumentos distintos, e mesturalas é como os consellos sobre prompts se equivocan nas dúas direccións á vez:

O achado xeral —que os modelos son forte e imprevisiblemente sensibles a escollas de formato sen contido semántico— non é novo. Sclar et al. variaron só separadores, espazado e maiúsculas/minúsculas en ducias de tarefas e atoparon dispersións de precisión o bastante amplas como para inverter rankings publicados de modelos.⁵ A consecuencia práctica non é «usa etiquetas XML». É que o formato é un hiperparámetro, non custa nada varrelo, e calquera comparación de dous modelos que fixa un formato compara formatos tanto como modelos.

In-context learning —mostrar ao modelo exemplos resoltos no prompt e facer que xeneralice a partir deles sen ningunha actualización de pesos— é a capacidade que fixo famoso a GPT-3.⁶ A pregunta práctica nunca é se funciona. É cantos exemplos pagar.

Os exemplos entran como quendas previas reais, alternando usuario e assistant, porque esa é a estrutura na que se adestrou o template. Cada k executouse con cinco extraccións aleatorias distintas dun pool disxunto de dezaseis tickets etiquetados:

Dous exemplos compraron sete puntos. Os seis seguintes non compraron nada medible: 83,7, logo 81,7, logo 83,7, unha secuencia que deambula dentro do seu propio ruído. Dezaseis compraron outros cinco e medio. A curva non é unha subida suave; é un chanzo, unha meseta e outro chanzo.

A columna que máis importa é a última. En k = 8, que oito exemplos che tocaron moveu a precisión 10 puntos: máis ca toda a ganancia de pasar de dous exemplos a oito. E a fila inferior é a versión máis clara: en k = 16 o pool está esgotado, así que as cinco execucións conteñen exactamente os mesmos dezaseis exemplos, que só difiren na orde na que aparecen. Só a orde moveu a precisión 8,3 puntos.

Ese é o resultado que informaron Lu et al. e sobrevive en todas partes onde se buscou: a orde dos exemplos é un hiperparámetro real con efectos comparables ao número de exemplos.⁷ Así que o consello honesto sobre few-shot prompting non é un número. É:

Agora o folclore. Cada unha destas é unha soa frase engadida ao comezo dun system prompt que polo demais é idéntico, nos mesmos sesenta casos.

Catro das cinco non fixeron nada. Non «fixeron un pouco»; nada que sesenta casos emparellados poidan ver. A persoa experta e o suborno puntuaron por debaixo da liña base intacta, e mesmo esas baixadas fallan a proba emparellada: son ruído apuntando costa abaixo.

A terceira fila é a que cómpre observar. «Isto é moi importante para a miña carreira» produciu exactamente a mesma precisión, 46 de 60, e cambiaron dez das sesenta respostas, cinco en cada dirección. A estatística resumo era idéntica e o comportamento non. Se a túa avaliación é un único número sobre un conxunto pequeno, un cambio que reescribe unha sexta parte das túas saídas pode parecer un cambio que non fixo nada, e lanzaralo crendo que era gratis.

E logo a ameaza, que é a única frase que moveu a agulla e moveuna 35 puntos cara abaixo, cambiando 24 casos de correcto a incorrecto. Iso non é un artefacto de arredondamento; é un comportamento distinto do modelo. A lección non é «nunca ameaces un modelo». É que o encadre emocional non é inerte. Despraza a distribución, ás veces con forza, nunha dirección que ninguén pode predicir lendo a frase; precisamente por iso hai que medilo en vez de razoalo.

Unha cautela que este capítulo che debe: estas cinco frases probáronse nun modelo pequeno e nunha tarefa. Algunhas teñen apoio publicado noutros lugares: «respira fondo» saíu dun artigo que buscou instrucións de alta puntuación en vez de inventalas, que é unha afirmación distinta e mellor ca a que circulou despois.⁸ O que xeneraliza non son as frases. É que a lista que sobreviviu nas publicacións de blog e a lista que sobrevive á medición son dúas listas distintas, e a única maneira de saber cal tes nas mans é executar o banco.

Unha regra que todo o mundo repite —di o que queres, non o que non queres— coa ausencia habitual dun número. Aquí está o número. O mesmo requisito de formato, escrito de tres maneiras, co modelo xerando libremente para poder observar o cumprimento:

Tres prohibicións foron peor ca unha instrución, e fixeron que o modelo escribise cinco veces máis texto: exactamente o contrario das tres á vez. Engadir de volta a frase positiva rescatouno ata o 68 %.

O mecanismo non é misterioso cando lembras o capítulo 8. O modelo escolle un seguinte token dunha distribución condicionada por todo o anterior, e unha prohibición pon a cousa prohibida dentro dese condicionamento. Non hai un operador para a negación; hai un contexto no que unha palabra agora aparece.

O cal é medible directamente. Toma o prompt de referencia e engade unha liña: Do not use the shipping queue for software problems. Despois mira só os corenta e cinco tickets que non son de envíos:

Nomear unha cola para descartala fixo que o modelo a escollese tres veces máis a miúdo, case triplicou a masa de probabilidade que lle asignou e custou 25 puntos de precisión global: 16 casos perdidos contra 1 gañado, probabilidade emparellada 0,0003.

Non penses nun elefante, medido. A reescritura é sempre a mesma: substitúe a prohibición pola regra positiva que a fai innecesaria. Non «non uses envíos para problemas de software», senón «usa envíos só cando haxa un paquete físico implicado».

O capítulo 12 construíu chain of thought correctamente —como técnica de prompting primeiro,⁹¹⁰ logo como algo adestrado con recompensas verificables— e rematou cun aviso que diferiu a este capítulo: dicirlle a un modelo que pense paso a paso deixa de axudar cando o modelo razoa pola súa conta, e pode prexudicar. Aquí está ese aviso cunha táboa debaixo, nunha tarefa onde é doado supoñer que pensar máis ten que ser mellor.

Ambos brazos lense co mesmo instrumento na mesma posición. A única diferenza é se unha chain of thought que o modelo escribiu por si mesmo está antes no contexto.

A precisión baixou e o custo subiu, e a propia regra deste capítulo aplícase ao seu propio resultado: a baixada é 7 casos gañados contra 10 perdidos, probabilidade emparellada 0,629, o que non queda establecido. O que si queda establecido é que produciu noventa e oito output tokens extra por chamada e non comprou nada medible con eles. A incerteza está enteiramente no lado do beneficio. A factura é certa.

Unha cadea que falla ensina máis ca unha que funciona. Cando se lle pediu razoar sobre «A túa integración con Slack deixou de publicar mensaxes despois do martes», o modelo escribiu:

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.

Iso é bo consello de resolución de problemas e non é a tarefa. Cando se lle pediu pensar, o modelo derivou cara ao xénero ao que máis se parece «pensa paso a paso sobre este ticket de soporte» nos seus datos de adestramento, e despois respondeu unha pregunta de clasificación con cincocentos caracteres de razoamento alleo dentro do seu propio contexto. Chain of thought axuda en problemas con estado intermedio que paga a pena computar: aritmética, buscas multi-hop, satisfacción de restricións. Enroutar unha frase a un de catro caixóns non ten estado intermedio. Non hai nada que a cadea teña que soster, así que o único que fai é engadir texto plausible que a decisión final logo ten que sobrevivir.

Dous corolarios prácticos. Primeiro, para un modelo adestrado para razoar —os modelos RLVR do capítulo 12— a instrución é peor ca redundante: pode substituír a cadea longa que o modelo produciría por unha curta con forma de prompt. E mostrear varias cadeas e votar, que é o que fai self-consistency,¹¹ non pode rescatar unha tarefa sen nada sobre o que discrepar: multiplica o custo polo número de mostras para desempatar empates que non existen. O capítulo 12 mediu esa troca onde si se aplica. Segundo, observa o que custou a propia armazón de comparación. Forzar a resposta nunha liña Final queue: baixou o brazo sen razoamento de 76,7 % a 61,7 %. Quince puntos, pagados para facer comparables os dous brazos. A estrutura que existe para a túa comodidade tampouco é gratis.

Unha última medición, porque é a pregunta que todo o mundo fai despois do primeiro resultado sorprendente. Sesenta prompts, decodificación greedy, executados repetidamente:

• A mesma chamada repetida mantendo todo fixo devolveu probabilidades idénticas bit a bit. Determinista.
• A mesma chamada batch con veciños distintos —tamaños de batch 1, 4, 12, 30 e 60— devolveu probabilidades que diferían ata 0,0128. A etiqueta escollida nunca cambiou, en 0 de 60 casos.

A etiqueta sobreviviu porque tiña marxe: nos sesenta casos, a brecha máis estreita entre as dúas colas superiores foi 0,0459, tres veces e media a deriva. A estabilidade non era unha propiedade do algoritmo. Era unha marxe, e as marxes esgótanse. O capítulo 17 é onde vive a razón aritmética e onde se desmontan os controis de mostraxe que amplían e estreitan esas brechas. A razón para plantalo aquí é que limita o que pode significar calquera medición de prompt: o banco mide un sistema reproducible só ata unha tolerancia, e unha diferenza de dous puntos entre variantes está dentro desa tolerancia nun mal día.

Todo o anterior é unha persoa escollendo unha variante e unha máquina puntuándoa. O seguinte paso obvio é deixar que a máquina escolla tamén as variantes.

APE fai exactamente iso: un modelo propón instrucións candidatas, puntúanse en exemplos reservados e sobreviven as mellores.⁸ As instrucións que atopa adoitan ser cousas que ningún humano escribiría, e ese é o punto: a busca é sobre o que puntúa, non sobre o que soa profesional.

DSPy vai máis alá e é a idea máis útil para un produto.¹² Declaras que toma e devolve cada paso dun pipeline, e o framework compílao en prompts, seleccionando demostracións e optimizando instrucións contra a túa métrica. Cambias de modelo e recompilas en vez de reescribir. O prompt deixa de ser código fonte que alguén axusta á man e convértese nun artefacto xerado contra unha métrica, que é o que debería ter sido desde o principio.

Ningún elimina a necesidade do banco. Ambos fan que sexa o único que precisas, porque un optimizador sen métrica non optimiza nada.

O que queda é a disciplina. Os prompts pertencen ao control de versións, en ficheiros, xunto ao código que os envía; non nunha fila de base de datos que alguén editou un martes. Precisan un identificador de versión gardado xunto a cada saída que produciron, ou o día que algo regresa non poderás descubrir que cambiou. Precisan o banco en integración continua, porque un prompt é a parte do teu sistema que un provedor pode invalidar en silencio ao despregar un modelo novo. E precisan casos: non cen casos enxeñosos, só os vinte aburridos que romperon o trimestre pasado, gardados para sempre. O banco é o entregable. O prompt é un subproduto del.

Todo neste capítulo mediuse en precisión. Cada unha desas variantes tamén ten un prezo.

O system prompt que comprou 21,7 puntos envíase en cada chamada, para sempre. Os dous exemplos que compraron sete puntos envíanse en cada chamada, para sempre. Os dezaseis que compraron doce envíanse en cada chamada, para sempre, e teñen aproximadamente dez veces a lonxitude da pregunta que o usuario fixo en realidade. A chain of thought que non comprou nada produciu noventa e oito tokens extra por solicitude, e os output tokens son os caros.

Nada diso é visible nunha táboa de precisións, e todo iso é visible nunha factura.

O capítulo 16 trata da unidade na que esas decisións están realmente denominadas. O token como unidade de facturación, a context window como orzamento e non como memoria, por que unha conversa de corenta quendas custa moito máis ca corenta veces a primeira quenda, que paga e que non paga prompt caching, e por que a orde do teu prompt decide se a caché acerta ou non; que resulta ser unha segunda razón, totalmente económica, para poñer primeiro o material estable e por último o material variable.

O banco e todas as táboas producíronse con Qwen/Qwen2.5-0.5B-Instruct baixo decodificación greedy, así que se reproducen exactamente. A documentación de Hugging Face sobre templates de chat é a referencia para o que realmente expanden os marcadores de template do capítulo 11, e para o feito de que un modelo que se distribúe co template equivocado é un fallo real e recorrente. Para os efectos de posición e formato a escala de produción e non de laboratorio, as citas anteriores son as fontes primarias; as guías de prompting dos provedores son útiles polos seus exemplos e deberían lerse sabendo que ningunha delas publica un intervalo.