Why this matters
- Panels reuse the same skeleton: what it is, why not fine-tuning, how you chunk, how you know it works, how you ship it.
- A memorized definition of RAG without a retrieval metric sounds like a blog summary.
- Code questions are pipeline questions. They want the order of calls, not a specific import from last year.
- This page is the revision pass. The earlier lessons are the explanations. Use both.
What they probe
Topics that actually come up
- Definition and architecture, including the index path versus the query path.
- Chunking, embeddings, and a vector store you have used, with a reason.
- Hybrid search, hallucinations, and evaluation numbers you can define.
- Agents and tools, only after the single-hop path is solid.
- Deployment, latency, and stale documents.
- A system-design sketch: clients, retrieval API, index, model, cache.
Basic questions
What is RAG? Retrieval-augmented generation fetches relevant text from an external store and puts it in the prompt so the model can answer from that text instead of only from its weights. The weights still write the sentences. They do not hold your handbook.
How does it work? Offline: load, clean, chunk, attach metadata, embed, store. Online: embed the question with the same model, search top-k, build a grounded prompt, generate, return citations. If retrieval misses, the generator should say it does not know.
Why RAG instead of fine-tuning? Fine-tuning changes weights. It is useful for style, format, or a stable skill. It is a poor database: it does not cite, it goes stale when the PDF changes, and retraining is slow. RAG updates when you re-index, keeps private data out of the training set, and can point at a page. Many systems use both: a model tuned to follow format, plus retrieval for facts. RAG does not require fine-tuning. Fine-tuning does not replace a current handbook.
Intermediate questions
What is an embedding? A fixed-length vector that places similar texts near each other. Cosine similarity is the dot product divided by the product of the lengths. On normalized vectors, cosine and dot product match. Name a model and its dimension (for example text-embedding-3-small at 1536, or bge-small at 384). Same model for index and query.
How do you chunk? Fixed windows, recursive splitting on paragraphs then sentences, semantic splits where meaning shifts, and overlap so a rule is not cut off its exception. Default: recursive, a few hundred to about a thousand tokens, overlap around 10 to 20 percent, metadata for source and section. Mention the footer bug.
Which vector database? Pick from constraints. FAISS is a fast library, not a database. Chroma is for prototypes. Qdrant is a strong self-hosted default with filters. Weaviate if hybrid search in one engine matters. Pinecone if you want it managed. Milvus if you need a large distributed cluster. pgvector if Postgres is already the system of record. Always say you store the text and filter on metadata.
How do you handle large documents? You do not paste them. You chunk, or you retrieve hierarchically: a chapter summary, then chunks inside that chapter. You keep k small enough that the prompt stays readable. You cite a page, not a filename alone.
How do you reduce hallucinations? Retrieve the right text, instruct the model to use only that text, demand citations, keep temperature low, and refuse when the context is empty. Re-ranking and filters make "the right text" more likely. Evaluation catches the cases where the model still wanders. Say clearly that RAG reduces hallucinations and does not delete them.
The rest of this guide is part of Pro
Free covers every fresher guide in full. Pro unlocks Senior, Staff and Architect guides across every track.
Still to come · 4 sections
- Advanced questions
- Code questions, as talking points
- A system-design sketch
- Final checklist
Test yourself
Answer these before moving on — recall is what makes it stick.