Prompt engineering, măsurat: ce schimbă output-ul

Înainte de măsurători, un fapt care explică discret jumătate din ce urmează.

Modelul nu are memorie. Între două apeluri nu păstrează nimic — nici ultima ta întrebare, nici propriul ultim răspuns, nici fișierul pe care l-ai atașat, nici faptul că l-ai întrebat deja de două ori. Fiecare apel pornește de la o mașină goală, iar singurul lucru pe care acea mașină îl știe este secvența de tokens pe care tocmai i-ai dat-o.

Ceea ce pare memorie într-o interfață de chat este clientul tău care retrimite întreaga conversație, fiecare turn, de la început. Modelul o citește din nou pe toată, de la zero, de fiecare dată. Capitolul 13 a măsurat costul acestei recitiri într-un forward pass; Capitolul 16 îl transformă într-o linie pe factură. Ce contează aici este consecința pentru design: prompt-ul nu este un mesaj către un sistem care are stare. Este starea.

Asta scoate din discuție o familie de confuzii. „Modelul a uitat ce i-am spus” înseamnă, de obicei, că acel lucru nu a fost trimis niciodată. „A ignorat instrucțiunea mea anterioară” înseamnă, de obicei, că instrucțiunea a ieșit din window când istoricul a fost trunchiat. „S-a comportat diferit în producție” înseamnă, de obicei, că producția asamblează un prompt diferit de cel pe care l-ai testat. Niciuna dintre acestea nu este o problemă de model și niciuna nu se repară reformulând ceva.

Afirmația „acest prompt este mai bun” este o afirmație despre o distribuție, iar o distribuție nu se vede uitându-te la un singur output. Ai nevoie de ceva plictisitor: cazuri cu răspunsuri cunoscute, N variante și un interval.

Harness-ul are cincizeci de linii de TypeScript, cu aceeași formă ca clientul din Capitolul 14 — o cerere, un deadline, ceva concurență, o numărătoare. Reapare în Capitolul 19 pentru a evalua un retriever și în Capitolul 29 ca 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 };
}

Numărul care se întoarce nu este rezultatul. Acesta este:

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

Capitolul 4 a făcut argumentul, iar acest capitol îl încasează. Șaptesprezece răspunsuri corecte din douăzeci înseamnă 85 %, iar intervalul său de 95 % merge de la 64 % la 95 %. O variantă care obține 13 din 20 — 65 %, ceea ce pare clar mai rău — are un interval de la 43 % la 82 %. Cele două intervale se suprapun pe aproape toată lungimea lor. Douăzeci de cazuri nu pot deosebi un prompt bun de unul mediocru, iar majoritatea sfaturilor publicate despre prompt au fost validate pe mai puține.

Șaizeci de cazuri, câte folosește acest capitol, tot nu înseamnă multe. Sunt suficiente ca să vezi efecte mari și suficient de oneste ca să recunoască atunci când nu pot vedea efecte mici — iar asta se va întâmpla de mai multe ori mai jos.

Trei blocuri — regulile R, tichetul T, instrucțiunea I — concatenate într-un singur mesaj de user. Toate cele șase permutări, conținut identic la nivel de byte, șaizeci de cazuri fiecare.

De la cel mai bun la cel mai rău sunt 28,3 puncte, iar intervalele nu se suprapun, deci aici nu vorbim despre zgomot. Cum fiecare arm este punctat pe aceleași șaizeci de itemi, întrebarea mai tăioasă este cea pereche: dintre cazurile în care două arms nu sunt de acord, cât de dezechilibrată este împărțirea? Trecerea de la cea mai proastă ordine la cea mai bună a întors 21 de cazuri în corect și 4 în greșit — probabilitate pereche exactă 0,0009.³

Citește tabelul pentru forma lui, nu pentru câștigător. Cele mai bune două rânduri ambele se termină cu tichetul; cele mai proaste două fie îngroapă instrucțiunea la mijloc, fie o lasă după date. Este același fenomen pe care Liu et al. l-au numit Lost in the Middle: materialul de la marginile unui prompt este folosit mai fiabil decât materialul din centru.⁴ Capitolul 16 pune preț pe window, iar Capitolul 24 măsoară corect efectul la lungime, unde mijlocul se prăbușește așa cum este descris, iar recuperarea de la finalul extrem nu reapare. Aici regula practică apare singură: task-ul sus, datele jos, nimic important la mijloc.

Acum mută aceleași cuvinte între turns. Capitolul 11 a stabilit că chat template-ul nu este decor în jurul modelului, ci parte din el — <|im_start|>system și <|im_start|>user sunt tokens reali pe care modelul i-a văzut de milioane de ori în timpul fine-tuning, exact în acele poziții. Așadar ar trebui să conteze de care parte a acelor markeri ajunge instrucțiunea ta, și contează:

Mutarea regulilor și a instrucțiunii peste granița template-ului a cumpărat 21,7 puncte — 19 cazuri câștigate, 6 pierdute, probabilitate pereche 0,0146 — fără să le schimbe un caracter. Acesta este răspunsul concret la system prompt versus user prompt: nu sunt două moduri de a spune același lucru. Sunt două poziții diferite de token într-o structură pe care modelul a fost antrenat, iar poziția system este locul instrucțiunilor care se aplică întregii conversații.

Observă și al treilea rând. Repetarea instrucțiunii după tichet — un truc recomandat pe scară largă — a obținut un scor sub formularea ei o singură dată. Pe acest model, pe acest task, a spune de două ori a fost mai rău decât a spune o dată.

Același prompt, cea mai bună plasare, șaizeci de cazuri. Singurul lucru care se schimbă este ce înconjoară textul tichetului.

O diferență de optsprezece puncte din punctuație. Dar uită-te la cele două intervale extreme: [73,9, 91,9] și [54,1, 77,3]. Se suprapun. După lectura grosieră — compară barele de eroare și, dacă se ating, nu spune nimic — acest tabel nu dovedește absolut nimic.

Lectura grosieră este greșită aici, iar a înțelege de ce valorează mai mult decât tabelul. Fiecare variantă a fost punctată pe aceleași șaizeci de tichete, deci cele două măsurători nu sunt eșantioane independente; sunt pereche. Cea mai mare parte din lățimea fiecărui interval vine dintr-o sursă de incertitudine pe care ambele arms o împart — dacă aceste șaizeci de tichete sunt reprezentative — iar acea sursă se anulează când le compari între ele. Pune întrebarea pereche în schimb, iar răspunsul este clar: trecerea de la ghilimele duble la tag-ul XML a întors 12 cazuri în corect și 1 în greșit, probabilitate pereche 0,0034. Aceasta este o diferență reală.

Și apoi același test dezumflă titlul. Tag-ul XML a bătut eticheta simplă Ticket: cu 8,3 puncte, numărul pe care un articol de blog l-ar pune în titlu. Pereche: 6 câștigate, 1 pierdut, probabilitate 0,1250. Nu este stabilit. Șapte cazuri sunt baza acelei îmbunătățiri celebre.

Așadar există două întrebări cu două instrumente diferite, iar amestecarea lor este felul în care sfaturile despre prompt greșesc în ambele direcții deodată:

Constatarea generală — că modelele sunt puternic și imprevizibil sensibile la alegeri de formatare fără conținut semantic — nu este nouă. Sclar et al. au variat doar separatorii, spațierea și capitalizarea pe zeci de task-uri și au găsit diferențe de acuratețe suficient de mari încât să inverseze clasamente publicate ale modelelor.⁵ Consecința practică nu este „folosește tag-uri XML”. Este că formatarea este un hiperparametru, nu costă nimic să o sweep-uiești, iar orice comparație între două modele care fixează un format compară formate aproape la fel de mult ca modele.

In-context learning — să îi arăți modelului exemple rezolvate în prompt și să îl faci să generalizeze din ele fără nicio actualizare de weights — este capabilitatea care a făcut GPT-3 celebru.⁶ Întrebarea practică nu este niciodată dacă funcționează. Este câte exemple merită plătite.

Exemplele intră ca prior turns reale, alternând user și assistant, pentru că aceasta este structura pe care template-ul a fost antrenat. Fiecare k a fost rulat cu cinci extrageri aleatoare diferite dintr-un pool disjunct de șaisprezece tichete etichetate:

Două exemple au cumpărat șapte puncte. Următoarele șase exemple nu au cumpărat nimic măsurabil — 83,7, apoi 81,7, apoi 83,7, o secvență care rătăcește în propriul zgomot. Șaisprezece au mai cumpărat încă cinci și jumătate. Curba nu este o urcare lină; este o treaptă, un platou și o treaptă.

Coloana care contează cel mai mult este ultima. La k = 8, care opt exemple s-a întâmplat să alegi a mutat acuratețea cu 10 puncte — mai mult decât întregul câștig de la două exemple la opt. Iar ultimul rând este versiunea cea mai clară: la k = 16 pool-ul este epuizat, deci toate cele cinci rulări conțin exact aceleași șaisprezece exemple, diferind doar prin ordinea în care apar. Doar ordinea a mutat acuratețea cu 8,3 puncte.

Acesta este rezultatul raportat de Lu et al. și supraviețuiește oriunde a fost căutat: ordinea exemplelor este un hiperparametru real, cu efecte comparabile cu numărul de exemple.⁷ Așadar sfatul onest despre few-shot prompting nu este un număr. Este:

Acum folclorul. Fiecare dintre acestea este o singură propoziție prefixată unui system prompt care altfel este identic, pe aceleași șaizeci de cazuri.

Patru din cele cinci nu au făcut nimic. Nu „au făcut puțin”; nimic ce șaizeci de cazuri pereche pot vedea. Persona de expert și mita au obținut ambele scoruri sub baseline-ul neatins, și chiar și acele scăderi pică testul pereche — sunt zgomot care arată în jos.

Al treilea rând este cel la care merită să stai. „Acest lucru este foarte important pentru cariera mea” a produs exact aceeași acuratețe, 46 din 60 — și zece dintre cele șaizeci de răspunsuri s-au schimbat, cinci în fiecare direcție. Statistica de rezumat a fost identică, iar comportamentul nu. Dacă evaluarea ta este un singur număr pe un set mic, o schimbare care rescrie o șesime din output-urile tale poate arăta ca o schimbare care nu a făcut nimic, iar tu o vei lansa crezând că a fost gratuită.

Și apoi amenințarea, singura propoziție care a mișcat acul și l-a mișcat 35 de puncte în jos, întorcând 24 de cazuri din corect în greșit. Nu este un artefact de rotunjire; este un comportament diferit al modelului. Lecția nu este „nu amenința niciodată un model”. Este că încadrarea emoțională nu este inertă. Mută distribuția, uneori puternic, într-o direcție pe care nimeni nu o poate prezice citind propoziția — exact de aceea trebuie măsurată, nu raționată.

O rezervă pe care acest capitol ți-o datorează: aceste cinci propoziții au fost testate pe un singur model mic și un singur task. Unele au sprijin publicat în altă parte — „respiră adânc” a ieșit dintr-o lucrare care a căutat instrucțiuni cu scor mare, în loc să le inventeze, ceea ce este o afirmație diferită și mai bună decât cea care a circulat după aceea.⁸ Ce se generalizează nu sunt propozițiile. Este faptul că lista care a supraviețuit în articole de blog și lista care supraviețuiește măsurătorii sunt două liste diferite, iar singura cale să știi pe care o ai în mână este să rulezi bench-ul.

O regulă pe care toată lumea o repetă — spune ce vrei, nu ce nu vrei — cu obișnuita absență a unui număr. Iată numărul. Aceeași cerință de format, scrisă în trei feluri, cu modelul generând liber astfel încât conformarea să poată fi observată:

Trei interdicții au mers mai prost decât o singură instrucțiune și au făcut modelul să scrie de cinci ori mai mult text — exact opusul tuturor celor trei deodată. Adăugarea propoziției pozitive înapoi l-a salvat până la 68 %.

Mecanismul nu este misterios după ce îți amintești Capitolul 8. Modelul alege următorul token dintr-o distribuție condiționată de tot ce a fost înaintea lui, iar o interdicție pune lucrul interzis în acea condiționare. Nu există operator pentru negație; există un context în care un cuvânt apare acum.

Ceea ce se poate măsura direct. Ia prompt-ul baseline și adaugă o linie: Do not use the shipping queue for software problems. Apoi uită-te doar la cele patruzeci și cinci de tichete care nu sunt tichete de expediere:

Numirea unei cozi ca să o excluzi a făcut modelul să o aleagă de trei ori mai des, aproape a triplat masa de probabilitate pe care i-a atribuit-o și a costat 25 de puncte de acuratețe totală — 16 cazuri pierdute față de 1 câștigat, probabilitate pereche 0,0003.

Nu te gândi la un elefant, măsurat. Rescrierea este mereu aceeași: înlocuiește interdicția cu regula pozitivă care o face inutilă. Nu „nu folosi expediere pentru probleme software”, ci „folosește expediere doar când este implicat un colet fizic”.

Capitolul 12 a construit chain of thought corect — mai întâi ca tehnică de prompting,⁹¹⁰ apoi ca ceva antrenat cu recompense verificabile — și s-a încheiat cu un avertisment amânat până la acest capitol: a spune unui model să gândească pas cu pas încetează să mai ajute odată ce modelul raționează singur și poate dăuna. Iată acel avertisment cu un tabel sub el, pe un task unde este ușor să presupui că mai multă gândire trebuie să fie mai bine.

Ambele arms sunt citite cu același instrument în aceeași poziție. Singura diferență este dacă un chain of thought scris de model însuși stă primul în context.

Acuratețea a scăzut și costul a crescut, iar regula proprie a acestui capitol se aplică propriului rezultat: scăderea este 7 cazuri câștigate față de 10 pierdute, probabilitate pereche 0,629, ceea ce nu este stabilit. Ce este stabilit este că a produs nouăzeci și opt de output tokens extra per apel și nu a cumpărat nimic măsurabil cu ei. Incertitudinea este complet pe partea beneficiului. Nota de plată este sigură.

Un chain care eșuează este mai instructiv decât unul care funcționează. Cerut să raționeze despre „Integrarea ta Slack a încetat să mai posteze mesaje după marți”, modelul a scris:

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.

Este un sfat competent de troubleshooting și nu este task-ul. Cerut să gândească, modelul a alunecat în genul cu care „gândește pas cu pas despre acest tichet de suport” seamănă cel mai mult în datele sale de antrenare — și apoi a răspuns unei întrebări de clasificare cu cinci sute de caractere de raționament fără legătură în propriul context. Chain of thought ajută la probleme cu stare intermediară care merită calculată: aritmetică, căutări multi-hop, satisfacerea constrângerilor. Route-area unei propoziții într-una dintre patru găleți nu are stare intermediară. Nu există nimic ce chain-ul să țină, așa că tot ce face este să adauge text plauzibil prin care decizia finală trebuie apoi să supraviețuiască.

Două corolare practice. Primul, pentru un model antrenat să raționeze — modelele RLVR din Capitolul 12 — instrucțiunea este mai rea decât redundantă: poate înlocui chain-ul lung pe care modelul l-ar fi produs cu unul scurt, în formă de prompt. Iar eșantionarea mai multor chains și votarea, ceea ce face self-consistency,¹¹ nu poate salva un task fără nimic pe care să nu fie de acord: multiplică costul cu numărul de eșantioane ca să rupă egalități care nu există. Capitolul 12 a măsurat acel schimb acolo unde se aplică. Al doilea, observă cât a costat însuși scaffold-ul comparației. Forțarea răspunsului într-o linie Final queue: a coborât arm-ul fără raționament de la 76,7 % la 61,7 %. Cincisprezece puncte, plătite ca cele două arms să fie comparabile. Structura care există pentru comoditatea ta nu este nici ea gratuită.

O ultimă măsurătoare, pentru că este întrebarea pe care toată lumea o pune după primul rezultat surprinzător. Șaizeci de prompts, greedy decoding, rulate repetat:

• Același apel repetat cu totul menținut fix a returnat probabilități bit-identice. Determinist.
• Același apel pus în batch cu vecini diferiți — batch sizes 1, 4, 12, 30 și 60 — a returnat probabilități care diferă cu până la 0,0128. Eticheta aleasă nu s-a schimbat niciodată, în 0 din 60 de cazuri.

Eticheta a supraviețuit pentru că avea loc: pe cele șaizeci de cazuri, cel mai îngust decalaj dintre primele două cozi a fost 0,0459, de trei ori și jumătate drift-ul. Stabilitatea nu era o proprietate a algoritmului. Era o marjă, iar marjele se termină. Capitolul 17 este locul unde se află motivul aritmetic și unde butoanele de sampling care lărgesc și îngustează acele decalaje sunt desfăcute. Motivul pentru a-l planta aici este că delimitează ce poate însemna orice măsurare de prompt: bench-ul măsoară un sistem reproductibil doar până la o toleranță, iar o diferență de două puncte între variante este în interiorul acelei toleranțe într-o zi proastă.

Tot ce este mai sus înseamnă un om care alege o variantă și o mașină care o notează. Următorul pas evident este să lași mașina să aleagă și variantele.

APE face exact asta: un model propune instrucțiuni candidate, acestea sunt punctate pe exemple held-out, iar cele mai bune supraviețuiesc.⁸ Instrucțiunile pe care le găsește sunt adesea unele pe care niciun om nu le-ar scrie, iar acesta este scopul — căutarea este peste ce obține scor, nu peste ce sună profesionist.

DSPy merge mai departe și este ideea mai utilă pentru un produs.¹² Declari ce primește și ce returnează fiecare pas al unui pipeline, iar framework-ul compilează asta în prompts, selectând demonstrații și optimizând instrucțiuni față de metrica ta. Schimbi modelul și recompilezi în loc să rescrii. Prompt-ul încetează să fie cod sursă pe care cineva îl reglează manual și devine un artefact generat față de o metrică, ceea ce ar fi trebuit să fie dintotdeauna.

Niciuna nu elimină nevoia de bench. Ambele îl transformă în singurul lucru de care ai nevoie, pentru că un optimizator fără metrică nu optimizează nimic.

Rămâne disciplina. Prompts aparțin în version control, în fișiere, lângă codul care le trimite — nu într-un rând de bază de date pe care cineva l-a editat într-o marți. Au nevoie de un identificator de versiune stocat alături de fiecare output pe care l-au produs, altfel în ziua în care ceva regresează nu poți afla ce s-a schimbat. Au nevoie de bench în continuous integration, pentru că un prompt este partea din sistemul tău pe care un furnizor o poate invalida în tăcere prin deploy-ul unui model nou. Și au nevoie de cazuri: nu o sută de cazuri istețe, ci cele douăzeci plictisitoare care s-au stricat trimestrul trecut, păstrate pentru totdeauna. Bench-ul este livrabilul. Prompt-ul este un produs secundar al lui.

Tot ce a fost în acest capitol a fost măsurat în acuratețe. Fiecare dintre acele variante are și un preț.

System prompt-ul care a cumpărat 21,7 puncte este trimis la fiecare apel, pentru totdeauna. Cele două exemple care au cumpărat șapte puncte sunt trimise la fiecare apel, pentru totdeauna. Cele șaisprezece care au cumpărat douăsprezece sunt trimise la fiecare apel, pentru totdeauna, și sunt cam de zece ori mai lungi decât întrebarea pe care userul chiar a pus-o. Chain of thought care nu a cumpărat nimic a produs nouăzeci și opt de tokens extra per cerere, iar output tokens sunt cei scumpi.

Nimic din asta nu este vizibil într-un tabel de acurateți, și totul este vizibil pe o factură.

Capitolul 16 este despre unitatea în care sunt denominate de fapt acele decizii. Token ca unitate de facturare, context window ca buget mai degrabă decât memorie, de ce o conversație de patruzeci de turns costă mult mai mult decât de patruzeci de ori primul turn, ce plătește și ce nu plătește prompt caching și de ce ordinea prompt-ului tău decide dacă cache-ul nimerește deloc — ceea ce se dovedește a fi un al doilea motiv, complet economic, să pui materialul stabil primul și materialul variabil ultimul.

Bench-ul și fiecare tabel au fost produse cu Qwen/Qwen2.5-0.5B-Instruct sub greedy decoding, deci se reproduc exact. Documentația Hugging Face despre chat templates este referința pentru ce se extind de fapt markerii de template din Capitolul 11 și pentru faptul că un model livrat cu template-ul greșit este un eșec real și recurent. Pentru efectele de poziție și format la scară de producție, nu de laborator, citările de mai sus sunt sursele primare; ghidurile de prompting ale furnizorilor sunt utile pentru exemplele lor și trebuie citite știind că niciunul nu publică un interval.