Prompt Engineering با عدد و سنجش: چه چیزی خروجی را تغییر می‌دهد

پیش از اندازه‌گیری‌ها، یک واقعیت که بی‌سروصدا نیمی از آنچه بعد می‌آید را توضیح می‌دهد.

مدل حافظه ندارد. بین دو فراخوانی هیچ چیز را نگه نمی‌دارد — نه پرسش قبلی شما، نه پاسخ قبلی خودش، نه فایلی که پیوست کرده‌اید، نه این واقعیت که قبلاً دو بار از آن پرسیده‌اید. هر فراخوانی از یک ماشین خالی شروع می‌شود، و تنها چیزی که آن ماشین می‌داند دنباله tokenهایی است که همین حالا به آن داده‌اید.

چیزی که در رابط چت شبیه حافظه به نظر می‌رسد، client شماست که کل مکالمه را، نوبت به نوبت، از ابتدا دوباره می‌فرستد. مدل هر بار همه آن را از صفر دوباره می‌خواند. فصل 13 هزینه این بازخوانی را در یک forward pass اندازه گرفت؛ فصل 16 آن را به یک خط روی فاکتور تبدیل می‌کند. آنچه اینجا مهم است پیامد طراحی است: prompt پیامی به سیستمی نیست که state دارد. خود state است.

این واقعیت یک خانواده از سردرگمی‌ها را کنار می‌گذارد. «مدل یادش رفت چه گفته بودم» معمولاً یعنی آن چیز اصلاً فرستاده نشده بود. «دستور قبلی من را نادیده گرفت» معمولاً یعنی آن دستور وقتی history کوتاه شد، از window بیرون افتاد. «در production متفاوت رفتار کرد» معمولاً یعنی production prompt متفاوتی از چیزی که شما تست کرده‌اید می‌سازد. هیچ‌کدام مشکل مدل نیستند، و هیچ‌کدام با بازنویسی چیزی حل نمی‌شوند.

ادعای «این prompt بهتر است» ادعایی درباره یک توزیع است، و با نگاه کردن به یک خروجی نمی‌توانید توزیع را ببینید. چیزی که لازم دارید کسل‌کننده است: موردهایی با پاسخ معلوم، N نسخه، و یک بازه.

harness پنجاه خط TypeScript است با همان شکل client از فصل 14 — یک request، یک deadline، کمی 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 متوسط جدا کند، و بیشتر توصیه‌های منتشرشده درباره prompt روی کمتر از این اعتبارسنجی شده‌اند.

شصت مورد، یعنی چیزی که این فصل استفاده می‌کند، هنوز زیاد نیست. برای دیدن اثرهای بزرگ کافی است و آن‌قدر صادق هست که وقتی نمی‌تواند اثرهای کوچک را ببیند اعتراف کند — و پایین‌تر چند بار همین کار را خواهد کرد.

سه بلوک — rules R، ticket T، instruction I — که در یک پیام user به هم چسبانده شده‌اند. همه شش جایگشت، محتوای byte-identical، هرکدام شصت مورد.

از بهترین تا بدترین 28.3 امتیاز فاصله است، و بازه‌ها هم‌پوشانی ندارند، پس این یکی داستان noise نیست. چون هر arm روی همان شصت آیتم امتیاز گرفته، پرسش دقیق‌تر پرسش paired است: در موردهایی که دو arm اختلاف دارند، شکاف چقدر یک‌طرفه است؟ رفتن از بدترین ترتیب به بهترین، 21 مورد را درست و 4 مورد را غلط کرد — احتمال paired دقیق 0.0009.³

جدول را برای شکلش بخوانید نه برنده‌اش. دو ردیف بهتر هر دو با ticket تمام می‌شوند؛ دو ردیف بدتر instruction را وسط دفن می‌کنند یا بعد از data دنبال آن می‌آورند. این همان پدیده‌ای است که Liu و همکاران Lost in the Middle نامیدند: ماده‌ای که در لبه‌های prompt است قابل‌اعتمادتر از ماده‌ای در مرکز استفاده می‌شود.⁴ فصل 16 برای window قیمت می‌گذارد و فصل 24 اثر را درست در طول زیاد اندازه می‌گیرد، جایی که middle همان‌طور که توصیف شده فرو می‌ریزد و بازیابی در انتهای کاملاً آخر دوباره ظاهر نمی‌شود. اینجا قاعده عملی خودش بیرون می‌افتد: task بالا، data پایین، هیچ چیز مهمی در وسط.

حالا همان واژه‌ها را بین نوبت‌ها جابه‌جا کنید. فصل 11 نشان داد که chat template تزئینی دور مدل نیست، بلکه بخشی از آن است — <|im_start|>system و <|im_start|>user tokenهای واقعی‌اند که مدل میلیون‌ها بار در طول fine-tuning دقیقاً در همان جایگاه‌ها دیده است. پس باید مهم باشد که instruction شما در کدام طرف آن markerها فرود می‌آید، و مهم هم هست:

بردن rules و instruction از آن سوی مرز template 21.7 امتیاز خرید — 19 مورد به دست آمد، 6 مورد از دست رفت، احتمال paired برابر 0.0146 — بدون تغییر حتی یک کاراکتر. این پاسخ ملموس به system prompt در برابر user prompt است: آن‌ها دو راه برای گفتن یک چیز نیستند. دو جایگاه token متفاوت در ساختاری‌اند که مدل روی آن آموزش دیده، و جایگاه system همان‌جایی است که instructionهای مربوط به کل مکالمه باید قرار بگیرند.

به ردیف سوم هم توجه کنید. تکرار instruction بعد از ticket — ترفندی که زیاد توصیه می‌شود — کمتر از یک بار گفتن آن امتیاز گرفت. روی این مدل، روی این وظیفه، دو بار گفتن بدتر از یک بار گفتن بود.

همان prompt، بهترین placement، شصت مورد. تنها چیزی که تغییر می‌کند چیزی است که دور متن ticket قرار می‌گیرد.

هجده امتیاز اختلاف از punctuation. اما به دو بازه افراطی نگاه کنید: [73.9, 91.9] و [54.1, 77.3]. هم‌پوشانی دارند. با خوانش خام — error barها را مقایسه کن، و اگر لمس شدند چیزی نگو — این جدول هیچ چیز را ثابت نمی‌کند.

اینجا خوانش خام اشتباه است، و فهمیدن چرایش از خود جدول ارزشمندتر است. هر نسخه روی همان شصت ticket امتیاز گرفته، پس دو اندازه‌گیری sampleهای مستقل نیستند؛ paired هستند. بیشتر عرض هر بازه از منبعی از عدم‌قطعیت می‌آید که هر دو arm در آن شریک‌اند — اینکه آیا این شصت ticket نماینده‌اند یا نه — و این منبع وقتی آن‌ها را با هم مقایسه می‌کنید حذف می‌شود. به‌جایش پرسش paired را بپرسید و پاسخ تیز است: رفتن از نقل‌قول دوتایی به تگ XML 12 مورد را درست و 1 مورد را غلط کرد، احتمال paired برابر 0.0034. این یک تفاوت واقعی است.

و بعد همان تست headline را کم‌باد می‌کند. تگ XML از label ساده Ticket: به اندازه 8.3 امتیاز بهتر بود، همان عددی که یک پست وبلاگی در عنوانش می‌گذاشت. Paired: 6 به دست آمده، 1 از دست رفته، احتمال 0.1250. ثابت نشده. آن بهبود مشهور روی هفت مورد تکیه دارد.

پس دو پرسش با دو ابزار متفاوت وجود دارد، و قاطی کردنشان همان چیزی است که توصیه‌های prompt را هم‌زمان در هر دو جهت خراب می‌کند:

یافته کلی — اینکه مدل‌ها به انتخاب‌های formatting که هیچ محتوای معنایی ندارند شدیداً و غیرقابل‌پیش‌بینی حساس‌اند — تازه نیست. Sclar و همکاران فقط separatorها، فاصله‌گذاری و casing را در ده‌ها task تغییر دادند و spread دقتی پیدا کردند که آن‌قدر بزرگ بود که rankingهای منتشرشده مدل‌ها را برعکس کند.⁵ پیامد عملی «از تگ XML استفاده کنید» نیست. این است که formatting یک hyperparameter است، sweep کردنش هزینه‌ای ندارد، و هر مقایسه دو مدل که یک format را ثابت می‌گیرد، formatها را به همان اندازه مدل‌ها مقایسه می‌کند.

In-context learning — نشان دادن مثال‌های حل‌شده به مدل در prompt و واداشتن آن به تعمیم از آن‌ها بدون هیچ weight update — همان قابلیتی است که GPT-3 را مشهور کرد.⁶ پرسش عملی هرگز این نیست که آیا کار می‌کند یا نه. این است که برای چند مثال باید پول بدهید.

مثال‌ها به‌صورت نوبت‌های prior واقعی می‌آیند، یکی user و یکی assistant، چون template روی همین ساختار آموزش دیده بود. هر k با پنج draw تصادفی متفاوت از یک pool جداگانه شامل شانزده ticket برچسب‌دار اجرا شد:

دو مثال هفت امتیاز خرید. شش مثال بعدی هیچ چیز قابل‌اندازه‌گیری نخرید — 83.7، بعد 81.7، بعد 83.7، دنباله‌ای که در noise خودش پرسه می‌زند. شانزده مثال پنج‌ونیم امتیاز دیگر خرید. منحنی صعود نرم نیست؛ یک پله، یک فلات و یک پله است.

مهم‌ترین ستون، ستون آخر است. در k = 8، اینکه تصادفاً کدام هشت مثال را انتخاب کرده‌اید دقت را 10 امتیاز جابه‌جا کرد — بزرگ‌تر از کل سود رفتن از دو مثال به هشت. و ردیف پایین تیزترین نسخه آن است: در k = 16 pool تمام می‌شود، پس هر پنج اجرا دقیقاً همان شانزده مثال را دارند و فقط در ترتیب ظاهرشدن فرق می‌کنند. فقط ترتیب، دقت را 8.3 امتیاز جابه‌جا کرد.

این همان نتیجه‌ای است که Lu و همکاران گزارش کردند و هرجا دنبالش گشته‌اند دوام آورده است: ترتیب مثال‌ها یک hyperparameter واقعی با اثرهایی هم‌اندازه تعداد مثال‌هاست.⁷ پس توصیه صادقانه درباره few-shot prompting یک عدد نیست. این است:

حالا نوبت folklore. هرکدام از این‌ها یک جمله واحد است که به ابتدای system promptی که در باقی موارد یکسان است اضافه شده، روی همان شصت مورد.

چهار مورد از پنج مورد هیچ کاری نکردند. نه «کمی اثر داشتند»؛ هیچ چیزی که شصت مورد paired بتواند ببیند. persona متخصص و رشوه هر دو کمتر از baseline دست‌نخورده امتیاز گرفتند، و حتی همان افت‌ها هم از تست paired عبور نمی‌کنند — noise هستند که رو به پایین اشاره می‌کند.

ردیف سوم همان است که باید با آن مکث کرد. «این برای مسیر شغلی من خیلی مهم است» دقیقاً همان دقت را تولید کرد، 46 از 60 — و ده پاسخ از شصت پاسخ تغییر کرد، پنج مورد در هر جهت. آمار خلاصه یکسان بود و رفتار نه. اگر ارزیابی شما یک عدد واحد روی مجموعه‌ای کوچک باشد، تغییری که یک‌ششم خروجی‌هایتان را بازنویسی می‌کند می‌تواند شبیه تغییری به نظر برسد که هیچ کاری نکرده، و شما آن را با این باور ship می‌کنید که رایگان بوده است.

و بعد تهدید، که تنها جمله‌ای است که needle را تکان داد و آن را 35 امتیاز رو به پایین برد، و 24 مورد را از درست به غلط برگرداند. این artifact گرد کردن نیست؛ رفتار مدل دیگری است. درس این نیست که «هرگز مدل را تهدید نکنید». این است که framing احساسی inert نیست. توزیع را جابه‌جا می‌کند، گاهی شدید، در جهتی که هیچ‌کس از خواندن جمله نمی‌تواند پیش‌بینی کند — و دقیقاً به همین دلیل باید سنجیده شود، نه اینکه درباره‌اش استدلال شود.

یک caveat که این فصل به شما بدهکار است: این پنج جمله روی یک مدل کوچک و یک task تست شدند. بعضی از آن‌ها پشتوانه منتشرشده در جاهای دیگر دارند — «یک نفس عمیق بکش» از مقاله‌ای آمد که برای instructionهای امتیازبالا جست‌وجو کرده بود نه اینکه آن‌ها را اختراع کند، و این ادعایی متفاوت و بهتر از چیزی است که بعداً پخش شد.⁸ آنچه generalise می‌شود جمله‌ها نیستند. این است که فهرستی که در پست‌های وبلاگی دوام آورد و فهرستی که از اندازه‌گیری جان سالم به در می‌برد دو فهرست متفاوت‌اند، و تنها راه دانستن اینکه کدام یکی را در دست دارید اجرای bench است.

قاعده‌ای که همه تکرار می‌کنند — بگویید چه می‌خواهید، نه اینکه چه نمی‌خواهید — با همان نبود همیشگی عدد. این عددش است. همان requirement قالب، به سه شکل نوشته شده، با مدل که آزادانه generate می‌کند تا compliance مشاهده شود:

سه نهی از یک instruction بدتر عمل کرد، و مدل را واداشت پنج برابر بیشتر متن بنویسد — دقیقاً خلاف هر سه آن‌ها به‌طور هم‌زمان. اضافه کردن دوباره جمله مثبت آن را تا 68 % نجات داد.

وقتی فصل 8 را به یاد بیاورید، سازوکار مرموز نیست. مدل token بعدی را از توزیعی انتخاب می‌کند که به هرچه پیش از آن آمده conditioned است، و یک prohibition چیز ممنوعه را داخل همان conditioning می‌گذارد. هیچ operatorای برای negation وجود ندارد؛ contextای هست که حالا یک واژه در آن ظاهر شده است.

این را می‌شود مستقیم اندازه گرفت. prompt baseline را بگیرید و یک خط اضافه کنید: Do not use the shipping queue for software problems. سپس فقط به چهل‌وپنج ticketی نگاه کنید که ticketهای shipping نیستند:

نام بردن از یک صف برای کنار گذاشتنش باعث شد مدل آن را سه برابر بیشتر انتخاب کند، تقریباً probability massی را که به آن اختصاص می‌داد سه برابر کرد، و 25 امتیاز از دقت کلی کم کرد — 16 مورد از دست رفت در برابر 1 مورد به دست آمده، احتمال paired برابر 0.0003.

به فیل فکر نکن، اندازه‌گیری‌شده. بازنویسی همیشه یکسان است: prohibition را با rule مثبت جایگزین کنید که آن را غیرضروری می‌کند. نه «برای مشکلات نرم‌افزاری از shipping استفاده نکن» بلکه «از shipping فقط وقتی استفاده کن که یک بسته فیزیکی در میان است».

فصل 12 chain of thought را درست ساخت — اول به‌عنوان یک تکنیک prompting،⁹¹⁰ بعد به‌عنوان چیزی که با rewardهای قابل‌راستی‌آزمایی در مدل training شد — و با هشداری تمام شد که به این فصل موکول کرده بود: گفتن اینکه مدل قدم‌به‌قدم فکر کند وقتی مدل خودش reasoning می‌کند دیگر کمک نمی‌کند، و می‌تواند آسیب بزند. این همان هشدار است با جدولی زیر آن، روی taskی که در آن آسان است فرض کنیم فکر بیشتر حتماً بهتر است.

هر دو arm با همان ابزار در همان جایگاه خوانده می‌شوند. تنها تفاوت این است که آیا chain of thoughtی که خود مدل نوشته اول در context نشسته یا نه.

دقت پایین آمد و هزینه بالا رفت، و قانون خود این فصل بر نتیجه خود این فصل هم اعمال می‌شود: افت 7 مورد به دست آمده در برابر 10 مورد از دست رفته، احتمال paired برابر 0.629 است، که ثابت‌شده نیست. آنچه ثابت‌شده این است که نودوهشت output token اضافه برای هر فراخوانی تولید کرد و هیچ چیز قابل‌اندازه‌گیری با آن نخرید. عدم‌قطعیت تماماً سمت سود است. صورت‌حساب قطعی است.

chainای که شکست می‌خورد آموزنده‌تر از chainای است که کار می‌کند. وقتی از مدل خواسته شد درباره «integration شما با Slack بعد از سه‌شنبه دیگر پیام ارسال نمی‌کند» reason کند، نوشت:

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.

این توصیه عیب‌یابی شایسته‌ای است و task نیست. وقتی از مدل خواسته شد فکر کند، مدل به ژانری drift کرد که «درباره این ticket پشتیبانی قدم‌به‌قدم فکر کن» بیشترین شباهت را در داده‌های training آن داشت — و بعد به یک پرسش classification با پانصد کاراکتر reasoning نامرتبط در context خودش پاسخ داد. Chain of thought روی مسئله‌هایی کمک می‌کند که intermediate state ارزش محاسبه کردن دارد: arithmetic، lookupهای multi-hop، constraint satisfaction. route کردن یک جمله به یکی از چهار bucket intermediate state ندارد. چیزی نیست که chain نگه دارد، پس فقط متن plausible اضافه می‌کند که تصمیم نهایی بعداً باید از آن جان سالم به در ببرد.

دو corollary عملی. اول، برای مدلی که برای reasoning آموزش دیده — مدل‌های RLVR فصل 12 — این instruction بدتر از redundant است: می‌تواند chain بلندتری را که مدل خودش تولید می‌کرد با یک chain کوتاه و prompt-shaped جایگزین کند. و sample گرفتن از چند chain و رأی‌گیری، همان کاری که self-consistency می‌کند،¹¹ نمی‌تواند taskی را نجات دهد که چیزی برای اختلاف ندارد: هزینه را در تعداد sampleها ضرب می‌کند تا tieهایی را بشکند که وجود ندارند. فصل 12 این trade را همان‌جایی که کاربرد دارد اندازه گرفت. دوم، توجه کنید خود scaffold مقایسه چه هزینه‌ای داشت. مجبور کردن پاسخ به یک خط Final queue: arm بدون reasoning را از 76.7 % به 61.7 % پایین آورد. پانزده امتیاز، پرداخت‌شده برای اینکه دو arm قابل‌مقایسه شوند. ساختاری که برای راحتی شما وجود دارد هم رایگان نیست.

یک اندازه‌گیری آخر، چون این همان پرسشی است که همه پس از اولین نتیجه غافلگیرکننده می‌پرسند. شصت prompt، greedy decoding، اجرای مکرر:

• همان فراخوانی تکرارشده با ثابت نگه داشتن همه چیز، probabilityهای bit-identical برگرداند. deterministic.
• همان فراخوانی batched با همسایه‌های متفاوت — اندازه batchهای 1، 4، 12، 30 و 60 — probabilityهایی برگرداند که تا 0.0128 فرق داشتند. label انتخاب‌شده هرگز تغییر نکرد، در 0 از 60 مورد.

label دوام آورد چون جا داشت: در میان شصت مورد، باریک‌ترین فاصله بین دو صف برتر 0.0459 بود، سه‌ونیم برابر drift. پایداری ویژگی algorithm نبود. یک margin بود، و marginها تمام می‌شوند. فصل 17 جایی است که دلیل حسابی آن قرار دارد و جایی که knobهای sampling که این فاصله‌ها را پهن و باریک می‌کنند باز می‌شوند. دلیل کاشتنش اینجا این است که کران می‌گذارد روی اینکه هر اندازه‌گیری prompt چه معنایی می‌تواند داشته باشد: bench سیستمی را اندازه می‌گیرد که فقط تا یک tolerance بازتولیدپذیر است، و اختلاف دو امتیازی بین نسخه‌ها در یک روز بد داخل همان tolerance است.

همه آنچه بالا آمد انسانی بود که یک نسخه انتخاب می‌کرد و ماشینی که نمره‌اش می‌داد. قدم بدیهی بعدی این است که بگذاریم ماشین نسخه‌ها را هم انتخاب کند.

APE دقیقاً همین کار را می‌کند: یک مدل instructionهای candidate پیشنهاد می‌دهد، روی مثال‌های held-out امتیاز می‌گیرند، و بهترین‌ها باقی می‌مانند.⁸ instructionهایی که پیدا می‌کند اغلب چیزهایی‌اند که هیچ انسانی نمی‌نوشت، و نکته همین است — جست‌وجو روی چیزی است که امتیاز می‌گیرد، نه روی چیزی که حرفه‌ای به نظر می‌رسد.

DSPy جلوتر می‌رود و برای محصول ایده مفیدتری است.¹² شما اعلام می‌کنید هر مرحله از یک pipeline چه چیزی می‌گیرد و چه چیزی برمی‌گرداند، و framework آن را به promptها compile می‌کند، demonstrationها را انتخاب می‌کند و instructionها را بر اساس metric شما optimise می‌کند. مدل را عوض کنید و به‌جای بازنویسی recompile می‌کنید. prompt دیگر source codeی نیست که کسی دستی tuning کند؛ به artefactی تبدیل می‌شود که در برابر یک metric تولید شده، همان چیزی که از اول باید می‌بود.

هیچ‌کدام نیاز به bench را حذف نمی‌کند. هر دو آن را به تنها چیزی تبدیل می‌کنند که نیاز دارید، چون optimiser بدون metric هیچ چیز را optimise نمی‌کند.

آنچه باقی می‌ماند discipline است. promptها باید در version control باشند، در فایل‌ها، کنار کدی که آن‌ها را می‌فرستد — نه در ردیفی از database که کسی یک سه‌شنبه ویرایش کرده است. باید یک شناسه نسخه داشته باشند که کنار هر خروجی‌ای که تولید کرده‌اند ذخیره شود، وگرنه روزی که چیزی regress می‌کند نمی‌توانید بفهمید چه چیزی تغییر کرده. به bench در continuous integration نیاز دارند، چون prompt همان بخشی از سیستم شماست که vendor می‌تواند با deploy کردن یک مدل جدید بی‌صدا invalidate کند. و به case نیاز دارند: نه صد مورد هوشمندانه، فقط همان بیست مورد کسل‌کننده‌ای که فصل قبل شکستند، و برای همیشه نگه داشته شوند. bench همان deliverable است. prompt محصول جانبی آن است.

همه چیز در این فصل با دقت اندازه‌گیری شد. هرکدام از آن نسخه‌ها یک قیمت هم دارد.

system promptای که 21.7 امتیاز خرید در هر فراخوانی، برای همیشه، فرستاده می‌شود. دو مثالی که هفت امتیاز خریدند در هر فراخوانی، برای همیشه، فرستاده می‌شوند. شانزده مثالی که دوازده امتیاز خریدند در هر فراخوانی، برای همیشه، فرستاده می‌شوند، و تقریباً ده برابر طول پرسشی هستند که کاربر واقعاً پرسیده است. chain of thoughtی که هیچ چیز نخرید برای هر request نودوهشت token اضافه تولید کرد، و output tokenها نوع گران‌اند.

هیچ‌کدام از این‌ها در جدول دقت‌ها دیده نمی‌شود، و همه آن‌ها روی فاکتور دیده می‌شود.

فصل 16 درباره واحدی است که این تصمیم‌ها واقعاً با آن denominated می‌شوند. token به‌عنوان واحد billing، context window به‌عنوان بودجه نه حافظه، اینکه چرا یک مکالمه چهل‌نوبتی خیلی بیشتر از چهل برابر نوبت اول هزینه دارد، prompt caching چه چیزی را پرداخت می‌کند و چه چیزی را نه، و چرا ترتیب prompt شما تصمیم می‌گیرد cache اصلاً hit می‌شود یا نه — که معلوم می‌شود دلیل دوم و کاملاً اقتصادی برای گذاشتن material پایدار در ابتدا و material متغیر در انتهاست.

bench و هر جدول با Qwen/Qwen2.5-0.5B-Instruct زیر greedy decoding تولید شدند، پس دقیقاً بازتولید می‌شوند. مستندات Hugging Face درباره chat templateها مرجع این است که markerهای template فصل 11 واقعاً به چه چیزی expand می‌شوند، و اینکه مدلی که template اشتباه ship می‌کند یک failure واقعی و تکرارشونده است. برای effectهای position و format در مقیاس production نه مقیاس آزمایشگاه، citationهای بالا منابع اصلی‌اند؛ راهنماهای prompting vendorها برای مثال‌هایشان مفیدند و باید با این آگاهی خوانده شوند که هیچ‌کدام interval منتشر نمی‌کنند.