DL0084 RAG: Retrieval-Augmented Generation

What is RAG (retrieval-augmented generation), and describe the components of a RAG pipeline?

Answer

Retrieval-augmented generation conditions a frozen language model on text fetched at query time from an external corpus, so the answer is grounded in documents the model never memorized. Nothing about the weights changes: the retriever supplies evidence, the prompt carries it, and the decoder writes an answer that should be traceable to that evidence. This buys three things a fine-tuned model cannot easily give you, namely freshness (reindex a document and the next query sees it), attribution (each claim can cite a chunk ID), and access control (metadata filters keep a user out of documents they may not read). A practical pipeline has an offline half and an online half: the offline half runs chunk → embed → index, and the online half runs retrieve → rerank → assemble prompt → generate. The parts that decide whether the system works in production are rarely the LLM; they are the chunking policy, the hybrid retrieval that combines dense and lexical matching, and the cross-encoder reranker that decides which five of fifty candidates actually reach the context window.

(1) Ingestion and Chunking: parse the source into text, then split it into passages of roughly 400 to 800 tokens with modest overlap, attaching metadata (document ID, section, timestamp, ACL tags) that later powers filtering and citation.
(2) Embedding and Indexing: a bi-encoder maps each chunk to a fixed vector stored in an ANN index (HNSW or IVF-PQ) alongside a sparse BM25 or SPLADE index, because dense and lexical retrieval fail on different queries.
(3) Query Processing and Retrieval: the query is optionally rewritten (decontextualized against chat history, expanded, or decomposed for multi-hop), encoded once, and used to pull a wide candidate set of 30 to 100 chunks from both indexes, fused by reciprocal rank fusion.
(4) Reranking and Context Assembly: a cross-encoder scores each query-chunk pair jointly and keeps the top 3 to 8, which are deduplicated, ordered, and packed into the prompt with instructions to answer only from the provided context and to cite chunk IDs.
(5) Generation, Evaluation, and Guardrails: the LLM generates a grounded answer, and an offline harness tracks retrieval recall@k separately from answer faithfulness, since a wrong answer with perfect retrieval and a right answer with broken retrieval demand opposite fixes.

Two-row diagram: the offline row runs corpus to chunker to embedding model to a hybrid index of HNSW vectors plus BM25 postings; the online row runs user query to rewrite and encode to hybrid retrieval of top-50 candidates to a cross-encoder rerank to top-5 to prompt assembly to LLM answer with citations, with a dashed arrow from the index down to the retrieval stage

Figure 1: The offline half builds a hybrid index once per document revision; the online half spends its latency budget on retrieval, reranking, and decoding, and only the reranked top-5 chunks ever enter the context window.

Most RAG failures are retrieval failures, so it helps to measure each stage separately. A useful decomposition is recall@50 for the first-stage retriever (did the answer-bearing chunk survive at all?) and recall@5 after reranking (did it reach the prompt?). Dense bi-encoders miss exact identifiers such as error codes, part numbers, and rare acronyms, which BM25 handles trivially; BM25 misses paraphrases, which the bi-encoder handles. Fusing the two lists and then letting a cross-encoder read query and chunk together typically removes a large share of the remaining misses, at the cost of one extra model call over 50 pairs, which is why the reranker runs on the shortlist and never on the corpus.

Bar chart of top-20 retrieval failure rate for five configurations: BM25 only at 9.2 percent, dense only at 5.7 percent, hybrid fusion at 4.5 percent, hybrid plus reranker at 3.2 percent, and contextual chunk embeddings plus hybrid plus reranker at 2.4 percent

Figure 2: Illustrative stage-by-stage gains: hybrid fusion fixes the queries dense retrieval alone drops, and the cross-encoder reranker plus context-aware chunk embeddings cut the residual failure rate further.

Mathematical Formulation:
s(q,c) = \frac{e_q^{\top} e_c}{\|e_q\|\,\|e_c\|}
\mathcal{R}_k(q) = \text{top-}k\{\, s(q,c) : c \in \mathcal{D} \,\}
\mathrm{RRF}(c) = \sum_{r=1}^{R} \frac{1}{K + \mathrm{rank}_r(c)}
p(y \mid q) = \prod_{t=1}^{T} p_\theta(y_t \mid y_{1:t-1}, q, \mathcal{R}_k(q))

Where:

  • s(q,c) is the cosine similarity between the query embedding e_q and the chunk embedding e_c, both produced by the same bi-encoder.
  • \mathcal{D} = \{c_1,\ldots,c_M\} is the chunked corpus with M passages, and \mathcal{R}_k(q) is the retrieved set of size k that the prompt will carry.
  • \mathrm{RRF}(c) fuses R ranked lists (dense, lexical, and any filtered variants); \mathrm{rank}_r(c) is the position of chunk c in list r, and the constant K \approx 60 damps the influence of top ranks so one confident list cannot dominate.
  • p_\theta is the frozen decoder, y_t the token at step t of a T-token answer; the retrieved set enters only as prompt context, so \theta is never updated by indexing new documents.
  • In practice the ANN index returns an approximate \mathcal{R}_k: HNSW recall is tuned by the search-width parameter, and quantized indexes trade a small recall loss for roughly 4\times to 8\times less memory.
DimensionRAGFine-tuningLong-Context Stuffing
Best forLarge, changing, permissioned corporaStyle, format, task behavior, domain jargonSmall corpora that fit in one window
Update costReindex the changed chunks, secondsA new training run per refreshNone, but every request pays for the tokens
AttributionNative: cite the retrieved chunk IDNone, facts are diffused into weightsPossible, but no ranking signal to audit
Main failure modeRetriever misses the answer-bearing chunkConfident stale answers, catastrophic forgettingLost-in-the-middle, cost and latency growth
Serving complexityHigh: index, retriever, reranker, eval harnessLow at serve time, high at train timeLow, especially with prompt caching

Login to view more content


Log in to track your progress

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *