LLM मूल्यांकन: public benchmarks से अपने golden set तक

evaluation पर लगभग हर बहस में दो लोग अलग-अलग चीज़ें माप रहे होते हैं। तीन projects हैं और उनका कोई instrument साझा नहीं है।

भ्रम एक दिशा में महँगा पड़ता है। leaderboard आपको बताता है कि कोई model graduate-level reasoning में मज़बूत है; वह यह नहीं बता सकता कि वह आपके 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 में घटाती है, इसी क्रम में: “Set up evals to establish a performance baseline”, “Focus on meeting your accuracy target with the best models available”, “Optimize for cost and latency by replacing larger models with smaller ones where possible”.¹ Evaluation पहले आता है, क्योंकि steps दो और तीन किसी संख्या के बिना अर्थहीन हैं।

golden set inputs की एक list है, हर input के साथ लिखा हुआ answer, और एक grader जो तय करता है कि output match करता है या नहीं। यह उबाऊ है, छोटा है, और इस अध्याय में यही एक artefact है जो आपका है। यहाँ बनाया गया set पाँच files वाली directory पर बीस tasks रखता है — अध्याय 23 के तीन नहीं, इसलिए answers वही answers नहीं हैं — और grader agent चलने से पहले लिखा गया है:

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 भार उठाती हैं। mustNot list इसलिए मौजूद है क्योंकि कोई model जो सही file सहित तीन files के नाम बताता है, उसने answer नहीं दिया। और answer prose में भी लिखा गया है और patterns में भी, क्योंकि बाद में human और judge दोनों को इसकी ज़रूरत होगी — और एक ही fact को दो notations में दो बार लिखना यह पता लगाने का तरीका है कि task क्या था, इस पर आप खुद से सहमत नहीं थे।

अब वह 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 पूछकर इसे और तेज किया — जिन cases में दो arms असहमत हैं, split कितना एकतरफा है? — क्योंकि 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 नहीं है। best arm no-tools वाले arm को पंद्रह points से हराता है, और यह तीन discordant cases पर टिका है। बीस cases एक mechanism दिखाते हैं और supplier नहीं चुन सकते; meeting में इसके उलट कहना ही खराब model खरीदवाता है।

एक चीज़ यह table establish करती है, और वह column है जिसे कोई नहीं डालता। Arm D solved task per arm B से तेरह गुना महँगा है, क्योंकि तीन trajectories sample करना और modal answer लेना bill को तीन गुना कर देता है, चाहे accuracy तीन गुना हो या न हो। Cost छोड़ देने वाली accuracy tables इस trade को अदृश्य बना देती हैं।

अब वह finding जो आपके हर देखे जाने वाले benchmark को पढ़ने का तरीका बदल देती है। उसी दो सौ transcripts को लें — बीस tasks, दस runs, एक भी token फिर से generated नहीं — और उन्हें तीन तरीकों से score करें:

शून्य, तेरह, छब्बीस। system नहीं बदला। grader बदला। Exact match शून्य इसलिए लौटाता है कि agent बेकार है नहीं, बल्कि इसलिए कि कोई free-text answer reference से byte-identical कभी नहीं होता: वह formatting मापता है और उसे capability के रूप में report करता है।

यह curiosity नहीं, mechanism है, और इसका नाम है। hard-cutoff metric कई sub-facts पर task को 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 लगभग तीन चौथाई समय सही है; तीनों को एक साथ माँगना score आधा कर देता है, और $0.77^3 = 0.457$ measured 0.50 के इतना करीब है कि गिरावट कहाँ से आई, दिख जाता है। Generalise करें:

$k = 10$ पर 0.90 row को 0.95 row के सामने पढ़िए: per-fact पाँच points का improvement conjunction पर पच्चीस points बन जाता है। model के साथ कुछ discontinuous नहीं हुआ। all-or-nothing metric के जरिए पढ़ी गई smooth curve jump जैसी दिखती है — यही ठीक वह argument है जो Schaeffer, Miranda और Koyejo ने emergent abilities पर किया, और जिसे अध्याय 10 ने यहाँ तक स्थगित किया था।² उनके audit ने पाया कि BIG-Bench के 39 preferred metrics में से अधिकतम 5 ही emergence दिखाते हैं, और दो discontinuous metrics claimed cases के 92 % से अधिक के लिए जिम्मेदार हैं।

तो discipline, एक line में: chart में jump metric के बारे में evidence है, जब तक उल्टा साबित न हो। किसी capability के प्रकट होने पर विश्वास करने से पहले, उन्हीं runs को partial credit देने वाले metric से plot करें और देखें कि cliff बचती है या नहीं।

इसका second-order version Kalai और colleagues के अनुसार upstream नुकसान कर रहा है: right-or-wrong score किए गए benchmarks “I do not know” कहने के बजाय guessing को reward करते हैं, इसलिए उनके खिलाफ optimised model guess करना सीखता है। उनका proposed fix कोई और hallucination benchmark नहीं बल्कि “modifying the scoring of existing benchmarks that are misaligned but dominate leaderboards” है।³ आपके golden set में वही lever है, और वह एक line है: तय करें कि abstention failure गिना जाएगा या अपनी category। ज़्यादातर लोग कभी तय नहीं करते, इसलिए वह चुपचाप failure गिना जाता है, और वे जो system ship करते हैं वह guess करता है।

अब तक सबने प्रति task एक attempt score किया। agent एक attempt नहीं है। अध्याय 17 ने establish किया कि temperature zero पर भी determinism नहीं है, इसलिए वही input trajectories का distribution पैदा करता है और हर task को एक बार चलाने वाला benchmark उससे एक sample report करता है।

τ-bench का contribution इसके लिए metric है। paper इसे साफ़ define करता है: “we propose a new metric – pass^k (pass hat k), defined as the chance that all k i.i.d. task trials are successful, averaged across tasks.”⁴ हर task को $n$ बार चलाएँ, $c$ successes गिनें, और unbiased estimators हैं:

दूसरा code generation वाला जाना-पहचाना pass@k है: $k$ attempts में से कम से कम एक के succeed होने की chance। उन्हें same measured counts पर साथ-साथ रखें और वे opposite directions में चलते हैं:

वही runs, वही grader, वही बीस tasks। एक column कहता है कि system ज्यादा attempts के साथ improve करता है और दूसरा कहता है कि वह worse होता है, और दोनों सही हैं, क्योंकि वे अलग questions का answer देते हैं। pass@k सही metric है जब human output filter करता है — code generation, drafts, brainstorming — और extra attempts सस्ते हैं। pass^k सही metric है जब agent बिना filter के act करता है, और “agent” का मतलब यही है। जहाँ दूसरा लागू होता है वहाँ पहला publish करना इस field की सबसे common overstatement है, और τ-bench का अपना headline ईमानदार version है: retail पर roughly 61 % pass^1 वाला gpt-4o pass^8 पर लगभग 25 % तक गिरता है।⁴

अब मेरे अपने numbers की चुभन। मेरे बीस tasks पर pass^10 5.0 % है: ठीक एक task in twenty जो सभी दस runs में solve हुआ। वह task t19 है, “Did 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 नहीं देता। दूसरा एक claim जोड़ता है जो false है — deploy 41 rollback हुआ था। दोनों /succe|yes/ से match हुए। pass^10 को zero से ऊपर रखने वाला अकेला task grader artefact है, इसलिए true figure zero है, और कोई aggregate मुझे यह नहीं दिखाता। आपकी best-scoring task के पीछे transcripts sample करना वह जगह है जहाँ graders मरने जाते हैं।

और एक और number, जिसके नाम पर यह section है। दस identical evaluations — वही system, वही बीस tasks, वही 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 पर thirty-point range जो बदला ही नहीं। अगर आप release से पहले suite एक बार चलाते हैं और बाद में एक बार, तो आठ-point “improvement” उस spread के अंदर है और आप उसे यह मानकर ship करेंगे कि आपने उसे caused किया। इसलिए ऊपर वाला pooled interval — 26.0 % [20.4, 32.5] — अपने आप quote करने के लिए बहुत narrow है: वह दो सौ correlated trials को दो सौ independent trials मानता है। agent evaluation का honest summary mean और repeats के across spread है, और दूसरा लगभग कोई publish नहीं करता।

Rubrics open-ended answers पर scale नहीं करते, इसलिए standard move है output को grade करने के लिए model लगाना। frontier scale पर यह default बनने लायक काम करता है, और इसकी तीन named failure modes हैं: position bias, verbosity bias और self-enhancement bias।⁵

इस पर भरोसा करने से पहले इसे मापिए। वही साठ answers — दस runs में से तीन — तीन तरीकों से labelled हुए। human label मेरा है: मैंने पाँच files खोलकर सभी साठ पढ़े और एक written rule apply किया, pass if and only if the answer states the fact the question asked for and contains nothing contradicted by the files.

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, वही साठ items:

instruction में दो labels का order swap करने से चार verdicts बदल गए। यह measurable effect है और गलत तरह का effect है: judge सामने रखे answer के बजाय prompt की shape पर respond कर रहा है।

clean demonstration pairwise है। बीस questions, प्रत्येक में एक साफ़ correct और एक साफ़ wrong candidate, दोनों orders में presented:

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 चुना। correctness पर 50 % partial competence नहीं है — यह arithmetic है, क्योंकि correct answer exactly आधे trials में position A पर है। यहाँ consistency MT-Bench की definition से defined है, “the percentage of cases where a judge gives consistent results when swapping the order of two assistants”, जिससे comparison apples to apples रहता है: GPT-4 इस measure पर 65.0 % score करता है, और few-shot prompting ने इसे 77.5 % तक उठाया।⁵ मेरा zero score करता है।

standard mitigation भी उसी paper से है: “call a judge twice by swapping the order of two answers and only declare a win when an answer is preferred in both orders.”⁵ इसे यहाँ apply करें और judge twenty pairs से zero usable verdicts देता है — यही correct outcome है, और twenty confident verdicts से infinitely बेहतर।

result से अधिक कीमत वाली methodological note। मैंने verbosity test भी चलाया: वही correct answer, एक copy 36-word sentence से padded जो कुछ नहीं जोड़ता। judge ने longer version को exactly 50 % trials में preferred किया — जो verbosity bias की absence जैसा दिखता है और वैसा बिल्कुल नहीं है, क्योंकि जो judge हमेशा position A चुनता है, वह किसी भी balanced pairing पर 50 % score करता है। पहला bias control किए बिना आप दूसरा bias measure नहीं कर सकते। Positions swap करना बाद में जोड़ने वाली refinement नहीं; यही हर दूसरे measurement को interpretable बनाता है।

honest caveat: यह judge half-billion-parameter model है, और किसी को भी ऐसे model से grade नहीं करना चाहिए। point यह नहीं है कि judges खराब हैं। point यह है कि ऊपर के numbers produce करने में आठ minutes लगे, और इनके बिना shipping decision पर इस judge का verdict 100 % होता।

यह course का तीसरा और आख़िरी declared Python panel है, और वजह है कि public numbers कहाँ से आते हैं। lm-evaluation-harness “over 60 standard academic benchmarks for LLMs, with hundreds of subtasks and variants implemented” cover करता है और “the backend for Hugging Face's popular Open LLM Leaderboard” है; HELM, SWE-bench और τ-bench Python entry points वाले Python packages हैं। अपने model को published figure के against चलाने का मतलब उनका code चलाना है, और जिस दिन आप किसी cited number से compare करना चाहेंगे, आप इसी ecosystem में होंगे:

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

दूसरी वजह यह है कि इस अध्याय का एक measurement HTTP पर impossible है। Contamination — test set का training data में leak हो जाना — वह failure है जो public benchmark को चुपचाप meaningless बना देती है, और उसके लिए सबसे sharp 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 में रहे हैं जबसे web है, पाँच आज सुबह इस अध्याय के लिए लिखे गए, प्रत्येक same content ले जाने वाले reworded version के साथ paired।

model आज सुबह लिखी sentence से चार गुना ज्यादा surprised है बनिस्बत उस sentence के जिसे उसने लाखों बार देखा है, और famous ones पर rewording की cost दो गुना है — extra cost वह हिस्सा है जो understood के बजाय memorised था। Absolute loss memorisation को ordinary naturalness के साथ confound करती है, इसलिए gap बेहतर statistic है और continuation test उससे भी बेहतर। उसे पहले छह 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 सुना रहा है। अगर आपका benchmark public web पर है, मान लीजिए वह weights में है। यही पूरे अध्याय के लिए argument भी है: आपके अपने data से आपके द्वारा लिखा गया golden set, जिसे किसी crawler द्वारा पढ़े जाने वाले repository से बाहर रखा गया हो, वही test set है जिसके बारे में आप sure हो सकते हैं कि उस पर कभी training नहीं हुई।

वे अब भी पढ़ने लायक हैं, बशर्ते आप उनसे जुड़ी single number के बजाय यह पढ़ें कि हर एक क्या measure करता है।

किसी row के बजाय table लें। agentic benchmarks सभी humans को models से बहुत ऊपर रखते हैं, जो knowledge benchmarks के opposite है और field कहाँ है इसका best one-line summary है; उनके figures महीनों में पुराने हो जाते हैं, इसलिए उन्हें पढ़ने की date के साथ cite करें; और हर एक ऐसा task measure करता है जो आपका नहीं है।

Accuracy वह metric है जिस पर आप argue करते हैं। ये वे हैं जो decide करते हैं कि चीज़ ship होगी या नहीं। चारों पहले से measured दो सौ runs से निकलते हैं।

Cost per solved task, per call नहीं। agent प्रति attempt $0.001345 और प्रति वास्तव में solved task $0.005172 cost करता है — 3.85 गुना ज्यादा, क्योंकि attempts के तीन चौथाई कुछ produce नहीं करते। Latency भी ऐसे ही behave करती है: 1,213 ms per attempt, 4,667 ms per solved task। हर retry, हर re-ask, हर abandoned trajectory दूसरी संख्या में है और पहली में invisible।

accuracy से बेहतर diagnostic। 200 attempts में से 123 में 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 छूने के करीब भी नहीं आते। यह aggregate 26 % से ज्यादा मूल्यवान है, क्योंकि यह fix करने वाली चीज़ का नाम देता है — model reason करने में fail नहीं हो रहा, वह देखने में fail हो रहा है — और fix harness में है, model में नहीं। एक caveat जो यह अध्याय अपने standards को owed है: दोनों groups अलग tasks हैं, same paired tasks नहीं, इसलिए उस gap का हिस्सा यह हो सकता है कि वह tools को ठीक उन questions पर skip करता है जिन्हें वह hard पाता है। split diagnostic है, causal claim नहीं।

Human intervention rate वह metric है जो buyer सबसे पहले पूछता है: कितने fraction runs approval, guardrail या handoff पर रुके। अध्याय 23 के typed interruptions इसे countable बनाते हैं, और task type और per week के हिसाब से count करने पर यही एक agent जो अपनी job सीख रहा है और एक जो चुपचाप queue बन रहा है, के बीच फर्क करता है।

Abandonment वह है जिसे कोई offline suite नहीं देख सकता: वह user जिसने answer पढ़ा, tab बंद किया और task खुद कर लिया। Offline evaluation gate है; production evaluation real traffic का continuous sample है, उसी grader plus इन चार से scored।

और अध्याय 17 से inherited rule: exact output पर कभी assert न करें। properties पर assert करें — valid JSON, correct schema, right tool called, tolerance के भीतर number, required substring present। इस अध्याय के ऊपर वाला exact-match column वही है जो इस rule के टूटने पर होता है।

supplier evaluate करना केवल accuracy के बारे में नहीं है, और यह इस course की ethics का दूसरा half है, appendix के बजाय अपने heading के साथ।

bias measure करें, assume न करें। names, dialects, genders या nationalities पर model के behaviour के बारे में आप जो भी मानते हों, वह आपकी pipeline की measurable property है, और instrument वही है जो आपके पास पहले से है: अपना golden set लें, केवल attribute vary करें, paired compare करें। HELM ठीक इसलिए exist करता है क्योंकि जहाँ bias, toxicity, calibration और robustness भी decidable थे वहाँ केवल accuracy report की जा रही थी।⁷ vendor का model card starting point है, आपके inputs के बारे में evidence नहीं।

Contamination supplier question भी है। ऊपर का probe यह पूछने की वजह है कि published number किस पर measured था, और model का data कब cut हुआ।

Retention, training और residency, 7 September 2026 को पढ़ा गया। ये बदलते हैं, इसलिए 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”, उस content के exception के साथ जिसे आप explicit feedback के रूप में submit करते हैं, जो “for 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 करती है, जो “excludes customer content from abuse monitoring logs”, plus regions की list में configurable data residency।¹⁶

पहली production call से पहले लिखित में लेने के लिए चार questions, क्योंकि हर एक का owner अलग है: क्या मेरा data training के लिए use होता है; वह कितने समय retained रहता है और किसके द्वारा; वह कहाँ processed और stored होता है; और अगर मैं provider को सीधे use करने के बजाय reseller, gateway या aggregator use करता हूँ तो इन सबका क्या होता है। सबसे ज्यादा surprises आख़िरी वाले में रहती हैं, और कोई benchmark आपको नहीं बताएगा।

अब आपके पास instrument है: आपका अपना 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 होते हैं।

इस अध्याय के golden set का हर task मैंने लिखा, और agent ने जो हर file पढ़ी वह मैंने लिखी। उस directory में कुछ भी कुछ करने की कोशिश नहीं कर रहा था। जिस file को agent को पढ़ने के लिए कहा गया है उसमें एक line बदल दें — ऐसी line जो अगले reader को addressed instruction पर खत्म होती है — और 26 % score करने वाला agent उसे वही tools, वही permissions और वही clean trace के साथ follow करेगा, और इस अध्याय की हर 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 से खुलता है जिसे यह अध्याय avoid कर रहा था — कि same passing score ऐसे agent के साथ compatible है जो ठीक वही करता है जो attacker ने उस file में लिखा जिसे उसे पढ़ने के लिए कहा गया था।

ऊपर की हर number एक machine पर produce हुई और इनमें से कोई paid endpoint को नहीं छुआ। agent अध्याय 23 का loop है, पाँच-file directory पर उसके चार tools में से दो के साथ; port के पीछे model Qwen/Qwen2.5-0.5B-Instruct है, chapter 23 की तरह chat completions endpoint जैसे shape वाले छोटे server के through exposed, लेकिन उस chapter के CPU के बजाय consumer GPU पर half precision में। Costs अध्याय 16 की rates use करते हैं — प्रति million input tokens $2.00 और प्रति million output $12.00 — measured token counts पर applied। repeated runs fixed seeds के साथ temperature 0.7 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 के under साठ answers पर applied। यहाँ हर magnitude को half-billion-parameter model की property और हर method को transferable पढ़ें: बड़ा model सभी numbers ऊपर ले जाता है और instruments में से कोई नहीं बदलता।