Prompt engineering zmierzony: co naprawdę zmienia wynik

Zanim przejdziemy do pomiarów, jeden fakt, który po cichu wyjaśnia połowę tego, co nastąpi.

Model nie ma pamięci. Między dwoma wywołaniami niczego nie zachowuje — ani Twojego poprzedniego pytania, ani swojej poprzedniej odpowiedzi, ani załączonego pliku, ani faktu, że pytałeś go już dwa razy. Każde wywołanie startuje z pustej maszyny, a jedyne, co ta maszyna zna, to sekwencja token, którą właśnie jej przekazałeś.

To, co w interfejsie czatu wygląda jak pamięć, jest klientem ponownie wysyłającym całą rozmowę, każdą turę, od początku. Model czyta wszystko od zera, za każdym razem. Rozdział 13 zmierzył, ile kosztuje to ponowne czytanie w forward pass; rozdział 16 zamienia to w pozycję na fakturze. Tutaj ważna jest konsekwencja dla projektowania: prompt nie jest wiadomością do systemu, który ma stan. On jest stanem.

To zamyka całą rodzinę nieporozumień. „Model zapomniał, co mu powiedziałem” zwykle znaczy, że nigdy mu tego nie wysłano. „Zignorował moją wcześniejszą instrukcję” zwykle znaczy, że instrukcja wypadła z okna, gdy historia została przycięta. „W produkcji zachował się inaczej” zwykle znaczy, że produkcja składa inny prompt niż ten, który testowałeś. Żaden z tych przypadków nie jest problemem modelu i żadnego nie naprawia przeformułowanie tekstu.

Twierdzenie „ten prompt jest lepszy” jest twierdzeniem o rozkładzie, a rozkładu nie zobaczysz, patrząc na jeden wynik. Potrzebujesz czegoś nudnego: przypadków ze znanymi odpowiedziami, N wariantów i przedziału.

Harness ma pięćdziesiąt linii TypeScript i ten sam kształt co klient z rozdziału 14 — żądanie, deadline, trochę współbieżności, podliczenie. Pojawia się ponownie w rozdziale 19, by ocenić retriever, i w rozdziale 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 };
}

Liczba, która wraca, nie jest wynikiem. Wynikiem jest to:

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

Rozdział 4 przedstawił argument, a ten rozdział go realizuje. Siedemnaście poprawnych odpowiedzi z dwudziestu to 85 %, a jego 95-procentowy przedział biegnie od 64 % do 95 %. Wariant z wynikiem 13 z 20 — 65 %, co wydaje się wyraźnie gorsze — ma przedział od 43 % do 82 %. Te dwa przedziały nakładają się niemal na całej długości. Dwadzieścia przypadków nie odróżnia dobrego prompt od przeciętnego, a większość opublikowanych porad o prompt weryfikowano na mniejszej liczbie.

Sześćdziesiąt przypadków, których używa ten rozdział, to nadal niewiele. Wystarczy, by zobaczyć duże efekty, i jest to na tyle uczciwe, by przyznać, kiedy nie widać małych — a przyznamy to niżej kilka razy.

Trzy bloki — reguły R, zgłoszenie T, instrukcja I — połączone w jedną wiadomość użytkownika. Wszystkie sześć permutacji, treść identyczna bajt w bajt, po sześćdziesiąt przypadków każda.

Od najlepszego do najgorszego jest 28,3 punktu, a przedziały się nie nakładają, więc nie jest to opowieść o szumie. Ponieważ każde ramię jest oceniane na tych samych sześćdziesięciu elementach, ostrzejsze pytanie jest sparowane: w przypadkach, w których dwa ramiona się nie zgadzają, jak jednostronny jest podział? Przejście od najgorszej kolejności do najlepszej odwróciło 21 przypadków na poprawne i 4 na błędne — dokładne prawdopodobieństwo sparowane 0,0009.³

Czytaj tabelę ze względu na jej kształt, nie zwycięzcę. Dwa najlepsze wiersze oba kończą się zgłoszeniem; dwa najgorsze oba zakopują instrukcję w środku albo wloką ją za danymi. To to samo zjawisko, które Liu i in. nazwali Lost in the Middle: materiał na krawędziach prompt jest używany bardziej niezawodnie niż materiał w środku.⁴ Rozdział 16 wycenia okno, a rozdział 24 mierzy ten efekt właściwie na długości, gdzie środek zapada się zgodnie z opisem, a odbicie na samym końcu nie wraca. Tutaj praktyczna reguła wypada sama: zadanie na górze, dane na dole, nic ważnego w środku.

Teraz przenieś te same słowa między turami. Rozdział 11 ustalił, że szablon czatu nie jest dekoracją wokół modelu, tylko jego częścią — <|im_start|>system i <|im_start|>user to prawdziwe token, które model widział miliony razy podczas fine-tuning, dokładnie w tych pozycjach. Powinno więc mieć znaczenie, po której stronie tych markerów ląduje Twoja instrukcja — i ma:

Przeniesienie reguł i instrukcji przez granicę szablonu dało 21,7 punktu — 19 przypadków zyskanych, 6 straconych, prawdopodobieństwo sparowane 0,0146 — bez zmiany ani jednego znaku. To konkretna odpowiedź na system prompt kontra user prompt: to nie są dwa sposoby powiedzenia tego samego. To dwie różne pozycje token w strukturze, na której model był trenowany, a pozycja systemowa jest miejscem dla instrukcji obowiązujących całą rozmowę.

Zauważ też trzeci wiersz. Powtórzenie instrukcji po zgłoszeniu — szeroko rekomendowany trik — wypadło gorzej niż podanie jej raz. Na tym modelu, w tym zadaniu, powiedzenie tego dwa razy było gorsze niż powiedzenie raz.

Ten sam prompt, najlepsze umiejscowienie, sześćdziesiąt przypadków. Zmienia się tylko to, co otacza tekst zgłoszenia.

Osiemnastopunktowy rozrzut od interpunkcji. Ale spójrz na dwa skrajne przedziały: [73,9; 91,9] i [54,1; 77,3]. Nakładają się. Przy prymitywnym odczycie — porównaj error bars, a jeśli się dotykają, nic nie mów — ta tabela nie dowodzi absolutnie niczego.

Prymitywny odczyt jest tu błędny, a zrozumienie dlaczego jest warte więcej niż tabela. Każdy wariant oceniano na tych samych sześćdziesięciu zgłoszeniach, więc dwa pomiary nie są niezależnymi próbkami; są sparowane. Większość szerokości każdego przedziału pochodzi ze źródła niepewności wspólnego dla obu ramion — czy te sześćdziesiąt zgłoszeń jest reprezentatywne — a to źródło znosi się, gdy porównujesz je ze sobą. Zadaj zamiast tego pytanie sparowane, a odpowiedź jest ostra: przejście od cudzysłowów do tagu XML odwróciło 12 przypadków na poprawne i 1 na błędny, prawdopodobieństwo sparowane 0,0034. To rzeczywista różnica.

A potem ten sam test spuszcza powietrze z nagłówka. Tag XML pokonał zwykłą etykietę Ticket: o 8,3 punktu — to liczba, którą blog wstawiłby do tytułu. Sparowane: 6 zyskanych, 1 stracony, prawdopodobieństwo 0,1250. Nieustalone. Siedem przypadków to wszystko, na czym opiera się ta słynna poprawa.

Są więc dwa pytania z dwoma różnymi instrumentami, a ich mieszanie to sposób, w jaki porady o prompt mylą się naraz w obie strony:

Ogólne ustalenie — że modele są silnie i nieprzewidywalnie wrażliwe na wybory formatowania nieniosące treści semantycznej — nie jest nowe. Sclar i in. zmieniali wyłącznie separatory, odstępy i wielkość liter w dziesiątkach zadań i znaleźli rozrzuty trafności wystarczająco duże, by odwrócić opublikowane rankingi modeli.⁵ Praktyczna konsekwencja nie brzmi „używaj tagów XML”. Brzmi: formatowanie jest hyperparameter, jego sweep nic nie kosztuje, a każde porównanie dwóch modeli, które zamraża jeden format, porównuje formaty tak samo jak modele.

In-context learning — pokazanie modelowi przepracowanych przykładów w prompt i oczekiwanie, że uogólni z nich bez żadnej aktualizacji weights — to zdolność, która rozsławiła GPT-3.⁶ Praktyczne pytanie nigdy nie brzmi, czy to działa. Brzmi: za ile przykładów warto płacić.

Przykłady trafiają jako prawdziwe wcześniejsze tury, naprzemiennie użytkownik i asystent, bo to struktura, na której trenowano szablon. Każde k uruchomiono z pięcioma różnymi losowymi wyborami z rozłącznej puli szesnastu oznaczonych zgłoszeń:

Dwa przykłady dały siedem punktów. Kolejne sześć przykładów nie dało nic mierzalnego — 83,7, potem 81,7, potem 83,7, sekwencja błądząca we własnym szumie. Szesnaście dało kolejne pięć i pół. Krzywa nie jest gładkim wzrostem; to schodek, plateau i schodek.

Najważniejsza jest ostatnia kolumna. Przy k = 8 to, które osiem przykładów akurat wybrałeś, przesunęło trafność o 10 punktów — więcej niż cały zysk z przejścia od dwóch przykładów do ośmiu. A dolny wiersz jest najostrzejszą wersją tego efektu: przy k = 16 pula jest wyczerpana, więc wszystkie pięć uruchomień zawiera dokładnie te same szesnaście przykładów, różniące się tylko kolejnością. Sama kolejność przesunęła trafność o 8,3 punktu.

To wynik, który opisali Lu i in., i przetrwał wszędzie, gdzie go szukano: kolejność przykładów jest prawdziwym hyperparameter z efektami porównywalnymi z liczbą przykładów.⁷ Uczciwa rada o few-shot prompting nie jest więc liczbą. Brzmi:

Teraz folklor. Każde z poniższych to jedno zdanie dopisane na początku system prompt, który poza tym jest identyczny, na tych samych sześćdziesięciu przypadkach.

Cztery z pięciu nie zrobiły nic. Nie „trochę zrobiły”; nic, co sześćdziesiąt sparowanych przypadków potrafi zobaczyć. Persona eksperta i łapówka wypadły nawet poniżej nietkniętego baseline, ale te spadki też nie przechodzą testu sparowanego — to szum wskazujący w dół.

Trzeci wiersz jest tym, nad którym warto posiedzieć. „To jest bardzo ważne dla mojej kariery” dało dokładnie tę samą trafność, 46 z 60 — a dziesięć z sześćdziesięciu odpowiedzi się zmieniło, po pięć w każdą stronę. Statystyka podsumowująca była identyczna, zachowanie nie. Jeśli Twoja ewaluacja to jedna liczba na małym zbiorze, zmiana, która przepisuje jedną szóstą wyników, może wyglądać jak zmiana, która nie zrobiła nic — i wdrożysz ją, wierząc, że była darmowa.

A potem groźba, czyli jedyne zdanie, które poruszyło wskazówkę, i poruszyło ją 35 punktów w dół, odwracając 24 przypadki z poprawnych na błędne. To nie jest artefakt zaokrągleń; to inne zachowanie modelu. Lekcja nie brzmi „nigdy nie groź modelowi”. Brzmi: emocjonalne ramowanie nie jest obojętne. Przesuwa rozkład, czasem mocno, w kierunku, którego nikt nie przewidzi po przeczytaniu zdania — i właśnie dlatego trzeba je mierzyć, a nie rozumować o nim.

Zastrzeżenie, które ten rozdział jest Ci winien: te pięć zdań testowano na jednym małym modelu i jednym zadaniu. Niektóre mają wsparcie w publikacjach gdzie indziej — „weź głęboki oddech” wyszło z pracy, która szukała wysoko punktujących instrukcji, zamiast je wymyślać, co jest innym i lepszym twierdzeniem niż to, które potem krążyło.⁸ Uogólniają się nie zdania. Uogólnia się to, że lista, która przetrwała w blogach, i lista, która przetrwała pomiar, to dwie różne listy, a jedyny sposób, by wiedzieć, którą trzymasz w ręku, to uruchomić bench.

Reguła powtarzana przez wszystkich — mów, czego chcesz, a nie czego nie chcesz — zwykle bez liczby. Oto liczba. Ten sam wymóg formatu, zapisany na trzy sposoby, z modelem generującym swobodnie, aby można było obserwować zgodność:

Trzy zakazy wypadły gorzej niż jedna instrukcja i sprawiły, że model napisał pięć razy więcej tekstu — dokładne przeciwieństwo wszystkich trzech naraz. Dodanie z powrotem zdania pozytywnego uratowało wynik do 68 %.

Mechanizm nie jest tajemniczy, gdy pamiętasz rozdział 8. Model wybiera następny token z rozkładu warunkowanego wszystkim, co było wcześniej, a zakaz wkłada zakazaną rzecz do tego warunkowania. Nie ma operatora negacji; jest kontekst, w którym słowo właśnie się pojawiło.

Da się to zmierzyć bezpośrednio. Weź baseline prompt i dodaj jedną linię: Do not use the shipping queue for software problems. Potem spójrz tylko na czterdzieści pięć zgłoszeń, które nie są zgłoszeniami wysyłkowymi:

Nazwanie kolejki po to, by ją wykluczyć, sprawiło, że model wybierał ją trzy razy częściej, niemal potroiło probability mass, którą jej przypisał, i kosztowało 25 punktów ogólnej trafności — 16 przypadków straconych wobec 1 zyskanego, prawdopodobieństwo sparowane 0,0003.

Nie myśl o słoniu, zmierzone. Przepisanie jest zawsze takie samo: zastąp zakaz pozytywną regułą, która czyni go zbędnym. Nie „nie używaj wysyłki dla problemów z oprogramowaniem”, tylko „używaj wysyłki tylko wtedy, gdy chodzi o fizyczną paczkę”.

Rozdział 12 zbudował chain of thought właściwie — najpierw jako technikę prompting,⁹¹⁰ potem jako coś wtrenowanego z weryfikowalnymi nagrodami — i zakończył ostrzeżeniem odłożonym do tego rozdziału: mówienie modelowi, by myślał krok po kroku, przestaje pomagać, gdy model rozumuje sam, i może szkodzić. Oto to ostrzeżenie z tabelą pod spodem, w zadaniu, w którym łatwo założyć, że więcej myślenia musi być lepsze.

Oba ramiona są czytane tym samym instrumentem w tej samej pozycji. Jedyna różnica polega na tym, czy chain of thought, który model sam napisał, najpierw siedzi w kontekście.

Trafność spadła, koszt wzrósł, a własna reguła tego rozdziału stosuje się do własnego wyniku tego rozdziału: spadek to 7 przypadków zyskanych wobec 10 straconych, prawdopodobieństwo sparowane 0,629, czyli nie jest ustalony. Ustalone jest to, że wyprodukował dziewięćdziesiąt osiem dodatkowych output tokens na wywołanie i nie kupił nimi nic mierzalnego. Niepewność leży w całości po stronie korzyści. Rachunek jest pewny.

Łańcuch, który zawodzi, uczy więcej niż taki, który działa. Poproszony o rozumowanie nad „Twoja integracja Slack przestała publikować wiadomości po wtorku”, model napisał:

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 kompetentna porada diagnostyczna i nie jest to zadanie. Poproszony o myślenie, model odpłynął w gatunek, który „pomyśl krok po kroku o tym zgłoszeniu wsparcia” najbardziej przypomina w jego danych treningowych — a potem odpowiedział na pytanie klasyfikacyjne pięciuset znakami niepowiązanego rozumowania we własnym kontekście. Chain of thought pomaga przy problemach z intermediate state wartym obliczenia: arytmetyce, multi-hop lookup, spełnianiu ograniczeń. Skierowanie zdania do jednego z czterech kubełków nie ma intermediate state. Nie ma nic, co łańcuch miałby przechować, więc dodaje tylko wiarygodny tekst, który końcowa decyzja musi potem przetrwać.

Dwie praktyczne konsekwencje. Po pierwsze, dla modelu trenowanego do rozumowania — modeli RLVR z rozdziału 12 — instrukcja jest gorsza niż redundantna: może zastąpić długi łańcuch, który model by wytworzył, krótkim, prompt-kształtnym. A próbkowanie kilku łańcuchów i głosowanie, czyli self-consistency,¹¹ nie uratuje zadania, w którym nie ma o co się spierać: mnoży koszt przez liczbę próbek, by rozstrzygać remisy, których nie ma. Rozdział 12 zmierzył ten trade tam, gdzie ma zastosowanie. Po drugie, zauważ, ile kosztował sam scaffold porównania. Wymuszenie odpowiedzi w linii Final queue: obniżyło ramię bez rozumowania z 76,7 % do 61,7 %. Piętnaście punktów zapłaconych po to, by dwa ramiona były porównywalne. Struktura istniejąca dla Twojej wygody też nie jest darmowa.

Ostatni pomiar, bo to pytanie zadają wszyscy po pierwszym zaskakującym wyniku. Sześćdziesiąt prompt, greedy decoding, uruchamiane wielokrotnie:

• To samo wywołanie powtórzone przy wszystkim zamrożonym zwróciło bitowo identyczne probability. Deterministyczne.
• To samo wywołanie zbatchowane z różnymi sąsiadami — batch sizes 1, 4, 12, 30 i 60 — zwróciło probability różniące się maksymalnie o 0,0128. Wybrana etykieta nie zmieniła się ani razu, w 0 z 60 przypadków.

Etykieta przetrwała, bo miała zapas: w sześćdziesięciu przypadkach najwęższa luka między dwiema najlepszymi kolejkami wynosiła 0,0459, trzy i pół raza więcej niż drift. Stabilność nie była właściwością algorytmu. Była marginesem, a marginesy się kończą. Rozdział 17 wyjaśnia arytmetyczny powód i rozbiera pokrętła próbkowania, które poszerzają i zwężają te luki. Powód, by umieścić to tutaj, jest taki, że wyznacza granice znaczenia każdego pomiaru prompt: bench mierzy system odtwarzalny tylko do pewnej tolerancji, a dwupunktowa różnica między wariantami w zły dzień mieści się w tej tolerancji.

Wszystko powyżej to człowiek wybierający wariant i maszyna go oceniająca. Oczywistym następnym krokiem jest pozwolić maszynie wybierać także warianty.

APE robi dokładnie to: model proponuje kandydackie instrukcje, są one oceniane na hold-out examples, a najlepsze przeżywają.⁸ Instrukcje, które znajduje, często są takie, jakich żaden człowiek by nie napisał — i o to chodzi. Szukanie odbywa się po tym, co punktuje, nie po tym, co brzmi profesjonalnie.

DSPy idzie dalej i jest bardziej użytecznym pomysłem dla produktu.¹² Deklarujesz, co każdy krok pipeline przyjmuje i zwraca, a framework kompiluje to do prompt, wybierając demonstrations i optymalizując instrukcje pod Twoją metrykę. Zmieniasz model i kompilujesz ponownie zamiast przepisywać. Prompt przestaje być kodem źródłowym, który ktoś ręcznie dostraja, i staje się artefaktem wygenerowanym względem metryki — czym powinien być od początku.

Żadne z nich nie usuwa potrzeby bench. Oba sprawiają, że bench jest jedyną rzeczą, której potrzebujesz, bo optimizer bez metryki nie optymalizuje niczego.

Pozostaje dyscyplina. Prompts należą do version control, w plikach, obok kodu, który je wysyła — nie w wierszu bazy danych, który ktoś edytował we wtorek. Potrzebują identyfikatora wersji zapisanego obok każdego output, który wyprodukowały, bo w dniu regresji inaczej nie dowiesz się, co się zmieniło. Potrzebują bench w continuous integration, bo prompt to ta część Twojego systemu, którą vendor może po cichu unieważnić, wdrażając nowy model. I potrzebują przypadków: nie stu sprytnych, tylko nudnych dwudziestu, które zepsuły się w zeszłym kwartale, zachowanych na zawsze. Bench jest deliverable. Prompt jest jego produktem ubocznym.

Wszystko w tym rozdziale mierzono trafnością. Każdy z tych wariantów ma też cenę.

System prompt, który kupił 21,7 punktu, jest wysyłany przy każdym wywołaniu, na zawsze. Dwa przykłady, które kupiły siedem punktów, są wysyłane przy każdym wywołaniu, na zawsze. Szesnaście, które kupiło dwanaście, jest wysyłane przy każdym wywołaniu, na zawsze, i są mniej więcej dziesięć razy dłuższe niż pytanie, które użytkownik faktycznie zadał. Chain of thought, który nie kupił nic, wyprodukował dziewięćdziesiąt osiem dodatkowych token na żądanie, a output tokens są droższym rodzajem.

Nic z tego nie jest widoczne w tabeli trafności, a wszystko jest widoczne na fakturze.

Rozdział 16 dotyczy jednostki, w której te decyzje są naprawdę denominowane. Token jako jednostka rozliczeniowa, context window jako budżet, a nie pamięć, dlaczego czterdziestoturowa rozmowa kosztuje znacznie więcej niż czterdzieści razy pierwsza tura, za co prompt caching płaci, a za co nie, i dlaczego kolejność Twojego prompt decyduje, czy cache w ogóle trafi — co okazuje się drugim, czysto ekonomicznym powodem, by stabilny materiał umieszczać najpierw, a zmienny na końcu.

Bench i każda tabela zostały wyprodukowane z Qwen/Qwen2.5-0.5B-Instruct pod greedy decoding, więc odtwarzają się dokładnie. Dokumentacja Hugging Face dotycząca szablonów czatu jest odniesieniem dla tego, do czego faktycznie rozwijają się markery szablonu z rozdziału 11, oraz dla faktu, że model dostarczony z niewłaściwym szablonem jest realną i powtarzającą się awarią. Dla efektów pozycji i formatu w skali produkcyjnej, a nie laboratoryjnej, podstawowymi źródłami są cytowania powyżej; vendor prompting guides są użyteczne przez przykłady i należy je czytać, wiedząc, że żaden z nich nie publikuje przedziału.