LLM evaluation: public benchmarks سے آپ کے golden set تک

evaluation پر تقریباً ہر بحث میں دو لوگ مختلف چیزیں measure کر رہے ہوتے ہیں۔ تین projects ہیں اور ان کا کوئی instrument مشترک نہیں۔

Confusion ایک سمت میں مہنگی پڑتی ہے۔ leaderboard آپ کو بتاتا ہے کہ model graduate-level reasoning میں strong ہے؛ یہ آپ کو نہیں بتا سکتا کہ وہ آپ کے support tickets route کرے گا یا نہیں۔ اور application evaluation جو ہر input پر ایک answer score کرتی ہے، agent کو دیکھ ہی نہیں سکتی، کیونکہ agent کے پاس trajectories کی distribution ہوتی ہے اور ایک answer اس کا ایک single sample ہے۔ باب 22 نے اس تیسری row کو نام دیا اور اسے خالی چھوڑا: performance measure، agent کی specification کا وہ حصہ جسے teams سب سے آخر میں لکھتی ہیں یا کبھی نہیں لکھتیں۔

ترتیب بھی اہم ہے، اور model بیچنے والا vendor بھی یہی کہتا ہے۔ OpenAI کی agent guide model selection کو تین steps میں کم کرتی ہے، اسی order میں: ”performance baseline قائم کرنے کے لیے evals set up کریں“، ”دستیاب بہترین models کے ساتھ اپنے accuracy target کو meet کرنے پر focus کریں“، ”جہاں ممکن ہو larger models کو smaller ones سے replace کر کے cost اور latency optimize کریں“۔¹ Evaluation پہلے آتی ہے، کیونکہ step دو اور تین کسی number کے بغیر بے معنی ہیں۔

golden set inputs کی فہرست ہے، ہر ایک کے ساتھ answer لکھا ہوا، اور ایک grader جو فیصلہ کرتا ہے کہ output match کرتی ہے یا نہیں۔ یہ boring ہے، یہ چھوٹا ہے، اور اس باب میں یہی واحد artefact ہے جو آپ کا ہے۔ یہاں built ہونے والا set پانچ files کی directory پر بیس tasks رکھتا ہے — باب 23 کے تین نہیں، اس لیے answers وہی answers نہیں — اور grader agent کے run ہونے سے پہلے لکھا جاتا ہے:

export type Task = {
  id: string;
  prompt: string;
  answer: string;          // the fact, in words, for a human and for a judge
  must: RegExp[];          // ALL must match the final answer
  mustNot?: RegExp[];      // NONE may match
};

export const GOLDEN: Task[] = [
  { id: "t04", prompt: "Which file is the largest?", answer: "access.log",
    must: [/access\.log/i], mustNot: [/errors\.log/i, /notes\.txt/i] },       
  { id: "t12", prompt: "Which HTTP status codes appear in access.log? List all of them.",
    answer: "200, 429 and 500", must: [/200/, /429/, /500/] },                
  // ...eighteen more
];

دو properties load-bearing ہیں۔ mustNot list اس لیے موجود ہے کہ ایسا model جو تین files کے نام دے، جن میں درست file بھی شامل ہو، اس نے answer نہیں کیا۔ اور answer prose کے ساتھ ساتھ patterns میں بھی لکھی گئی ہے، کیونکہ بعد میں human اور judge دونوں کو اس کی ضرورت ہوگی — اور ایک ہی fact کو دو notations میں دوبارہ لکھنا ہی وہ طریقہ ہے جس سے آپ کو پتا چلتا ہے کہ آپ خود task کے بارے میں اپنے ساتھ agree نہیں کرتے تھے۔

اب فیصلہ کرنے والی table۔ چار candidate systems، وہی بیس tasks، interval سمیت accuracy، اور وہ دو columns جو accuracies کی table اکیلی ہمیشہ چھپا دیتی ہے:

winner سے پہلے intervals پڑھیں۔ Arm B کی runs 11 % سے 47 % تک جاتی ہیں؛ arm A کی 3 % سے 30 % تک۔ وہ اپنی length کے بیشتر حصے میں overlap کرتی ہیں، جو باب 4 کی finding کو عین اسی جگہ لے آتا ہے جہاں اس کا وعدہ کیا گیا تھا: بیس cases چار systems کو rank نہیں کر سکتے۔ باب 15 نے paired question پوچھ کر اسے sharpen کیا تھا — جن cases میں دو arms disagree کرتے ہیں، split کتنا lopsided ہے؟ — کیونکہ set کی shared difficulty cancel ہو جاتی ہے۔ ہر pair یہ ہے:

A vs B  +0 / -3   p = 0.2500       B vs C  +4 / -1   p = 0.3750
A vs C  +2 / -2   p = 1.0000       B vs D  +4 / -0   p = 0.1250
A vs D  +2 / -1   p = 1.0000       C vs D  +1 / -0   p = 1.0000

چھ comparisons میں سے ایک بھی established نہیں۔ بہترین arm no tools والی arm کو پندرہ points سے beat کرتا ہے، اور یہ تین discordant cases پر کھڑا ہے۔ بیس cases mechanism دکھاتے ہیں اور supplier نہیں چن سکتے؛ meeting میں اس کے برعکس کہنا ہی وہ طریقہ ہے جس سے bad model خریدا جاتا ہے۔

ایک چیز ہے جو یہ table establish کرتی ہے، اور وہی column ہے جو کوئی نہیں لگاتا۔ Arm D فی solved task arm B سے تیرہ گنا cost کرتا ہے، کیونکہ تین trajectories sample کرنا اور modal answer لینا bill کو تین گنا کر دیتا ہے چاہے accuracy تین گنا ہو یا نہ ہو۔ Accuracy tables جو cost omit کرتی ہیں اس trade کو invisible بنا دیتی ہیں۔

اب وہ finding جو ہر benchmark کو پڑھنے کا آپ کا طریقہ بدل دیتی ہے۔ وہی دو سو transcripts لیں — بیس tasks، دس runs، ایک token بھی regenerate نہیں — اور انہیں تین طریقوں سے score کریں:

صفر، تیرہ، چھبیس۔ system نہیں بدلا۔ grader بدلا۔ Exact match صفر return کرتا ہے اس لیے نہیں کہ agent useless ہے، بلکہ اس لیے کہ کوئی free-text answer کبھی reference کے byte-identical نہیں ہوتا: یہ formatting کو measure کرتا ہے اور اسے capability کے طور پر report کرتا ہے۔

یہ curiosity نہیں، mechanism ہے، اور اس کا نام ہے۔ hard-cutoff metric کسی task کو کئی sub-facts پر all-or-nothing score کرتی ہے، اس لیے یہ compound ہوتی ہے۔ Task t12 ایک ساتھ تین status codes مانگتا ہے۔ دس runs میں:

per-code presence   200: 9/10    429: 6/10    500: 8/10    (mean 0.77 per fact)
all three at once   5/10

ہر fact تقریباً تین چوتھائی وقت درست ہے؛ تینوں کو ایک ساتھ demand کرنا score کو آدھا کر دیتا ہے، اور $0.77^3 = 0.457$ measured 0.50 کے اتنا قریب ہے کہ بتا دیتا ہے drop کہاں سے آیا۔ Generalise کریں:

0.90 row کو $k = 10$ پر 0.95 row کے against پڑھیں: per-fact میں پانچ points کی improvement conjunction پر پچیس points بن جاتی ہے۔ model کے ساتھ کچھ discontinuous نہیں ہوا۔ smooth curve جب all-or-nothing metric کے ذریعے پڑھی جائے تو jump لگتی ہے — یہی عین وہ argument ہے جو Schaeffer، Miranda اور Koyejo نے emergent abilities کے بارے میں کیا، اور جسے باب 10 نے یہاں تک deferred رکھا تھا۔² ان کے audit نے پایا کہ BIG-Bench کی 39 preferred metrics میں زیادہ سے زیادہ 5 ہی emergence دکھاتی ہیں، جبکہ دو discontinuous metrics claimed cases کے 92 % سے زیادہ کی ذمہ دار ہیں۔

لہٰذا discipline ایک line میں: chart میں jump metric کے بارے میں evidence ہے جب تک otherwise ثابت نہ ہو۔ کسی capability کے ظاہر ہونے پر یقین کرنے سے پہلے، انہی runs کو ایسی metric کے ساتھ plot کریں جو partial credit دیتی ہو اور دیکھیں cliff بچتی ہے یا نہیں۔

اس کا ایک second-order version ہے جس کے بارے میں Kalai اور colleagues argue کرتے ہیں کہ یہ upstream damage کر رہا ہے: right-or-wrong score ہونے والے benchmarks ”I do not know“ کہنے کے بجائے guessing کو reward کرتے ہیں، اس لیے ان کے against optimize کیا گیا model guess کرنا سیکھتا ہے۔ ان کا proposed fix ایک اور hallucination benchmark نہیں بلکہ ”ان existing benchmarks کی scoring modify کرنا ہے جو misaligned ہیں مگر leaderboards dominate کرتے ہیں“۔³ آپ کے golden set کے پاس بھی یہی lever ہے، اور یہ ایک line ہے: decide کریں کہ abstention failure گنی جائے یا اپنی category۔ زیادہ تر لوگ کبھی decide نہیں کرتے، اس لیے یہ silent طور پر failure count ہوتی ہے، اور وہ system جو وہ ship کرتے ہیں guess کرتا ہے۔

اب تک ہر چیز نے فی task ایک attempt score کیا۔ agent ایک attempt نہیں ہوتا۔ باب 17 نے establish کیا کہ temperature zero پر بھی determinism نہیں ہوتا، اس لیے same input trajectories کی distribution produce کرتی ہے اور benchmark جو ہر task ایک بار run کرتا ہے اس سے ایک sample report کرتا ہے۔

τ-bench کی contribution اس کے لیے metric ہے۔ paper اسے صاف define کرتا ہے: ”ہم ایک نئی metric propose کرتے ہیں — pass^k (pass hat k)، جس کی تعریف یہ ہے کہ k i.i.d. task trials سب کے سب successful ہوں، tasks پر averaged۔“⁴ ہر task کو $n$ بار چلائیں، $c$ successes count کریں، اور unbiased estimators یہ ہیں:

دوسری وہ familiar pass@k ہے code generation سے: chance کہ $k$ attempts میں کم از کم ایک successful ہو۔ انہیں same measured counts پر side by side رکھیں تو وہ opposite directions میں move کرتی ہیں:

Same runs، same grader، same بیس tasks۔ ایک column کہتا ہے کہ system زیادہ attempts کے ساتھ improve ہوتا ہے اور دوسرا کہتا ہے کہ یہ worse ہوتا ہے، اور دونوں correct ہیں، کیونکہ وہ مختلف questions کا answer دیتے ہیں۔ pass@k درست metric ہے جب human output filter کرتا ہے — code generation، drafts، brainstorming — اور extra attempts cheap ہیں۔ pass^k درست metric ہے جب agent بغیر filter کے act کرتا ہے، جو ”agent“ کا مطلب ہے۔ جہاں second apply ہوتی ہو وہاں first publish کرنا اس field کی سب سے عام overstatement ہے، اور τ-bench کی اپنی headline honest version ہے: retail پر gpt-4o تقریباً 61 % pass^1 سے pass^8 پر تقریباً 25 % تک گر جاتا ہے۔⁴

اب میرے اپنے numbers کا sting۔ میرے بیس tasks پر pass^10 5.0 % ہے: بیس میں سے عین ایک task جو تمام دس runs پر حل ہوا۔ وہ task t19 ہے، ”کیا deploy 42 succeed ہوا؟“، اور یہاں دس میں سے دو answers ہیں جنہیں rubric نے correct score کیا:

run 2  "To check if 'deploy.log' succeeded in deploying 42, I will list the file
        names in the working directory using the list_files function..."
run 8  "Yes, deploy 42 has successfully deployed. Deploying was successful for 41
        as well."

پہلا answer کبھی دیتا ہی نہیں۔ دوسرا ایک false claim add کرتا ہے — deploy 41 rolled back تھا۔ دونوں /succe|yes/ سے match ہوئے۔ وہ واحد task جو pass^10 کو zero سے اوپر رکھ رہا ہے grader artefact ہے، اس لیے true figure zero ہے، اور کوئی aggregate مجھے یہ نہ دکھاتا۔ اپنے best-scoring task کے پیچھے transcripts sample کرنا وہ جگہ ہے جہاں graders مرنے جاتے ہیں۔

اور ایک اور number، جس کے نام پر یہ section ہے۔ دس identical evaluations — same system، same بیس tasks، same code، seeds کے سوا کچھ نہیں بدلا:

per-run correct: 5 2 5 5 8 5 8 5 4 5   ->  10 % .. 40 %,  mean 26.0 %,  sd 8.8 points

ایسے system پر تیس point range جو بدلا ہی نہیں۔ اگر آپ release سے پہلے suite ایک بار run کریں اور بعد میں ایک بار، تو آٹھ point ”improvement“ اسی spread کے اندر ہے اور آپ اسے ship کر دیں گے یہ سمجھتے ہوئے کہ آپ نے اسے cause کیا۔ اسی لیے اوپر والا pooled interval — 26.0 % [20.4, 32.5] — اکیلا quote کرنے کے لیے too narrow ہے: یہ دو سو correlated trials کو دو سو independent trials treat کرتا ہے۔ agent evaluation کا honest summary mean اور repeats کے across spread ہے، اور تقریباً کوئی second publish نہیں کرتا۔

Rubrics open-ended answers پر scale نہیں ہوتیں، اس لیے standard move یہ ہے کہ model output کو grade کرے۔ frontier scale پر یہ default ہونے کے لیے کافی کام کرتا ہے، اور اس کے تین named failure modes ہیں: position bias، verbosity bias اور self-enhancement bias۔⁵

اس پر trust کرنے سے پہلے اسے measure کریں۔ وہی ساٹھ answers — دس runs میں سے تین — تین طریقوں سے labelled ہوئے۔ human label میرا ہے: میں نے پانچ files کھلی رکھ کر تمام ساٹھ پڑھے اور ایک written rule apply کیا، pass if and only if answer اس fact کو state کرتا ہے جو question نے پوچھا تھا اور files سے contradicted کچھ contain نہیں کرتا۔

judge نے ساٹھ میں سے ساٹھ بار PASS کہا۔ یہ اس agent کو ایسے set پر 100 % accuracy report کرتا جہاں human اسے 18 % score کرتا ہے۔ جس judge میں discriminative power نہ ہو وہ noisy instrument نہیں؛ وہ constant function ہے، اور constant function آپ کے best system اور worst system کو same score دیتا ہے۔

Prompting نے اسے rescue نہیں کیا۔ چار variants، same ساٹھ items:

instruction میں دو labels کا order swap کرنے سے چار verdicts move ہوئے۔ یہ measurable effect ہے اور غلط قسم کا effect ہے: judge اپنے سامنے موجود answer کے بجائے prompt کی shape پر respond کر رہا ہے۔

صاف demonstration pairwise ہے۔ بیس questions، ہر ایک کے ساتھ ایک صاف correct اور ایک صاف wrong candidate، دونوں orders میں پیش کیے گئے:

picked the FIRST option              40/40 = 100.0 %
order-consistent (same winner both ways)   0/20 = 0.0 %   [Wilson 0.0, 16.1]
picked the CORRECT answer            20/40 = 50.0 %

اس نے position A چالیس میں سے چالیس بار pick کی۔ correctness پر 50 % partial competence نہیں — یہ arithmetic ہے، کیونکہ correct answer trials کے عین نصف میں position A پر بیٹھا ہے۔ یہاں consistency کو MT-Bench کی تعریف کے مطابق define کیا گیا ہے، ”cases کا percentage جہاں judge دو assistants کا order swap کرنے پر consistent results دیتا ہے“، جس سے comparison apples to apples ہو جاتا ہے: GPT-4 اس measure پر 65.0 % score کرتا ہے، اور few-shot prompting نے اسے 77.5 % تک اٹھایا۔⁵ میرا zero score کرتا ہے۔

standard mitigation بھی اسی paper سے ہے: ”دو answers کا order swap کر کے judge کو دو بار call کریں اور win صرف تب declare کریں جب answer دونوں orders میں preferred ہو۔“⁵ اسے یہاں apply کریں تو judge بیس pairs سے zero usable verdicts produce کرتا ہے — جو correct outcome ہے، اور بیس confident verdicts سے infinitely better ہے۔

ایک methodological note جو result سے زیادہ قیمتی ہے۔ میں نے verbosity test بھی چلایا: وہی correct answer، ایک copy میں 36-word sentence add کیا جو کچھ add نہیں کرتا۔ judge نے exactly 50 % trials میں longer version prefer کیا — جو verbosity bias کی absence جیسا لگتا ہے اور ایسا ہرگز نہیں، کیونکہ جو judge ہمیشہ position A pick کرتا ہے وہ کسی بھی balanced pairing پر 50 % score کرتا ہے۔ آپ second bias کو measure نہیں کر سکتے جب تک first controlled نہ ہو۔ positions swap کرنا later add کی جانے والی refinement نہیں؛ یہی ہر دوسری measurement کو interpretable بناتا ہے۔

honest caveat: یہ judge half-billion-parameter model ہے، اور کسی کو بھی ایسے model سے grade نہیں کرنا چاہیے۔ point یہ نہیں کہ judges bad ہیں۔ point یہ ہے کہ اوپر کے numbers produce کرنے میں آٹھ minutes لگے، اور ان کے بغیر shipping decision پر اس judge کا verdict 100 % ہوتا۔

یہ course کا تیسرا اور آخری declared Python panel ہے، اور وجہ یہ ہے کہ public numbers کہاں سے آتے ہیں۔ lm-evaluation-harness ”LLMs کے لیے 60 سے زیادہ standard academic benchmarks، hundreds of subtasks and variants implemented“ cover کرتا ہے اور ”Hugging Face کے popular Open LLM Leaderboard کا backend“ ہے؛ HELM، SWE-bench اور τ-bench Python packages ہیں جن کے Python entry points ہیں۔ published figure کے against اپنا model چلانے کا مطلب ان کا code چلانا ہے، اور جس دن آپ کسی cited number کے ساتھ compare کرنا چاہیں گے، آپ اسی ecosystem میں ہوں گے:

lm_eval --model hf \
    --model_args pretrained=EleutherAI/gpt-j-6B \
    --tasks hellaswag \
    --device cuda:0 \
    --batch_size 8

دوسری وجہ یہ ہے کہ اس chapter کی ایک measurement HTTP پر impossible ہے۔ Contamination — test set کا training data میں leak ہو جانا — وہ failure ہے جو public benchmark کو خاموشی سے meaningless بنا دیتا ہے، اور اس کے لیے sharpest probe کو model کا اپنا loss چاہیے، جو کوئی chat API return نہیں کرتی۔ یہ باب 8 کا cross-entropy per token ہے، memory کے بارے میں question پر pointed:

def nll(text: str) -> float:
    """Mean negative log-likelihood per token, in nats."""
    ids = tok(text, return_tensors="pt").input_ids.to(model.device)
    with torch.no_grad():
        out = model(ids, labels=ids)
    return float(out.loss)

دس sentence pairs: پانچ جو web کے ہر crawl میں اس کے وجود سے ہیں، پانچ آج صبح اس chapter کے لیے لکھے گئے، ہر ایک paired with reworded version carrying same content۔

model آج صبح لکھے گئے sentence پر اس sentence سے چار گنا زیادہ surprised ہے جسے اس نے million times دیکھا ہے، اور famous ones پر rewording twice as much cost کرتی ہے — extra cost وہ حصہ ہے جو understood کے بجائے memorised تھا۔ Absolute loss memorisation کو ordinary naturalness کے ساتھ confound کرتا ہے، اس لیے gap بہتر statistic ہے اور continuation test اس سے بھی بہتر۔ اسے first six words دیں:

famous  "Permission is hereby granted, free of"
     -> "charge, to any person obtaining a copy of this software and associated
         documentation files (the "
famous  "All human beings are born free"
     -> "and equal in dignity and rights. The right to life, liberty, and security"
fresh   "All evaluation harnesses are born tiny"
     -> ", and the most common way to measure their size is by using a ruler."

پانچ famous strings میں سے تین six words سے word-perfect continue ہوئیں؛ پانچ fresh میں سے کوئی نہیں۔ یہ half-billion-parameter model MIT License recite کر رہا ہے۔ اگر آپ کا benchmark public web پر ہے، assume کریں کہ وہ weights میں ہے۔ یہی پورے chapter کے لیے argument بھی ہے: آپ کے اپنے data سے لکھا گیا golden set، کسی بھی crawler-readable repository سے باہر رکھا ہوا، واحد test set ہے جس کے بارے میں آپ sure ہو سکتے ہیں کہ اس پر کبھی training نہیں ہوئی۔

وہ اب بھی پڑھنے کے قابل ہیں، بشرطیکہ آپ ہر ایک سے attached single number کے بجائے یہ پڑھیں کہ ہر ایک measure کیا کرتا ہے۔

کسی ایک row کے بجائے table لیں۔ agentic benchmarks سب humans کو models سے بہت اوپر رکھتے ہیں، جو knowledge benchmarks کا opposite ہے اور field کہاں ہے اس کا best one-line summary؛ ان کے figures months کے اندر old ہو جاتے ہیں، اس لیے انہیں اس date کے ساتھ cite کریں جس دن آپ نے پڑھا؛ اور ہر ایک ایسا task measure کرتا ہے جو آپ کا نہیں۔

Accuracy وہ metric ہے جس پر آپ argue کرتے ہیں۔ یہ وہ metrics ہیں جو decide کرتی ہیں کہ چیز ship ہوتی ہے یا نہیں۔ چاروں پہلے ہی measured دو سو runs سے نکلتی ہیں۔

Cost per solved task، نہ کہ per call۔ agent فی attempt $0.001345 cost کرتا ہے اور فی actually solved task $0.005172 — 3.85 گنا زیادہ، کیونکہ attempts کے تین چوتھائی کچھ produce نہیں کرتے۔ Latency بھی اسی طرح behave کرتی ہے: 1,213 ms per attempt، 4,667 ms per solved task۔ ہر retry، ہر re-ask، ہر abandoned trajectory second number پر ہے اور first میں invisible۔

ایک diagnostic جو accuracy کو beat کرتا ہے۔ 200 میں سے 123 attempts میں agent نے ایک بھی tool call کیے بغیر answer کیا — اس نے دیکھا نہیں، guess کیا۔ اس split پر:

answered without reading anything   8/123  =  6.5 %  [3.3, 12.3]
answered after reading something   44/77   = 57.1 %  [46.0, 67.6]

intervals touch کے قریب بھی نہیں آتے۔ یہ aggregate 26 % سے زیادہ valuable ہے، کیونکہ یہ fix کرنے والی چیز کا نام لیتا ہے — model reasoning میں fail نہیں ہو رہا، یہ look کرنے میں fail ہو رہا ہے — اور fix harness میں ہے، model میں نہیں۔ ایک caveat جو یہ chapter اپنے standards کا مقروض ہے: دو groups different tasks ہیں، same paired tasks نہیں، اس لیے gap کا حصہ یہ بھی ہو سکتا ہے کہ یہ tools کو عین ان questions پر skip کرتا ہے جو اسے hard لگتے ہیں۔ split diagnostic ہے، causal claim نہیں۔

Human intervention rate وہ metric ہے جو buyer پہلے پوچھتا ہے: runs کا کتنا fraction approval، guardrail یا handoff پر رکا۔ باب 23 کی typed interruptions اسے countable بناتی ہیں، اور per task type اور per week count کیا جائے تو یہی فرق بتاتی ہے کہ agent اپنا job سیکھ رہا ہے یا خاموشی سے queue بنتا جا رہا ہے۔

Abandonment وہ ہے جو کوئی offline suite نہیں دیکھ سکتی: وہ user جس نے answer پڑھا، tab بند کی اور task خود کر لیا۔ Offline evaluation gate ہے؛ production evaluation real traffic کا continuous sample ہے، same grader plus ان چار کے ساتھ scored۔

اور باب 17 سے inherited rule: exact output پر کبھی assert نہ کریں۔ properties پر assert کریں — valid JSON، correct schema، right tool called، tolerance کے اندر number، required substring present۔ اس chapter کے top پر exact-match column وہی ہے جو rule ٹوٹنے پر ہوتا ہے۔

supplier evaluate کرنا صرف accuracy کے بارے میں نہیں، اور یہ اس course کی ethics کا دوسرا half ہے، appendix کے بجائے اپنے heading کے ساتھ۔

bias کو measure کریں، assume نہ کریں۔ names، dialects، genders یا nationalities پر model کے behaviour کے بارے میں آپ جو بھی believe کرتے ہیں، وہ آپ کی pipeline کی measurable property ہے، اور instrument وہی ہے جو آپ کے پاس پہلے ہی ہے: اپنا golden set لیں، صرف attribute vary کریں، paired compare کریں۔ HELM اسی لیے exists کرتا ہے کہ accuracy اکیلی report کی جا رہی تھی جہاں bias، toxicity، calibration اور robustness بھی decidable تھے۔⁷ vendor کا model card starting point ہے، آپ کی inputs کے بارے میں evidence نہیں۔

Contamination بھی supplier question ہے۔ اوپر والا probe اسی لیے ہے کہ پوچھا جائے published number کس پر measure ہوا، اور model کا data کب cut ہوا۔

Retention، training اور residency، 7 September 2026 کو read کریں۔ یہ بدلتے ہیں، اس لیے answer کے ساتھ date record کریں۔ Anthropic کی policy page کہتی ہے: ”By default, we will not use your inputs or outputs from our commercial products (e.g. Claude for Work, Anthropic API, Claude Gov, etc.) to train our models“، except وہ content جسے آپ explicitly feedback کے طور پر submit کریں، جو ”up to 5 years“ stored رہتا ہے۔¹⁵ OpenAI کی data controls documentation کہتی ہے کہ ”data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)“، abuse-monitoring logs کے لیے thirty-day default retention describe کرتی ہے، اور Zero Data Retention offer کرتی ہے، جو ”customer content کو abuse monitoring logs سے exclude“ کرتی ہے، plus regions کی list کے across configurable data residency۔¹⁶

first production call سے پہلے writing میں لینے کے لیے چار questions، کیونکہ ہر ایک کا owner different ہے: کیا میرا data training کے لیے use ہوتا ہے؛ یہ کتنی دیر retained رہتا ہے اور کس کے by؛ کہاں process اور store ہوتا ہے؛ اور اگر میں provider directly کے بجائے reseller، gateway یا aggregator use کروں تو ان سب کے ساتھ کیا ہوتا ہے۔ آخری one میں اکثر surprises رہتی ہیں، اور کوئی benchmark آپ کو نہیں بتائے گا۔

اب آپ کے پاس instrument ہے: آپ کا own golden set، ہر number پر interval، ہر comparison کے لیے paired test، ان runs کے لیے pass^k جو آپ نے کسی کو نہیں دکھائیں، measured judge، اور یہ probe کہ public score کوئی معنی رکھتا ہے یا نہیں۔ باب 23 کا closing claim اب assert کے بجائے check کیا جا سکتا ہے — harness agent کو governable بناتا ہے، correct نہیں — اور اسے check کرنے میں دو سو runs اور آٹھ minutes لگے۔

agent کی ایک property ایسی ہے جسے ان میں سے کچھ بھی measure نہیں کرتا، اور یہی وہ ہے جس سے لوگ fired ہوتے ہیں۔

اس chapter کے golden set میں ہر task میں نے لکھا، اور ہر file جو agent نے پڑھی میں نے لکھی۔ اس directory میں کچھ بھی کچھ کرنے کی کوشش نہیں کر رہا تھا۔ ایک file میں، جسے agent کو پڑھنے کو کہا گیا ہے، ایک line بدل دیں — ایسی line جو اس instruction پر ختم ہوتی ہو جو اگلا پڑھنے والے کو address کرتی ہے — اور وہ agent جس نے 26 % score کیا same tools، same permissions اور same clean trace کے ساتھ اسے follow کرے گا، اور اس chapter کا ہر number exactly وہیں رہے گا۔ evaluation suite measure کرتی ہے کہ system آپ کے goal تک کتنی بار پہنچتا ہے۔ یہ measure نہیں کرتی کہ کوئی اور اپنا goal کتنی آسانی سے substitute کر سکتا ہے۔

باب 30 یہی ہے: prompt injection، private data، untrusted content اور external communication کی lethal trifecta، اور agent کو real permissions دینے کی cost۔ یہ اس observation سے کھلتا ہے جس سے یہ chapter بچتا رہا ہے — کہ same passing score ایسے agent کے ساتھ compatible ہے جو بالکل وہی کرتا ہے جو attacker نے اس file میں لکھا تھا جسے اسے پڑھنے کو کہا گیا۔

اوپر کا ہر number ایک machine پر produce ہوا اور اس میں کوئی paid endpoint touch نہیں ہوا۔ agent باب 23 کا loop ہے جس کے چار میں سے دو tools پانچ-file directory پر ہیں؛ port کے پیچھے model Qwen/Qwen2.5-0.5B-Instruct ہے، چھوٹے server کے ذریعے exposed جس کی shape chat completions endpoint جیسی ہے exactly باب 23 کی طرح، مگر اس chapter کے CPU کے بجائے ایک consumer GPU پر half precision میں۔ Costs باب 16 کی rates use کرتی ہیں — $2.00 per million input tokens اور $12.00 per million output — measured token counts پر applied۔ repeated runs temperature 0.7 fixed seeds کے ساتھ use کرتی ہیں تاکہ whole set reproduce ہو؛ four-arm table greedy ہے۔ Intervals 95 % پر Wilson ہیں، paired comparisons discordant pairs پر two-sided exact sign tests ہیں؛ Wilson interval باب 4 کا ہے اور exact paired sign test باب 15 کا، دونوں unchanged reused۔ human labels میرے ہیں، text میں quoted written rule کے تحت ساٹھ answers پر applied۔ یہاں ہر magnitude کو half-billion-parameter model کی property سمجھیں اور ہر method کو transferable: bigger model تمام numbers اوپر move کرتا ہے اور instruments میں سے کسی کو نہیں۔