Prompt engineering, mesurat: què canvia la sortida

Abans de les mesures, un fet que explica en silenci la meitat del que ve després.

El model no té memòria. Entre dues crides no reté res: ni la teva última pregunta, ni la seva última resposta, ni el fitxer que has adjuntat, ni el fet que ja l’hi hagis demanat dues vegades. Cada crida comença des d’una màquina buida, i l’única cosa que aquesta màquina sap és la seqüència de tokens que li acabes de donar.

Allò que sembla memòria en una interfície de xat és el teu client reenviant tota la conversa, cada torn, des del principi. El model ho torna a llegir tot des de zero, cada vegada. El Capítol 13 va mesurar què costa aquesta relectura en una passada endavant; el Capítol 16 ho converteix en una línia d’una factura. El que importa aquí és la conseqüència per al disseny: el prompt no és un missatge a un sistema que té estat. És l’estat.

Això jubila tota una família de confusions. «El model ha oblidat el que li havia dit» normalment vol dir que mai se li va enviar. «Ha ignorat la meva instrucció anterior» normalment vol dir que la instrucció va caure fora de la finestra quan es va truncar l’historial. «S’ha comportat diferent en producció» normalment vol dir que producció munta un prompt diferent del que vas provar. Res d’això és un problema del model, i res d’això s’arregla reescrivint res.

L’afirmació «aquest prompt és millor» és una afirmació sobre una distribució, i no pots veure una distribució mirant una sola sortida. El que necessites és avorrit: casos amb respostes conegudes, N variants i un interval.

El harness són cinquanta línies de TypeScript amb la mateixa forma que el client del Capítol 14: una petició, un termini, una mica de concurrència, un recompte. Reapareix al Capítol 19 per avaluar un recuperador i al Capítol 29 com a conjunt daurat.

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 torna no és el resultat. Això 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ítol 4 va construir l’argument i aquest capítol el cobra. Disset encerts de vint són un 85 %, i el seu interval del 95 % va del 64 % al 95 %. Una variant que puntua 13 de 20 —65 %, que sembla clarament pitjor— té un interval del 43 % al 82 %. Aquests dos intervals se superposen gairebé en tota la seva longitud. Vint casos no poden distingir un bon prompt d’un de mediocre, i la majoria de consells publicats sobre prompt es van validar amb menys.

Seixanta casos, que és el que fa servir aquest capítol, encara no són gaires. Són prou per veure efectes grans i prou honestos per admetre quan no poden veure’n de petits —i ho admetrà diverses vegades més avall.

Tres blocs —les regles R, el tiquet T, la instrucció I— concatenats en un sol missatge d’usuari. Totes sis permutacions, contingut idèntic byte a byte, seixanta casos cadascuna.

Del millor al pitjor hi ha 28,3 punts, i els intervals no se superposen, així que això no és una història sobre soroll. Com que cada braç es puntua sobre els mateixos seixanta elements, la pregunta més esmolada és la parellada: dels casos en què dos braços discrepen, com de desequilibrat és el repartiment? Passar del pitjor ordre al millor va capgirar 21 casos cap a encert i 4 cap a error: probabilitat parellada exacta 0,0009.³

Llegeix la taula per la seva forma més que pel guanyador. Les dues millors files totes dues acaben amb el tiquet; les dues pitjors totes dues enterren la instrucció al mig o la deixen després de les dades. És el mateix fenomen que Liu et al. van anomenar Lost in the Middle: el material als extrems d’un prompt s’utilitza amb més fiabilitat que el material del centre.⁴ El Capítol 16 posa preu a la finestra i el Capítol 24 mesura l’efecte correctament a llargada, on el mig col·lapsa tal com es descriu i la recuperació al final de tot no reapareix. Aquí la regla pràctica cau sola: tasca a dalt, dades a baix, res important al mig.

Ara mou les mateixes paraules entre torns. El Capítol 11 va establir que la plantilla de xat no és decoració al voltant del model sinó part del model: <|im_start|>system i <|im_start|>user són tokens reals que el model va veure milions de vegades durant el fine-tuning, exactament en aquestes posicions. Així que hauria d’importar a quin costat d’aquests marcadors cau la teva instrucció, i importa:

Moure les regles i la instrucció a través de la frontera de la plantilla va comprar 21,7 punts —19 casos guanyats, 6 perduts, probabilitat parellada 0,0146— sense canviar-ne ni un caràcter. Aquesta és la resposta concreta a system prompt versus user prompt: no són dues maneres de dir la mateixa cosa. Són dues posicions de token diferents en una estructura amb què el model va ser entrenat, i la posició de sistema és on pertanyen les instruccions que s’apliquen a tota la conversa.

Fixa’t també en la tercera fila. Repetir la instrucció després del tiquet —un truc molt recomanat— va puntuar per sota de dir-la una vegada. En aquest model, en aquesta tasca, dir-ho dues vegades va ser pitjor que dir-ho una.

Mateix prompt, millor col·locació, seixanta casos. L’únic que canvia és què envolta el text del tiquet.

Una dispersió de divuit punts per puntuació. Però mira els dos intervals extrems: [73,9, 91,9] i [54,1, 77,3]. Se superposen. Amb la lectura barroera —compara les barres d’error i, si es toquen, no diguis res— aquesta taula no prova absolutament res.

La lectura barroera aquí és equivocada, i entendre per què val més que la taula. Cada variant es va puntuar sobre els mateixos seixanta tiquets, així que les dues mesures no són mostres independents; són parellades. La major part de l’amplada de cada interval ve d’una font d’incertesa que tots dos braços comparteixen —si aquests seixanta tiquets són representatius— i aquesta font es cancel·la quan els compares entre ells. Fes la pregunta parellada en lloc d’això i la resposta és nítida: passar de cometes dobles a l’etiqueta XML va capgirar 12 casos cap a encert i 1 cap a error, probabilitat parellada 0,0034. És una diferència real.

I després la mateixa prova desinfla el titular. L’etiqueta XML va superar l’etiqueta plana Ticket: per 8,3 punts, que és el número que un blog posaria al títol. Parellat: 6 guanyats, 1 perdut, probabilitat 0,1250. No establert. Set casos és tot el que sosté aquella famosa millora.

Per tant hi ha dues preguntes amb dos instruments diferents, i confondre-les és com els consells sobre prompt s’equivoquen en totes dues direccions alhora:

La conclusió general —que els models són fortament i imprevisiblement sensibles a eleccions de format que no porten contingut semàntic— no és nova. Sclar et al. van variar només separadors, espaiat i majúscules/minúscules en desenes de tasques i van trobar dispersions de precisió prou àmplies per invertir rànquings de models publicats.⁵ La conseqüència pràctica no és «fes servir etiquetes XML». És que el format és un hiperparàmetre, no costa res d’escombrar, i qualsevol comparació de dos models que fixa un format compara formats tant com models.

L’aprenentatge in-context —mostrar al model exemples resolts dins del prompt i fer que generalitzi a partir d’ells sense cap actualització de pesos— és la capacitat que va fer famós GPT-3.⁶ La pregunta pràctica mai no és si funciona. És quants exemples vols pagar.

Els exemples entren com a torns previs reals, alternant usuari i assistant, perquè aquesta és l’estructura amb què es va entrenar la plantilla. Cada k es va executar amb cinc seleccions aleatòries diferents d’un conjunt separat de setze tiquets etiquetats:

Dos exemples van comprar set punts. Els sis exemples següents no van comprar res de mesurable: 83,7, després 81,7, després 83,7, una seqüència que vaga dins del seu propi soroll. Setze en van comprar cinc i mig més. La corba no és una pujada suau; és un esglaó, un altiplà i un esglaó.

La columna que més importa és l’última. A k = 8, quins vuit exemples vas acabar triant va moure la precisió 10 punts: més que tot el guany de passar de dos exemples a vuit. I la fila inferior n’és la versió més clara: a k = 16 el conjunt s’esgota, de manera que les cinc execucions contenen exactament els mateixos setze exemples, i només difereixen en l’ordre en què apareixen. Només l’ordre va moure la precisió 8,3 punts.

Aquest és el resultat que van reportar Lu et al. i sobreviu arreu on s’ha buscat: l’ordre dels exemples és un hiperparàmetre genuí amb efectes comparables al recompte d’exemples.⁷ Així que el consell honest sobre few-shot prompting no és un número. És:

Ara, el folklore. Cadascuna d’aquestes és una sola frase afegida al principi d’un system prompt que, per la resta, és idèntic, sobre els mateixos seixanta casos.

Quatre de cinc no van fer res. No «una mica»; res que seixanta casos parellats puguin veure. La persona experta i el suborn tots dos van puntuar per sota de la línia base intacta, i fins i tot aquestes caigudes fallen la prova parellada: són soroll apuntant avall.

La tercera fila és la que cal pair. «Això és molt important per a la meva carrera» va produir exactament la mateixa precisió, 46 de 60, i deu de les seixanta respostes van canviar, cinc en cada direcció. L’estadístic resum era idèntic i el comportament no. Si la teva avaluació és un sol número sobre un conjunt petit, un canvi que reescriu una sisena part de les sortides pot semblar un canvi que no ha fet res, i l’enviaràs a producció creient que era gratis.

I després l’amenaça, que és l’única frase que va moure l’agulla i la va moure 35 punts avall, capgirant 24 casos d’encert a error. Això no és un artefacte d’arrodoniment; és un comportament de model diferent. La lliçó no és «no amenacis mai un model». És que l’emmarcament emocional no és inert. Desplaça la distribució, de vegades amb força, en una direcció que ningú no pot predir llegint la frase, que és exactament per què s’ha de mesurar en lloc de raonar-hi.

Una advertència que aquest capítol et deu: aquestes cinc frases es van provar en un model petit i una tasca. Algunes tenen suport publicat en altres llocs: «respira profundament» va sortir d’un article que buscava instruccions amb puntuació alta en lloc d’inventar-les, que és una afirmació diferent i millor que la que va circular després.⁸ El que generalitza no són les frases. És que la llista que va sobreviure als blogs i la llista que sobreviu a la mesura són dues llistes diferents, i l’única manera de saber quina tens a les mans és executar el bench.

Una regla que tothom repeteix —digues què vols, no què no vols— amb l’absència habitual d’un número. Aquí tens el número. El mateix requisit de format, escrit de tres maneres, amb el model generant lliurement perquè se’n pugui observar el compliment:

Tres prohibicions van anar pitjor que una instrucció, i van fer que el model escrivís cinc vegades més text: exactament el contrari de totes tres alhora. Afegir de nou la frase positiva ho va rescatar fins al 68 %.

El mecanisme no és misteriós un cop recordes el Capítol 8. El model tria un token següent d’una distribució condicionada per tot el que ve abans, i una prohibició posa la cosa prohibida dins d’aquest condicionament. No hi ha cap operador per a la negació; hi ha un context en què ara apareix una paraula.

Això es pot mesurar directament. Agafa el prompt de línia base i afegeix una línia: Do not use the shipping queue for software problems. Després mira només els quaranta-cinc tiquets que no són tiquets d’enviament:

Anomenar una cua per descartar-la va fer que el model la triés tres vegades més sovint, gairebé va triplicar la massa de probabilitat que li assignava, i va costar 25 punts de precisió global: 16 casos perduts contra 1 guanyat, probabilitat parellada 0,0003.

No pensis en un elefant, mesurat. La reescriptura sempre és la mateixa: substitueix la prohibició per la regla positiva que la fa innecessària. No «no facis servir enviament per a problemes de programari», sinó «fes servir enviament només quan hi hagi un paquet físic implicat».

El Capítol 12 va construir chain of thought correctament —primer com a tècnica de prompting,⁹¹⁰ després com una cosa entrenada amb recompenses verificables— i va acabar amb una advertència que va ajornar fins a aquest capítol: dir a un model que pensi pas a pas deixa d’ajudar quan el model raona pel seu compte, i pot fer mal. Aquí tens aquella advertència amb una taula a sota, en una tasca on és fàcil assumir que pensar més ha de ser millor.

Tots dos braços es llegeixen amb el mateix instrument a la mateixa posició. L’única diferència és si una chain of thought que el model va escriure per si mateix se situa abans dins del context.

La precisió va baixar i el cost va pujar, i la regla pròpia d’aquest capítol s’aplica al resultat propi d’aquest capítol: la caiguda és 7 casos guanyats contra 10 perduts, probabilitat parellada 0,629, que no queda establerta. El que sí queda establert és que va produir noranta-vuit tokens de sortida extra per crida i no hi va comprar res de mesurable. La incertesa és tota al costat del benefici. La factura és segura.

Una cadena que falla és més instructiva que una que funciona. Quan se li va demanar que raonés sobre «La teva integració de Slack va deixar de publicar missatges després de dimarts», el model va escriure:

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.

Això és consell competent de resolució de problemes i no és la tasca. Quan se li va demanar que pensés, el model va derivar cap al gènere al qual més s’assembla «pensa pas a pas sobre aquest tiquet de suport» en les seves dades d’entrenament, i després va respondre una pregunta de classificació amb cinc-cents caràcters de raonament no relacionat dins del seu propi context. Chain of thought ajuda en problemes amb estat intermedi que val la pena calcular: aritmètica, consultes de múltiples salts, satisfacció de restriccions. Encaminar una frase cap a un de quatre cubells no té estat intermedi. No hi ha res que la cadena hagi de sostenir, així que tot el que fa és afegir text plausible que la decisió final després ha de sobreviure.

Dues conseqüències pràctiques. Primera, per a un model entrenat per raonar —els models RLVR del Capítol 12— la instrucció és pitjor que redundant: pot substituir la cadena llarga que el model hauria produït per una de curta i amb forma de prompt. I mostrejar diverses cadenes i votar, que és el que fa self-consistency,¹¹ no pot rescatar una tasca on no hi ha res sobre què discrepar: multiplica el cost pel nombre de mostres per desfer empats que no existeixen. El Capítol 12 va mesurar aquest intercanvi on sí que aplica. Segona, fixa’t en què va costar la bastida de comparació mateixa. Forçar la resposta dins d’una línia Final queue: va fer caure el braç sense raonament del 76,7 % al 61,7 %. Quinze punts, pagats per fer comparables els dos braços. L’estructura que existeix per a la teva comoditat tampoc no és gratis.

Una última mesura, perquè és la pregunta que tothom fa després del primer resultat sorprenent. Seixanta prompts, descodificació greedy, executats repetidament:

• La mateixa crida repetida amb tot fix va retornar probabilitats idèntiques bit a bit. Determinista.
• La mateixa crida batched with different neighbours —mides de batch 1, 4, 12, 30 i 60— va retornar probabilitats que diferien fins a 0,0128. L’etiqueta triada no va canviar mai, en 0 de 60 casos.

L’etiqueta va sobreviure perquè tenia marge per fer-ho: entre els seixanta casos, la separació més estreta entre les dues cues superiors era 0,0459, tres vegades i mitja el desviament. L’estabilitat no era una propietat de l’algoritme. Era un marge, i els marges s’esgoten. El Capítol 17 és on viu la raó aritmètica i on es desmunten els controls de mostreig que eixamplen i estrenyen aquests buits. La raó de plantar-ho aquí és que delimita què pot significar qualsevol mesura de prompt: el bench mesura un sistema reproduïble només fins a una tolerància, i una diferència de dos punts entre variants és dins d’aquesta tolerància en un mal dia.

Tot el que hi ha més amunt és un humà triant una variant i una màquina puntuant-la. El següent pas evident és deixar que la màquina triï també les variants.

APE fa exactament això: un model proposa instruccions candidates, es puntuen sobre exemples reservats, i les millors sobreviuen.⁸ Les instruccions que troba sovint són coses que cap humà escriuria, i aquest és el punt: la cerca és sobre què puntua, no sobre què sona professional.

DSPy va més enllà i és la idea més útil per a un producte.¹² Declares què pren i què retorna cada pas d’una pipeline, i el framework ho compila en prompts, seleccionant demostracions i optimitzant instruccions contra la teva mètrica. Canvia el model i recompiles en lloc de reescriure. El prompt deixa de ser codi font que algú ajusta a mà i es converteix en un artefacte generat contra una mètrica, que és el que hauria d’haver estat des del principi.

Cap dels dos elimina la necessitat del bench. Tots dos el converteixen en l’única cosa que necessites, perquè un optimitzador sense mètrica no optimitza res.

Queda la disciplina. Els prompts han d’estar en control de versions, en fitxers, al costat del codi que els envia; no en una fila de base de dades que algú va editar un dimarts. Necessiten un identificador de versió desat al costat de cada sortida que han produït, o el dia que alguna cosa regressi no podràs descobrir què ha canviat. Necessiten el bench en integració contínua, perquè un prompt és l’única part del teu sistema que un proveïdor pot invalidar en silenci desplegant un model nou. I necessiten casos: no un centenar d’enginyosos, només els vint avorrits que es van trencar el trimestre passat, conservats per sempre. El bench és el lliurable. El prompt n’és un subproducte.

Tot el que hi ha en aquest capítol s’ha mesurat en precisió. Cadascuna d’aquestes variants també té un preu.

El system prompt que va comprar 21,7 punts s’envia en cada crida, per sempre. Els dos exemples que van comprar set punts s’envien en cada crida, per sempre. Els setze que en van comprar dotze s’envien en cada crida, per sempre, i són aproximadament deu vegades més llargs que la pregunta que l’usuari realment ha fet. La chain of thought que no va comprar res va produir noranta-vuit tokens extra per petició, i els tokens de sortida són els cars.

Res d’això no és visible en una taula de precisions, i tot això és visible en una factura.

El Capítol 16 tracta de la unitat en què aquestes decisions estan realment denominades. El token com a unitat de facturació, el context window com a pressupost més que com a memòria, per què una conversa de quaranta torns costa molt més que quaranta vegades el primer torn, què paga i què no paga el prompt caching, i per què l’ordre del teu prompt decideix si la cache encerta o no —que resulta ser una segona raó, completament econòmica, per posar el material estable primer i el material variable al final.

El bench i totes les taules es van produir amb Qwen/Qwen2.5-0.5B-Instruct sota descodificació greedy, així que es reprodueixen exactament. La documentació de Hugging Face sobre plantilles de xat és la referència del que els marcadors de plantilla del Capítol 11 expandeixen realment, i del fet que un model enviat amb la plantilla equivocada és un error real i recurrent. Per als efectes de posició i format a escala de producció més que d’escala de laboratori, les cites anteriors són les fonts primàries; les guies de prompting dels proveïdors són útils pels seus exemples i s’han de llegir sabent que cap d’elles publica un interval.