Skip to content
← All field notes

Building Reliable RAG Systems

Design patterns, evaluation strategies, and latency tips for production RAG.

Karan Bista4 min read
RAGLLMsVector DB

Retrieval-Augmented Generation (RAG) pairs a parametric model with a non-parametric datastore. The model supplies fluency and reasoning; the datastore supplies facts you can update without retraining anything. That split is the whole appeal — and the whole difficulty, because now two systems have to be right at once.

Patterns that survive production

Chunking with semantic overlap. Fixed-size splits cut sentences in half and strand the antecedent of every pronoun. Chunk on structure first (headings, sections, list boundaries), then pad with overlap so a retrieved chunk carries enough context to stand alone.

Query rewriting and expansion. Users do not write queries that look like documents. A cheap rewrite pass — resolve pronouns against conversation history, expand acronyms, generate two or three paraphrases — usually buys more recall than swapping embedding models.

Hybrid search. Dense retrieval understands meaning and misses exact identifiers. Sparse retrieval (BM25) nails error codes, SKUs, and function names and misses paraphrase. Run both, fuse the rankings. This is the single highest-leverage change in most systems.

Reranking for precision. Retrieve broadly, then rerank the top 50 with a cross-encoder and keep 5. Bi-encoders are built for speed at index time; cross-encoders are built for judgment at query time. Use each where it is strong.

Measure the thing you actually care about

Retrieval quality and answer quality are separate metrics and they fail separately. Track them separately:

  • Retrieval: hit-rate@k and MRR against a labeled set of question → gold-passage pairs.
  • Generation: exact match or semantic similarity for closed questions; faithfulness (is every claim supported by a retrieved chunk?) for open ones.

A build can lose 10 points of faithfulness while retrieval metrics hold steady. Without the split you will spend a week tuning the retriever for a generator regression.

Observability and guardrails

Log latency by stage (embed, search, rerank, generate), retrieval hit-rate, and hallucination flags — per query, not just in aggregate. P50 hides everything interesting; watch P95.

Then constrain the surface: keep prompts templated rather than concatenated, cap the context you will pass, and make the model cite the chunk it used. A system that says "I don't have that" is far more useful than one that improvises, and citations turn every answer into something a user can verify themselves.

Share ↗

// Transmissions

Comments

0/2000 · no account, no tracking