Benchmark design and evaluation rigor — Hinglish notes

6.5.3 · AI-ML › Research Frontiers & Practice

Overview

Benchmark design ek systematic process hai jisme datasets, tasks, aur evaluation protocols create kiye jaate hain jo model capabilities ko reliably measure kar sakein. Evaluation rigor ensure karta hai ki performance claims reproducible hain, statistically valid hain, aur data leakage ya test sets pe overfitting ke artifacts nahi hain.

Core Concepts

Intuition Benchmarks kyun socho se zyada important hain

Ek benchmark sirf ek dataset nahi hai—yeh ek measurement instrument hai. Jaise ek thermometer jo galat calibrate hua ho, ek poorly designed benchmark aapko aise numbers deta hai jo precise lagte hain lekin bilkul galat cheez measure karte hain.

Paradox yeh hai: Jaise-jaise models better hote hain, benchmarks worse hote jaate hain. GPT-2 ko un datasets pe test kiya gaya tha jinhe GPT-4 ne memorize kar liya hai. Har SOTA result benchmark ko future models ke liye aur kam useful bana deta hai.

Isko school mein "teaching to the test" ki tarah socho: agar students bina samjhe answers memorize kar lein, toh test toh ace kar lenge lekin knowledge apply nahi kar paayenge. Models bhi aisa hi karte hain—woh MNIST "solve" kar sakte hain lekin thode rotate kiye digits pe fail ho jaate hain.

Definition Benchmark components

Ek rigorous benchmark mein yeh hota hai:

Task specification: Precisely kya capability measure ki ja rahi hai (e.g., "physical interactions ke baare mein commonsense reasoning" na ki sirf "question answering")
Dataset construction: Examples kaise source, annotate, aur split kiye jaate hain

Train/validation/test splits information leakage rokni chahiye
Annotation protocols labeler bias aur ambiguity minimize karni chahiye
Distribution specification define karta hai kya in-scope hai aur kya out-of-scope

Evaluation metrics: Raw model outputs scores mein kaise convert hote hain

Jo capability measure ki ja rahi hai uske saath align honi chahiye
Trivial exploits ke against robust honi chahiye

Experimental protocol: Computational budget, hyperparameter search, number of runs, statistical tests
Negative controls: Aisi tests jinhe models fail karni chahiye taaki verify ho sake ki benchmark trivially solvable nahi hai

Derivation from first principles: Statistical validity of benchmark claims

Sawaal: Jab ek paper kehta hai "Model A achieves 92.3% on benchmark B", toh woh number actually kya mean karta hai?

Step 1: Random variables ko pehchano

Performance $P$ ek random variable hai jo depend karta hai:

Random seed $s$ pe (initialization, data order, dropout)
Train/test split $D$ pe (agar multiple splits exist karti hain)
Hyperparameters $θ$ pe (aksar validation set ke zariye select kiye jaate hain)

Yeh kyun matter karta hai: Ek single number ek distribution se liya gaya point estimate hai. Uncertainty quantification ke bina, aap signal aur noise mein fark nahi kar sakte.

Step 2: Performance distribution ko model karo

Different seeds ke saath $n$ independent runs ke liye:

$P_{1}, P_{2}, \dots, P_{n} \sim Performance Distribution$

Sample mean: $\overset{ˉ}{P} = \frac{1}{n} \sum_{i = 1}^{n} P_{i}$

Sample standard deviation: $s_{P} = \frac{1}{n - 1} \sum_{i = 1}^{n} (P_{i} - \overset{ˉ}{P})^{2}$

Best run hi kyun report nahi karte? Kyunki woh selection bias hai—aap distribution ki right tail se cherry-picking kar rahe ho. Yeh model ki true capability ko overestimate karta hai.

Step 3: Confidence intervals construct karo

$n \geq 30$ runs ke liye (central limit theorem apply hota hai), 95% confidence interval hai:

$CI_{95} = \overset{ˉ}{P} \pm 1.96 \cdot \frac{s _{P}}{n}$

Chhote $n$ ke liye, $n - 1$ degrees of freedom ke saath Student's t-distribution use karo:

$CI_{95} = \overset{ˉ}{P} \pm t_{0.975, n - 1} \cdot \frac{s _{P}}{n}$

Interpretation: "Agar hum yeh poora experiment kai baar repeat karein, toh 95% computed intervals true mean performance ko contain karenge."

Yeh step kyun? Yeh epistemic uncertainty quantify karta hai—finite samples diye hue, hum model ki true capability ke baare mein kitne sure hain?

Step 4: Model comparison ke liye hypothesis testing

Claim: "Model A, Model B se better perform karta hai"

Null hypothesis $H_{0}$ : $μ_{A} - μ_{B} = 0$ (true means mein koi difference nahi)

Independent samples ke liye test statistic:

$t = \frac{P ˉ _{A} - P ˉ _{B}}{\frac{s _{A}^{2}}{n _{A}} + \frac{s _{B}^{2}}{n _{B}}}$

Yeh form kyun? Numerator effect size measure karta hai. Denominator noise measure karta hai (difference ka standard error). Bada $∣ t ∣$ matlab difference $H_{0}$ ke under unlikely hai.

Degrees of freedom (Welch's approximation):

$ν = \frac{( \frac{s _{A}^{2}}{n _{A}} + \frac{s _{B}^{2}}{n _{B}} ) ^{2}}{\frac{( s _{A}^{2} / n _{A} ) ^{2}}{n _{A} - 1} + \frac{( s _{B}^{2} / n _{B} ) ^{2}}{n _{B} - 1}}$

Welch's approximation kyun? Kyunki hum equal variances assume nahi karte—Model A initialization ke liye Model B se zyada sensitive ho sakta hai.

p-value: $H_{0}$ ke true hone par $∣ t ∣$ itना bada observe karne ki probability.

Agar $p < 0.05$ , toh $H_{0}$ reject karo aur conclude karo ki Model A, Model B se significantly differ karta hai.

Critical nuance: Statistical significance ≠ practical significance. 0.1% improvement statistically significant ho sakta hai enough runs ke saath, lekin applications ke liye meaningless ho sakta hai.

Standard error of the mean: $SEM = \frac{s}{n}$ jahan $s$ sample standard deviation hai, $n$ number of runs hai.

Kyun matter karta hai: Dikhata hai ki aapne mean ko kitni precisely estimate kiya hai. $1/ n$ ke saath scale karta hai—uncertainty aadha karne ke liye aapko 4× zyada runs chahiye.

Effect size (Cohen's d): $d = \frac{P ˉ _{A} - P ˉ _{B}}{\frac{( n _{A} - 1 ) s _{A}^{2} + ( n _{B} - 1 ) s _{B}^{2}}{n _{A} + n _{B} - 2}}$

Interpretation:

$∣ d ∣ < 0.2$ : negligible
$0.2 \leq ∣ d ∣ < 0.5$ : small
$0.5 \leq ∣ d ∣ < 0.8$ : medium
$∣ d ∣ \geq 0.8$ : large

Bonferroni correction for multiple comparisons: Agar $m$ hypotheses test kar rahe ho, toh $α$ ki jagah significance level $α / m$ use karo.

Kyun: 20 models ko pairwise test karne se 190 comparisons milti hain. $α = 0.05$ ke saath, aap expect karte ho $190 \times 0.05 \approx 10$ false positives chance se! Bonferroni family-wise error rate control karta hai.

Worked Examples

Worked example Example 1: Negative controls ke zariye data leakage detect karna

Scenario: Aap ek "novel reasoning" benchmark banate ho. Model 89% accuracy score karta hai.

Step 1: Ek negative control create karo—answer choices randomly shuffle karo.

Random chance 4 choices ke liye 25% dena chahiye
Model ko 27% milta hai Step 2: Dusra control create karo—adversarially likhe distractors use karo jo plausible lagte hain lekin logically impossible hain.
Model ko ~89% maintain karni chahiye agar properly reason kar raha hai
Model 52% pe drop ho jaata hai

Diagnosis: Model reason nahi kar raha; woh surface patterns match kar raha hai. Benchmark spurious correlations measure kar raha hai, intended capability nahi.

Yeh kyun kaam kiya: Negative controls isolate karte hain ki model actually kya use karta hai. Jaise ek "face detector" ko ulte faces pe test karna—agar woh fir bhi kaam karta hai, toh woh actually face structure detect nahi kar raha.

Worked example Example 2: Proper statistical reporting

Paper A: "Hamara model benchmark X pe 92.3% achieve karta hai"

1 run, validation set se best hyperparameters Paper B: "Hamara model benchmark X pe 91.8% ± 0.7% achieve karta hai"
Different seeds ke saath 5 runs, mean ± SEM report karta hai
Test set evaluation se pehle hyperparameters fix

Step 1: Actual confidence intervals calculate karo. Paper B ke saath $n = 5$ , SEM=0.7: $CI_{95} = 91.8 \pm t_{0.975, 4} \cdot 0.7 = 91.8 \pm 2.776 \cdot 0.7 = 91.8 \pm 1.94$ Toh CI = [89.86, 93.74] Step 2: Kya hum conclude kar sakte hain ki Paper A better hai?

Nahi! Paper A ka single result (92.3) Paper B ke confidence interval ke andar hi aata hai. Yeh difference aasaani se noise ho sakta hai.

Step 3: Kya hoga agar Paper A ne bhi 5 baar run karke 92.3 ± 0.5 paya hota?

Toh CI = [91.0, 93.6]. Fir bhi overlapping! Proper t-test chahiye: $t = \frac{92.3 - 91.8}{0. 5 ^{2} + 0. 7 ^{2}} = \frac{0.5}{0.86} = 0.58$

$ν \approx 7$ degrees of freedom ke saath, yeh $p > 0.5$ deta hai—significant nahi.

Yeh steps kyun: Uncertainty ke saath intuition fail ho jaati hai. 0.5% difference meaningful lagta hai, lekin noise signal se badi hai.

Worked example Example 3: Scratch se ek robust benchmark design karna

Goal: "Physical common sense ki understanding" measure karna

Step 1: Task specification

Vague: "Physics questions answer karo"
Precise: "Everyday physical interactions ke qualitative outcomes predict karo (e.g., 'Agar main ek ball release karun, toh woh upar jaayegi ya neeche?') bina calculation require kiye" Qualitatively specify kyun? Taaki task equations memorize karke solve na kiya ja sake.

Step 2: Dataset construction Bad approach: Physics textbooks scrape karo
→ Models textbook problems memorize kar sakte hain Better: Programmatically synthetic scenarios generate karo

Physical rules define karo (gravity, friction, collision)
Procedurally 10,000 scenarios generate karo
Har ek ka ek rendering (image/text) aur ek question ho

Programmatic kyun? Aap exactly prove kar sakte ho kaunsi reasoning chahiye—koi ambiguity nahi.

Step 3: Generation parameters ke basis pe Train/test split

Train: 1-2 objects ke scenarios, smooth surfaces
Test: 3-5 objects, rough surfaces, pehle na dekhe material combinations

Yeh split kyun? Slightly out-of-distribution cases mein generalization test karta hai, memorization nahi.

Step 4: Multiple metrics

Overall accuracy
Objects ki sankhya ke basis pe accuracy (kya yeh scale karta hai?)
Counterfactual questions pe accuracy ("Agar gravity na hoti toh kya hota?") Multiple metrics kyun? Ek single accuracy number failures chupa sakta hai. Shayad model sirf simple scenes ke liye kaam karta ho.

Step 5: Adversarial validation

Humans se model ko edge cases se "trick" karne ki koshish karwao
Unhe test set mein add karo
Tab tak repeat karo jab tak human tricks kaam na karein

Adversarial kyun? Static benchmarks saturate ho jaate hain. Adversarial examples brittleness reveal karte hain.

Common Mistakes & How to Fix Them

Common mistake Mistake 1: Test set pe tuning karna

Kya hota hai: Aap model train karte ho → test pe evaluate karte ho → hyperparameters tweak karte ho → phir evaluate karte ho → best result report karte ho.

Kyun sahi lagta hai: Aap toh sirf "best model find" kar rahe ho, hai na?

Problem: Test set ab effectively aapke training data ka hissa ban gaya hai. Aapne test distribution ke saath adapt kar liya hai, na ki true task distribution ke saath.

Steel-man: Practice mein, aapko iterate karna hi padta hai. Aap kabhi test performance dekhe bina kaise kaam kar sakte ho?

Fix:

Data ko train/validation/test mein split karo
SAARA hyperparameter tuning validation set pe karo
Model finalize hone ke baad, test set pe SIRF EK BAAR evaluate karo
Agar iterate karna hi hai, har baar ek naya held-out test set create karo

Mental model: Test set ek sealed box hai. Bilkul end mein aapko ek baar andar dekhne ka mauka milta hai.

Common mistake Mistake 2: Sirf best run report karna

Kya hota hai: Model 10 baar run karo, best seed se accuracy report karo.

Kyun sahi lagta hai: Aap model ki "true potential" dikhaa rahe ho!

Problem: Yeh selection bias hai. Aap $E [P]$ ki jagah $max (P_{1}, \dots, P_{n})$ se sample kar rahe ho.

Expected maximum hamesha expected value se zyada hota hai. Mean 90% aur std 2% wale model ke $n = 10$ runs ke liye, expected max ~93% hai—3 percentage points inflated!

Steel-man: Lekin production mein, kya hum best checkpoint use nahi karenge?

Fix:

SAARE runs mein mean aur standard deviation report karo
Agar best report karna hi hai: "Best of 10 runs: 93.2%. Mean: 90.1% ± 2.0%"
Better: Validation set se best checkpoint pick karo, phir us checkpoint ki test performance multiple train runs mein report karo

Common mistake Mistake 3: Task contamination ignore karna

Kya hota hai: Web crawl pe language model train karo → "CommonsenseQA" pe evaluate karo → yeh check na karo ki questions training data mein aaye the ya nahi

Kyun sahi lagta hai: Web toh bahut bada hai; kya odds hain?

Problem: Zyada hain. GPT-3 ki training data contamination analysis ne common benchmarks ke saath 1-6% overlap paya. Models reasoning seekhne ki bajay answers memorize kar sakte hain. Example: Model ek math word problem "solve" karta hai kyunki exactly wahi problem training data mein homework help site pe aayi thi.

Steel-man: Chahe overlap ho, model ko woh knowledge dhundni aur use karni toh padti hai.

Fix:

Deduplicate: Jo bhi test examples training data mein aate hain unhe remove karo (partial matches bhi)
Perturb: Test questions paraphrase karo taaki exact matches impossible ho jaayein
Date-based splits: Sirf date X se pehle ke data pe train karo, date Y ke baad ke data pe test karo
Contamination analysis report karo: "Humne 47 near-duplicates (test set ka 0.3%) paaye aur unhe remove kar diya."

Tools: Fuzzy deduplication ke liye MinHashLSH, n-gram overlap checks

Common mistake Mistake 4: Ablations mein correlation ko causation samajhna

Kya hota hai: Aap feature X add karte ho → performance improve hoti hai → conclude karte ho ki X important hai

Kyun sahi lagta hai: Ablations isi kaam ke liye hote hain!

Problem: Shayad X true cause ke saath correlated ho lekin khud causal na ho.

Example: "Prompt mein words ki sankhya" ko feature ki tarah add karo → accuracy improve hoti hai → conclude karo ki word count useful hai.
Actually: Lambe prompts zyada detailed hote hain (true cause). Word count sirf ek proxy hai.

Steel-man: Lekin causality prove karna mushkil hai. Kya correlation kaafi nahi hai?

Fix:

Controlled experiments: Baaki sab constant rakhte hue sirf X vary karo
Mechanistic interpretability: Trace karo ki model internally X ko kaise use karta hai
Counterfactual tests: Agar X causal hai, toh ise remove karna hurt karega. Agar yeh proxy hai, toh root cause fix karne se X irrelevant ho jaana chahiye

Example fix: "Lamba lekin vague prompt" vs "chhota lekin detailed prompt" compare karo. Agar length se zyada detail matter karta hai, toh tumhari hypothesis support ho gayi.

Recall Ek 12 saal ke bachche ko explain karo

Socho tum ek teacher ho jo apni class ke liye math test bana rahe ho.

Bura test: Tum students ko exactly wohi problems dete ho jo class mein practice kiye the. Sabko 100% milta hai! Lekin kya unhone actually math seekhi, ya sirf woh specific problems memorize kar li? Tum bata nahi sakte.

Achha test: Tum unhe naye problems dete ho jo same concepts use karte hain. Ab tum dekh sakte ho ki kaun actually math samjhta hai aur kaun sirf memorize kiya.

Benchmarks AI models ke liye tests hain. Jab researchers kehte hain "mera model is test pe 95% laya", toh humein poochna chahiye:

Kya yeh achha test tha? (Kya usne real understanding measure ki ya sirf memorization?)
Kya unhone ek baar run kiya ya kai baar? (Agar aap multiple-choice test 10 baar lete ho aur guess karte ho, toh shayad ek baar luck se ace ho jaaye—iska matlab nahi ki tum material jaante ho!)
Kya model ne test se hi "padhai" ki? (Yeh cheating hai!)

Tricky part: Jaise-jaise AI smarter hoti jaati hai, purane tests bahut easy ho jaate hain. Jaise college students ko elementary school math se test karna—unhe 100% milega, lekin unki real abilities ke baare mein kuch pata nahi chalta.

Isliye benchmark designers ko baar-baar harder, fairer tests invent karne padte hain. Woh teachers jaisi hain, lekin robots ke liye!

Connections

6.5.01-Emerging-architectures - Naye architectures ko naye benchmarks chahiye; purane benchmarks unki capabilities stress nahi kar sakte
6.5.02-Interpretability-and-AI-safety - Evaluation rigor ek safety issue hai: humein jaanna chahiye ki models actually kya karte hain, na ki woh kya karte dikhte hain
3.2.01-Bias-variance-tradeoff - Runs mein performance variance bias-variance tradeoff reflect karta hai
2.4.02-Regularization-techniques - Benchmarks pe overfitting training data pe overfitting jaisi hai—dono ko regularization chahiye (zyada test sets, adversarial examples)
4.1.03-Evaluation-metrics - Metrics task objectives ke saath align hone chahiye warna tum galat cheez measure karte ho

#flashcards/ai-ml

Benchmark evaluation mein data leakage kya hai? :: Jab test set ki information model development ko influence kare (e.g., test data pe tune kiye gaye hyperparameters, ya test examples training data mein appear ho jaayein). Isse overestimated performance hoti hai jo generalize nahi hoti.

Best run ki jagah mean ± SEM kyun report karni chahiye?

Sirf best run report karna selection bias introduce karta hai—aap ek distribution ke maximum se sample kar rahe ho, mean se nahi. Yeh true model capability overestimate karta hai. Mean ± SEM dono central tendency aur uncertainty quantify karta hai.

Benchmark design mein negative control kya hai?

Test ka ek aisa version jisme model ko fail hona chahiye agar woh truly task solve kar raha hai (e.g., shuffled answer choices, adversarial distractors). Agar model phir bhi succeed karta hai, toh woh spurious correlations exploit kar raha hai, intended reasoning nahi kar raha.

Task contamination define karo aur isse kaise rokein :: Task contamination tab hoti hai jab test examples training data mein appear hote hain, reasoning seekhne ki jagah memorization allow karte hain. Rokne ke liye: (1) fuzzy deduplication, (2) date-based splits (purane data pe train, naye pe test), (3) test data ka programmatic generation jo training ke dauran exist hi nahi karta tha.

Bonferroni correction kya hai aur ise kab zaroorat hai?

m hypotheses test karte waqt, α ki jagah significance level α/m use karo. Multiple comparisons ke liye zaroori hai—correction ke bina, 20 models ko pairwise (190 comparisons) α=0.05 ke saath test karna ~10 false positives chance se deta hai.

Model performance ke liye 95% confidence interval kaise calculate karte hain?

n ≥ 30 runs ke liye: CI = mean ± 1.96·(std/√n). Chhote n ke liye: CI = mean ± t₀.₉₇₅,ₙ₋₁·(std/√n) Student's t-distribution use karke. Yeh true mean ke baare mein epistemic uncertainty quantify karta hai.

Cohen's d kya hai aur yeh kyun matter karta hai?

Practical significance measure karne wala effect size: d = (mean_A - mean_B) / pooled_std. Values: |d|<0.2 negligible, 0.2-0.5 small, 0.5-0.8 medium, ≥0.8 large. Statistical significance (p<0.05) practical importance imply nahi karta—effect size bhi chahiye.

Test data ko randomly split karne ki jagah generation parameters se kyun split karte hain?

Random splits information leak kar sakti hain—test examples train examples se trivially similar ho sakte hain. Parameters se split karna (e.g., 2 objects pe train, 5 pe test) slightly out-of-distribution cases mein genuine generalization test karta hai, memorization nahi.