Prompt engineering у цифрах: що змінює output

Перед вимірюваннями — один факт, який тихо пояснює половину подальшого.

У моделі немає пам’яті. Між двома викликами вона нічого не зберігає — ні ваше останнє запитання, ні власну останню відповідь, ні файл, який ви прикріпили, ні факт, що ви вже питали її двічі. Кожен виклик стартує з порожньої машини, і єдине, що ця машина знає, — це послідовність tokens, яку ви щойно їй передали.

Те, що в інтерфейсі чату виглядає як пам’ять, — це ваш клієнт, який щоразу заново надсилає всю розмову, кожен turn, від самого початку. Модель щоразу перечитує все з нуля. Розділ 13 виміряв, скільки коштує це перечитування у forward pass; Розділ 16 перетворює це на рядок у рахунку. Тут важливий наслідок для дизайну: prompt — це не повідомлення системі, яка має стан. Він і є станом.

Це знімає цілу родину непорозумінь. «Модель забула, що я їй сказав» зазвичай означає, що це ніколи не було надіслано. «Вона проігнорувала мою попередню інструкцію» зазвичай означає, що інструкція випала з window, коли історію обрізали. «У production вона поводилася інакше» зазвичай означає, що production збирає інший prompt, ніж той, який ви тестували. Жодне з цього не є проблемою моделі, і жодне не виправляється переформулюванням.

Твердження «цей prompt кращий» — це твердження про розподіл, а розподіл не видно з одного output. Потрібне щось нудне: кейси з відомими відповідями, N варіантів і інтервал.

harness — це п’ятдесят рядків TypeScript тієї самої форми, що й клієнт із Розділу 14: запит, дедлайн, трохи конкурентності, підрахунок. Він знову з’являється в Розділі 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 — склеєні в одне user message. Усі шість перестановок, байтово ідентичний вміст, по шістдесят кейсів кожна.

Від найкращого до найгіршого — 28,3 пункта, і інтервали не перекриваються, тож це не історія про шум. Оскільки кожну гілку оцінено на тих самих шістдесяти items, гостріше запитання — парне: серед кейсів, де дві гілки не погоджуються, наскільки перекошений розподіл? Перехід від найгіршого порядку до найкращого перевернув 21 кейс у правильний бік і 4 у неправильний — точна парна ймовірність 0,0009.³

Читайте таблицю за її формою, а не за переможцем. Два найкращі рядки обидва закінчуються тікетом; два найгірші або ховають інструкцію посередині, або тягнуть її після даних. Це те саме явище, яке Liu et al. назвали Lost in the Middle: матеріал на краях prompt використовується надійніше, ніж матеріал у центрі.⁴ Розділ 16 рахує ціну window, а Розділ 24 вимірює ефект як слід на довжині, де середина провалюється, як описано, а відновлення в самому кінці не повторюється. Тут практичне правило випадає саме: задача згори, дані знизу, нічого важливого посередині.

Тепер перенесіть ті самі слова між turns. Розділ 11 встановив, що chat template — це не декорація навколо моделі, а частина моделі: <|im_start|>system і <|im_start|>user — реальні tokens, які модель бачила мільйони разів під час fine-tuning, саме в цих позиціях. Тож має значення, по який бік цих маркерів опиниться ваша інструкція, — і воно має:

Перенесення правил і інструкції через межу template дало 21,7 пункта — 19 кейсів здобуто, 6 втрачено, парна ймовірність 0,0146 — без зміни жодного символу. Це конкретна відповідь на system prompt проти user prompt: це не два способи сказати те саме. Це дві різні token positions у структурі, на якій навчали модель, і system position — місце для інструкцій, що застосовуються до всієї розмови.

Зверніть увагу і на третій рядок. Повторення інструкції після тікета — широко рекомендований трюк — спрацювало гірше, ніж одноразове формулювання. На цій моделі, у цій задачі, сказати двічі було гірше, ніж сказати один раз.

Той самий prompt, найкраще розміщення, шістдесят кейсів. Змінюється лише те, що оточує текст тікета.

Вісімнадцять пунктів розмаху від пунктуації. Але подивіться на два крайні інтервали: [73,9, 91,9] і [54,1, 77,3]. Вони перекриваються. За грубим прочитанням — порівняти error bars, і якщо вони торкаються, нічого не казати — ця таблиця взагалі нічого не доводить.

Грубе прочитання тут неправильне, і зрозуміти чому важливіше за таблицю. Кожен варіант оцінювали на тих самих шістдесяти тікетах, тож два вимірювання не є незалежними вибірками; вони парні. Більша частина ширини кожного інтервалу походить із джерела невизначеності, спільного для обох гілок, — чи репрезентативні ці шістдесят тікетів, — і це джерело скасовується, коли ви порівнюєте їх між собою. Поставте натомість парне запитання, і відповідь буде різкою: перехід від подвійних лапок до XML-тега перевернув 12 кейсів у правильний бік і 1 у неправильний, парна ймовірність 0,0034. Це реальна різниця.

А потім той самий тест здуває заголовок. XML-тег переміг просту мітку Ticket: на 8,3 пункта — саме це число блог поставив би в заголовок. Парно: 6 здобуто, 1 втрачено, ймовірність 0,1250. Не встановлено. Сім кейсів — ось на чому тримається те знамените покращення.

Отже, є два запитання з двома різними інструментами, і їхнє змішування — це спосіб, яким поради щодо prompt помиляються в обох напрямах одночасно:

Загальний висновок — що моделі сильно й непередбачувано чутливі до форматування, яке не несе семантичного змісту, — не новий. Sclar et al. змінювали лише розділювачі, пробіли й регістр у десятках задач і знайшли розмахи точності, достатні, щоб перевернути опубліковані рейтинги моделей.⁵ Практичний наслідок — не «використовуйте XML-теги». А те, що форматування — це hyperparameter, його нічого не коштує перебрати, і будь-яке порівняння двох моделей, яке фіксує один формат, порівнює формати не менше, ніж моделі.

In-context learning — показати моделі відпрацьовані приклади в prompt і змусити її узагальнити з них без жодного оновлення weights — це здатність, яка зробила GPT-3 знаменитою.⁶ Практичне питання ніколи не в тому, чи це працює. Воно в тому, за скільки прикладів варто платити.

Приклади заходять як справжні попередні turns, чергуючи user і assistant, бо саме на такій структурі навчався template. Кожен k запускали з п’ятьма різними випадковими вибірками з окремого пулу шістнадцяти розмічених тікетів:

Два приклади дали сім пунктів. Наступні шість прикладів не дали нічого вимірюваного — 83,7, потім 81,7, потім 83,7, послідовність блукає всередині власного шуму. Шістнадцять дали ще п’ять із половиною. Крива — не плавне зростання; це крок, плато й крок.

Найважливіший стовпець — останній. На k = 8 те, які саме вісім прикладів ви випадково вибрали, зрушило точність на 10 пунктів — більше, ніж увесь виграш від переходу з двох прикладів до восьми. А нижній рядок — найгостріша версія цього: на k = 16 пул вичерпано, тож усі п’ять запусків містять рівно ті самі шістнадцять прикладів, відрізняючись лише порядком появи. Сам лише порядок зрушив точність на 8,3 пункта.

Це результат, про який повідомили Lu et al., і він виживає всюди, де його шукали: порядок прикладів — справжній hyperparameter з ефектами, порівнянними з кількістю прикладів.⁷ Тож чесна порада щодо few-shot prompting — не число. Вона така:

Тепер фольклор. Кожне з них — одне речення, додане на початок system prompt, який в іншому ідентичний, на тих самих шістдесяти кейсах.

Чотири з п’яти не зробили нічого. Не «зробили трохи»; нічого, що могли б побачити шістдесят парних кейсів. Персона експерта й хабар обидва спрацювали гірше за недоторканий baseline, і навіть ці падіння не проходять парний тест — це шум, що вказує вниз.

Третій рядок — той, із яким варто посидіти. «This is very important to my career» дало рівно ту саму точність, 46 із 60, — і десять із шістдесяти відповідей змінилися, п’ять у кожен бік. Зведена статистика була ідентичною, а поведінка — ні. Якщо ваша оцінка — одне число на малому наборі, зміна, яка переписує шосту частину outputs, може виглядати як зміна, що нічого не зробила, і ви ship її, вірячи, що вона безкоштовна.

А потім погроза — єдине речення, яке зрушило стрілку, і зрушило її на 35 пунктів вниз, перевернувши 24 кейси з правильних у неправильні. Це не артефакт округлення; це інша поведінка моделі. Урок не в тому, що «ніколи не погрожуйте моделі». Він у тому, що емоційне framing не інертне. Воно зсуває розподіл, іноді сильно, у напрямку, який ніхто не може передбачити, просто читаючи речення, — саме тому це треба вимірювати, а не виводити розумом.

Застереження, яке цей розділ вам винен: ці п’ять речень тестували на одній малій моделі й одній задачі. Деякі мають опубліковану підтримку в інших місцях — «take a deep breath» вийшло зі статті, яка шукала високо результативні інструкції, а не вигадувала їх, і це інша та краща заява, ніж та, що потім розійшлася.⁸ Узагальнюються не речення. Узагальнюється те, що список, який вижив у блогах, і список, який виживає у вимірюванні, — це два різні списки, і єдиний спосіб дізнатися, який у вас, — запустити bench.

Правило, яке повторюють усі, — кажіть, чого хочете, а не чого не хочете, — зі звичною відсутністю числа. Ось число. Та сама вимога до формату, записана трьома способами, з вільною генерацією моделі, щоб можна було спостерігати compliance:

Три заборони спрацювали гірше, ніж одна інструкція, і змусили модель написати вп’ятеро більше тексту — точну протилежність усім трьом одночасно. Додавання позитивного речення назад врятувало результат до 68 %.

Механізм не загадковий, якщо пам’ятати Розділ 8. Модель обирає next token із розподілу, conditioned on всього, що перед ним, а заборона кладе заборонене всередину цього conditioning. Оператора заперечення немає; є context, у якому слово тепер з’являється.

Це можна виміряти напряму. Візьміть baseline prompt і додайте один рядок: Do not use the shipping queue for software problems. Потім дивіться лише на сорок п’ять тікетів, які не є shipping tickets:

Назвати чергу, щоб її виключити, змусило модель обирати її утричі частіше, майже втричі збільшило probability mass, яку вона їй призначила, і коштувало 25 пунктів загальної точності — 16 кейсів втрачено проти 1 здобутого, парна ймовірність 0,0003.

Не думайте про слона — виміряно. Переписування завжди однакове: замініть заборону позитивним правилом, яке робить її непотрібною. Не «не використовуйте shipping для проблем із software», а «використовуйте shipping лише коли йдеться про фізичну посилку».

Розділ 12 побудував chain of thought належно — спершу як prompting technique,⁹¹⁰ потім як щось, натреноване verifiable rewards, — і завершив попередженням, яке відклав до цього розділу: прохання до моделі думати крок за кроком перестає допомагати, щойно модель міркує сама, і може шкодити. Ось це попередження з таблицею під ним, у задачі, де легко припустити, що більше мислення має бути кращим.

Обидві гілки читаються тим самим інструментом у тій самій позиції. Єдина різниця — чи сидить у context спочатку chain of thought, який модель написала сама.

Точність знизилася, витрати зросли, і правило самого цього розділу застосовується до власного результату цього розділу: падіння — це 7 кейсів здобуто проти 10 втрачено, парна ймовірність 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, — а потім відповіла на класифікаційне запитання п’ятьма сотнями символів стороннього міркування у власному context. Chain of thought допомагає на задачах із intermediate state, який варто обчислювати: арифметика, multi-hop lookups, constraint satisfaction. Маршрутизація одного речення в один із чотирьох кошиків не має intermediate state. Chain нічого втримувати, тож він лише додає правдоподібний текст, який фінальне рішення потім має пережити.

Два практичні наслідки. По-перше, для моделі, навченої міркувати, — RLVR-моделей із Розділу 12 — інструкція гірша за надлишкову: вона може замінити довгий chain, який модель створила б сама, коротким, prompt-shaped. А sampling кількох chains і голосування, що робить self-consistency,¹¹ не може врятувати задачу, де немає про що не погоджуватися: воно множить вартість на кількість samples, щоб розв’язувати нічиї, яких немає. Розділ 12 виміряв цей trade там, де він справді застосовується. По-друге, зверніть увагу, скільки коштував сам comparison scaffold. Примусова відповідь у рядку Final queue: опустила гілку без reasoning із 76,7 % до 61,7 %. П’ятнадцять пунктів, заплачених за порівнюваність двох гілок. Структура, що існує для вашої зручності, теж не безкоштовна.

Останнє вимірювання, бо це питання всі ставлять після першого несподіваного результату. Шістдесят prompts, greedy decoding, багаторазові запуски:

• Той самий виклик, повторений із незмінним усім, повернув bit-identical ймовірності. Deterministic.
• Той самий виклик, batched з різними сусідами — batch sizes 1, 4, 12, 30 і 60 — повернув ймовірності, що відрізнялися максимум на 0,0128. Вибрана мітка не змінилася жодного разу, у 0 із 60 кейсів.

Мітка вижила, бо мала запас: серед шістдесяти кейсів найвужчий розрив між двома верхніми чергами був 0,0459, у три з половиною рази більший за дрейф. Стабільність не була властивістю алгоритму. Це була margin, а margins закінчуються. Розділ 17 пояснює арифметичну причину й розбирає sampling knobs, що розширюють і звужують ці розриви. Причина розмістити це тут у тому, що воно обмежує сенс будь-якого вимірювання prompt: bench вимірює систему, відтворювану лише до tolerance, і різниця у два пункти між варіантами в поганий день лежить усередині цієї tolerance.

Усе вище — це людина, яка обирає варіант, і машина, яка його оцінює. Очевидний наступний крок — дозволити машині обирати й варіанти теж.

APE робить саме це: модель пропонує кандидатні інструкції, їх оцінюють на held-out examples, і найкращі виживають.⁸ Інструкції, які вона знаходить, часто такі, яких жодна людина не написала б, і саме в цьому сенс — пошук ведеться по тому, що набирає бали, а не по тому, що звучить професійно.

DSPy іде далі й є кориснішою ідеєю для продукту.¹² Ви оголошуєте, що кожен крок pipeline приймає й повертає, а framework компілює це в prompts, добираючи demonstrations і оптимізуючи інструкції під вашу метрику. Змінюєте модель — перекомпілюєте замість переписування. Prompt перестає бути source code, який хтось вручну тюнить, і стає артефактом, згенерованим під метрику, яким і мав бути від самого початку.

Жоден із підходів не прибирає потреби в bench. Обидва роблять його єдиним, що вам потрібно, бо optimiser без метрики нічого не оптимізує.

Залишається дисципліна. Prompts мають жити у version control, у файлах, поруч із кодом, який їх надсилає, — а не в рядку бази даних, який хтось відредагував у вівторок. Їм потрібен ідентифікатор версії, збережений поруч із кожним output, який вони породили, інакше в день регресії ви не дізнаєтеся, що змінилося. Їм потрібен bench у continuous integration, бо prompt — це та частина вашої системи, яку постачальник може тихо знецінити, розгорнувши нову модель. І їм потрібні кейси: не сотня хитрих, а просто нудні двадцять, які ламалися минулого кварталу, збережені назавжди. Bench — це deliverable. Prompt — його побічний продукт.

Усе в цьому розділі вимірювалося точністю. Кожен із цих варіантів також має ціну.

System prompt, який купив 21,7 пункта, надсилається в кожному виклику, назавжди. Два приклади, що купили сім пунктів, надсилаються в кожному виклику, назавжди. Шістнадцять, що купили дванадцять, надсилаються в кожному виклику, назавжди, і вони приблизно вдесятеро довші за запитання, яке користувач насправді поставив. Chain of thought, який нічого не купив, породив дев’яносто вісім додаткових tokens на запит, а output tokens — дорогий тип.

Нічого з цього не видно в таблиці точності, і все це видно в рахунку.

Розділ 16 — про одиницю, у якій ці рішення насправді деноміновані. Token як одиниця білінгу, context window як бюджет, а не пам’ять, чому сорок turn conversation коштує значно більше, ніж у сорок разів перший turn, за що prompt caching платить і за що ні, і чому порядок вашого prompt вирішує, чи взагалі буде cache hit, — що виявляється другою, суто економічною причиною ставити стабільний матеріал першим, а змінний останнім.

Bench і кожну таблицю було створено з Qwen/Qwen2.5-0.5B-Instruct під greedy decoding, тому вони відтворюються точно. Документація Hugging Face щодо chat templates — це reference для того, у що насправді розгортаються markers template з Розділу 11, і для факту, що модель, яка ship з неправильним template, — реальний і повторюваний збій. Для position і format effects у production scale, а не laboratory scale, основні джерела — наведені вище цитати; vendor prompting guides корисні своїми прикладами, і їх слід читати, пам’ятаючи, що жоден із них не публікує інтервал.