Prompt Engineering، ناپ کر: output کو کیا بدلتا ہے

measurements سے پہلے، ایک حقیقت جو خاموشی سے آگے آنے والی آدھی باتوں کی وضاحت کرتی ہے۔

model کے پاس memory نہیں ہوتی۔ دو calls کے درمیان یہ کچھ بھی retain نہیں کرتا — نہ آپ کا پچھلا سوال، نہ اپنا پچھلا جواب، نہ وہ file جو آپ نے attach کی، نہ یہ fact کہ آپ پہلے ہی اسے دو بار پوچھ چکے ہیں۔ ہر call ایک empty machine سے شروع ہوتی ہے، اور اس machine کو صرف tokens کی وہ sequence معلوم ہوتی ہے جو آپ نے ابھی اسے دی ہے۔

chat interface میں جو memory جیسی لگتی ہے وہ آپ کا client پوری conversation کو، ہر turn سمیت، beginning سے دوبارہ بھیج رہا ہوتا ہے۔ model ہر بار اسے پھر سے scratch سے پڑھتا ہے۔ Chapter 13 نے forward pass میں اس re-reading کی cost ناپی؛ Chapter 16 اسے invoice کی ایک line بنا دیتا ہے۔ design کے لیے یہاں consequence اہم ہے: prompt کسی state رکھنے والے system کو message نہیں ہے۔ یہ state ہے۔

اس سے confusions کا ایک خاندان ختم ہو جاتا ہے۔ ”model بھول گیا جو میں نے بتایا تھا“ عموماً اس کا مطلب ہے کہ وہ کبھی بھیجا ہی نہیں گیا۔ ”اس نے میری پہلے والی instruction ignore کی“ عموماً اس کا مطلب ہے کہ history truncate ہونے پر instruction window سے باہر نکل گئی۔ ”production میں اس نے مختلف behave کیا“ عموماً اس کا مطلب ہے کہ production اس prompt سے مختلف prompt assemble کرتا ہے جسے آپ نے test کیا تھا۔ ان میں سے کوئی model problem نہیں، اور ان میں سے کوئی بھی کچھ reword کرنے سے fix نہیں ہوتا۔

claim ”یہ prompt بہتر ہے“ ایک distribution کے بارے میں claim ہے، اور آپ ایک output دیکھ کر distribution نہیں دیکھ سکتے۔ آپ کو boring چیز چاہیے: known answers والے cases، N variants، اور ایک interval۔

harness پچاس lines کا TypeScript ہے جس کی shape Chapter 14 کے client جیسی ہے — ایک request، ایک deadline، کچھ concurrency، ایک tally۔ یہ Chapter 19 میں retriever evaluate کرنے کے لیے اور Chapter 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 };
}

جو number واپس آتا ہے وہ result نہیں ہے۔ یہ ہے:

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

Chapter 4 نے argument بنایا اور یہ chapter اسے cash کرتا ہے۔ بیس میں سے سترہ درست 85 % ہیں، اور اس کا 95 % interval 64 % سے 95 % تک چلتا ہے۔ ایک variant جو 20 میں سے 13 score کرتا ہے — 65 %، جو واضح طور پر worse محسوس ہوتا ہے — اس کا interval 43 % سے 82 % تک ہے۔ یہ دونوں intervals تقریباً اپنی پوری length پر overlap کرتے ہیں۔ بیس cases ایک اچھے prompt کو mediocre prompt سے الگ نہیں بتا سکتے، اور زیادہ تر published prompt advice اس سے کم پر validate ہوئی۔

ساٹھ cases، جو یہ chapter استعمال کرتا ہے، پھر بھی زیادہ نہیں۔ یہ بڑے effects دیکھنے کے لیے کافی ہے اور اتنا honest ہے کہ جب چھوٹے effects نہیں دیکھ سکتا تو admit کرے — اور نیچے کئی بار ایسا کرے گا۔

تین blocks — rules R، ticket T، instruction I — ایک user message میں concatenate کیے گئے۔ تمام چھ permutations، byte-identical content، ہر ایک پر ساٹھ cases۔

best سے worst تک 28.3 points ہیں، اور intervals overlap نہیں کرتے، اس لیے یہ noise کی story نہیں۔ چونکہ ہر arm کو انہی ساٹھ items پر score کیا گیا ہے، sharper question paired ہے: جہاں دو arms disagree کرتے ہیں، split کتنا lopsided ہے؟ worst order سے best کی طرف جانے سے 21 cases right اور 4 wrong flipped — exact paired probability 0.0009۔³

table کو اس کے winner کے بجائے اس کی shape کے لیے پڑھیں۔ دو best rows دونوں ticket پر end ہوتی ہیں؛ دو worst instruction کو middle میں bury کرتی ہیں یا data کے بعد trail کرتی ہیں۔ یہی phenomenon ہے جسے Liu et al. نے Lost in the Middle کہا: prompt کے edges پر material centre کے material سے زیادہ reliably use ہوتا ہے۔⁴ Chapter 16 window کی pricing کرتا ہے اور Chapter 24 effect کو length پر properly measure کرتا ہے، جہاں middle described طریقے سے collapse ہوتا ہے اور very end پر recovery دوبارہ ظاہر نہیں ہوتی۔ یہاں practical rule خود نکل آتا ہے: task اوپر، data نیچے، middle میں کچھ important نہیں۔

اب وہی words turns کے درمیان move کریں۔ Chapter 11 نے establish کیا کہ chat template model کے around decoration نہیں بلکہ اس کا حصہ ہے — <|im_start|>system اور <|im_start|>user real tokens ہیں جو model نے fine-tuning کے دوران millions of times exactly انہی positions میں دیکھے۔ لہٰذا matter کرنا چاہیے کہ آپ کی instruction ان markers کے کس side پر land کرتی ہے، اور واقعی کرتی ہے:

rules اور instruction کو template boundary کے پار move کرنے سے 21.7 points ملے — 19 cases gained، 6 lost، paired probability 0.0146 — ان کے ایک character کو بھی بدلے بغیر۔ یہ system prompt versus user prompt کا concrete answer ہے: یہ ایک ہی بات کہنے کے دو طریقے نہیں۔ یہ اس structure میں دو مختلف token positions ہیں جس پر model trained تھا، اور system position وہ جگہ ہے جہاں پوری conversation پر apply ہونے والی instructions belong کرتی ہیں۔

تیسری row بھی notice کریں۔ ticket کے بعد instruction repeat کرنا — ایک widely recommended trick — اسے ایک بار state کرنے سے below score ہوا۔ اس model پر، اس task پر، دو بار کہنا ایک بار کہنے سے worse تھا۔

وہی prompt، best placement، ساٹھ cases۔ صرف یہ بدلتا ہے کہ ticket text کے گرد کیا ہے۔

punctuation سے اٹھارہ-point spread۔ لیکن دو extreme intervals دیکھیں: [73.9, 91.9] اور [54.1, 77.3]۔ وہ overlap کرتے ہیں۔ crude reading کے مطابق — error bars compare کریں، اور اگر وہ touch کریں تو کچھ نہ کہیں — یہ table کچھ بھی prove نہیں کرتی۔

crude reading یہاں غلط ہے، اور اس کی وجہ سمجھنا table سے زیادہ قیمتی ہے۔ ہر variant کو انہی ساٹھ tickets پر score کیا گیا، لہٰذا دونوں measurements independent samples نہیں؛ paired ہیں۔ ہر interval کی width کا زیادہ تر حصہ uncertainty کے ایک ایسے source سے آتا ہے جو دونوں arms share کرتے ہیں — آیا یہ ساٹھ tickets representative ہیں — اور جب آپ انہیں ایک دوسرے کے خلاف compare کرتے ہیں تو وہ source cancel ہو جاتا ہے۔ اس کے بجائے paired question پوچھیں تو answer sharp ہے: double quotes سے XML tag تک جانے سے 12 cases right اور 1 wrong flipped، paired probability 0.0034۔ یہ real difference ہے۔

اور پھر وہی test headline کو deflate کر دیتا ہے۔ XML tag نے plain Ticket: label کو 8.3 points سے beat کیا، یہی number کوئی blog post اپنے title میں رکھتا۔ Paired: 6 gained، 1 lost، probability 0.1250۔ Established نہیں۔ سات cases ہی وہ basis ہیں جس پر وہ famous improvement rests کرتا ہے۔

تو دو questions ہیں جن کے دو different instruments ہیں، اور انہیں conflate کرنا prompt advice کو بیک وقت دونوں directions میں غلط بناتا ہے:

general finding — کہ models formatting choices کے لیے strongly اور unpredictably sensitive ہیں جن میں کوئی semantic content نہیں — نئی نہیں۔ Sclar et al. نے dozens of tasks پر صرف separators، spacing اور casing vary کی اور accuracy spreads اتنے wide پائے کہ published model rankings reverse ہو جائیں۔⁵ practical consequence ”XML tags use کریں“ نہیں۔ یہ ہے کہ formatting ایک hyperparameter ہے، sweep کرنے کی cost صفر ہے، اور دو models کا کوئی بھی comparison جو ایک format fix کرتا ہے، models جتنا ہی formats بھی compare کر رہا ہوتا ہے۔

In-context learning — model کو prompt میں worked examples دکھانا اور weight update کے بغیر ان سے generalise کروانا — وہ capability ہے جس نے GPT-3 کو famous کیا۔⁶ practical question کبھی یہ نہیں کہ آیا یہ کام کرتی ہے۔ سوال یہ ہے کہ کتنے examples کی cost دینی ہے۔

Examples real prior turns کے طور پر جاتے ہیں، user اور assistant alternate کرتے ہوئے، کیونکہ یہی structure template پر trained تھا۔ ہر k کو سولہ labelled tickets کے disjoint pool سے پانچ different random draws کے ساتھ run کیا گیا:

دو examples نے سات points دیے۔ اگلے چھ examples نے کچھ measurable نہیں دیا — 83.7، پھر 81.7، پھر 83.7، ایک sequence جو اپنی noise کے اندر wander کرتی ہے۔ سولہ نے مزید پانچ and a half دیے۔ curve smooth climb نہیں؛ ایک step، ایک plateau اور ایک step ہے۔

سب سے important column آخری ہے۔ k = 8 پر، آپ نے اتفاقاً کون سے آٹھ examples pick کیے accuracy کو 10 points move کر گئے — دو examples سے آٹھ examples تک جانے کے entire gain سے بڑا۔ اور bottom row اس کا sharpest version ہے: k = 16 پر pool exhaust ہے، لہٰذا پانچوں runs میں بالکل وہی سولہ examples ہیں، فرق صرف ان کی order کا ہے۔ order alone نے accuracy کو 8.3 points move کیا۔

یہی result Lu et al. نے report کیا اور جہاں بھی اسے دیکھا گیا یہ survive کرتا ہے: example ordering ایک genuine hyperparameter ہے جس کے effects example count کے comparable ہیں۔⁷ اس لیے few-shot prompting کے بارے میں honest advice کوئی number نہیں۔ یہ ہے:

اب folklore۔ ان میں سے ہر ایک ایک single sentence ہے جو ایسے system prompt کے شروع میں prepended ہے جو otherwise identical ہے، انہی ساٹھ cases پر۔

پانچ میں سے چار نے کچھ نہیں کیا۔ ”تھوڑا کیا“ نہیں؛ ایسا کچھ نہیں جو ساٹھ paired cases دیکھ سکیں۔ expert persona اور bribe دونوں untouched baseline سے below score ہوئے، اور وہ drops بھی paired test fail کرتے ہیں — downhill point کرتی noise ہیں۔

تیسری row وہ ہے جس کے ساتھ بیٹھنا چاہیے۔ ”This is very important to my career“ نے بالکل وہی accuracy پیدا کی، 60 میں سے 46 — اور ساٹھ answers میں سے دس بدل گئے، پانچ ہر direction میں۔ summary statistic identical تھا اور behaviour نہیں۔ اگر آپ کی evaluation ایک small set پر single number ہے، تو ایک change جو آپ کے outputs کے ایک sixth کو rewrite کرتا ہے، ایک ایسی change جیسا لگ سکتا ہے جس نے کچھ نہیں کیا، اور آپ اسے یہ سمجھ کر ship کریں گے کہ یہ free تھا۔

اور پھر threat، جو واحد sentence ہے جس نے needle move کیا اور اسے 35 points down move کیا، 24 cases کو right سے wrong میں flip کرتے ہوئے۔ یہ rounding artefact نہیں؛ یہ different model behaviour ہے۔ lesson ”model کو کبھی threaten نہ کریں“ نہیں۔ یہ ہے کہ emotional framing inert نہیں۔ یہ distribution کو shift کرتی ہے، کبھی hard، ایسی direction میں جسے sentence پڑھ کر کوئی predict نہیں کر سکتا — اسی لیے اسے reason about کرنے کے بجائے measure کرنا پڑتا ہے۔

ایک caveat جو یہ chapter آپ کو owed ہے: یہ پانچ sentences ایک small model اور ایک task پر tested تھے۔ کچھ کو elsewhere published support حاصل ہے — ”take a deep breath“ ایک paper سے آیا جس نے high-scoring instructions کے لیے search کیا تھا، انہیں invent نہیں کیا، جو بعد میں circulate ہونے والے claim سے different اور better claim ہے۔⁸ جو generalise کرتا ہے وہ sentences نہیں۔ یہ ہے کہ جو list blog posts میں survive ہوئی اور جو list measurement میں survive کرتی ہے، وہ دو different lists ہیں، اور یہ جاننے کا واحد طریقہ کہ آپ کے ہاتھ میں کون سی ہے bench run کرنا ہے۔

ایک rule جو ہر کوئی repeat کرتا ہے — وہ کہیں جو آپ چاہتے ہیں، وہ نہیں جو آپ نہیں چاہتے — معمول کے number کے absence کے ساتھ۔ یہ number ہے۔ وہی format requirement، تین ways میں لکھی ہوئی، model freely generate کر رہا ہے تاکہ compliance observe ہو سکے:

تین prohibitions نے ایک instruction سے worse کیا، اور model کو پانچ گنا زیادہ text لکھوایا — ایک ساتھ تینوں کا exact opposite۔ positive sentence واپس add کرنے سے یہ 68 % تک rescue ہو گیا۔

mechanism mysterious نہیں جب آپ Chapter 8 یاد رکھتے ہیں۔ model پہلے آنے والی ہر چیز پر conditioned distribution سے next token choose کرتا ہے، اور prohibition forbidden thing کو اسی conditioning میں ڈال دیتی ہے۔ negation کے لیے کوئی operator نہیں؛ ایک context ہے جس میں ایک word اب appear ہوتا ہے۔

یہ directly measurable ہے۔ baseline prompt لیں اور ایک line add کریں: Do not use the shipping queue for software problems. پھر صرف ان پینتالیس tickets کو دیکھیں جو shipping tickets نہیں ہیں:

کسی queue کو rule out کرنے کے لیے name کرنے سے model نے اسے تین گنا زیادہ often choose کیا، اسے assign کی ہوئی probability mass تقریباً triple کر دی، اور overall accuracy کے 25 points cost کیے — 1 gained کے مقابلے میں 16 cases lost، paired probability 0.0003۔

ہاتھی کے بارے میں نہ سوچیں، measured۔ rewrite ہمیشہ یہی ہے: prohibition کو اس positive rule سے replace کریں جو اسے unnecessary بنا دے۔ ”software problems کے لیے shipping use نہ کریں“ نہیں بلکہ ”shipping صرف تب use کریں جب physical parcel involved ہو“۔

Chapter 12 نے chain of thought properly build کیا — پہلے prompting technique کے طور پر،⁹¹⁰ پھر ایسی چیز کے طور پر جو verifiable rewards کے ساتھ train in ہوتی ہے — اور ایک warning پر ختم ہوا جسے اس chapter تک defer کیا: model کو step by step سوچنے کو کہنا تب مدد کرنا بند کر دیتا ہے جب model خود reason کرتا ہے، اور hurt کر سکتا ہے۔ یہاں وہ warning ایک table کے ساتھ ہے، ایسے task پر جہاں assume کرنا آسان ہے کہ زیادہ thinking بہتر ہی ہو گی۔

دونوں arms کو same instrument سے same position پر read کیا گیا۔ فرق صرف یہ ہے کہ آیا model کا خود لکھا ہوا chain of thought پہلے context میں بیٹھا ہے۔

Accuracy نیچے گئی اور cost اوپر گئی، اور اس chapter کا اپنا rule اس chapter کے اپنے result پر apply ہوتا ہے: drop 7 cases gained against 10 lost, paired probability 0.629 ہے، جو established نہیں۔ جو established ہے وہ یہ کہ اس نے فی call اٹھانوے extra output tokens پیدا کیے اور ان سے کچھ measurable نہیں خریدا۔ uncertainty entirely benefit side پر ہے۔ bill certain ہے۔

ایک fail ہونے والی chain کامیاب one سے زیادہ instructive ہے۔ ”Your Slack integration stopped posting messages after Tuesday“ کے بارے میں reason کرنے کو کہا گیا، model نے لکھا:

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.

یہ competent troubleshooting advice ہے اور یہ task نہیں ہے۔ سوچنے کو کہا گیا تو model اس genre میں drift ہو گیا جس سے ”think step by step about this support ticket“ اپنی training data میں سب سے زیادہ resembles کرتا ہے — اور پھر classification question کا answer اپنی context میں unrelated reasoning کے پانچ سو characters کے ساتھ دیا۔ Chain of thought ان problems پر help کرتا ہے جن میں compute کرنے کے قابل intermediate state ہو: arithmetic، multi-hop lookups، constraint satisfaction۔ ایک sentence کو چار buckets میں سے ایک میں route کرنے میں کوئی intermediate state نہیں۔ chain کے hold کرنے کے لیے کچھ نہیں، لہٰذا یہ صرف plausible text add کرتا ہے جس سے final decision کو پھر survive کرنا پڑتا ہے۔

دو practical corollaries۔ پہلے، ایسے model کے لیے جو reason کرنے کے لیے trained ہے — Chapter 12 کے RLVR models — instruction redundant سے worse ہے: یہ اس long chain کو جو model produce کرتا، ایک short، prompt-shaped chain سے replace کر سکتی ہے۔ اور کئی chains sample کر کے voting، جو self-consistency کرتی ہے،¹¹ ایسے task کو rescue نہیں کر سکتی جس میں disagree کرنے کو کچھ نہیں: یہ cost کو samples کی number سے multiply کرتی ہے تاکہ ایسی ties break کرے جو موجود ہی نہیں۔ Chapter 12 نے وہ trade measure کیا جہاں یہ apply ہوتا ہے۔ دوسرا، note کریں کہ comparison scaffold itself نے کیا cost کیا۔ answer کو Final queue: line میں force کرنے سے no-reasoning arm 76.7 % سے 61.7 % پر drop ہو گیا۔ پندرہ points، دو arms کو comparable بنانے کے لیے paid۔ آپ کی convenience کے لیے موجود structure بھی free نہیں۔

ایک آخری measurement، کیونکہ پہلا surprising result آنے کے بعد یہی question ہر کوئی پوچھتا ہے۔ ساٹھ prompts، greedy decoding، repeatedly run کیے گئے:

• وہی call، ہر چیز fixed رکھ کر repeated، bit-identical probabilities returned۔ Deterministic۔
• وہی call different neighbours کے ساتھ batched — batch sizes 1، 4، 12، 30 اور 60 — نے probabilities return کیں جو 0.0128 تک differ تھیں۔ chosen label کبھی نہیں بدلا، 60 میں سے 0 cases میں۔

label survive ہوا کیونکہ اس کے پاس room تھا: ساٹھ cases کے across top دو queues کے درمیان narrowest gap 0.0459 تھا، drift سے ساڑھے تین گنا۔ stability algorithm کی property نہیں تھی۔ یہ margin تھی، اور margins ختم ہو جاتی ہیں۔ Chapter 17 وہ جگہ ہے جہاں arithmetic reason رہتی ہے اور جہاں sampling knobs جو ان gaps کو widen اور narrow کرتے ہیں، take apart کیے جاتے ہیں۔ اسے یہاں plant کرنے کی وجہ یہ ہے کہ یہ bound کرتا ہے کہ کوئی prompt measurement کیا mean کر سکتی ہے: bench ایک ایسے system کو measure کرتا ہے جو صرف tolerance تک reproducible ہے، اور variants کے درمیان two-point difference کسی bad day پر اسی tolerance کے اندر ہے۔

اوپر سب کچھ ایک human کا variant choose کرنا اور machine کا اسے grade کرنا ہے۔ obvious next step یہ ہے کہ machine کو variants بھی choose کرنے دیں۔

APE یہی کرتا ہے: model candidate instructions propose کرتا ہے، وہ held-out examples پر scored ہوتی ہیں، اور best survive کرتی ہیں۔⁸ یہ جو instructions find کرتا ہے وہ frequently ایسی ہوتی ہیں جو کوئی human نہ لکھے، اور یہی point ہے — search اس پر ہے کہ کیا score کرتا ہے، اس پر نہیں کہ professional کیا sound کرتا ہے۔

DSPy آگے جاتا ہے اور product کے لیے زیادہ useful idea ہے۔¹² آپ declare کرتے ہیں کہ pipeline کا ہر step کیا لیتا اور return کرتا ہے، اور framework اسے prompts میں compile کرتا ہے، demonstrations select کرتا ہے اور آپ کے metric کے against instructions optimise کرتا ہے۔ model change کریں تو rewrite کے بجائے recompile کریں۔ prompt وہ source code نہیں رہتا جسے کوئی hand-tune کرتا ہے بلکہ metric کے against generated artefact بن جاتا ہے، جو اسے شروع سے ہونا چاہیے تھا۔

Neither bench کی need remove کرتا ہے۔ دونوں اسے واحد چیز بنا دیتے ہیں جو آپ کو چاہیے، کیونکہ metric کے بغیر optimiser کچھ optimise نہیں کرتا۔

اب discipline باقی ہے۔ Prompts version control میں، files میں، انہیں بھیجنے والے code کے next to belong کرتے ہیں — کسی database row میں نہیں جسے کسی نے Tuesday کو edit کیا۔ انہیں ہر output کے alongside stored version identifier چاہیے جو انہوں نے produce کیا، ورنہ جس دن کچھ regress ہو آپ معلوم نہیں کر سکتے کیا changed۔ انہیں continuous integration میں bench چاہیے، کیونکہ prompt آپ کے system کا وہ ایک حصہ ہے جسے vendor نیا model deploy کر کے silently invalidate کر سکتا ہے۔ اور انہیں cases چاہیے: hundred clever ones نہیں، بس boring بیس جو last quarter broken تھے، forever kept۔ bench deliverable ہے۔ prompt اس کا by-product ہے۔

اس chapter میں ہر چیز accuracy میں measured تھی۔ ان variants میں سے ہر ایک کی price بھی ہے۔

وہ system prompt جس نے 21.7 points دیے، ہر call پر، forever بھیجا جاتا ہے۔ وہ دو examples جنہوں نے سات points دیے، ہر call پر، forever بھیجے جاتے ہیں۔ وہ سولہ جنہوں نے بارہ دیے، ہر call پر، forever بھیجے جاتے ہیں، اور وہ roughly اس question کی length کے ten times ہیں جو user نے واقعی پوچھا۔ chain of thought جس نے کچھ نہیں خریدا، فی request اٹھانوے extra tokens produce کر گیا، اور output tokens expensive kind ہیں۔

یہ کچھ بھی accuracies کی table میں visible نہیں، اور یہ سب invoice پر visible ہے۔

Chapter 16 اس unit کے بارے میں ہے جس میں یہ decisions actually denominated ہیں۔ billing unit کے طور پر token، memory کے بجائے budget کے طور پر context window، کیوں forty-turn conversation first turn کے forty times سے کہیں زیادہ cost کرتی ہے، prompt caching کس چیز کی payment کرتی ہے اور کس کی نہیں، اور کیوں آپ کے prompt کی order decide کرتی ہے کہ cache hit ہو گا بھی یا نہیں — جو stable material پہلے اور variable material آخر میں رکھنے کی ایک دوسری، entirely economic وجہ نکلتی ہے۔

bench اور ہر table Qwen/Qwen2.5-0.5B-Instruct کے ساتھ greedy decoding کے تحت produced ہوئے، اس لیے وہ exactly reproduce ہوتے ہیں۔ chat templates پر Hugging Face documentation اس بات کا reference ہے کہ Chapter 11 کے template markers actually کس میں expand ہوتے ہیں، اور اس fact کا بھی کہ wrong template کے ساتھ ship ہونے والا model real اور recurring failure ہے۔ laboratory scale کے بجائے production scale پر position اور format effects کے لیے اوپر citations primary sources ہیں؛ vendor prompting guides اپنی examples کے لیے useful ہیں اور انہیں یہ جان کر پڑھنا چاہیے کہ ان میں سے کوئی interval publish نہیں کرتا۔