Lesson 83 — Intermediate

Introduction to LLM Evaluations

Jab tak tumhara LLM app chhota tha, "chalta hai — dikhta toh sahi hai" wali testing chal jaati thi. Par jaise hi users badhe, wahi "sahi lagne wale" answers production mein galat nikle. Is lesson mein hum seekhenge ki LLM evals hote kya hain, traditional software testing yahan kyun fail hoti hai, aur ek proper evaluation workflow kaise banta hai.

⏱ 10 min• Intermediate• Basic computer usage

LLM evaluation kya hai

WHAT

LLM evaluation ka matlab hai apne model ya application ke output ko ek defined criteria ke against systematically measure karna — sirf "accha lagta hai" nahi, balki ek number ya verdict jo repeatable ho. Jaise unit test code ko check karta hai, waise hi eval LLM behaviour ko check karta hai.

WHEN

Har baar jab tum prompt badlo, model switch karo, RAG pipeline chhoo ya koi naya feature add karo — pehle yeh poochho ki "kya mera quality standard abhi bhi khara hai?" Eval sirf launch se pehle nahi, poore product lifecycle mein chalta hai.

WHERE

Development ke waqt offline suites mein, CI/CD gates mein, aur deployment ke baad production logs par online sampling ke roop mein. LLM applications jaise chatbots, RAG search, agents — sab jagah yeh zaroori hai.

Ek line ka funda: jo cheez tum measure nahi karte, wo drift karti jaati hai. LLM systems mein yeh drift aur bhi tez hoti hai — model updates, user behaviour badalna, naye types ke inputs aana. Evaluation hi woh compass hai jo tumhe batata hai ki app abhi bhi sahi disha mein hai ya nahi.

Yaad rakho: Evaluation = criteria + dataset + execution + analysis. Sirf "10 prompts chala kar dekh liya" evaluation nahi hai — usme koi defined criteria, koi repeatable process aur koi recorded result hona chahiye.

Vibe testing — kyun kaafi nahi

Jab tum khud kuch prompts likh kar output dekhte ho aur sochte ho "haan, theek lag raha hai" — yehi vibe testing hai. Yeh development ke shuruwati dinon mein theek hai, par production ke liye khatarnak hai kyunki yeh tumhari apni expectations ko hi test karta hai, real users ke cases ko nahi.

Sirf tumhe pata hai kya "sahi" hai: vibe check mein tum wahi prompts chunte ho jinme tumhe alreadyandaza hota hai. Edge cases, unexpected inputs, ambiguous sawaal — sab chhoot jaate hain.
Ek real failure pattern: ek airline ka customer-support chatbot grieving passenger ko galat refund policy bata gaya, aur public tribunal ne airline ko hi jawabdar thehra — kyunki unhone chatbot ke "sahi lagne wale" answers ko verify nahi kiya tha.
Confirmation bias: jab tumhe koi feature pasand hai, tum unconsciously wahi examples choose karte ho jinme wo accha karta hai. Vibe testing isi bias ka shikar hai.
Koi regression coverage nahi: aaj 20 prompts se "sahi" laga, kal naya prompt add hua — pehle wale 20 ka kya? Bina suite ke tumhe pata hi nahi chalega ki kuch toota hai.

Warning: Vibe testing ka sabse bada khatra yeh hai ki wo kaam karta hua dikhta hai — jab tak ek bada failure na ho jaaye. Us waqt tak tumhe bharosa rehta hai ki "sab theek hai", aur tab tak damage ho chuka hota hai.

Deterministic vs probabilistic testing

Traditional software testing isi liye aasaan thi kyunki code deterministic hai: same input, same output, hamesha. LLM ek probabilistic system hai — same prompt pe bhi output har baar thoda alag ho sakta hai, aur phir bhi wo "sahi" ho sakta hai. Yahi fundamental shift hai jo poori testing paradigm badal deti hai.

Traditional software:          LLM application:
input → exact expected output  input → many valid outputs
assert output == "X"           check: meaning / criteria match kiya?
flaky test = bug (tumhara)    variation = normal (model ka nature)
100% coverage possible         100% coverage impossible (open-ended)

Isliye: exact-match ki jagah semantic checks, aur single run ki jagah
multiple samples + aggregate scores chahiye.

Output variation normal hai: do baar same prompt pe alag-alag phrasing aana failure nahi — failure hai criteria todna (galat fact, tone breach, format miss).
Eval bhi probabilistic hai: isliye ek hi test case ko kabhi-kabhi multiple times chala kar average dekhte hain, taaki ek random sample poori judgement na kare.
Deterministic parts phir bhi hain: JSON schema validity, required fields present hain ya nahi, refusal hona chahiye ya nahi — yeh sab abhi bhi exact checks se ho sakte hain.
Greedy decoding ≠ solution: temperature 0 karke output stabilize kar sakte ho, par tab bhi model badalne (version update) se output badlega — regression risk rehti hai.

Model evals vs application evals

MODEL EVALS                       APPLICATION EVALS
─────────────────────────────     ─────────────────────────────
Kya test karte hain:               Kya test karte hain:
  foundation model ki apni           poora app — prompt template,
  capability (reasoning,             retrieval, tools, system
  knowledge, formatting)             instructions, UI formatting

Kaun chalata hai:                  Kaun chalata hai:
  model providers / research         tum, apne real task data pe

Example: kya model ek              Example: kya tumhara support
logic puzzle solve kar paata        bot order status sahi context
hai                                ke sahi nikalta hai

Public leaderboards tumhe batate hain ki model overall kitna capable hai — par tumhara app us model ko ek tight system prompt, apna data aur apne rules ke saath chalata hai. Ek strong model bhi ghalat prompt aur ghalat context ke saath bekaar output de sakta hai. Isliye model evals se shortlist karo, application evals se final decision lo.

Rule of thumb: Model change kar rahe ho? Model eval dekho. Prompt, retrieval ya tools chhoo rahe ho? Application eval chalao. Production mein "mera app kaisa hai" — hamesha application eval batata hai, leaderboard nahi.

End-to-end evaluation workflow

1. TASK DEFINE     — kya kaam karna hai? (e.g. "order status question ka sahi jawab")
2. CRITERIA        — "sahi" ka matlab kya hai? (faithful, complete, tone, format)
3. DATASET         — 30-100 representative inputs (real logs se, edge cases ke saath)
4. EXECUTION       — har input pe app chalao, output + intermediate steps log karo
5. SCORING         — har criteria ka score ya pass/fail lagao
6. ANALYSIS        — overall score nahi, failures dekho: kahan, kyun, kis type ke
7. ITERATION       — fix karo, phir se chalao, dataset mein naye failures add karo

# Ek chhota skeleton — pipeline ko function maan ke:
def run_eval(app_fn, dataset, scorers):
    results = []
    for case in dataset:
        output = app_fn(case["input"])
        scores = {name: fn(case, output) for name, fn in scorers.items()}
        results.append({"input": case["input"], "output": output, **scores})
    return summarize(results)   # avg scores + failure breakdown

Is workflow ka step 6 (analysis) hi asli seekh hai. Ek average score se pata chalta hai "kitna accha", par failures dekhne se pata chalta hai "kahan galat ho raha hai" — aur sirf wahi fixable hai. Naye engineers aksar sirf aggregate number dekhte hain aur ruk jaate hain; asli improvement failure patterns padhne se aati hai.

Pro Tip: Pehla eval suite 30-50 cases se banao, perfect hone ka intezar mat karo. Chhota suite jo roz chalta hai, us suite se jo seekh milti hai — wo 500-case sheet se jo kabhi run hi nahi hoti, usse zyada hai.

Exercise

Question: LLM deterministic system hai ya probabilistic? Ek shabd mein jawab do.

Question: Vibe testing mein output check karne ka kya tareeka hota hai — defined criteria ya sirf aankhon se "theek lagta hai"?

Question: End-to-end eval workflow mein pehla step kya hai — task define karna ya scoring script likhna?

Question: Application eval mein kya evaluate hota hai — sirf foundation model ya poora app (prompt + retrieval + model)?

Common mistakes

Vibe testing ko evaluation samajhna: — 10 favourite prompts chala kar "sahi hai" kehna evaluation nahi hai. Bina defined criteria aur recorded results ke koi regression pakad mein nahi aayega.
Sirf average score dekh kar ruk jaana: — average number good-looking ho sakta hai, par 30% cases agar ek hi tarike se fail ho rahe hain toh wo pattern hi asli bug hai. Hamesha failure-wise breakdown padho.
Model eval aur application eval ko mix karna: — leaderboard score dekh kar sochna "mera app bhi utna accha hai" galat hai. Tumhara prompt, data aur rules us model ko alag tarike se chalate hain — apne task pe apna eval chalao.
Evaluation ko sirf launch-event samajhna: — "ek baar kar liya" se kaam nahi chalta. Har prompt change, har model update aur har data shift ke baad eval dobara chalao — tabhi suite meaningful hai.

Desi example: Doctor ka check-up vs "mujhe theek lag raha hoon"

Bina check-up ke "sahi lag raha hai" kehna vibe testing hai — doctor kabhi lab tests (eval dataset) bina diagnosis nahi deta. Wahi discipline LLM apps ke liye chahiye:

# Vibe check (kabhi mat karo)
print(app("What is my order status?"))   # "theek lagta hai" ✔

# Structured eval (yeh karo)
cases = [
    {"input": "Where is my order 123?", "must_mention": "123"},
    {"input": "Cancel my order",        "must_not_do": "cancel_without_confirm"},
]
for c in cases:
    out = app(c["input"])
    ok = c.get("must_mention", "") in out
    print(c["input"], "->", "PASS" if ok else "FAIL")

Interview angle — yahan se sawaal aate hain

Q: Traditional unit test aur LLM eval mein fundamental difference kya hai?
Q: "Vibe testing" kyun dangerous hai — ek real-world failure example ke saath batao.
Q: Model evaluation aur application evaluation alag kyun hain? Kab kaunsa use karte ho?
Q: End-to-end evaluation workflow ke steps batao — task definition se iteration tak.
Q: LLM output probabilistic hai — isse evaluation strategy pe kya asar padta hai?

Lesson complete?

LLM evals ka base clear. Agla lesson — Evaluation Methods & Paradigms — mein dekhenge programmatic checks, human review aur LLM-as-a-Judge kab aur kaise use karte hain.