Prompt engineering, mérve: mi változtatja meg a kimenetet

A mérések előtt egy tény, amely csendben megmagyarázza a következők felét.

A modelnek nincs memóriája. Két hívás között semmit sem őriz meg — sem az előző kérdésedet, sem a saját előző válaszát, sem a csatolt fájlt, sem azt, hogy már kétszer megkérdezted. Minden hívás üres gépről indul, és az egyetlen dolog, amit az a gép tud, az a tokenek sorozata, amelyet éppen átadtál neki.

Ami egy chatfelületen memóriának látszik, az az, hogy a kliensed újraküldi az egész beszélgetést, minden turnt, az elejétől. A model minden alkalommal újraolvassa az egészet a nulláról. A 13. fejezet megmérte, mennyibe kerül ez az újraolvasás egy forward passben; a 16. fejezet számlasorrá alakítja. Itt a designra gyakorolt következmény számít: a prompt nem üzenet egy állapottal rendelkező rendszernek. A prompt maga az állapot.

Ez félreértések egész családját nyugdíjazza. „A model elfelejtette, amit mondtam neki” általában azt jelenti, hogy sosem lett elküldve. „Figyelmen kívül hagyta a korábbi utasításomat” általában azt jelenti, hogy az utasítás kiesett az ablakból, amikor az előzményt csonkolták. „Másképp viselkedett productionben” általában azt jelenti, hogy a production más promptot állít össze, mint amit teszteltél. Ezek egyike sem modelprobléma, és egyik sem javítható átírással.

Az az állítás, hogy „ez a prompt jobb”, egy eloszlásról szóló állítás, és egyetlen kimenetre nézve nem látsz eloszlást. Ami kell, unalmas: ismert válaszú esetek, N változat és egy intervallum.

A harness ötven sor TypeScript, ugyanolyan felépítéssel, mint a 14. fejezet kliense — egy kérés, egy határidő, némi concurrency, egy számláló. A 19. fejezetben újra előkerül egy retriever értékelésére, a 29. fejezetben pedig golden setként.

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

A visszatérő szám nem az eredmény. Ez az:

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

A 4. fejezet felépítette az érvet, ez a fejezet pedig beváltja. Húszból tizenhét helyes 85 %, és a 95 %-os intervalluma 64 %-tól 95 %-ig fut. Egy húszból 13-at elérő változat — 65 %, ami érzésre egyértelműen rosszabb — 43 %-tól 82 %-ig tartó intervallummal rendelkezik. Ez a két intervallum szinte teljes hosszában átfed. Húsz eset nem tud megkülönböztetni egy jó promptot egy közepestől, és a legtöbb publikált prompttanácsot ennél kevesebben validálták.

Hatvan eset, amennyit ez a fejezet használ, még mindig nem sok. Elég ahhoz, hogy nagy hatásokat lássunk, és elég őszinte ahhoz, hogy beismerje, amikor a kicsiket nem látja — és ezt lentebb többször is meg fogja tenni.

Három blokk — a szabályok R, a ticket T, az utasítás I — egyetlen user üzenetté összefűzve. Mind a hat permutáció, byte-ra azonos tartalom, mindegyik hatvan eseten.

A legjobbtól a legrosszabbig 28,3 pont a különbség, és az intervallumok nem fednek át, tehát ez nem zajról szóló történet. Mivel minden kart ugyanazon a hatvan elemen pontozunk, az élesebb kérdés a párosított: azokban az esetekben, ahol két kar eltér, mennyire ferde a megoszlás? A legrosszabb sorrendről a legjobbra váltva 21 eset lett helyes és 4 lett rossz — az egzakt párosított valószínűség 0,0009.³

A táblát inkább a formája, mint a győztese miatt olvasd. A két legjobb sor mindkettője a tickettel végződik; a két legrosszabb mindkettője középre temeti az utasítást, vagy az adatok után húzza. Ugyanaz a jelenség, amelyet Liu és társai Lost in the Middle néven írtak le: a prompt szélein lévő anyagot megbízhatóbban használják a modellek, mint a középen lévőt.⁴ A 16. fejezet beárazza az ablakot, a 24. fejezet pedig hosszban méri meg rendesen a hatást, ahol a közép a leírt módon összeomlik, és a legvégén látható helyreállás nem tér vissza. Itt a gyakorlati szabály magától esik ki: feladat felül, adat alul, semmi fontos középen.

Most mozgasd ugyanazokat a szavakat turnök között. A 11. fejezet megmutatta, hogy a chat template nem díszítés a model körül, hanem a része — <|im_start|>system és <|im_start|>user valódi tokenek, amelyeket a model milliószor látott fine-tuning során, pontosan ezekben a pozíciókban. Tehát számítania kell, hogy az utasításod e markerek melyik oldalára kerül, és számít is:

A szabályok és az utasítás áthelyezése a template-határon 21,7 pontot hozott — 19 eset nyert, 6 veszett, párosított valószínűség 0,0146 — anélkül, hogy egy karakterük megváltozott volna. Ez a konkrét válasz arra, hogy system prompt versus user prompt: nem ugyanannak a dolognak két megfogalmazása. Két különböző tokenpozíció egy olyan struktúrában, amelyen a modelt betanították, és a system pozíció az, ahová az egész beszélgetésre vonatkozó utasítások tartoznak.

Figyeld meg a harmadik sort is. Az utasítás megismétlése a ticket után — széles körben ajánlott trükk — rosszabbul teljesített, mint egyszer kimondani. Ezen a modellen, ezen a feladaton kétszer kimondani rosszabb volt, mint egyszer kimondani.

Ugyanaz a prompt, legjobb elhelyezés, hatvan eset. Csak az változik, mi veszi körül a ticket szövegét.

Tizennyolc pontos szórás írásjelekből. De nézd meg a két szélső intervallumot: [73,9, 91,9] és [54,1, 77,3]. Átfednek. A durva olvasat szerint — hasonlítsd össze a hibasávokat, és ha összeérnek, ne mondj semmit — ez a tábla semmit sem bizonyít.

A durva olvasat itt rossz, és megérteni, miért, többet ér, mint maga a tábla. Minden változatot ugyanazon a hatvan ticketen pontozunk, tehát a két mérés nem független minta; párosítottak. Az egyes intervallumok szélességének nagy része olyan bizonytalansági forrásból jön, amelyet mindkét kar megoszt — hogy ez a hatvan ticket reprezentatív-e —, és ez a forrás kioltódik, amikor egymáshoz hasonlítod őket. Tedd fel inkább a párosított kérdést, és a válasz éles: dupla idézőjelekről XML tagre váltva 12 eset lett helyes és 1 rossz, párosított valószínűség 0,0034. Ez valós különbség.

És aztán ugyanaz a teszt leengedi a címsort. Az XML tag 8,3 ponttal verte a sima Ticket: címkét, ezt a számot tenné a címébe egy blogposzt. Párosítva: 6 nyereség, 1 veszteség, valószínűség 0,1250. Nem bizonyított. Hét eset az, amin ez a híres javulás nyugszik.

Tehát két kérdés van két különböző műszerrel, és ezek összemosása az, ahogyan a prompttanács egyszerre megy félre mindkét irányban:

Az általános eredmény — hogy a modellek erősen és kiszámíthatatlanul érzékenyek a szemantikai tartalmat nem hordozó formázási választásokra — nem új. Sclar és társai tucatnyi feladaton csak elválasztókat, térközöket és kis-/nagybetűzést variáltak, és olyan széles pontosságszórásokat találtak, amelyek publikált modelrangsort is megfordítottak.⁵ A gyakorlati következmény nem az, hogy „használj XML tageket”. Hanem az, hogy a formázás hyperparameter, semmibe sem kerül végigpróbálni, és bármely két model összehasonlítása, amely rögzít egy formátumot, a formátumokat legalább annyira hasonlítja, mint a modelleket.

Az in-context learning — amikor a promptban kidolgozott példákat mutatsz a modelnek, és súlyfrissítés nélkül általánosít belőlük — az a képesség, amely híressé tette a GPT-3-at.⁶ A gyakorlati kérdés sosem az, hogy működik-e. Hanem az, hány példáért érdemes fizetni.

A példák valódi korábbi turnökként kerülnek be, váltakozó user és assistant formában, mert ez az a struktúra, amelyen a template-et betanították. Minden k öt különböző véletlen húzással futott egy elkülönített, tizenhat címkézett ticketből álló poolból:

Két példa hét pontot hozott. A következő hat példa semmi mérhetőt — 83,7, aztán 81,7, aztán 83,7, egy sorozat, amely a saját zaján belül kóborol. Tizenhat újabb öt és felet hozott. A görbe nem sima emelkedés; egy lépcső, egy plató és egy lépcső.

A legfontosabb oszlop az utolsó. k = 8 mellett az, hogy történetesen melyik nyolc példát választottad, 10 ponttal mozgatta a pontosságot — ez nagyobb, mint a teljes nyereség két példáról nyolcra. És az alsó sor ennek a legélesebb változata: k = 16 mellett a pool kimerül, tehát mind az öt futás pontosan ugyanazt a tizenhat példát tartalmazza, csak a sorrendjük különbözik. Egyedül a sorrend 8,3 ponttal mozgatta a pontosságot.

Ezt az eredményt közölte Lu és társai, és mindenhol túléli, ahol keresték: a példák sorrendje valódi hyperparameter, a példaszámhoz mérhető hatásokkal.⁷ Tehát a few-shot promptingról szóló őszinte tanács nem egy szám. Hanem ez:

Most a folklór. Mindegyik egyetlen mondat, amely egy egyébként azonos system prompt elé kerül, ugyanazon a hatvan eseten.

Az ötből négy semmit sem csinált. Nem „egy kicsit csinált”; semmit, amit hatvan párosított eset látni tudna. Az expert persona és a megvesztegetés is az érintetlen alapvonal alatt teljesített, és még ezek az esések sem mennek át a párosított teszten — lefelé mutató zajok.

A harmadik sorral érdemes elidőzni. „Ez nagyon fontos a karrierem szempontjából” pontosan ugyanazt a pontosságot hozta, 46-ot 60-ból — és a hatvan válaszból tíz megváltozott, öt-öt mindkét irányban. Az összesítő statisztika azonos volt, a viselkedés nem. Ha az értékelésed egyetlen szám egy kis készleten, egy változás, amely a kimeneteid egyhatodát átírja, úgy nézhet ki, mint ami semmit sem csinált, és abban a hitben fogod shipelni, hogy ingyen volt.

Aztán jön a fenyegetés, az egyetlen mondat, amely megmozdította a mutatót, méghozzá 35 ponttal lefelé, 24 esetet fordítva helyesről rosszra. Ez nem kerekítési műtermék; más modelviselkedés. A lecke nem az, hogy „sose fenyegess modelt”. Hanem az, hogy az érzelmi keretezés nem inert. Elmozdítja az eloszlást, néha keményen, olyan irányba, amelyet senki sem tud megjósolni a mondat olvasásából — pontosan ezért mérni kell, nem okoskodni róla.

Egy caveat, amellyel ez a fejezet tartozik neked: ezt az öt mondatot egy kis modellen és egy feladaton teszteltük. Némelyikhez máshol van publikált támogatás — a „vegyél egy mély levegőt” egy olyan cikkből jött, amely magas pontszámú utasításokat keresett, nem kitalálta őket, ami más és jobb állítás annál, mint ami utána elterjedt.⁸ Ami általánosít, nem a mondatok. Hanem az, hogy a blogposztokban túlélő lista és a mérésben túlélő lista két különböző lista, és az egyetlen módja annak, hogy tudd, melyik van nálad, a bench futtatása.

Egy szabály, amelyet mindenki ismétel — azt mondd, amit akarsz, ne azt, amit nem akarsz — a szokásos számhiánnyal. Itt a szám. Ugyanaz a formátumkövetelmény háromféleképp megírva, a model szabad generálásával, hogy a megfelelés megfigyelhető legyen:

Három tiltás rosszabbul teljesített, mint egy utasítás, és a modelt ötször több szöveg írására késztette — mindháromnak egyszerre pontosan az ellenkezőjére. A pozitív mondat visszaadása 68 %-ra mentette.

A mechanizmus nem rejtélyes, ha emlékszel a 8. fejezetre. A model a korábbiakra kondicionált eloszlásból választ következő tokent, és egy tiltás a tiltott dolgot beleteszi ebbe a kondicionálásba. Nincs operátor a tagadásra; van egy kontextus, amelyben egy szó most megjelenik.

Ez közvetlenül mérhető. Vedd az alap promptot, és adj hozzá egy sort: Do not use the shipping queue for software problems. Aztán csak azt a negyvenöt ticketet nézd, amelyek nem shipping ticketek:

Egy sor megnevezése azért, hogy kizárjuk, arra késztette a modelt, hogy háromszor gyakrabban válassza, majdnem megháromszorozta a neki adott valószínűségi tömeget, és 25 pontnyi teljes pontosságba került — 16 elvesztett eset 1 nyert ellenében, párosított valószínűség 0,0003.

Ne gondolj az elefántra, megmérve. Az átírás mindig ugyanaz: cseréld a tiltást arra a pozitív szabályra, amely szükségtelenné teszi. Nem „ne használd a shippinget szoftverproblémákra”, hanem „shippinget csak akkor használj, ha fizikai csomagról van szó”.

A 12. fejezet rendesen felépítette a chain of thoughtot — először prompting technikaként,⁹¹⁰ majd verifikálható jutalmakkal betanított dologként —, és egy figyelmeztetéssel zárult, amelyet erre a fejezetre halasztott: ha azt mondod egy modelnek, hogy gondolkodjon lépésről lépésre, az már nem segít, amikor a model magától is érvel, sőt árthat. Itt ez a figyelmeztetés táblával alatta, egy olyan feladaton, ahol könnyű feltételezni, hogy a több gondolkodás csak jobb lehet.

Mindkét kart ugyanazzal a műszerrel, ugyanazon a pozíción olvassuk. Az egyetlen különbség az, hogy előbb egy, a model által írt chain of thought ül-e a kontextusban.

A pontosság csökkent, a költség nőtt, és ennek a fejezetnek a saját szabálya ennek a fejezetnek a saját eredményére is érvényes: az esés 7 nyert eset 10 elvesztett ellenében, párosított valószínűség 0,629, ami nincs bizonyítva. Ami bizonyított, az az, hogy hívásonként kilencvennyolc extra kimeneti tokent termelt, és semmi mérhetőt nem vásárolt velük. A bizonytalanság teljesen a haszon oldalán van. A számla biztos.

Egy elbukó chain tanulságosabb, mint egy működő. Amikor arra kértük, hogy érveljen erről: „A Slack-integrációd kedd óta nem posztol üzeneteket”, a model ezt írta:

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.

Ez kompetens hibaelhárítási tanács, és nem ez a feladat. Gondolkodásra kérve a model belesodródott abba a műfajba, amelyre a „gondolkodj lépésről lépésre erről a support ticketről” a leginkább hasonlít a training data alapján — majd egy klasszifikációs kérdésre ötszáz karakter irreleváns érveléssel válaszolt a saját kontextusában. A chain of thought olyan problémákon segít, ahol érdemes köztes állapotot kiszámítani: aritmetika, multi-hop lookupok, constraint satisfaction. Egy mondat négy vödör egyikébe route-olásának nincs köztes állapota. Nincs mit tartania a chainnek, így csak hihető szöveget ad hozzá, amelyet a végső döntésnek aztán túl kell élnie.

Két gyakorlati következmény. Először, egy érvelésre betanított modelnél — a 12. fejezet RLVR modelljeinél — az utasítás rosszabb, mint redundáns: lecserélheti azt a hosszú chaint, amelyet a model magától létrehozott volna, egy rövid, prompt-alakúra. És több chain mintavétele és szavaztatása, amit a self-consistency tesz,¹¹ nem ment meg olyan feladatot, ahol nincs min vitatkozni: megsokszorozza a költséget a minták számával, hogy olyan döntetleneket törjön meg, amelyek nincsenek. A 12. fejezet ott mérte ezt a trade-offot, ahol alkalmazható. Másodszor, figyeld meg, mennyibe került maga az összehasonlító scaffold. A válasz Final queue: sorba kényszerítése 76,7 %-ról 61,7 %-ra ejtette a reasoning nélküli kart. Tizenöt pont, azért fizetve, hogy a két kar összehasonlítható legyen. A kényelmedért létező struktúra sem ingyenes.

Még egy utolsó mérés, mert ez az a kérdés, amelyet mindenki feltesz az első meglepő eredmény után. Hatvan prompt, greedy decoding, ismételten futtatva:

• Ugyanaz a hívás, minden rögzítve, bitre azonos valószínűségeket adott vissza. Determinisztikus.
• Ugyanaz a hívás különböző szomszédokkal batchelve — batchméretek 1, 4, 12, 30 és 60 — legfeljebb 0,0128 eltérésű valószínűségeket adott vissza. A választott címke egyszer sem változott, 60 esetből 0-ban.

A címke azért élte túl, mert volt tere: a hatvan esetben a két legjobb sor közötti legszűkebb rés 0,0459 volt, a drift három és félszerese. A stabilitás nem az algoritmus tulajdonsága volt. Margin volt, és a marginok elfogynak. A 17. fejezet az, ahol az aritmetikai ok lakik, és ahol szétszedjük a sampling gombokat, amelyek szélesítik és szűkítik ezeket a réseket. Azért kell itt elültetni, mert behatárolja, mit jelenthet bármilyen promptmérés: a bench egy olyan rendszert mér, amely csak tűréshatáron belül reprodukálható, és a változatok közötti kétpontos különbség rossz napon ezen a tűréshatáron belül van.

A fentiekben mindenhol ember választott változatot, és gép osztályozta. A nyilvánvaló következő lépés az, hogy a gép válassza a változatokat is.

APE pontosan ezt teszi: egy model jelölt utasításokat javasol, ezeket held-out példákon pontozzák, és a legjobbak túlélnek.⁸ Az általa talált utasítások gyakran olyanok, amelyeket ember nem írna le, és éppen ez a lényeg — a keresés azon fut, hogy mi pontoz jól, nem azon, hogy mi hangzik professzionálisnak.

DSPy továbbmegy, és termékhez hasznosabb ötlet.¹² Deklarálod, hogy egy pipeline minden lépése mit vesz fel és mit ad vissza, a framework pedig ezt promptokká fordítja, demonstrációkat választ és az utasításokat a metrikádra optimalizálja. Modelt váltasz, és újrafordítasz átírás helyett. A prompt megszűnik kézzel hangolt forráskód lenni, és metrika ellen generált artefakttá válik, aminek mindvégig lennie kellett volna.

Egyik sem szünteti meg a bench szükségességét. Mindkettő azt teszi az egyetlen dologgá, amire szükséged van, mert metrika nélküli optimalizáló semmit sem optimalizál.

Marad a fegyelem. A promptoknak verziókövetésben, fájlokban, az őket küldő kód mellett a helyük — nem egy adatbázissorban, amelyet valaki kedden szerkesztett. Kell hozzájuk egy verzióazonosító, amelyet minden általuk előállított kimenet mellett eltárolsz, különben amikor valami regresszál, nem tudod kideríteni, mi változott. Kell hozzájuk a bench continuous integrationben, mert a prompt a rendszered egyetlen olyan része, amelyet egy vendor csendben érvényteleníthet egy új model telepítésével. És kellenek esetek: nem száz okos, csak az az unalmas húsz, amely az előző negyedévben eltört, örökre megtartva. A bench a deliverable. A prompt a mellékterméke.

Ebben a fejezetben mindent pontosságban mértünk. Minden ilyen változatnak ára is van.

A system prompt, amely 21,7 pontot hozott, minden hívásnál elmegy, örökre. A két példa, amely hét pontot hozott, minden hívásnál elmegy, örökre. A tizenhat, amely tizenkettőt hozott, minden hívásnál elmegy, örökre, és nagyjából tízszer olyan hosszú, mint a kérdés, amelyet a felhasználó ténylegesen feltett. A chain of thought, amely semmit sem hozott, kilencvennyolc extra tokent termelt kérésenként, és a kimeneti tokenek a drága fajták.

Ebből semmi sem látszik egy pontosságtáblában, és mindez látszik egy számlán.

A 16. fejezet arról az egységről szól, amelyben ezek a döntések valójában denominálva vannak. A token mint számlázási egység, a context window mint budget, nem memória, miért kerül egy negyven turnös beszélgetés sokkal többe, mint az első turn negyvenszerese, mit fizet meg és mit nem a prompt caching, és miért dönti el a promptod sorrendje, hogy a cache egyáltalán talál-e — ami kiderül, hogy egy második, teljesen gazdasági ok arra, hogy a stabil anyagot előre, a változót hátra tedd.

A bench és minden tábla Qwen/Qwen2.5-0.5B-Instruct alatt, greedy decodinggal készült, így pontosan reprodukálhatók. A Hugging Face chat template dokumentációja a referencia arra, hogy a 11. fejezet template markerjei valójában mire expandálnak, és arra, hogy egy rossz template-tel shipelt model valós és visszatérő hiba. A position és format hatásokra production scale-en, nem laboratóriumi léptékben, a fenti hivatkozások az elsődleges források; a vendor prompting útmutatók a példáik miatt hasznosak, és azzal a tudattal olvasandók, hogy egyikük sem publikál intervallumot.