How would you design a production RAG pipeline end-to-end in 2025-26?
859 views
69 of 83
1
The problem
Question presented to candidate:
"Design the retrieval-augmented question answering system for our product: about two hundred thousand help-centre articles, contracts and internal docs, used by customers and support agents. Walk me from raw documents to a cited answer on screen, and tell me how you would know it is working."
What a strong answer should cover:
Two paths: an offline ingestion path (connectors, parsing, chunking with context, embedding, metadata and permissions, incremental updates by content hash, deletes, versioned indexes with blue-green re-indexing) and an online query path (query rewrite and routing, scoped hybrid retrieval with fusion, reranking, context packing under a token budget, generation with citations, abstain when nothing is relevant)
Back-of-envelope numbers stated as assumptions: chunk count, vector memory, embedding cost for a full build and daily changes, queries per second at peak, prompt tokens and generation cost per query, and a per-stage latency budget with streaming
Security and scope: tenant and permission filters built from the session, retrieved text treated as untrusted (prompt injection), caches and logs scoped the same way
Quality loop: a labelled eval set with retrieval metrics and answer-level checks (faithfulness, citation validity), traces of every stage per request, and regression runs before changing models, chunking or prompts
Current practice and its limits: hybrid search plus a reranker as the default retriever, contextual chunk headers, agentic or multi-step retrieval for hard questions, and long context windows as a complement to retrieval rather than a replacement
Clarifying questions expected:
Who are the users, what are the latency and freshness requirements, and how often do documents change?
Are there per-customer or per-document permissions, and can data be sent to external model APIs?
What does a good answer look like: short factual replies with citations, or long synthesized reports?
Code / implementation expected: Optional โ an architecture diagram with numbers is the core; a sketch of incremental ingestion or the query pipeline is a strong addition.
rag
architecture
retrieval
2
Try it yourself
Sketch your approach before you read the solution. That is what the interview tests.
Stuck? Get a hint.
A short nudge toward the approach. It will not give the answer away.
3
Solution
Target Audience: Engineers preparing for an AI or backend system design round who can explain RAG in one sentence and now need to design the whole thing: ingestion, retrieval, generation, numbers, operations and evaluation.
Difficulty: Hard
Verified with: Node 22.22.0 and Python 3.12.3 (the miniature pipeline and the sizing arithmetic below). Every input to the sizing is a stated assumption, and the prices in it are illustrative placeholders, not a vendor price list. Product facts are cited inline with the date checked (October 2026).
How to read this doc: Every idea is explained in plain language first, then tagged with ๐ Interview term: so you also learn the words an interviewer expects. All program output shown was produced by actually running the example; the Verified section quotes it in full.