Prompt engineering, uppmätt: vad som ändrar output

Före mätningarna: ett faktum som i tysthet förklarar hälften av det som följer.

Modellen har inget minne. Mellan två anrop behåller den ingenting — inte din förra fråga, inte sitt eget förra svar, inte filen du bifogade, inte det faktum att du redan frågat den två gånger. Varje anrop startar från en tom maskin, och det enda den maskinen vet är sekvensen av tokens du just gav den.

Det som ser ut som minne i ett chattgränssnitt är att din klient skickar om hela konversationen, varje tur, från början. Modellen läser allt igen från noll, varje gång. Kapitel 13 mätte vad den omläsningen kostar i en forward pass; kapitel 16 gör det till en rad på en faktura. Det som spelar roll här är konsekvensen för design: prompten är inte ett meddelande till ett system som har tillstånd. Den är tillståndet.

Det avvecklar en hel familj av missförstånd. "Modellen glömde vad jag sa till den" betyder oftast att det aldrig skickades. "Den ignorerade min tidigare instruktion" betyder oftast att instruktionen föll ut ur fönstret när historiken trunkerades. "Den betedde sig annorlunda i produktion" betyder oftast att produktion sätter ihop en annan prompt än den du testade. Inget av detta är ett modellproblem, och inget av det fixas genom att formulera om något.

Påståendet "den här prompten är bättre" är ett påstående om en fördelning, och du kan inte se en fördelning genom att titta på en output. Det du behöver är tråkigt: fall med kända svar, N varianter och ett intervall.

harness är femtio rader TypeScript med samma form som klienten från kapitel 14 — en begäran, en deadline, lite samtidighet, en summering. Den återkommer i kapitel 19 för att utvärdera en retriever och 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 };
}

Siffran som kommer tillbaka är inte resultatet. Det här är:

/** 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 lade fram argumentet och det här kapitlet inkasserar det. Sjutton rätt av tjugo är 85 %, och dess 95-procentiga intervall går från 64 % till 95 %. En variant som får 13 av 20 — 65 %, vilket känns klart sämre — har ett intervall från 43 % till 82 %. De två intervallen överlappar nästan hela vägen. Tjugo fall kan inte skilja en bra prompt från en medioker, och de flesta publicerade prompt-råd validerades på färre.

Sextio fall, vilket är vad det här kapitlet använder, är fortfarande inte många. Det räcker för att se stora effekter och är ärligt nog för att erkänna när det inte kan se små — och det kommer att erkänna det flera gånger nedan.

Tre block — reglerna R, ärendet T, instruktionen I — konkatenerade till ett user-meddelande. Alla sex permutationer, byte-identiskt innehåll, sextio fall vardera.

Bäst till sämst är 28,3 punkter, och intervallen överlappar inte, så det här är inte en historia om brus. Eftersom varje arm poängsätts på samma sextio objekt är den skarpare frågan den parade: av fallen där två armar är oense, hur sned är fördelningen? Att gå från sämsta ordningen till bästa vände 21 fall till rätt och 4 till fel — exakt parad sannolikhet 0,0009.³

Läs tabellen för dess form snarare än dess vinnare. De två bästa raderna slutar med ärendet; de två sämsta gömmer båda instruktionen i mitten eller låter den släpa efter datan. Det är samma fenomen som Liu et al. kallade Lost in the Middle: material vid kanterna av en prompt används mer tillförlitligt än material i centrum.⁴ Kapitel 16 prissätter fönstret och kapitel 24 mäter effekten ordentligt vid längd, där mitten kollapsar som beskrivet och återhämtningen allra sist inte återkommer. Här faller den praktiska regeln ut av sig själv: uppgift överst, data nederst, inget viktigt i mitten.

Flytta nu samma ord mellan turer. Kapitel 11 etablerade att chat template inte är dekoration runt modellen utan del av den — <|im_start|>system och <|im_start|>user är verkliga tokens som modellen såg miljontals gånger under fine-tuning, exakt i de positionerna. Så det borde spela roll på vilken sida om de markörerna din instruktion landar, och det gör det:

Att flytta reglerna och instruktionen över template-gränsen gav 21,7 punkter — 19 fall vunna, 6 förlorade, parad sannolikhet 0,0146 — utan att ändra ett tecken i dem. Det är det konkreta svaret på system prompt kontra user prompt: de är inte två sätt att säga samma sak. De är två olika token-positioner i en struktur modellen tränades på, och systempositionen är där instruktioner som gäller hela konversationen hör hemma.

Notera också tredje raden. Att upprepa instruktionen efter ärendet — ett vida rekommenderat knep — fick lägre resultat än att säga den en gång. På den här modellen, i den här uppgiften, var det sämre att säga det två gånger än att säga det en gång.

Samma prompt, bästa placering, sextio fall. Det enda som ändras är vad som omger ärendetexten.

En spridning på arton punkter från skiljetecken. Men titta på de två extrema intervallen: [73,9, 91,9] och [54,1, 77,3]. De överlappar. Enligt den grova läsningen — jämför felstaplarna, och om de rör vid varandra, säg ingenting — bevisar den här tabellen ingenting alls.

Den grova läsningen är fel här, och att förstå varför är mer värt än tabellen. Varje variant poängsattes på samma sextio ärenden, så de två mätningarna är inte oberoende urval; de är parade. Det mesta av varje intervalls bredd kommer från en osäkerhetskälla som båda armar delar — om dessa sextio ärenden är representativa — och den källan tar ut sig när du jämför dem mot varandra. Ställ den parade frågan i stället och svaret blir skarpt: att gå från dubbla citattecken till XML-taggen vände 12 fall till rätt och 1 till fel, parad sannolikhet 0,0034. Det är en verklig skillnad.

Och sedan punkterar samma test rubriken. XML-taggen slog den vanliga Ticket:-etiketten med 8,3 punkter, vilket är siffran ett blogginlägg skulle sätta i sin titel. Parat: 6 vunna, 1 förlorat, sannolikhet 0,1250. Inte etablerat. Sju fall är vad den berömda förbättringen vilar på.

Så det finns två frågor med två olika instrument, och att blanda ihop dem är hur prompt-råd går fel åt båda håll samtidigt:

Den allmänna upptäckten — att modeller är starkt och oförutsägbart känsliga för formateringsval utan semantiskt innehåll — är inte ny. Sclar et al. varierade inget annat än avgränsare, mellanrum och versalisering över dussintals uppgifter och fann träffsäkerhetsspridningar stora nog att vända publicerade modellrankningar.⁵ Den praktiska konsekvensen är inte "använd XML-taggar". Den är att formatering är en hyperparameter, den kostar inget att svepa, och varje jämförelse av två modeller som låser ett format jämför format lika mycket som modeller.

In-context learning — att visa modellen arbetade exempel i prompten och låta den generalisera från dem utan någon viktuppdatering — är förmågan som gjorde GPT-3 berömd.⁶ Den praktiska frågan är aldrig om det fungerar. Den är hur många exempel som är värda att betala för.

Exempel läggs in som verkliga tidigare turer, växlande user och assistant, eftersom det är strukturen templaten tränades på. Varje k kördes med fem olika slumpmässiga dragningar från en separat pool med sexton märkta ärenden:

Två exempel gav sju punkter. De nästa sex exemplen gav inget mätbart — 83,7, sedan 81,7, sedan 83,7, en sekvens som vandrar runt i sitt eget brus. Sexton gav ytterligare fem och en halv. Kurvan är inte en jämn stigning; den är ett steg, en platå och ett steg.

Kolumnen som betyder mest är den sista. Vid k = 8 flyttade vilka åtta exempel du råkade välja träffsäkerheten med 10 punkter — mer än hela vinsten från att gå från två exempel till åtta. Och nedersta raden är den skarpaste versionen av det: vid k = 16 är poolen uttömd, så alla fem körningar innehåller exakt samma sexton exempel, och skiljer sig bara i ordningen de visas. Enbart ordningen flyttade träffsäkerheten 8,3 punkter.

Det är resultatet Lu et al. rapporterade, och det överlever överallt där någon har letat efter det: exempelordning är en genuin hyperparameter med effekter jämförbara med antal exempel.⁷ Så det ärliga rådet om few-shot prompting är inte ett tal. Det är:

Nu folkloren. Var och en av dessa är en enda mening som läggs före en system prompt som annars är identisk, på samma sextio fall.

Fyra av de fem gjorde ingenting. Inte "gjorde lite"; inget som sextio parade fall kan se. Expertpersonan och mutan fick båda lägre resultat än den orörda baseline, och även de fallen klarar inte det parade testet — de är brus som pekar nedåt.

Den tredje raden är den man ska stanna vid. "Det här är mycket viktigt för min karriär" gav exakt samma träffsäkerhet, 46 av 60 — och tio av de sextio svaren ändrades, fem åt vardera håll. Sammanfattningsstatistiken var identisk och beteendet var det inte. Om din utvärdering är en enda siffra över ett litet set kan en ändring som skriver om en sjättedel av dina outputs se ut som en ändring som inte gjorde något, och du lanserar den i tron att den var gratis.

Och sedan hotet, som är den enda meningen som flyttade nålen och flyttade den 35 punkter ned, med 24 fall vända från rätt till fel. Det är inte en avrundningsartefakt; det är ett annat modellbeteende. Lärdomen är inte "hota aldrig en modell". Den är att emotionell inramning inte är inert. Den flyttar fördelningen, ibland kraftigt, i en riktning ingen kan förutsäga genom att läsa meningen — vilket är precis varför den måste mätas i stället för att resoneras fram.

En brasklapp som det här kapitlet är skyldigt dig: dessa fem meningar testades på en liten modell och en uppgift. Några har publicerat stöd på andra håll — "ta ett djupt andetag" kom ur en artikel som sökte efter högpoängande instruktioner i stället för att hitta på dem, vilket är ett annat och bättre påstående än det som sedan cirkulerade.⁸ Det som generaliserar är inte meningarna. Det är att listan som överlevde i blogginlägg och listan som överlever mätning är två olika listor, och det enda sättet att veta vilken du håller i är att köra benchen.

En regel alla upprepar — säg vad du vill ha, inte vad du inte vill ha — med den vanliga frånvaron av en siffra. Här är siffran. Samma formatkrav, skrivet på tre sätt, med modellen som genererar fritt så att efterlevnad kan observeras:

Tre förbud gjorde sämre ifrån sig än en instruktion, och fick modellen att skriva fem gånger mer text — raka motsatsen till alla tre samtidigt. Att lägga tillbaka den positiva meningen räddade det till 68 %.

Mekanismen är inte mystisk när du minns kapitel 8. Modellen väljer nästa token från en fördelning villkorad på allt före den, och ett förbud lägger det förbjudna in i den villkorningen. Det finns ingen operator för negation; det finns en context där ett ord nu förekommer.

Vilket går att mäta direkt. Ta baseline-prompten och lägg till en rad: Do not use the shipping queue for software problems. Titta sedan bara på de fyrtiofem ärenden som inte är shipping-ärenden:

Att namnge en kö för att utesluta den fick modellen att välja den tre gånger oftare, nästan tredubblade sannolikhetsmassan den tilldelade den och kostade 25 punkter i total träffsäkerhet — 16 fall förlorade mot 1 vunnet, parad sannolikhet 0,0003.

Tänk inte på en elefant, uppmätt. Omskrivningen är alltid densamma: ersätt förbudet med den positiva regel som gör det onödigt. Inte "använd inte shipping för mjukvaruproblem" utan "använd shipping endast när ett fysiskt paket är inblandat".

Kapitel 12 byggde chain of thought ordentligt — först som en prompting-teknik,⁹¹⁰ sedan som något som tränats in med verifierbara belöningar — och slutade med en varning som det sköt upp till det här kapitlet: att säga åt en modell att tänka steg för steg slutar hjälpa när modellen resonerar på egen hand, och kan skada. Här är den varningen med en tabell under sig, på en uppgift där det är lätt att anta att mer tänkande måste vara bättre.

Båda armar läses med samma instrument vid samma position. Den enda skillnaden är om en chain of thought som modellen själv skrev ligger i context först.

Träffsäkerheten gick ned och kostnaden gick upp, och det här kapitlets egen regel gäller för det här kapitlets eget resultat: tappet är 7 fall vunna mot 10 förlorade, parad sannolikhet 0,629, vilket inte är etablerat. Det som är etablerat är att det producerade nittioåtta extra output tokens per anrop och inte köpte något mätbart med dem. Osäkerheten ligger helt på nyttosidan. Notan är säker.

En kedja som misslyckas är mer lärorik än en som fungerar. När modellen ombads resonera om "Din Slack-integration slutade posta meddelanden efter tisdagen" skrev den:

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 är kompetenta felsökningsråd och det är inte uppgiften. Ombedd att tänka drev modellen in i genren som "tänk steg för steg om det här supportärendet" mest liknar i dess träningsdata — och svarade sedan på en klassificeringsfråga med femhundra tecken orelaterat resonemang i sin egen context. Chain of thought hjälper på problem med mellantillstånd som är värt att beräkna: aritmetik, uppslag i flera hopp, constraint satisfaction. Att route:a en mening till en av fyra hinkar har inget mellantillstånd. Det finns inget för kedjan att hålla, så allt den gör är att lägga till plausibel text som det slutliga beslutet sedan måste överleva.

Två praktiska följder. För det första: för en modell tränad att resonera — RLVR-modellerna i kapitel 12 — är instruktionen värre än redundant: den kan ersätta den långa kedja modellen skulle ha producerat med en kort, prompt-formad. Och att sampla flera kedjor och rösta, vilket är vad self-consistency gör,¹¹ kan inte rädda en uppgift där det inte finns något att vara oense om: det multiplicerar kostnaden med antalet samples för att bryta oavgjorda lägen som inte finns. Kapitel 12 mätte den handeln där den faktiskt gäller. För det andra, notera vad jämförelseställningen själv kostade. Att tvinga svaret till en Final queue:-rad sänkte armen utan resonemang från 76,7 % till 61,7 %. Femton punkter, betalda för att göra de två armarna jämförbara. Struktur som finns för din bekvämlighet är inte heller gratis.

En sista mätning, eftersom det är frågan alla ställer efter det första överraskande resultatet. Sextio prompts, greedy decoding, körda upprepade gånger:

• Samma anrop upprepat med allt låst returnerade bit-identiska sannolikheter. Deterministiskt.
• Samma anrop batchat med olika grannar — batchstorlekar 1, 4, 12, 30 och 60 — returnerade sannolikheter som skilde sig med upp till 0,0128. Den valda etiketten ändrades aldrig, i 0 av 60 fall.

Etiketten överlevde eftersom den hade utrymme att göra det: över de sextio fallen var det smalaste gapet mellan de två högsta köerna 0,0459, tre och en halv gånger driften. Stabiliteten var inte en egenskap hos algoritmen. Den var en marginal, och marginaler tar slut. Kapitel 17 är där det aritmetiska skälet finns och där sampling-vreden som vidgar och smalnar av de gapen plockas isär. Skälet att plantera det här är att det sätter gränser för vad en prompt-mätning kan betyda: benchen mäter ett system som bara är reproducerbart upp till en tolerans, och en tvåpunktskillnad mellan varianter ligger inom den toleransen en dålig dag.

Allt ovan är en människa som väljer en variant och en maskin som betygsätter den. Det uppenbara nästa steget är att låta maskinen välja varianterna också.

APE gör exakt det: en modell föreslår kandidatinstruktioner, de poängsätts på held-out-exempel, och de bästa överlever.⁸ Instruktionerna den hittar är ofta sådana ingen människa skulle skriva, vilket är poängen — sökningen sker över vad som får poäng, inte över vad som låter professionellt.

DSPy går längre och är den mer användbara idén för en produkt.¹² Du deklarerar vad varje steg i en pipeline tar emot och returnerar, och ramverket kompilerar det till prompts, väljer demonstrationer och optimerar instruktioner mot ditt mått. Byt modell och du kompilerar om i stället för att skriva om. Prompten slutar vara källkod som någon handtrimmar och blir ett artefakt genererat mot ett mått, vilket är vad den borde ha varit hela tiden.

Ingetdera tar bort behovet av benchen. Båda gör den till det enda du behöver, eftersom en optimerare utan ett mått inte optimerar någonting.

Kvar finns disciplinen. Prompts hör hemma i versionshantering, i filer, bredvid koden som skickar dem — inte i en databasrad som någon redigerade en tisdag. De behöver en versionsidentifierare lagrad bredvid varje output de producerade, annars kan du inte ta reda på vad som ändrades den dag något regresserar. De behöver benchen i continuous integration, eftersom en prompt är den del av ditt system som en leverantör tyst kan ogiltigförklara genom att deploy:a en ny modell. Och de behöver fall: inte hundra smarta, bara de tråkiga tjugo som gick sönder förra kvartalet, sparade för alltid. Benchen är leveransen. Prompten är en biprodukt av den.

Allt i det här kapitlet mättes i träffsäkerhet. Varenda en av de varianterna har också ett pris.

System prompt som gav 21,7 punkter skickas vid varje anrop, för alltid. De två exemplen som gav sju punkter skickas vid varje anrop, för alltid. De sexton som gav tolv skickas vid varje anrop, för alltid, och de är ungefär tio gånger så långa som frågan användaren faktiskt ställde. Chain of thought som inte gav något producerade nittioåtta extra tokens per begäran, och output tokens är den dyra sorten.

Inget av det syns i en tabell över träffsäkerhet, och allt syns på en faktura.

Kapitel 16 handlar om enheten de besluten faktiskt denomineras i. Token som faktureringsenhet, context window som budget snarare än minne, varför en konversation på fyrtio turer kostar långt mer än fyrtio gånger första turen, vad prompt caching betalar och inte betalar för, och varför ordningen på din prompt avgör om cachen träffar alls — vilket visar sig vara ett andra, helt ekonomiskt skäl att lägga det stabila materialet först och det variabla materialet sist.

Benchen och varje tabell producerades med Qwen/Qwen2.5-0.5B-Instruct under greedy decoding, så de reproduceras exakt. Hugging Face-dokumentationen om chat templates är referensen för vad template-markörerna i kapitel 11 faktiskt expanderar till, och för att en modell som levereras med fel template är ett verkligt och återkommande fel. För positions- och formateffekter i produktionsskala snarare än laboratorieskala är citeringarna ovan primärkällorna; leverantörernas prompting-guider är användbara för sina exempel och bör läsas med vetskapen att ingen av dem publicerar ett intervall.