Lesson 84 — Intermediate

Evaluation Methods & Paradigms

Ek baar criteria set ho gaye, toh agla sawaal hai — score karega kaun? Tumhare paas teen tareeke hain: code (programmatic), insaan (human), ya ek dusra LLM (LLM-as-a-Judge). Is lesson mein hum har method ka mechanism samjhenge, reference-based vs reference-free ka farq dekhenge, aur decision rule seekhenge ki kaunsa behaviour kis method se check hota hai.

Teen execution mechanisms

In teeno ko "teeno tareeke hain scoring ke" mat dekho — ye ek escalation ladder hain. Jo kaam code kar sakta hai wo code karo (tez, sasta, deterministic). Code nahi kar paya toh judge lagao. Judge bhi doubt mein ho toh insaan. Har level pe cost badhta hai, isliye neeche se shuru karo.

Programmatic, Human aur Judge — mechanism

# 1) PROGRAMMATIC — code exact check karta hai
def check_json_valid(output):
    try:
        data = json.loads(output)
        return 1.0 if "answer" in data else 0.0
    except json.JSONDecodeError:
        return 0.0

# 2) LLM-AS-A-JUDGE — ek LLM criteria ke against score deta hai
JUDGE_PROMPT = """Rate the assistant answer 0 or 1.
Criterion: the answer must stay strictly within the given context.
Return JSON: {\"score\": 0 or 1, \"reason\": \"...\"}
Context: {context}
Answer: {answer}
"""
def llm_judge(context, answer):
    verdict = call_llm(JUDGE_PROMPT.format(context=context, answer=answer))
    return json.loads(verdict)["score"]

# 3) HUMAN — code nahi, form bharoge
def human_review(sample):
    # crowd/internal reviewer rating form: 1-5 per criterion
    return reviewer_form(sample)   # slowest, sabse trustworthy

• Programmatic: regex, exact-match, JSON schema, keyword presence, length limits, refusal rules. Free aur perfectly reproducible — par sirf un behaviours pe jo tumhe exactly describe kar sako.
• Human: tone, nuance, harmfulness, "kya ye answer ek real customer ko theek lagega". Sabse trustworthy par mehnga aur slow — isliye sampling pe chalta hai, har example pe nahi.
• LLM-as-a-Judge: judgement natural language criteria de kar leta hai. Scale pe cheap, par khud bhi galat ho sakta hai — position bias (pehla option pasand), verbosity bias (lamba answer = accha), self-preference (jo model judge kare, usi family ko zyada score).
• Judge ko calibrate karo: judge ke scores ko ek chhote human-labelled set se compare karo. Human se 70% match ho raha hai toh judge usable hai; bekaar nikle toh prompt ya judge model badlo.

Reference-based vs reference-free

Doosri axis hai — tumhare paas ek "sahi jawab" (reference) hai ya nahi. Reference-based mein har input ke saath ek answer key hoti hai aur output usse compare hota hai. Reference-free mein koi answer key nahi — sirf criteria (faithful hai? relevant hai? safe hai?) jo context ya rubric se check hote hain.

• Reference-based: classification, extraction, Text-to-SQL (ek known query hai), summarization (ek reference summary hai). Precision, recall, exact-match yahin lagte hain.
• Reference-free: open QA, RAG faithfulness, tone checks, safety. Yahan "ek hi sahi jawab" exist hi nahi karta — isliye judgement criteria pe hota hai, answer key pe nahi.
• Dono ka hybrid: RAG eval mein context hi tumhara reference hai — "kya answer context se support hota hai" reference-free lagta hai, par actually ek implicit answer key (retrieved chunks) use ho rahi hai.
• Sawaal pehle: "kya is task ka ek canonical answer set hai?" Haan toh reference-based, nahi toh reference-free. Ye decide karte hi scoring design aadha clear ho jaata hai.

Golden Dataset kab chahiye

Golden dataset = tumhara answer-key wala curated test set — har input ke saath expected behaviour, jo release gate ke taur pe chalta hai. Iske bina tum sirf "lagta hai theek hai" pe depend rehte ho, aur reference-based metrics ka koi base hi nahi hota.

# Ek chhota golden dataset entry ka shape
case = {
    "id": "refund-policy-03",
    "input": "Does the 30-day return apply to opened electronics?",
    "reference_answer": "Opened electronics are eligible only within 7 days.",
    "required_facts": ["7 days", "opened electronics"],
    "forbidden_claims": ["30-day return for opened electronics"],
    "category": "policy",
}

# Reference-based score: required facts mile ya nahi
def score_case(case, output):
    hits = sum(1 for f in case["required_facts"] if f.lower() in output.lower())
    leak = any(bad.lower() in output.lower() for bad in case["forbidden_claims"])
    return {"recall": hits / len(case["required_facts"]), "harmful": leak}

• Chahiye jab: regression gate chahiye (release rokna hai agar quality giri), reference-based metric chahiye, ya judge ko calibrate karna ho.
• Abhi zaroorat nahi: exploration phase mein, jab task abhi define hi ho raha ho — tab human spot-check hi kaafi hai.
• Kahan se banayein: production logs ke real inputs + hand-written edge cases + LLM se synthetic variations (par phir human verify zaroor).
• Rakhna mushkil hai: golden dataset bhi data hai — usse version control mein rakho, stale entries hatao, aur naye production failures ko usme add karte raho.

Behaviour ke hisaab se method match karna

Behaviour type       Example                       Best method
───────────────────  ────────────────────────────  ──────────────────────────
Deterministic        JSON schema, required field   Programmatic exact check
Format-based         CSV columns, regex pattern    Programmatic (regex/parse)
Semantic (known ans) SQL query jo sahi result de   Reference-based + judge
Subjective           tone, helpfulness, style      Human rubric (judge at scale)
Operational          latency, cost, error rate     Telemetry (auto-captured)
Safety               harmful / PII / injection      Red-team set + classifier/judge

Is table ko apne har metric pe apply karo — har criterion ke saamne likho ki wo kis bucket mein hai. Aksar teams sab kuch LLM judge se karwane lagti hain kyunki "flexible hai" — par deterministic checks judge se karwana mehnga, dheema aur kabhi-kabhi non-deterministic bhi hai.

Exercise

Common mistakes

• Har cheez LLM judge se karwana: — regex, schema aur exact-match wale checks judge se karna mehnga aur flaky hai. Pehle programmatic check likho; judge sirf semantic/subjective criteria ke liye bachao.
• Judge ko bina calibrate kiye trust karna: — judge ka apna bias hota hai (position, verbosity, self-preference). Ek chhote human-labelled set pe judge ka agreement check karo, tabhi uske scores production gate banao.
• Open-ended task pe exact string match: — "7 days" aur "within a week" dono sahi hain, par exact match ek ko fail kar dega. Reference-based hote hue bhi semantic ya rubric-based comparison lagao.
• Golden dataset ko ek-time ka kaam samajhna: — wo live artifact hai. Production ke naye failures usme add karte raho, warna suite purani duniya test karta rahega aur regressions nikal ke aayenge.

# Desi mapping: exam checking ke 3 tareeke
def check_answer(question, answer, method):
    if method == "OMR":        # programmatic — exact option match
        return answer == question["key"]
    if method == "viva":       # human — samajh ke nuance dekhta hai
        return teacher_asks_followups(answer)
    if method == "rubric":     # LLM judge — defined rubric se score
        return call_llm(f"Score 0-5 by rubric: {question["rubric"]}\nAns: {answer}")
# Har answer ka method pehle se decide hota hai — jabardasti ek se nahi!