Lesson 101 — Advanced

The AI System Design Framework

AI system design ka matlab boxes draw karna nahi — requirements se architecture tak defend karne layak decisions lena hai. Is lesson mein requirement sheet kaise bharte hain, approach kaise chunte hain, trade-off tension kaise balance karte hain, aur kyun pehle baseline chahiye — sophistication se pehle.

⏱ 20 min• Advanced• Basic computer usage

Requirements se shuru — technology baad mein

WHAT

AI system design ek decision process hai: pehle use case, success criteria aur constraints likho, phir architecture choose karo. Pasand ka technology baad mein aata hai — requirement pehle.

WHEN

Naya AI feature banate waqt, kisi existing system ke review mein, ya interview ke system design round mein. Ek line ka idea aaya — turant code likhne se pehle yahi step chahiye.

WHERE

Design doc, whiteboard discussion, architecture review, ya notebook ka ek page — jagah matter nahi, order matter karta hai: requirements → options → trade-offs → decision.

Design ka pehla sawaal "kaunsa model?" nahi hai — kaunsa kaam hai, safalta kaise check hoga, aur kya constraints hain. Ye chaar cheezein likh lo, technology choice khud saaf ho jaati hai.

Rule: Favourite technology se shuru mat karo. Pehle requirement likho, phir options compare karo — tabhi interview mein aur team review mein "yahi kyun" defend kar paoge.

Requirement sheet — 8 fields

USE CASE        : kaun kya karega (job to be done)
SUCCESS CRITERIA: kya "sahi" hai — kaise check hoga
TRAFFIC         : request ka shape (steady ya burst)
LATENCY         : user kitna intezaar seh sakta hai (interactive ya batch)
QUALITY         : galti ki mehngai — kitni galti chalegi
PRIVACY         : kya data andar aayega, kahan store hoga, kaun dekh sakta hai
COST BUDGET     : per request kharcha ki ceiling (apne system se measure karo)
OPS             : kaun maintain karega, kitna complexity chal sakta hai

Har field ka answer likho — blank chhodna matlab baad mein surprise. Privacy wala field aksar sabse late aata hai aur sabse mehnga padta hai: data kahan jaayega, retention kitni, access kiska — ye baad mein add karna rewrite hota hai.

Constraint stacking: Constraints ek doosre ko khichtay hain — strict latency + strict privacy + low cost teeno saath mushkil hain. Ek ko relax karo ya scope chhota karo, warna design andar se hi tootega.

Prompting, RAG, agents, fine-tuning — chunav rules

Prompting: knowledge model ke andar hai aur kaam straightforward hai — sabse pehle yahi. Sasta, shipping fast, evaluate karne mein aasaan.
RAG: jawab tumhare private docs se aana chahiye ya knowledge badalti rehti hai — context bahar se laao, fine-tuning mat karo.
Fine-tuning: behaviour/style/format baar-baar same ho raha hai aur prompt se fix nahi hota — tab, aur tabhi. Pehle few-shot examples try karo.
Agents: kaam mein kai steps, tools aur decisions hain — jab deterministic pipeline kaafi na ho. Simple task par agent = unnecessary risk.
Combinations: asli systems mix hote hain — RAG + routing (L9.3) + prompt caching (L9.5) ek saath chalte hain.

Chunav ka order of operations: prompt → RAG → fine-tune → agentic. Har step complexity, cost aur failure modes badhata hai — pichla step fail hua hi nahi toh agla step zaroori nahi.

Combination bhi rule se: Hybrid design tab banao jab har piece ka justification ho ("docs private hain isliye RAG, FAQ repeat hote hain isliye cache"). Mixture bina reason = maintenance nightmare.

Quality ↔ latency ↔ cost (aur do chhupay hue poles)

              quality
                 /\
               /    \
             /        \
           /____________\
         cost           latency

har point ek CHOICE hai, koi "best" nahi:
interactive  -> latency pole chuno
batch        -> quality pole chuno
high risk    -> quality + auditability pole
sides mein   : complexity aur reliability bhi poles hain

Teeno poles hain — ek behtar karo toh doosra chhootta hai. Stronger model se quality upar, latency aur cost dono upar. Chhota model se latency neeche, quality par risk. Isliye pole pehle choose karo workload dekh ke, phir model nahi.

Do chhupay hue poles: Complexity aur reliability bhi usi triangle mein hain — har extra component ek naya failure mode laata hai aur sambhalne wala banda chahiye. Design ke saath "kaun maintain karega" bhi count karo.

Baseline pehle, sophistication baad mein

Simplest version banao jo actually chalta ho — ek prompt, ek model, ek hardcoded path — aur usse measure karo. Yahi tumhara baseline hai jisse har improvement ka proof milega.

# Baseline = sabse simple working version + uska measurement
def baseline(q):
    return call_model("Answer from general knowledge: " + q)

def compare(candidate, questions, gold):
    rows = []
    for q in questions:
        rows.append({
            "q": q,
            "baseline": score(baseline(q), gold[q]),
            "candidate": score(candidate(q), gold[q]),
        })
    return summarize(rows)   # better / worse — bina baseline ke koi claim nahi

Interview line: Pehle baseline, phir architecture. "Tumne improvement kaise measure kiya?" — iska jawab sirf tab hai jab baseline pehle se recorded ho. RAG lagaya, agent banaya — sab tab tak opinion hain.

Exercise

Question: Design ka pehla step — use case ya model chunna? (ek shabd, English)

Question: Sabse simple working version jisse shuru karte hain — ek shabd, English?

Question: Private docs se jawab chahiye toh approach — teen akshar kya?

Question: Behaviour/style prompt se fix nahi hota toh kya karte hain? (do shabd, English)

Common mistakes

Favourite technology se shuru karna: Model aata hai isliye uske around design — ulta order. Requirement sheet pehle, options baad mein; warna har sawaal ka answer "kyunki hum use karte hain" ban jaayega.
Baseline bina hi improved bolna: Measurement nahi toh har claim sirf opinion hai. Simple version chalao, score karo, phir candidate se compare karo — tabhi "better" ka proof hai.
Constraints ko alag-alag sochna: Latency, privacy aur cost ek saath apply hote hain. Alag-alag design karoge toh integration par doosra constraint tootega — stacking check mandatory hai.

Desi example: Ghar banane ka process — framework ka desi analogy

Mistri seedha cement mangwata hai; asli architect pehle budget, family ki need aur zameen ka angle dekhta hai. AI design bhi wahi — pehle requirement sheet, phir material list:

budget + family need + plot   -> requirement sheet
material options compare      -> approach choice
cost/time/quality balance     -> trade-offs
layout before furniture       -> baseline first

Interview angle — yahan se sawaal aate hain

Q: Naya AI feature aaya — pehle kya likhoge? (use case, success criteria, traffic, latency, quality, privacy, cost — phir architecture)
Q: Prompting vs RAG vs fine-tuning kaise decide karoge? (knowledge kahan hai, kya badalta hai, facts vs behaviour)
Q: Quality-latency-cost ka tension kaise defend karoge? (workload ke hisaab se pole — interactive, batch, high-risk)
Q: Baseline kya hota hai aur kyun zaroori? (simplest working version + measurement — improvement ka proof)

Lesson complete?

Framework set. Agla lesson — Context & Knowledge Architecture: model ko sahi information sahi time par kaise pahunchayein.