Prompt engineering v číslech: co mění výstup

Než přijdou měření, jedna skutečnost, která potichu vysvětluje polovinu toho, co následuje.

Model nemá paměť. Mezi dvěma voláními si neuchová nic — ani vaši poslední otázku, ani svou poslední odpověď, ani soubor, který jste přiložili, ani fakt, že jste se už ptali dvakrát. Každé volání začíná na prázdném stroji a jediné, co ten stroj zná, je posloupnost token, kterou jste mu právě předali.

To, co v chatovacím rozhraní vypadá jako paměť, je klient, který znovu posílá celou konverzaci, každý turn, od začátku. Model ji pokaždé čte znovu od nuly. Kapitola 13 měřila, kolik tohle opakované čtení stojí ve forward pass; kapitola 16 z toho dělá řádek na faktuře. Tady je důležitý důsledek pro návrh: prompt není zpráva systému, který má stav. Prompt je stav.

Tím mizí celá rodina zmatků. „Model zapomněl, co jsem mu řekl“ obvykle znamená, že mu to nikdy nebylo posláno. „Ignoroval moji dřívější instrukci“ obvykle znamená, že instrukce vypadla z okna, když byla historie zkrácena. „V produkci se choval jinak“ obvykle znamená, že produkce skládá jiný prompt než ten, který jste testovali. Nic z toho není problém modelu a nic z toho se neopraví přeformulováním.

Tvrzení „tenhle prompt je lepší“ je tvrzení o rozdělení, a rozdělení neuvidíte pohledem na jeden výstup. Potřebujete něco nudného: případy se známými odpověďmi, N variant a interval.

Harness má padesát řádků TypeScriptu a stejný tvar jako klient z kapitoly 14 — request, deadline, trochu concurrency, součet. Znovu se objeví v kapitole 19 pro vyhodnocení retrieveru a v kapitole 29 jako 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 };
}

Číslo, které se vrátí, není výsledek. Výsledek je tohle:

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

Kapitola 4 ten argument postavila a tato kapitola ho zúročuje. Sedmnáct správně z dvaceti je 85 % a jeho 95% interval vede od 64 % do 95 %. Varianta se skóre 13 z 20 — 65 %, což působí zřetelně hůř — má interval od 43 % do 82 %. Tyto dva intervaly se překrývají téměř po celé délce. Dvacet případů nerozliší dobrý prompt od průměrného a většina publikovaných rad k prompt byla ověřena na menším počtu.

Šedesát případů, což je počet použitý v této kapitole, pořád není mnoho. Stačí to k zachycení velkých efektů a je to dost poctivé na to, aby přiznalo, když malé efekty nevidí — a níže to přizná několikrát.

Tři bloky — pravidla R, ticket T, instrukce I — spojené do jedné user zprávy. Všech šest permutací, bajtově identický obsah, šedesát případů pro každou.

Rozdíl mezi nejlepší a nejhorší variantou je 28,3 bodu a intervaly se nepřekrývají, takže tady nejde o příběh o šumu. Protože každé rameno se hodnotí na stejných šedesáti položkách, ostřejší otázka je párová: v případech, kde se dvě ramena neshodnou, jak jednostranné je rozdělení? Přechod od nejhoršího pořadí k nejlepšímu otočil 21 případů na správné a 4 na chybné — přesná párová pravděpodobnost 0,0009.³

Tabulku čtěte podle jejího tvaru, ne podle vítěze. Dva nejlepší řádky oba končí ticketem; dva nejhorší buď zahrabávají instrukci doprostřed, nebo ji vlečou za daty. Je to tentýž jev, který Liu et al. pojmenovali Lost in the Middle: materiál na okrajích prompt se používá spolehlivěji než materiál uprostřed.⁴ Kapitola 16 okno nacení a kapitola 24 změří efekt pořádně na délce, kde se prostředek zhroutí tak, jak je popsáno, a zotavení na úplném konci se už neobjeví. Praktické pravidlo tady vyplyne samo: úloha nahoře, data dole, nic důležitého uprostřed.

Teď přesuňte stejná slova mezi turn. Kapitola 11 ukázala, že chat template není dekorace kolem modelu, ale jeho součást — <|im_start|>system a <|im_start|>user jsou skutečné token, které model během fine-tuning viděl milionkrát, přesně na těchto pozicích. Mělo by tedy záležet na tom, na které straně těchto značek vaše instrukce skončí, a záleží:

Přesun pravidel a instrukce přes hranici template přinesl 21,7 bodu — 19 případů získaných, 6 ztracených, párová pravděpodobnost 0,0146 — bez změny jediného znaku. To je konkrétní odpověď na system prompt versus user prompt: nejsou to dva způsoby, jak říct totéž. Jsou to dvě různé token pozice ve struktuře, na které byl model trénován, a system pozice je místo, kam patří instrukce platné pro celou konverzaci.

Všimněte si i třetího řádku. Zopakování instrukce za ticketem — široce doporučovaný trik — dosáhlo skóre nižšího než její jediné uvedení. Na tomto modelu, v této úloze, bylo říct to dvakrát horší než říct to jednou.

Stejný prompt, nejlepší umístění, šedesát případů. Mění se jen to, co obklopuje text ticketu.

Osmnáctibodový rozptyl způsobený interpunkcí. Ale podívejte se na dva krajní intervaly: [73,9, 91,9] a [54,1, 77,3]. Překrývají se. Hrubé čtení — porovnejte chybové úsečky, a pokud se dotýkají, neříkejte nic — by tvrdilo, že tahle tabulka nedokazuje vůbec nic.

Hrubé čtení je tady špatně a pochopit proč má větší hodnotu než samotná tabulka. Každá varianta byla hodnocena na stejných šedesáti ticketech, takže dvě měření nejsou nezávislé vzorky; jsou párová. Většina šířky každého intervalu pochází ze zdroje nejistoty, který sdílejí obě ramena — zda je těchto šedesát ticketů reprezentativních — a tento zdroj se při jejich vzájemném porovnání vyruší. Položte místo toho párovou otázku a odpověď je ostrá: přechod od dvojitých uvozovek ke značce XML otočil 12 případů na správné a 1 na chybný, párová pravděpodobnost 0,0034. To je skutečný rozdíl.

A tentýž test pak splaskne titulek. Značka XML porazila prostý label Ticket: o 8,3 bodu, což je číslo, které by blogový článek dal do titulku. Párově: 6 získaných, 1 ztracený, pravděpodobnost 0,1250. Neprokázáno. Sedm případů je základ, na kterém slavné zlepšení stojí.

Existují tedy dvě otázky se dvěma různými nástroji a jejich zaměňování je důvod, proč se rady k prompt mýlí oběma směry najednou:

Obecné zjištění — že modely jsou silně a nepředvídatelně citlivé na formátovací volby, které nenesou žádný sémantický obsah — není nové. Sclar et al. napříč desítkami úloh měnili jen oddělovače, mezery a velikost písmen a našli rozptyly přesnosti dost velké na to, aby převrátily publikovaná pořadí modelů.⁵ Praktický důsledek není „používejte značky XML“. Je to, že formátování je hyperparametr, jeho sweep nic nestojí a jakékoli porovnání dvou modelů, které fixuje jeden formát, porovnává formáty stejně jako modely.

In-context learning — ukazovat modelu v prompt vypracované příklady a nechat ho z nich zobecnit bez jakékoli aktualizace vah — je schopnost, která proslavila GPT-3.⁶ Praktická otázka nikdy nezní, jestli to funguje. Zní, za kolik příkladů platit.

Příklady se vkládají jako skutečné předchozí turn, střídavě user a assistant, protože to je struktura, na které byl template trénován. Každý k byl spuštěn s pěti různými náhodnými výběry z odděleného poolu šestnácti označených ticketů:

Dva příklady přinesly sedm bodů. Dalších šest příkladů nepřineslo nic měřitelného — 83,7, pak 81,7, pak 83,7, sekvence, která se toulá uvnitř vlastního šumu. Šestnáct přineslo dalších pět a půl. Křivka není hladké stoupání; je to schod, plošina a schod.

Nejdůležitější je poslední sloupec. Při k = 8 posunulo to, kterých osm příkladů jste náhodou vybrali, přesnost o 10 bodů — víc než celý zisk z přechodu ze dvou příkladů na osm. A spodní řádek je nejostřejší verze téhož: při k = 16 je pool vyčerpán, takže všech pět běhů obsahuje přesně stejných šestnáct příkladů, liší se jen pořadím, v jakém se objevují. Samotné pořadí posunulo přesnost o 8,3 bodu.

To je výsledek, který popsali Lu et al., a přežívá všude, kde ho někdo hledal: pořadí příkladů je skutečný hyperparametr s efekty srovnatelnými s počtem příkladů.⁷ Poctivá rada k few-shot prompting proto není číslo. Je to:

Teď folklor. Každá z nich je jedna věta přidaná na začátek system prompt, který je jinak identický, na stejných šedesáti případech.

Čtyři z pěti neudělaly nic. Ne „trochu pomohly“; nic, co by šedesát párových případů dokázalo vidět. Expertní persona i úplatek skončily pod nedotčeným baseline, a ani tyto poklesy neprojdou párovým testem — je to šum mířící z kopce.

Třetí řádek stojí za zastavení. „Tohle je velmi důležité pro mou kariéru“ vytvořilo přesně stejnou přesnost, 46 ze 60 — a deset z šedesáti odpovědí se změnilo, pět každým směrem. Souhrnná statistika byla identická, chování ne. Pokud je vaše evaluace jedno číslo nad malou sadou, změna, která přepíše šestinu vašich výstupů, může vypadat jako změna, která neudělala nic, a vy ji nasadíte s přesvědčením, že byla zdarma.

A pak hrozba, jediná věta, která pohnula jehlou — a pohnula jí o 35 bodů dolů, když otočila 24 případů ze správných na chybné. To není artefakt zaokrouhlení; to je jiné chování modelu. Poučení není „nikdy modelu nevyhrožujte“. Poučení je, že emoční rámování není inertní. Posouvá rozdělení, někdy prudce, směrem, který nikdo neodhadne ze čtení věty — právě proto se musí měřit, ne rozumově obhajovat.

Jedna výhrada, kterou vám tato kapitola dluží: těchto pět vět bylo testováno na jednom malém modelu a jedné úloze. Některé mají publikovanou oporu jinde — „zhluboka se nadechněte“ pochází z paperu, který hledal instrukce s vysokým skóre, ne že by je vymýšlel, což je jiné a lepší tvrzení než to, které pak kolovalo.⁸ Zobecňují se ne samotné věty. Zobecňuje se to, že seznam, který přežil v blogových článcích, a seznam, který přežije měření, jsou dva různé seznamy, a jediný způsob, jak zjistit, který držíte v ruce, je spustit bench.

Pravidlo, které opakuje každý — říkejte, co chcete, ne co nechcete — s obvyklou absencí čísla. Tady je číslo. Stejný požadavek na formát, napsaný třemi způsoby, s volným generováním modelu, aby bylo možné pozorovat compliance:

Tři zákazy dopadly hůř než jedna instrukce a přiměly model napsat pětkrát víc textu — přesný opak všech tří najednou. Přidání pozitivní věty zpět to zachránilo na 68 %.

Mechanismus není záhadný, jakmile si vzpomenete na kapitolu 8. Model vybírá další token z rozdělení podmíněného vším, co mu předcházelo, a zákaz vloží zakázanou věc do tohoto podmínění. Neexistuje operátor negace; existuje kontext, ve kterém se teď objevuje slovo.

To lze změřit přímo. Vezměte baseline prompt a přidejte jeden řádek: Do not use the shipping queue for software problems. Pak se podívejte jen na pětačtyřicet ticketů, které nejsou shipping tickets:

Pojmenování fronty ve snaze ji vyloučit způsobilo, že ji model vybral třikrát častěji, téměř ztrojnásobil pravděpodobnostní hmotu, kterou jí přidělil, a stálo 25 bodů celkové přesnosti — 16 případů ztracených proti 1 získanému, párová pravděpodobnost 0,0003.

Nemyslete na slona, změřeno. Přepis je vždy stejný: nahraďte zákaz pozitivním pravidlem, které ho učiní zbytečným. Ne „nepoužívejte shipping pro softwarové problémy“, ale „používejte shipping jen tehdy, když jde o fyzický balík“.

Kapitola 12 postavila chain of thought pořádně — nejdřív jako prompting techniku,⁹¹⁰ pak jako něco natrénovaného s ověřitelnými odměnami — a skončila varováním, které odložila do této kapitoly: říct modelu, aby myslel krok za krokem, přestává pomáhat, jakmile model uvažuje sám, a může škodit. Tady je to varování s tabulkou pod ním, na úloze, kde je snadné předpokládat, že víc přemýšlení musí být lepší.

Obě ramena se čtou stejným nástrojem na stejné pozici. Jediný rozdíl je v tom, zda v kontextu nejdřív sedí chain of thought, který model sám napsal.

Přesnost klesla a náklady stouply, a vlastní pravidlo této kapitoly platí i pro vlastní výsledek této kapitoly: pokles je 7 případů získaných proti 10 ztraceným, párová pravděpodobnost 0,629, což není prokázáno. Co prokázáno je, je to, že vzniklo devadesát osm extra output tokens na volání a nepřineslo to nic měřitelného. Nejistota je celá na straně přínosu. Účet je jistý.

Chain, který selže, je poučnější než ten, který funguje. Když měl model uvažovat o „Vaše integrace Slack po úterý přestala posílat zprávy“, napsal:

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.

To je kompetentní rada k troubleshooting a není to tato úloha. Když byl požádán, aby přemýšlel, model odplul do žánru, kterému se „přemýšlej krok za krokem o tomto ticketu podpory“ v jeho trénovacích datech nejvíc podobá — a pak odpověděl na klasifikační otázku pěti sty znaky nesouvisejícího uvažování ve vlastním kontextu. Chain of thought pomáhá u problémů s mezistavem, který stojí za výpočet: aritmetika, multi-hop lookupy, constraint satisfaction. Směrování věty do jedné ze čtyř přihrádek žádný mezistav nemá. Chain nemá co držet, takže jen přidává věrohodný text, který musí finální rozhodnutí přežít.

Dva praktické důsledky. Zaprvé, u modelu trénovaného k uvažování — RLVR modelů z kapitoly 12 — je instrukce horší než nadbytečná: může nahradit dlouhý chain, který by model vytvořil, krátkým, prompt-shaped řetězcem. A vzorkování několika chain a hlasování, což dělá self-consistency,¹¹ nezachrání úlohu, ve které není o čem se neshodnout: násobí náklady počtem vzorků, aby lámalo remízy, které neexistují. Kapitola 12 tento trade změřila tam, kde se uplatňuje. Zadruhé si všimněte, kolik stála samotná porovnávací konstrukce. Vynucení odpovědi do řádku Final queue: shodilo rameno bez uvažování ze 76,7 % na 61,7 %. Patnáct bodů zaplacených za to, aby byla dvě ramena porovnatelná. Ani struktura, která existuje pro vaše pohodlí, není zdarma.

Jedno poslední měření, protože to je otázka, kterou si po prvním překvapivém výsledku klade každý. Šedesát prompts, greedy decoding, opakovaně spuštěno:

• Stejné volání opakované se vším fixním vrátilo bitově identické pravděpodobnosti. Deterministické.
• Stejné volání batched s různými sousedy — velikosti batche 1, 4, 12, 30 a 60 — vrátilo pravděpodobnosti lišící se až o 0,0128. Zvolený label se nezměnil nikdy, v 0 ze 60 případů.

Label přežil, protože měl prostor: napříč šedesáti případy byla nejužší mezera mezi dvěma nejlepšími frontami 0,0459, tedy třiapůlkrát drift. Stabilita nebyla vlastností algoritmu. Byla to margin, a margin jednou dojdou. Kapitola 17 je místo, kde žije aritmetický důvod a kde se rozebírají sampling knoby, které tyto mezery rozšiřují a zužují. Důvod zasadit to sem je ten, že to vymezuje, co může jakékoli měření prompt znamenat: bench měří systém reprodukovatelný jen do tolerance a dvoubodový rozdíl mezi variantami je ve špatný den uvnitř této tolerance.

Všechno výše je člověk, který vybírá variantu, a stroj, který ji známkuje. Zřejmý další krok je nechat stroj vybírat i varianty.

APE dělá přesně to: model navrhuje kandidátní instrukce, ty se skórují na hold-out příkladech a nejlepší přežijí.⁸ Instrukce, které najde, jsou často takové, jaké by žádný člověk nenapsal, což je pointa — hledá se nad tím, co skóruje, ne nad tím, co zní profesionálně.

DSPy jde dál a pro produkt je to užitečnější myšlenka.¹² Deklarujete, co každý krok pipeline přijímá a vrací, a framework to zkompiluje do prompts, vybírá demonstrace a optimalizuje instrukce proti vaší metrice. Změníte model a překompilujete místo přepisování. Prompt přestává být zdrojový kód, který někdo ručně ladí, a stává se artefaktem generovaným proti metrice, což měl být od začátku.

Ani jedno neodstraňuje potřebu bench. Obojí z něj dělá jedinou věc, kterou potřebujete, protože optimalizátor bez metriky neoptimalizuje nic.

Zbývá disciplína. Prompts patří do version control, do souborů, vedle kódu, který je posílá — ne do řádku databáze, který někdo upravil v úterý. Potřebují identifikátor verze uložený vedle každého výstupu, který vytvořily, jinak v den regrese nezjistíte, co se změnilo. Potřebují bench v continuous integration, protože prompt je ta část systému, kterou vám vendor může tiše zneplatnit nasazením nového modelu. A potřebují případy: ne sto chytrých, jen nudných dvacet, které se rozbily minulý kvartál, uchovaných navždy. Bench je deliverable. Prompt je jeho vedlejší produkt.

Všechno v této kapitole bylo měřeno přesností. Každá z těch variant má také cenu.

System prompt, který přinesl 21,7 bodu, se posílá při každém volání, navždy. Dva příklady, které přinesly sedm bodů, se posílají při každém volání, navždy. Šestnáct, které přinesly dvanáct, se posílá při každém volání, navždy, a jsou zhruba desetkrát delší než otázka, kterou uživatel skutečně položil. Chain of thought, který nepřinesl nic, vytvořil devadesát osm extra tokens na request a output tokens jsou ten drahý druh.

Nic z toho není vidět v tabulce přesností a všechno z toho je vidět na faktuře.

Kapitola 16 je o jednotce, ve které jsou tato rozhodnutí skutečně denominována. Token jako fakturační jednotka, context window jako rozpočet místo paměti, proč konverzace o čtyřiceti turn stojí mnohem víc než čtyřicetinásobek prvního turn, za co prompt caching platí a za co ne, a proč pořadí vašeho prompt rozhoduje, jestli cache vůbec zasáhne — což se ukáže jako druhý, čistě ekonomický důvod dávat stabilní materiál dopředu a proměnlivý materiál dozadu.

Bench a každá tabulka vznikly s Qwen/Qwen2.5-0.5B-Instruct pod greedy decoding, takže se reprodukují přesně. Dokumentace Hugging Face k chat templates je referencí pro to, na co se template markers z kapitoly 11 skutečně rozbalují, a pro fakt, že model dodaný se špatnou template je skutečné a opakované selhání. Pro poziční a formátové efekty v produkčním měřítku místo laboratorního jsou primárními zdroji citace výše; vendor prompting guides jsou užitečné svými příklady a měly by se číst s vědomím, že žádný z nich nepublikuje interval.