Prompt engineering, målt: Hvad der ændrer outputtet

Før målingerne er der én kendsgerning, der stille forklarer halvdelen af det, der følger.

Modellen har ingen hukommelse. Mellem to kald bevarer den intet — ikke dit sidste spørgsmål, ikke sit eget sidste svar, ikke filen du vedhæftede, ikke det faktum at du allerede har spurgt den to gange. Hvert kald starter fra en tom maskine, og det eneste, den maskine kender, er sekvensen af tokens, du lige har givet den.

Det, der ligner hukommelse i en chatgrænseflade, er din klient, der sender hele samtalen igen, hvert turn, fra begyndelsen. Modellen læser det hele igen fra bunden, hver gang. Kapitel 13 målte, hvad den genlæsning koster i en forward pass; Kapitel 16 gør det til en linje på en faktura. Det vigtige her er konsekvensen for design: prompten er ikke en besked til et system, der har tilstand. Den er tilstanden.

Det rydder en familie af misforståelser af vejen. »Modellen glemte, hvad jeg sagde til den« betyder som regel, at det aldrig blev sendt. »Den ignorerede min tidligere instruktion« betyder som regel, at instruktionen faldt ud af vinduet, da historikken blev afkortet. »Den opførte sig anderledes i produktion« betyder som regel, at produktion samler en anden prompt end den, du testede. Ingen af disse er et modelproblem, og ingen løses ved at omformulere noget.

Påstanden »denne prompt er bedre« er en påstand om en fordeling, og du kan ikke se en fordeling ved at kigge på ét output. Det, du har brug for, er kedeligt: cases med kendte svar, N varianter og et interval.

Harnessen er halvtreds linjer TypeScript med samme form som klienten fra Kapitel 14 — en request, en deadline, lidt concurrency, en optælling. Den dukker op igen i Kapitel 19 for at evaluere en retriever og i Kapitel 29 som 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 };
}

Tallet, der kommer tilbage, er ikke resultatet. Det her er:

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

Kapitel 4 fremlagde argumentet, og dette kapitel indløser det. Sytten rigtige ud af tyve er 85 %, og dets 95 %-interval går fra 64 % til 95 %. En variant, der scorer 13 ud af 20 — 65 %, som føles klart dårligere — har et interval fra 43 % til 82 %. De to intervaller overlapper næsten hele vejen. Tyve cases kan ikke skelne en god prompt fra en middelmådig, og de fleste publicerede prompt-råd blev valideret på færre.

Tres cases, som er det, dette kapitel bruger, er stadig ikke mange. Det er nok til at se store effekter og ærligt nok til at indrømme, når det ikke kan se små — og det vil indrømme det flere gange nedenfor.

Tre blokke — reglerne R, ticketen T, instruktionen I — sat sammen til én brugerbesked. Alle seks permutationer, byte-identisk indhold, tres cases hver.

Bedst til værst er 28,3 point, og intervallerne overlapper ikke, så dette er ikke en historie om støj. Da hver arm scores på de samme tres items, er det skarpere spørgsmål det parrede: i de cases hvor to arme er uenige, hvor skæv er fordelingen? At gå fra den værste rækkefølge til den bedste vendte 21 cases til rigtige og 4 til forkerte — eksakt parret sandsynlighed 0,0009.³

Læs tabellen for dens form snarere end dens vinder. De to bedste rækker slutter begge med ticketen; de to værste begraver begge instruktionen i midten eller lader den komme efter dataene. Det er det samme fænomen, Liu et al. kaldte Lost in the Middle: materiale ved kanterne af en prompt bruges mere pålideligt end materiale i centrum.⁴ Kapitel 16 prissætter vinduet, og Kapitel 24 måler effekten ordentligt ved længde, hvor midten kollapser som beskrevet, og genopretningen helt til sidst ikke dukker op igen. Her falder den praktiske regel ud af sig selv: opgave øverst, data nederst, intet vigtigt i midten.

Flyt nu de samme ord mellem turns. Kapitel 11 fastslog, at chat-skabelonen ikke er dekoration omkring modellen, men en del af den — <|im_start|>system og <|im_start|>user er rigtige tokens, modellen så millioner af gange under fine-tuning, i præcis de positioner. Så det burde betyde noget, på hvilken side af de markører din instruktion lander, og det gør det:

At flytte reglerne og instruktionen over template-grænsen købte 21,7 point — 19 cases vundet, 6 tabt, parret sandsynlighed 0,0146 — uden at ændre et tegn i dem. Det er det konkrete svar på system prompt versus user prompt: de er ikke to måder at sige det samme på. De er to forskellige token-positioner i en struktur, modellen er trænet på, og systempositionen er der, hvor instruktioner, der gælder hele samtalen, hører hjemme.

Læg også mærke til tredje række. At gentage instruktionen efter ticketen — et bredt anbefalet trick — scorede under at sige den én gang. På denne model, på denne opgave, var det værre at sige det to gange end at sige det én gang.

Samme prompt, bedste placering, tres cases. Det eneste, der ændres, er hvad der omgiver ticket-teksten.

Et spænd på atten point fra tegnsætning. Men se på de to ekstreme intervaller: [73,9, 91,9] og [54,1, 77,3]. De overlapper. Med den grove læsning — sammenlign error bars, og hvis de rører hinanden, så sig ingenting — beviser denne tabel slet ingenting.

Den grove læsning er forkert her, og det er mere værd end tabellen at forstå hvorfor. Hver variant blev scoret på de samme tres tickets, så de to målinger er ikke uafhængige samples; de er parrede. Det meste af hvert intervals bredde kommer fra en usikkerhedskilde, begge arme deler — om disse tres tickets er repræsentative — og den kilde udlignes, når du sammenligner dem med hinanden. Stil det parrede spørgsmål i stedet, og svaret er skarpt: at gå fra dobbelte anførselstegn til XML-taggen vendte 12 cases til rigtige og 1 til forkert, parret sandsynlighed 0,0034. Det er en reel forskel.

Og så punkterer den samme test overskriften. XML-taggen slog den almindelige Ticket:-label med 8,3 point, hvilket er tallet, et blogindlæg ville sætte i sin titel. Parret: 6 vundet, 1 tabt, sandsynlighed 0,1250. Ikke etableret. Syv cases er det, den berømte forbedring hviler på.

Så der er to spørgsmål med to forskellige instrumenter, og at blande dem sammen er sådan prompt-råd går galt i begge retninger på én gang:

Den generelle observation — at modeller er stærkt og uforudsigeligt følsomme over for formatteringsvalg uden semantisk indhold — er ikke ny. Sclar et al. varierede intet andet end separatorer, mellemrum og store/små bogstaver på tværs af dusinvis af opgaver og fandt accuracy-spænd, der var brede nok til at vende publicerede modelranglister.⁵ Den praktiske konsekvens er ikke »brug XML-tags«. Den er, at formattering er en hyperparameter, den koster ingenting at sweep, og enhver sammenligning af to modeller, der fastlåser ét format, sammenligner formater lige så meget som modeller.

In-context learning — at vise modellen gennemarbejdede eksempler i prompten og få den til at generalisere fra dem uden nogen vægtopdatering — er den evne, der gjorde GPT-3 berømt.⁶ Det praktiske spørgsmål er aldrig, om det virker. Det er, hvor mange eksempler det kan betale sig at betale for.

Eksempler indsættes som rigtige tidligere turns, skiftevis user og assistant, fordi det er den struktur, template'en blev trænet på. Hver k blev kørt med fem forskellige tilfældige udtræk fra en adskilt pulje på seksten labellede tickets:

To eksempler købte syv point. De næste seks eksempler købte intet målbart — 83,7, så 81,7, så 83,7, en sekvens der vandrer rundt i sin egen støj. Seksten købte yderligere fem og et halvt. Kurven er ikke en jævn stigning; den er et trin, et plateau og et trin.

Den vigtigste kolonne er den sidste. Ved k = 8 flyttede hvilke otte eksempler du tilfældigvis valgte accuracy med 10 point — større end hele gevinsten ved at gå fra to eksempler til otte. Og nederste række er den skarpeste version af det: ved k = 16 er puljen opbrugt, så alle fem runs indeholder præcis de samme seksten eksempler og adskiller sig kun ved den rækkefølge, de optræder i. Rækkefølge alene flyttede accuracy 8,3 point.

Det er det resultat, Lu et al. rapporterede, og det overlever overalt, hvor man har ledt efter det: eksemplernes rækkefølge er en reel hyperparameter med effekter på niveau med antallet af eksempler.⁷ Så det ærlige råd om few-shot prompting er ikke et tal. Det er:

Nu folkloren. Hver af disse er én enkelt sætning sat foran en system prompt, der ellers er identisk, på de samme tres cases.

Fire af de fem gjorde ingenting. Ikke »gjorde lidt«; ingenting, som tres parrede cases kan se. Ekspertpersonaen og bestikkelsen scorede begge under den urørte baseline, og selv de fald fejler den parrede test — de er støj, der peger nedad.

Tredje række er den, man skal dvæle ved. »Dette er meget vigtigt for min karriere« producerede præcis samme accuracy, 46 ud af 60 — og ti af de tres svar ændrede sig, fem i hver retning. Opsummeringsstatistikken var identisk, og adfærden var det ikke. Hvis din evaluering er ét enkelt tal over et lille sæt, kan en ændring, der omskriver en sjettedel af dine outputs, ligne en ændring, der ikke gjorde noget, og du shipper den i den tro, at den var gratis.

Og så truslen, som er den eneste sætning, der flyttede nålen, og flyttede den 35 point ned, med 24 cases vendt fra rigtige til forkerte. Det er ikke en afrundingsartefakt; det er en anden modeladfærd. Lektien er ikke »tru aldrig en model«. Den er, at følelsesmæssig framing ikke er inert. Den flytter fordelingen, nogle gange hårdt, i en retning ingen kan forudsige ved at læse sætningen — hvilket netop er grunden til, at den skal måles i stedet for at ræsonneres om.

Et forbehold, dette kapitel skylder dig: disse fem sætninger blev testet på én lille model og én opgave. Nogle har publiceret støtte andre steder — »tag en dyb indånding« kom ud af en artikel, der søgte efter højtscorende instruktioner snarere end at opfinde dem, hvilket er en anden og bedre påstand end den, der cirkulerede bagefter.⁸ Det, der generaliserer, er ikke sætningerne. Det er, at listen, der overlevede i blogindlæg, og listen, der overlever måling, er to forskellige lister, og den eneste måde at vide, hvilken du står med, er at køre benchen.

En regel alle gentager — sig hvad du vil have, ikke hvad du ikke vil have — med den sædvanlige mangel på et tal. Her er tallet. Samme formatkrav, skrevet på tre måder, hvor modellen genererer frit, så compliance kan observeres:

Tre forbud klarede sig dårligere end én instruktion og fik modellen til at skrive fem gange mere tekst — det stik modsatte af alle tre på én gang. At tilføje den positive sætning tilbage reddede den til 68 %.

Mekanismen er ikke mystisk, når du husker Kapitel 8. Modellen vælger en næste token fra en fordeling betinget af alt før den, og et forbud putter den forbudte ting ind i den betingelse. Der er ingen operator for negation; der er en kontekst, hvor et ord nu optræder.

Det kan måles direkte. Tag baseline-prompten, og tilføj én linje: Do not use the shipping queue for software problems. Kig derefter kun på de femogfyrre tickets, der ikke er shipping-tickets:

At navngive en kø for at udelukke den fik modellen til at vælge den tre gange oftere, næsten tredoblede den probability mass, den tildelte den, og kostede 25 point samlet accuracy — 16 cases tabt mod 1 vundet, parret sandsynlighed 0,0003.

Tænk ikke på en elefant, målt. Omskrivningen er altid den samme: erstat forbuddet med den positive regel, der gør det unødvendigt. Ikke »brug ikke shipping til softwareproblemer«, men »brug kun shipping, når en fysisk pakke er involveret«.

Kapitel 12 byggede chain of thought ordentligt — først som en prompting-teknik,⁹¹⁰ derefter som noget trænet ind med verificerbare belønninger — og sluttede med en advarsel, det udsatte til dette kapitel: at bede en model tænke trin for trin holder op med at hjælpe, når modellen ræsonnerer af sig selv, og kan skade. Her er den advarsel med en tabel under sig, på en opgave hvor det er let at antage, at mere tænkning må være bedre.

Begge arme læses med samme instrument ved samme position. Den eneste forskel er, om en chain of thought, modellen selv skrev, først ligger i konteksten.

Accuracy gik ned, og omkostningen gik op, og dette kapitels egen regel gælder for dette kapitels eget resultat: faldet er 7 cases vundet mod 10 tabt, parret sandsynlighed 0,629, hvilket ikke er etableret. Det, der er etableret, er, at det producerede otteoghalvfems ekstra output-tokens pr. kald og ikke købte noget målbart med dem. Usikkerheden ligger udelukkende på benefitsiden. Regningen er sikker.

En chain, der fejler, er mere lærerig end en, der virker. Bedt om at ræsonnere om »Your Slack integration stopped posting messages after Tuesday« skrev modellen:

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.

Det er kompetent troubleshooting-rådgivning, og det er ikke opgaven. Bedt om at tænke drev modellen ind i den genre, som »think step by step about this support ticket« mest ligner i dens træningsdata — og besvarede derefter et klassifikationsspørgsmål med fem hundrede tegn af irrelevant ræsonnement i sin egen kontekst. Chain of thought hjælper på problemer med mellemtilstand, der er værd at beregne: aritmetik, multi-hop opslag, constraint satisfaction. At route en sætning ind i en af fire buckets har ingen mellemtilstand. Der er intet for chainen at holde, så alt den gør, er at tilføje plausibel tekst, som den endelige beslutning derefter skal overleve.

To praktiske følgeslutninger. For det første: for en model, der er trænet til at ræsonnere — RLVR-modellerne fra Kapitel 12 — er instruktionen værre end redundant: den kan erstatte den lange chain, modellen ville have produceret, med en kort, prompt-formet en. Og at sample flere chains og stemme, hvilket er det self-consistency gør,¹¹ kan ikke redde en opgave uden noget at være uenig om: det ganger omkostningen med antallet af samples for at bryde uafgjortheder, der ikke findes. Kapitel 12 målte den trade dér, hvor den faktisk gælder. For det andet: bemærk, hvad selve sammenligningsstilladset kostede. At tvinge svaret ind i en Final queue:-linje sænkede armen uden ræsonnement fra 76,7 % til 61,7 %. Femten point, betalt for at gøre de to arme sammenlignelige. Struktur, der findes for din bekvemmelighed, er heller ikke gratis.

Én sidste måling, fordi det er det spørgsmål, alle stiller efter det første overraskende resultat. Tres prompts, greedy decoding, kørt gentagne gange:

• Det samme kald gentaget med alt holdt fast returnerede bit-identiske sandsynligheder. Deterministisk.
• Det samme kald batchet med forskellige naboer — batch-størrelser 1, 4, 12, 30 og 60 — returnerede sandsynligheder, der afveg med op til 0,0128. Den valgte label ændrede sig aldrig, i 0 af 60 cases.

Labelen overlevede, fordi den havde plads til det: på tværs af de tres cases var det smalleste gap mellem de to øverste køer 0,0459, tre en halv gang driften. Stabiliteten var ikke en egenskab ved algoritmen. Den var en margin, og marginer løber tør. Kapitel 17 er der, hvor den aritmetiske grund bor, og hvor sampling-knapperne, der udvider og indsnævrer de gaps, skilles ad. Grunden til at plante det her er, at det afgrænser, hvad enhver prompt-måling kan betyde: benchen måler et system, der kun er reproducerbart op til en tolerance, og en forskel på to point mellem varianter ligger inden for den tolerance på en dårlig dag.

Alt ovenfor er et menneske, der vælger en variant, og en maskine, der bedømmer den. Det oplagte næste skridt er også at lade maskinen vælge varianterne.

APE gør præcis det: en model foreslår kandidatinstruktioner, de scores på hold-out-eksempler, og de bedste overlever.⁸ De instruktioner, den finder, er ofte nogle, ingen mennesker ville skrive, hvilket er pointen — søgningen handler om, hvad der scorer, ikke om hvad der lyder professionelt.

DSPy går længere og er den mere nyttige idé for et produkt.¹² Du deklarerer, hvad hvert trin i en pipeline tager og returnerer, og frameworket compiler det til prompts, vælger demonstrationer og optimerer instruktioner mod din metric. Skift model, og du recompiler i stedet for at omskrive. Prompten holder op med at være source code, nogen håndtuner, og bliver et artefakt genereret mod en metric, hvilket er det, den burde have været hele tiden.

Ingen af delene fjerner behovet for benchen. Begge gør den til det eneste, du har brug for, fordi en optimiser uden en metric intet optimerer.

Tilbage står disciplinen. Prompts hører hjemme i version control, i filer, ved siden af den kode der sender dem — ikke i en database-række, nogen redigerede en tirsdag. De har brug for en versionsidentifikator gemt sammen med hvert output, de producerede, ellers kan du ikke finde ud af, hvad der ændrede sig den dag, noget regresserer. De har brug for benchen i continuous integration, fordi en prompt er den ene del af dit system, som en leverandør tavst kan invalidere ved at deploye en ny model. Og de har brug for cases: ikke hundrede smarte, bare de kedelige tyve, der gik i stykker sidste kvartal, gemt for altid. Benchen er leverancen. Prompten er et biprodukt af den.

Alt i dette kapitel blev målt i accuracy. Hver eneste af de varianter har også en pris.

System prompten, der købte 21,7 point, sendes på hvert kald, for altid. De to eksempler, der købte syv point, sendes på hvert kald, for altid. De seksten, der købte tolv, sendes på hvert kald, for altid, og de er omtrent ti gange så lange som det spørgsmål, brugeren faktisk stillede. Chain of thought, der intet købte, producerede otteoghalvfems ekstra tokens pr. request, og output-tokens er den dyre slags.

Intet af det er synligt i en tabel over accuracies, og alt sammen er synligt på en faktura.

Kapitel 16 handler om den enhed, de beslutninger faktisk er denomineret i. Token som faktureringsenhed, context window som budget snarere end hukommelse, hvorfor en samtale på fyrre turns koster langt mere end fyrre gange første turn, hvad prompt caching betaler og ikke betaler for, og hvorfor rækkefølgen af din prompt afgør, om cachen overhovedet rammer — hvilket viser sig at være en anden, helt økonomisk grund til at lægge det stabile materiale først og det variable materiale sidst.

Benchen og hver tabel blev produceret med Qwen/Qwen2.5-0.5B-Instruct under greedy decoding, så de reproduceres præcist. Hugging Face-dokumentationen om chat templates er referencen for, hvad template-markørerne fra Kapitel 11 faktisk udvider sig til, og for det faktum, at en model, der shipper med den forkerte template, er en reel og tilbagevendende fejl. For positions- og formateffekterne i produktionsskala snarere end laboratorieskala er citaterne ovenfor de primære kilder; leverandørernes prompting guides er nyttige for deres eksempler og bør læses med den viden, at ingen af dem publicerer et interval.