Lesson 171 — Advanced

Fine-tuning & model adaptation interviews

Interview mein fine-tuning ka sawaal aksar ek product brief ke roop mein aata hai — aur test ye hai ki tum turant training shuru karne ke bajaye pehle decision frame lagao: prompt se hoga? RAG se hoga? Fine-tune hi chahiye? Is lesson mein tum LoRA/QLoRA/PEFT/quantization ko definitions ke bajaye engineering trade-offs mein padhoge, fine-tuned open-weight model ka serving kaise sochte hain, aur wo debugging checklist jo "deploy ke baad accuracy gir gayi" ke sawaal mein kaam aati hai.

⏱ 10 min• Advanced• Agentic AI interview scenarios

Prompt vs RAG vs fine-tune — brief se decision

Kya hai?

Model adaptation ke teen layers hain: prompt (behaviour nudge, zero infra), RAG (dynamic knowledge inject, no training), fine-tuning (weights badalte hain — behaviour, format, domain bake-in ho jaata hai). Faisla product brief se hota hai, fashion se nahi.

Kab kaam aata hai?

Prompt hamesha pehla. RAG jab knowledge chahiye jo badalta rehta hai. Fine-tune tab jab repeatable behaviour/format/style chahiye ya high volume pe per-call prompt chhota karna ho.

Kahan milta hai?

Support reply tone, structured extraction formats, domain jargon, chhote model se bada kaam karwana — yahan fine-tune ka genuine case banta hai. Fresh facts ke liye kabhi nahi.

need                    pehla      phir        phir bhi nahi toh
naya knowledge (badalta) prompt      RAG         (fine-tune FACTS nahi sikhata)
behaviour/format/style   prompt      fine-tune   (few-shot examples try karo)
domain vocabulary/tasks  prompt      fine-tune   (base model hi kaafi ho sakta hai)
cost/latency at volume   small model + fine-tune (chhota context, sasta inference)

Golden rule: Fine-tuning knowledge nahi, behaviour sikhata hai. "Company ke policies model ko sikhana hai" — nahi, RAG se dynamically do. "Har ticket ka JSON hamesha isi format mein aaye" — haan, fine-tune ka case yahin hai.

Fine-tuning kab earn karti hai complexity

Task stable ho: mahino tak same behaviour chahiye. Har hafte badalne wale requirements pe fine-tune = har hafte retrain — paise ka kua.
Eval set ho: improvement prove karna hai toh held-out set chahiye. Bina eval ke fine-tune andheri khadaai hai.
Volume ho: ek chhote prompt ki token bachat hi training + serving ka kharcha barafaye. Cost per request, not per demo.
Asli faida: inference pe prompt chhota, behaviour consistent, aur chhota model bade jaisa kaam karta hai (distillation style) — latency aur cost dono ginte hain.
Complexity cost: data curation, training runs, eval harness, retraining cadence, serving — har cheez ka owner chahiye. Ye list interviewer ko dikhao, chhupao nahi.

Decision line: "Kya ek accha prompt + few-shot examples se kaam chal jaata hai?" Haan toh fine-tune ka case bana hi nahi. Interview mein ye question khud pooch kar batana ki tum complexity ko justify karte ho, promote nahi karte.

LoRA, QLoRA, PEFT, quantization — trade-offs, definitions nahi

technique      kya karta hai                          trade-off
LoRA           base frozen, chhote adapter ranks     sasta training; multiple adapters per base
QLoRA          base 4-bit quantized + LoRA            aur sasta GPU; thoda quality ka tail risk
PEFT           LoRA + adapters/prefix tuning family   family ka naam, approaches ka jhund
quantization   weights chhote (int8/int4)             memory/latency kam; worst cases dekho

serving soch:
  base + adapter memory mein? -> hot-swap adapters, alag-alag tasks ek base pe
  batching + KV-cache reuse -> latency budget se config, guess se nahi
  cost: GPU fixed cost vs traffic curve -> utilization hi asli meter hai
  quantized build pe EK BAAR full eval -> bench-quality aur prod-quality alag ho sakte hain

LoRA ka engineering faida: adapter chhota hai, isliye task switching sasta — ek base model, do adapters (support, extraction), same serving box.
QLoRA ka faida aur darr: base 4-bit mein fit ho jaata hai, chhoti GPU pe training; par quantization ka quality loss har task pe same nahi hota — worst cases nikaalo.
Serving ka asli sawaal: latency budget kya hai, traffic curve kaisa hai, batching kitni hai. GPU ki specs nahi, workload ka number decide karta hai.
Cost ka defence: utilization. Raat bhar idle GPU vs steady traffic — dono ke numbers bolo; "GPU mehnga hai" opinion hai, utilization engineering hai.

Trade-off language: Interview mein definitions mat sunao — "LoRA low-rank adaptation hai" se koi impress nahi hota. Bolo: "LoRA se ek base pe 3 adapters, training cost chhota, inference pe hot-swap; par adapter versioning tumhe khud karni padegi." Farq hi score hai.

"Deploy ke baad accuracy gir gayi" — checklist

checklist (order mein, ek saath mat badlo):
1. training data   -> eval set se overlap/toxicity? contamination check
2. formatting      -> inference prompt template train ke jaisa? chat template sahi?
3. distribution    -> prod queries ka mix badla? languages, lengths, user types
4. eval regressions-> eval set hi stale/toxic? baseline dobara chalao
5. inference config-> temperature, stop tokens, max tokens, system prompt drift
6. serving changes -> quantization on? batching truncation? tokenizer version?
7. quant artifacts -> same weights, alag precision -> worst cases spot-check

order: pehle REPRODUCE (same input, do predictions compare), phir config diff, phir data diff

Reproduce pehle: ek hi input, purana build aur naya build — do predictions side by side. Bina reproduce ke sab kuch guess hai.
Format mismatch sabse aam: training mein ek chat template tha, inference mein doosra — model bas thoda confused hota hai, accuracy silently girti hai.
Distribution shift: eval set clean tha, prod queries messy hain. Fine-tuned model apne training distribution ke bahar zyada fragile hota hai.
Quantization artifacts: accuracy drop aksar sirf worst cases mein hota hai — average dekh kar mat chhodo, error cases ka review karo.

Debug ka order: Reproduce → config diff → data diff → eval diff. Pehle dikhao ki problem real hai (reproduce), phir sabse sasta explanation check karo (config/format), phir mehngi (data, weights). Interview mein ye order hi tumhara score hai.

Exercise

Question: Fine-tuning se pehle ka fallback kya hai — RAG ya prompt?

Question: LoRA mein base weights kya hote hain — trained ya frozen?

Question: QLoRA base model ko kis format mein rakhta hai? (do shabd)

Question: Naye facts sikhane ke liye kaunsa adaptation sahi hai — fine-tune ya RAG?

Question: Deploy ke baad quality drop — pehle kya karo: naya training run ya reproduce karke config diff?

Common mistakes

Fine-tune se pehle RAG try nahi karna: Facts update karne ka sabse sasta aur reversible raasta RAG hai; fine-tune facts ko weights mein jam deta hai. Fix: knowledge = RAG, behaviour = fine-tune — dono ka jagah alag hai.
Eval set ke bina fine-tune karna: "Lagta hai behtar hai" koi measurement nahi hai. Fix: pehle baseline, phir tuned model, same held-out set pe compare — sirf tab ship karo jab farq statistically zaheen ho.
Chat template ya prompt format ka dhyan na rakhna: Training aur inference ka format alag toh model confuse — accuracy girti hai bina weights ke blame ke. Fix: inference wrapper ka template test karo aur version pin karo.
Quantized build pe bina eval ke ship karna: Memory bach gaya par worst cases chupke se kharab. Fix: quantization ke baad full eval + error-case review — average score se mat chhodo.

Desi example: Bawarchi training vs menu

Fine-tune = bawarchi ko andar tak style sikhana (weights badalte hain). RAG = aaj ka fresh menu table pe rakhna (knowledge bahar, badal sakti hai). Prompt = ek line mein order. Fresh veggies (facts) kabhi bawarchi ki training mein nahi — menu se aati hain:

prompt     -> "jaldi bolo" (behaviour nudge, zero cost)
RAG        -> menu card (aaj ka stock, kal badal jaayega)
fine-tune  -> bawarchi ki training (style andar tak, re-training chahiye)
facts      -> menu pe hi, bawarchi ko yaad nahi karwane

Interview angle — yahan se sawaal aate hain

Q: Prompt vs RAG vs fine-tune ka decision kaise? — Knowledge badalta hai toh RAG; behaviour/format repeatable hai toh fine-tune; warna prompt. Volume aur eval set hi fine-tune ko justify karte hain.
Q: LoRA/QLoRA ko engineering lens se batao. — LoRA: frozen base + chhote adapters, sasta training, hot-swap. QLoRA: 4-bit base, aur sasta, par quality tail risk. Definitions nahi, trade-off.
Q: Fine-tuned model deploy karte waqt kya sochte ho? — Serving architecture (base+adapter memory), GPU capacity, batching/KV-cache, latency budget aur utilization se cost.
Q: "Accuracy deploy ke baad giri" — investigate kya karoge? — Reproduce → format/template mismatch → distribution shift → eval staleness → inference config → quantization artifacts.
Q: Fine-tune facts kyun nahi sikhata? — Knowledge weights mein fix ho jaata hai; update = retrain. Isliye freshness ki zarurat wali knowledge RAG mein, behaviour fine-tune mein.

Lesson complete?

Adaptation ka decision frame ready — ab tum fine-tune ko justify ya refuse kar sakte ho aur degradation ko systematically dhoond sakte ho. Agla lesson — LLMOps & Production Debugging Interviews — mein poore system ko on-call ki nazar se dekhenge.