Prompt engineering с измервания: какво променя резултата

Преди измерванията — един факт, който тихо обяснява половината от следващото.

Моделът няма памет. Между две извиквания не запазва нищо — нито последния ви въпрос, нито собствения си последен отговор, нито файла, който сте прикачили, нито факта, че вече сте го питали два пъти. Всяко извикване започва от празна машина и единственото, което тази машина знае, е последователността от tokens, която току-що сте ѝ подали.

Това, което изглежда като памет в chat интерфейс, е клиентът ви, който изпраща отново целия разговор, всеки turn, от самото начало. Моделът чете всичко отначало, всеки път. Глава 13 измери колко струва това повторно четене във forward pass; Глава 16 го превръща в ред във фактура. Важно тук е следствието за дизайна: prompt не е съобщение към система, която има състояние. Той е състоянието.

Това премахва цяло семейство обърквания. „Моделът забрави какво му казах“ обикновено означава, че това никога не е било изпратено. „Игнорира по-ранната ми инструкция“ обикновено означава, че инструкцията е изпаднала от прозореца, когато историята е била съкратена. „Държа се различно в production“ обикновено означава, че production сглобява различен prompt от този, който сте тествали. Нито едно от тези неща не е проблем на модела и нито едно не се поправя с преформулиране.

Твърдението „този prompt е по-добър“ е твърдение за разпределение, а разпределение не се вижда, като гледате един output. Нужно е нещо скучно: случаи с известни отговори, N варианта и интервал.

harness е петдесет реда TypeScript със същата форма като клиента от Глава 14 — заявка, краен срок, малко concurrency, брояч. Той се появява отново в Глава 19, за да оцени retriever, и в Глава 29 като 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 };
}

Числото, което се връща, не е резултатът. Това е:

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

Глава 4 изгради аргумента, а тази глава го осребрява. Седемнадесет верни от двадесет са 85 %, а неговият 95 % интервал е от 64 % до 95 %. Вариант с 13 от 20 — 65 %, което се усеща очевидно по-зле — има интервал от 43 % до 82 %. Тези два интервала се припокриват почти по цялата си дължина. Двадесет случая не могат да различат добър prompt от посредствен, а повечето публикувани съвети за prompt са валидирани върху по-малко.

Шестдесет случая, колкото използва тази глава, все още не са много. Достатъчни са, за да се видят големи ефекти, и достатъчно честни, за да признаят, когато не могат да видят малки — а по-долу това ще бъде признато няколко пъти.

Три блока — правилата R, тикетът T, инструкцията I — конкатенирани в едно потребителско съобщение. Всичките шест пермутации, byte-identical съдържание, по шестдесет случая всяка.

От най-доброто до най-лошото има 28,3 пункта, а интервалите не се припокриват, така че това не е история за шум. Понеже всеки arm се оценява върху същите шестдесет елемента, по-острият въпрос е paired: в случаите, в които два arms не са съгласни, колко едностранно е разделението? Преминаването от най-лошия ред към най-добрия обърна 21 случая към верни и 4 към грешни — exact paired probability 0,0009.³

Четете таблицата заради формата ѝ, не заради победителя. Двата най-добри реда и двата завършват с тикета; двата най-лоши или заравят инструкцията в средата, или я оставят след данните. Това е същото явление, което Liu et al. нарекоха Lost in the Middle: материалът по краищата на prompt се използва по-надеждно от материала в центъра.⁴ Глава 16 остойностява прозореца, а Глава 24 измерва ефекта правилно при дължина, където средата се срива, както е описано, и възстановяването в самия край не се появява отново. Тук практическото правило се появява само: задачата отгоре, данните отдолу, нищо важно в средата.

Сега преместете същите думи между turns. Глава 11 установи, че chat template не е декорация около модела, а част от него — <|im_start|>system и <|im_start|>user са реални tokens, които моделът е видял милиони пъти по време на fine-tuning, точно на тези позиции. Значи трябва да има значение от коя страна на тези markers попада инструкцията ви — и има:

Преместването на правилата и инструкцията през границата на template донесе 21,7 пункта — 19 спечелени случая, 6 загубени, paired probability 0,0146 — без промяна на нито един символ в тях. Това е конкретният отговор на system prompt срещу user prompt: те не са два начина да се каже едно и също. Те са две различни token позиции в структура, върху която моделът е обучаван, а system позицията е мястото за инструкции, които важат за целия разговор.

Забележете и третия ред. Повтарянето на инструкцията след тикета — широко препоръчван трик — даде резултат под еднократното ѝ заявяване. При този модел, за тази задача, да го кажеш два пъти беше по-лошо от това да го кажеш веднъж.

Същият prompt, най-доброто позициониране, шестдесет случая. Единственото, което се променя, е какво обгражда текста на тикета.

Осемнадесет пункта размах от пунктуация. Но вижте двата крайни интервала: [73,9, 91,9] и [54,1, 77,3]. Те се припокриват. При грубото четене — сравни error bars и ако се докосват, не казвай нищо — тази таблица не доказва абсолютно нищо.

Тук грубото четене е грешно и разбирането защо струва повече от таблицата. Всеки вариант е оценен върху същите шестдесет тикета, така че двете измервания не са независими samples; те са paired. По-голямата част от ширината на всеки интервал идва от източник на несигурност, който двата arms споделят — дали тези шестдесет тикета са представителни — и този източник се занулява, когато ги сравните един срещу друг. Задайте вместо това paired въпроса и отговорът е остър: преминаването от двойни кавички към XML tag обърна 12 случая към верни и 1 към грешен, paired probability 0,0034. Това е реална разлика.

А после същият тест сваля заглавието на земята. XML tag победи обикновения label Ticket: с 8,3 пункта, което е числото, което blog post би сложил в заглавието си. Paired: 6 спечелени, 1 загубен, probability 0,1250. Не е установено. Седем случая са всичко, върху което лежи прочутото подобрение.

Значи има два въпроса с два различни инструмента, а смесването им е начинът съветите за prompt да се объркват едновременно в двете посоки:

Общият извод — че моделите са силно и непредвидимо чувствителни към форматиращи избори без семантично съдържание — не е нов. Sclar et al. променят само разделители, интервали и capitalization в десетки задачи и откриват разлики в точността, достатъчно широки, за да обърнат публикувани класации на модели.⁵ Практическото следствие не е „използвайте XML tags“. То е, че форматирането е hyperparameter, не струва нищо да се sweep-не, и всяко сравнение на два модела, което фиксира един формат, сравнява формати толкова, колкото и модели.

In-context learning — да покажете на модела работени примери в prompt и да го накарате да обобщава от тях без update на weights — е способността, която направи GPT-3 известен.⁶ Практическият въпрос никога не е дали работи. Той е за колко примера да платите.

Примерите влизат като реални предишни turns, редуващи user и assistant, защото това е структурата, върху която template е обучен. Всеки k беше изпълнен с пет различни random draws от отделен pool от шестнадесет етикетирани тикета:

Два примера донесоха седем пункта. Следващите шест примера не донесоха нищо измеримо — 83,7, после 81,7, после 83,7, последователност, която се лута в собствения си шум. Шестнадесет донесоха още пет и половина. Кривата не е плавно изкачване; тя е стъпка, плато и стъпка.

Най-важната колона е последната. При k = 8 точно кои осем примера сте случили да изберете премести точността с 10 пункта — повече от цялата печалба при преминаването от два към осем примера. А долният ред е най-острата версия: при k = 16 pool е изчерпан, така че всичките пет изпълнения съдържат точно същите шестнадесет примера, различаващи се само по реда, в който се появяват. Само редът премести точността с 8,3 пункта.

Това е резултатът, който Lu et al. докладват, и той оцелява навсякъде, където е търсен: редът на примерите е истински hyperparameter с ефекти, сравними с броя примери.⁷ Така че честният съвет за few-shot prompting не е число. Той е:

Сега фолклорът. Всяко от тези е едно изречение, добавено в началото на system prompt, който иначе е идентичен, върху същите шестдесет случая.

Четири от петте не направиха нищо. Не „малко“; нищо, което шестдесет paired случая могат да видят. Expert persona и подкупът и двата се класираха под непокътнатия baseline, и дори тези спадове не минават paired теста — те са шум, сочещ надолу.

Третият ред е този, върху който си струва да се поседи. „This is very important to my career“ произведе точно същата точност, 46 от 60 — и десет от шестдесетте отговора се промениха, пет във всяка посока. Обобщаващата статистика беше идентична, а поведението не беше. Ако оценката ви е едно число върху малък набор, промяна, която пренаписва една шеста от outputs, може да изглежда като промяна, която не е направила нищо, и ще я пуснете, вярвайки, че е безплатна.

А после заплахата, която е единственото изречение, преместило иглата — и я премести 35 пункта надолу, обръщайки 24 случая от верни към грешни. Това не е артефакт от закръгляне; това е различно поведение на модела. Урокът не е „никога не заплашвайте модел“. Той е, че емоционалното рамкиране не е инертно. То измества разпределението, понякога силно, в посока, която никой не може да предскаже от прочитането на изречението — точно затова трябва да се измерва, вместо да се разсъждава за него.

Една уговорка, която тази глава ви дължи: тези пет изречения бяха тествани върху един малък модел и една задача. Някои имат публикувана подкрепа другаде — „take a deep breath“ идва от paper, който търси инструкции с висок резултат, вместо да ги измисля, което е различно и по-добро твърдение от това, което се разпространи после.⁸ Това, което се обобщава, не са изреченията. То е, че списъкът, оцелял в blog posts, и списъкът, оцелял при измерване, са два различни списъка, а единственият начин да знаете кой държите е да пуснете bench.

Правило, което всички повтарят — кажете какво искате, не какво не искате — с обичайната липса на число. Ето числото. Същото изискване за формат, написано по три начина, като моделът генерира свободно, така че да може да се наблюдава compliance:

Три забрани се справиха по-зле от една инструкция и накараха модела да напише пет пъти повече текст — точно обратното на трите наведнъж. Добавянето на положителното изречение обратно го спаси до 68 %.

Механизмът не е мистериозен, щом си спомните Глава 8. Моделът избира следващ token от разпределение, conditioned върху всичко преди него, а забраната поставя забраненото нещо в това conditioning. Няма оператор за отрицание; има контекст, в който дадена дума вече се появява.

Което се измерва директно. Вземете baseline prompt и добавете един ред: Do not use the shipping queue for software problems. После гледайте само четиридесет и петте тикета, които не са shipping тикети:

Назоваването на опашка, за да бъде изключена, накара модела да я избира три пъти по-често, почти утрои probability mass, което ѝ задава, и струва 25 пункта обща точност — 16 загубени случая срещу 1 спечелен, paired probability 0,0003.

Не мислете за слон, измерено. Пренаписването винаги е едно и също: заменете забраната с положителното правило, което я прави ненужна. Не „не използвай shipping за софтуерни проблеми“, а „използвай shipping само когато е замесена физическа пратка“.

Глава 12 изгради chain of thought правилно — първо като prompting техника,⁹¹⁰ после като нещо обучено с проверими rewards — и завърши с предупреждение, което отложи за тази глава: да кажеш на модел да мисли step by step спира да помага, щом моделът разсъждава сам, и може да вреди. Ето това предупреждение с таблица под него, върху задача, при която е лесно да се предположи, че повече мислене трябва да е по-добре.

И двата arms се четат със същия инструмент на същата позиция. Единствената разлика е дали chain of thought, който моделът е написал сам, стои първо в контекста.

Точността падна, а цената се качи, и собственото правило на тази глава важи за собствения ѝ резултат: спадът е 7 спечелени случая срещу 10 загубени, paired probability 0,629, което не е установено. Това, което е установено, е, че произведе деветдесет и осем допълнителни output tokens на извикване и не купи нищо измеримо с тях. Несигурността е изцяло от страната на ползата. Сметката е сигурна.

Chain, който се проваля, е по-поучителен от такъв, който работи. Помолен да разсъждава за „Your Slack integration stopped posting messages after Tuesday“, моделът написа:

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.

Това е компетентен troubleshooting съвет и не е задачата. Помолен да мисли, моделът се отклони към жанра, на който „think step by step about this support ticket“ най-много прилича в training data — и после отговори на classification въпрос с петстотин символа несвързано разсъждение в собствения си контекст. Chain of thought помага при проблеми с междинно състояние, което си струва да се изчисли: аритметика, multi-hop lookups, constraint satisfaction. Насочването на едно изречение към една от четири кофи няма междинно състояние. Няма какво chain да държи, така че всичко, което прави, е да добавя правдоподобен текст, който финалното решение после трябва да преживее.

Две практически следствия. Първо, за модел, обучен да разсъждава — RLVR моделите от Глава 12 — инструкцията е по-лоша от излишна: тя може да замени дългия chain, който моделът би произвел, с кратък, prompt-shaped. А sampling на няколко chains и гласуване, което е това, което self-consistency прави,¹¹ не може да спаси задача, при която няма за какво да се спори: умножава цената по броя samples, за да разбива равенства, които не съществуват. Глава 12 измери този trade там, където важи. Второ, обърнете внимание какво струваше самият comparison scaffold. Принуждаването на отговора в ред Final queue: свали no-reasoning arm от 76,7 % на 61,7 %. Петнадесет пункта, платени, за да направят двата arms сравними. Структура, която съществува за ваше удобство, също не е безплатна.

Едно последно измерване, защото това е въпросът, който всички задават след първия изненадващ резултат. Шестдесет prompts, greedy decoding, изпълнявани многократно:

• Същото извикване, повторено при фиксирано всичко, върна bit-identical вероятности. Детерминистично.
• Същото извикване, batched с различни съседи — batch sizes 1, 4, 12, 30 и 60 — върна вероятности, различаващи се с до 0,0128. Избраният label не се промени нито веднъж, в 0 от 60 случая.

label оцеля, защото имаше място: в шестдесетте случая най-тясната разлика между двете водещи опашки беше 0,0459, три и половина пъти drift. Стабилността не беше свойство на алгоритъма. Беше margin, а margins свършват. Глава 17 е мястото, където живее аритметичната причина и където sampling knobs, които разширяват и стесняват тези gaps, се разглобяват. Причината да го поставим тук е, че ограничава какво може да означава всяко prompt измерване: bench измерва система, възпроизводима само до tolerance, а двупунктова разлика между варианти е вътре в този tolerance в лош ден.

Всичко по-горе е човек, който избира вариант, и машина, която го оценява. Очевидната следваща стъпка е да оставим машината да избира и вариантите.

APE прави точно това: модел предлага кандидат-инструкции, те се оценяват върху held-out examples, а най-добрите оцеляват.⁸ Инструкциите, които намира, често са такива, които никой човек не би написал, и това е смисълът — търсенето е върху това, което постига резултат, не върху това, което звучи професионално.

DSPy отива по-далеч и е по-полезната идея за продукт.¹² Декларирате какво приема и връща всяка стъпка от pipeline, а framework го компилира в prompts, като избира demonstrations и оптимизира инструкции спрямо вашата метрика. Сменяте модела и recompilе-вате, вместо да пренаписвате. prompt спира да бъде source code, който някой hand-tune-ва, и става артефакт, генериран спрямо метрика — какъвто е трябвало да бъде от самото начало.

Нито едното не премахва нуждата от bench. И двете го правят единственото, което ви трябва, защото optimiser без метрика не оптимизира нищо.

Остава дисциплината. Prompts принадлежат във version control, във файлове, до кода, който ги изпраща — не в database row, редактиран от някого във вторник. Нуждаят се от version identifier, съхранен до всеки output, който са произвели, иначе в деня, в който нещо regress-не, не можете да разберете какво се е променило. Нуждаят се от bench в continuous integration, защото prompt е една част от системата ви, която vendor може тихо да инвалидира, като deploy-не нов модел. И се нуждаят от случаи: не сто clever ones, просто скучните двадесет, които са се счупили миналото тримесечие, пазени завинаги. Bench е deliverable. prompt е негов страничен продукт.

Всичко в тази глава беше измерено в точност. Всеки един от тези варианти има и цена.

System prompt, който донесе 21,7 пункта, се изпраща при всяко извикване, завинаги. Двата примера, които донесоха седем пункта, се изпращат при всяко извикване, завинаги. Шестнадесетте, които донесоха дванадесет, се изпращат при всяко извикване, завинаги, и са приблизително десет пъти по-дълги от въпроса, който потребителят всъщност е задал. Chain of thought, който не донесе нищо, произведе деветдесет и осем допълнителни tokens на заявка, а output tokens са скъпият вид.

Нищо от това не се вижда в таблица с точности, и всичко се вижда във фактура.

Глава 16 е за единицата, в която тези решения реално са деноминирани. token като billing unit, context window като бюджет, а не памет, защо разговор с четиридесет turns струва много повече от четиридесет пъти първия turn, какво prompt caching плаща и какво не, и защо редът на вашия prompt решава дали cache изобщо ще hit-не — което се оказва втора, изцяло икономическа причина да сложите стабилния материал първи, а променливия последен.

Bench и всяка таблица бяха произведени с Qwen/Qwen2.5-0.5B-Instruct под greedy decoding, така че се възпроизвеждат точно. Документацията на Hugging Face за chat templates е reference за това в какво реално се разширяват template markers от Глава 11 и за факта, че модел, доставен с грешен template, е реален и повтарящ се failure. За position и format effects в production scale, а не laboratory scale, цитатите по-горе са primary sources; vendor prompting guides са полезни с примерите си и трябва да се четат със знанието, че никой от тях не публикува интервал.