RAG (Retrieval Augmented Generation) interview questions & answers

LLM ko ek brilliant student samajh jisne closed-book exam diya hai — internet ke bade dher se train hua hai ek cutoff date tak, aur uske baad training ruk gayi. Usse bahut saari general baatein pata hain, par usne tera company ka HR manual, tere private PDFs, ya training ke baad hui koi bhi cheez kabhi nahi dekhi. Us knowledge ke bahar kuch poocho toh ya toh bolega "mujhe nahi pata", ya usse bhi bura — confidently kuch bana ke bol dega (hallucination).

RAG me, model ne jo yaad kiya hai sirf usi pe depend karne ke bajaye, tu usse ek open-book exam deta hai: jawab dene se pehle, tu TERE documents se relevant pages nikaal ke sawaal ke saath model ko de deta hai. RAG ka matlab hai Retrieve → Augment → Generate: apne data se relevant chunks retrieve karo, unse prompt ko augment (badhao) karo, fir LLM ko us context ke basis pe grounded answer generate karne do. Model ke weights kabhi nahi badalte — tu sirf prompt me kya jaa raha hai wo badal raha hai.

RAG ke do alag phases hote hain. Indexing (offline, ek baar, ya jab bhi documents change hon): documents load karo → chunks me split karo → har chunk embed karo (Ch3) → vectors ko vector DB me store karo (Ch3 — ChromaDB/Pinecone/pgvector). Query (online, har question pe): user ke question ko embed karo → vector DB se top-k nearest chunks retrieve karo → un chunks + question ko context bana ke prompt banao → LLM final answer generate karta hai.

Sirf retrieval hallucination rokne ke liye kaafi nahi hai — tujhe ek grounding prompt bhi chahiye. Ye ek system instruction hai jo model ko bolta hai: "Sirf neeche diye context se answer do. Agar context me answer nahi hai, toh bolo ki tumhare paas ye information nahi hai — guess mat karo." Isko citations ke saath jodo: batao ki answer kis chunk se aaya, taaki user (ya interviewer) usse verify kar sake. Ye grounding + citation combo hi RAG ka anti-hallucination core hai, aur yahi RAG ke answer ko ek confident guess se better, trustworthy banata hai.

🌍 Real-world example: Ek plain LLM se poocho "meri company ki annual leave policy kya hai?" toh wo ek generic number guess karega ya bolega usse pata nahi. Actual HR policy text ko context ke roop me grounding prompt ke saath do, toh wo sahi se "24 days" bolega — aur ye bhi bata dega ki ye exactly kis document se aaya.

💡 RAG = Retrieval Augmented Generation — apne data se relevant text retrieve karke prompt me daal do, taaki LLM un facts se answer de jo usne kabhi train nahi kiye the.

💡 Indexing phase = one-time (ya jab bhi data change ho) kaam jisme documents ko searchable vectors me prepare karte hain — chunk, embed, store.

💡 Query phase = har question ke liye ka kaam — question embed karna, matching chunks retrieve karna, aur LLM se unke basis pe answer maangna.

💡 Grounding prompt = ek instruction jo LLM ko sirf diye gaye context se answer karne tak limit karta hai, aur jab answer wahan na ho toh admit karne ko kehta hai — hallucination ke against sabse bada defence.

💡 Citations = user ko batana ki answer ka har hissa kis source chunk/document se aaya, taaki answer verify ho sake.

Standard definition (interview me bolo): RAG (Retrieval Augmented Generation) is a technique where relevant text is retrieved from an external knowledge source and inserted into the LLM's prompt as context before generation, so the model answers using up-to-date or private data it was never trained on, without changing the model's weights.

from openai import OpenAI
import chromadb

client = OpenAI()
chroma = chromadb.PersistentClient(path="./rag_db")
collection = chroma.get_or_create_collection("company_docs")

# ============================
# INDEXING PHASE (run once)
# ============================
documents = [
    "Annual leave policy: Every employee gets 24 days of annual leave per year.",
    "Sick leave: Employees are entitled to 12 days of sick leave annually.",
    "Work from home: WFH is allowed 2 days per week with manager approval.",
]
collection.add(documents=documents, ids=[f"doc_{i}" for i in range(len(documents))])

# ============================
# QUERY PHASE (run per question)
# ============================
def ask(question):
    # RETRIEVE: nearest chunks from Ch3's vector search
    results = collection.query(query_texts=[question], n_results=2)
    chunks = results["documents"][0]

    # AUGMENT: grounding prompt + citations
    context = "\n".join(f"[{i+1}] {c}" for i, c in enumerate(chunks))
    prompt = f"""Answer ONLY using the context below. If the answer is not in
the context, say "I don't have this information in the documents."
Cite the source number(s) you used, like [1].

Context:
{context}

Question: {question}
Answer:"""

    # GENERATE: grounded answer
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        temperature=0,
    )
    return response.choices[0].message.content

print(ask("How many annual leaves do I get?"))
print(ask("What is the CEO's name?"))

LLM ko ek naye employee ki tarah socho. Unhe better banane ke do bilkul alag tareeke hain: unhe ek reference folder de do jise wo har sawaal se pehle palat sake, ya unhe ek training course pe bhej do jo unke sochne aur bolne ka tareeka hi badal de. RAG wo reference folder hai. Fine-tuning wo training course hai.

Gen AI me, RAG (Retrieval Augmented Generation, Ch4) query time pe tere documents se relevant text nikaal ke prompt me paste kar deta hai — model ke weights kabhi change nahi hote, sirf wo kya padhta hai wo change hota hai. Fine-tuning iska ulta karta hai: tu model ke weights ko hazaaron labelled examples pe retrain karta hai taaki uska underlying behaviour permanently change ho jaaye — answer time pe extra documents ki zaroorat nahi.

Decision framework simple hai jab tu EK sawaal poochta hai: problem missing knowledge hai, ya galat behaviour?

• Missing knowledge ("model ko humari refund policy / aaj ki price list / ye naya law nahi pata") -> RAG. Facts jo baar-baar change hote hain, jinhe source tak trace karna zaroori hai, aur jinke liye har document change pe retrain nahi karna chahiye.
• Galat behaviour ("model ko facts pata hain lekin humare exact tone / JSON schema / medical-report format / rare domain jargon me reply nahi karta") -> fine-tuning. Style, structure, aur consistency jo akela prompt har baar lock karne me struggle karta hai.

🌍 Real-world example: Ek hospital chatbot ko (a) ISI hafte ki bed-availability sheet se answer dena hai — ye RAG hai, kyunki data daily change hota hai aur har answer source ke against check-able hona chahiye — aur (b) hamesha ek strict clinical-note format me reply karna hai jo hospital ki compliance team ne approve kiya hai — ye fine-tuning ka candidate hai, kyunki har answer ka shape identical hona chahiye, sirf facts nahi.

💡 Knowledge vs behaviour = sabse important lens: RAG facts ko context me inject karta hai; fine-tuning ek skill/style ko weights me bake karta hai. 💡 Grounding / citations = RAG ek fact exactly kis chunk/document se aaya ye point kar sakta hai; fine-tuned model nahi kar sakta — ek baar fact weights me bake ho jaaye toh koi "source" cite karne ke liye bacha nahi rehta. 💡 Update speed = RAG document re-index karte hi update ho jaata hai (minutes); fine-tuning ko ek fact bhi change karne ke liye naya labelled dataset aur retraining run chahiye (hours se days).

Standard definition (interview me bolo): RAG changes what the model reads (retrieved context injected into the prompt, weights untouched) to add or refresh knowledge cheaply and with citations; fine-tuning changes what the model is (weights retrained on labelled examples) to change behaviour, tone, or output format permanently — the two solve different problems and are often combined, and most real systems should start with a well-prompted RAG pipeline before ever considering fine-tuning.

Comparison table

Dimension	RAG	Fine-tuning
Fixes	Missing/changing knowledge	Galat behaviour, tone, format
Cost	Kam — embedding + vector DB	Zyada — GPU training + MLOps
Update speed	Minutes (document re-index)	Hours se days (retrain)
Citations / traceability	Haan — exact source chunk cite kar sakte ho	Nahi — facts weights me bake ho jaate hain
Data chahiye	Tumhare existing documents	Sainkdo-hazaaron labelled examples
Naye/changing facts handle karta hai	Haan, natively	Kharab — har baar retrain chahiye
Consistent style/format lock karta hai	Weak — prompt discipline pe depend karta hai	Strong — model ka default ban jaata hai
Hallucination risk	Kam (retrieved text me grounded)	Base model jitna hi, jab tak RAG bhi na add ho

Jab dono me se kuch bhi na use karo

Agar model ko already facts pata hain AUR wo already sahi style me output deta hai, toh shayad tumhe sirf behtar prompting chahiye — ek clearer system prompt, kuch few-shot examples, ya ek strict output-format instruction. RAG ya fine-tuning try karne se pehle ek achhe se likhe prompt ko try karo; ye sabse sasta lever hai aur aksar 80% "model wo nahi kar raha jo main chahta hoon" cases solve kar deta hai.

Jab dono ko combine karo

Bohot saare production systems dono use karte hain: model ko chhote se example-set pe fine-tune karo taaki wo hamesha tumhare exact tone/format/domain jargon me reply kare, AUR RAG use karo taaki wo hamesha fresh, citable facts se answer de. Fine-tuning kaise handle karta hai; RAG kya handle karta hai.

One-line interview answer: "Start with RAG; fine-tune only when prompting + RAG can't get you the behaviour you need — and even then the two are often combined, not either/or."

Kya bana rahe hain: Ek real AI Document Q&A Bot — koi bhi PDF upload karo, plain English mein uske baare mein sawaal poochho, grounded answers milte hain neeche exact source snippets ke saath. Ye wahi project hai jismein is chapter ke saare RAG interview questions (chunking, embeddings, retrieval, grounding, citations) ek saath aate hain. Tech stack: Streamlit (UI) + pypdf (text extraction) + ChromaDB (vector store, Ch3 se) + OpenAI (embeddings + chat).

---

Step 0 — Poora pipeline, end to end (pehle padho)

User PDF upload karta hai
   -> pypdf raw text extract karta hai
   -> text splitter use chunk karta hai (size 500, overlap 100)
   -> OpenAI har chunk ko embed karta hai
   -> ChromaDB vectors store karta hai
   -> user ek sawaal type karta hai
   -> sawaal embed hota hai
   -> ChromaDB top-5 nearest chunks return karta hai
   -> chunks + sawaal ek grounding prompt mein jaate hain
   -> LLM sirf us context se answer deta hai
   -> answer + source snippets user ko dikhte hain

Neeche har step us chain ka ek link hai — notice karo har step agle ko kya hand karta hai.

---

Step 1 — Uploaded PDF se text extract karo

from pypdf import PdfReader

def load_pdf(file):
    reader = PdfReader(file)
    text = ""
    for page in reader.pages:
        text += page.extract_text() + "\n"
    return text

Ho ye raha hai: PdfReader(file) uploaded PDF ko open karta hai (Streamlit tumhe seedha ek file-like object deta hai — pehle disk pe save karne ki zaroorat nahi). reader.pages page objects ki list hai; .extract_text() har ek se plain text nikaalta hai. Hum har page ko ek lambe text string mein jod dete hain, beech mein \n daal ke taaki page boundaries pe do words merge na ho jaayein. Step 2 ko hand hota hai: raw document text ka ek bada string.

🌍 Real-world example: ye bilkul wahi hai jo ek company ke policy-document search tool HR handbook ke saath karta hai, ya legal-tech tool contract ke saath karta hai — jo PDF koi padhna nahi chahta, use searchable text bana dena.

---

Step 2 — Text ko chunk karo (size 500, overlap 100)

from langchain.text_splitter import RecursiveCharacterTextSplitter

def create_chunks(text):
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=500, chunk_overlap=100
    )
    return splitter.split_text(text)

Ho ye raha hai: poore PDF ke liye ek hi embedding kisi specific sawaal ka jawab dene ke liye bahut vague hota, isliye hum ~500-character pieces mein split karte hain. chunk_overlap=100 ka matlab hai har chunk pichhle chunk ke last 100 characters repeat karta hai — to koi sentence jo chunk boundary pe aadha kat jaata hai, wo kam se kam ek chunk mein poora rehta hai. Step 3 ko hand hota hai: chunk strings ki ek Python list, jaise ["chunk 0 text...", "chunk 1 text...", ...].

💡 Chunk overlap = wo safety margin jo kisi fact ko chunk boundary pe chupke se lost hone se rokta hai.

---

Step 3 — Embed karo aur ChromaDB mein store karo

import chromadb

chroma = chromadb.PersistentClient(path="./vectordb")

def store_documents(chunks, collection_name="docs"):
    collection = chroma.get_or_create_collection(collection_name)
    collection.add(
        documents=chunks,
        ids=[f"chunk_{i}" for i in range(len(chunks))]
    )
    return collection

Ho ye raha hai (Ch3 recap, ek line): tumhe already pata hai ChromaDB text ko embeddings mein badalta hai aur similarity search ke liye vectors store karta hai. PersistentClient(path=...) DB ko disk pe save karta hai taaki wo runs ke beech survive kare (sirf memory mein nahi). collection.add(documents=chunks, ...) — plain text pass karo aur Chroma ka default embedding function har chunk ko tumhare liye embed karke vector + original text + ek id store kar deta hai. Step 4 ko hand hota hai: disk pe baitha ek searchable collection, queries ke liye ready.

---

Step 4 — Ek sawaal ke liye top-5 chunks retrieve karo

def ask_question(question, collection_name="docs"):
    collection = chroma.get_collection(collection_name)
    results = collection.query(query_texts=[question], n_results=5)
    context = "\n---\n".join(results["documents"][0])

Ho ye raha hai: collection.query(query_texts=[question], n_results=5) sawaal ko usi tarah embed karta hai jaise chunks embed hue the, fir un 5 chunks ko return karta hai jinke vectors sabse kareeb hain (cosine similarity, Ch3 se). results["documents"][0] un 5 chunk strings ki list hai; unhe "\n---\n" se jod ke ek context block banta hai jo LLM padh sake. Step 5 ko hand hota hai: ek context string jismein PDF ke 5 sabse relevant slices hain.

---

Step 5 — Grounding prompt (anti-hallucination core)

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": f"""Answer based ONLY on this context.
If not found, say "Not in the documents."

Context:
{context}"""},
        {"role": "user", "content": question}
    ],
    temperature=0
)

Ho ye raha hai: ye poore project ki sabse important line hai. system message model ko hard-instruct karta hai: sirf hamara retrieve kiya context use karo, aur jab answer wahaan na ho to admit karo — ye hi cheez LLM ko confidently apni general training knowledge se cheezein bana lene (hallucinate karne) se rokti hai, jo ki tumhare document se alag hoti. temperature=0 answer ko jitna ho sake deterministic/factual banata hai, creative nahi. Step 6 ko hand hota hai: ek response object jiska .choices[0].message.content grounded answer text hai.

🌍 Real-world example: ye exact pattern — pehle retrieve, fir "only from context" instruct karo — har real internal-docs chatbot (Notion AI, company ka HR bot, legal contract assistant) isi tarah non-existent policy invent karne se bachta hai.

---

Step 6 — Answer WITH source snippets return karo

    return {
        "answer": response.choices[0].message.content,
        "sources": results["documents"][0][:3]
    }

Ho ye raha hai: hum sirf answer text return nahi karte — hum wo top 3 raw chunks bhi return karte hain jo answer generate karne mein use hue. Yahi cheez ek black-box answer ko ek trustworthy, citable answer mein badalti hai: user "Sources" expand kar sakta hai aur apni aankhon se dekh sakta hai ki bot apna answer PDF ki kaunsi lines pe base kar raha hai. Step 7 ko hand hota hai: ek dict {answer, sources} jise frontend seedha render kar deta hai.

💡 Source citation = wo exact retrieve kiya gaya text dikhana jahaan se ek claim aayi, taaki user (ya interviewer) verify kar sake ki answer hallucinated nahi hai.

---

Step 7 — Streamlit UI se wire karo

import streamlit as st
from rag_engine import load_pdf, create_chunks, store_documents, ask_question

st.title("AI Document Q&A Bot")

uploaded_file = st.file_uploader("Upload PDF", type="pdf")
if uploaded_file:
    with st.spinner("Processing..."):
        text = load_pdf(uploaded_file)
        chunks = create_chunks(text)
        store_documents(chunks)
    st.success(f"Processed! {len(chunks)} chunks created.")

question = st.text_input("Ask a question about your document:")
if question:
    result = ask_question(question)
    st.write("### Answer:")
    st.write(result["answer"])
    with st.expander("Sources"):
        for i, source in enumerate(result["sources"]):
            st.write(f"**Source {i+1}:** {source[:200]}...")

Ho ye raha hai — poori wiring, traced: st.file_uploader tumhe wahi file object deta hai jo Step 1 consume karta hai. Upload karte hi Steps 1-3 trigger hote hain (load_pdf -> create_chunks -> store_documents) ek spinner ke andar, to ChromaDB ek baar, upfront populate ho jaata hai. st.text_input sawaal capture karta hai; har sawaal Steps 4-6 trigger karta hai (ask_question = retrieve + grounding prompt + sources) fresh. Answer aur expandable source list chain ka aakhri link hain — ek backend pipeline ko kuch aisa banate hain jo ek non-technical user actually use aur trust kar sake.

---

Bonus features (resume/recruiter differentiators)

Base bot prove karta hai ki tum RAG end-to-end wire kar sakte ho. Ye chaar cheezein tumhe har doosre "maine RAG chatbot banaya" resume line se alag karti hain:

• Multi-file upload — kai PDFs accept karo, har chunk ke metadata ko uski source filename se tag karo, taaki citations bataayein ki answer kaunse document se aaya, sirf kaunsa chunk nahi.
• Chat history — pichhle Q&A turns store karo aur recent turns ko prompt mein pass karo, follow-ups handle karne ke liye jaise "aur page 3 pe?" (ye conversational-rag hai, agla topic — query ko standalone question mein rewrite karna).
• Cohere re-ranking — pehle wide retrieve karo (jaise top 20) fir cross-encoder se re-rank karke best 5 tak laao prompt banane se pehle, tricky sawaalon pe kaafi better answer quality ke liye.
• Token usage tracking — har call ka response.usage log karo taaki tum real cost/latency numbers dikha sako — exactly wo cheez jo ek production team ko matter karti hai, aur ek badhiya interview talking point ("maine apne RAG pipeline ka token spend X% optimize kiya").

Recruiter is project mein kya dekhta hai

• RAG implementation — 2025-26 job postings mein sabse hot applied-AI skill.
• Ek real document processing pipeline — extraction, chunking, embedding, storage, sab wired together.
• Vector database usage — ChromaDB production-shaped code mein, koi toy example nahi.
• Grounding + source attribution — proof ki tum hallucination risk aur uska mitigation samajhte ho, yahi cheez ek junior "maine API call ki" project ko senior-shaped project se alag karti hai.
• Ek working, demoable UI — recruiters wo projects yaad rakhte hain jo wo 30 second mein click through kar sakein; resume mein ek Streamlit link ek GitHub repo se zyada value ka hai jo wo clone nahi karenge.

Standard definition (interview me bolo): The AI Document Q&A Bot is a retrieval-augmented generation application that extracts text from an uploaded PDF, splits it into overlapping chunks, embeds and stores the chunks in a vector database, retrieves the most relevant chunks for a user's question, and generates an answer using a grounding prompt that restricts the LLM to the retrieved context — returning both the answer and the source snippets it was built from.

import chromadb
from openai import OpenAI
from pypdf import PdfReader
from langchain.text_splitter import RecursiveCharacterTextSplitter

client = OpenAI()
chroma = chromadb.PersistentClient(path="./vectordb")

def load_pdf(file):
    reader = PdfReader(file)
    text = ""
    for page in reader.pages:
        text += page.extract_text() + "\n"
    return text

def create_chunks(text):
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=500, chunk_overlap=100
    )
    return splitter.split_text(text)

def store_documents(chunks, collection_name="docs"):
    collection = chroma.get_or_create_collection(collection_name)
    collection.add(
        documents=chunks,
        ids=[f"chunk_{i}" for i in range(len(chunks))]
    )
    return collection

def ask_question(question, collection_name="docs"):
    collection = chroma.get_collection(collection_name)
    results = collection.query(query_texts=[question], n_results=5)

    context = "\n---\n".join(results["documents"][0])

    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": f"""Answer based ONLY on this context.
If not found, say "Not in the documents."

Context:
{context}"""},
            {"role": "user", "content": question}
        ],
        temperature=0
    )

    return {
        "answer": response.choices[0].message.content,
        "sources": results["documents"][0][:3]
    }