← All Blogs
AI/ML · System Design

Building a Production RAG Pipeline for Document-Heavy Domains

A 9-step architecture that turns thousands of unstructured documents — legal, medical, financial, compliance, or technical — into reliable, grounded answers.

Mudit Kumar
Mudit Kumar · 6 min read

The Problem: Every Industry Has It

Healthcare systems have 10,000+ clinical protocols. Law firms manage 50,000+ case documents. Banks maintain thousands of compliance policies across geographies. Insurance companies handle hundreds of underwriting guidelines that change quarterly.

The pattern is universal: organizations accumulate thousands of documents authored by different teams, at different times, with overlapping and sometimes contradictory information. Then someone asks a simple question — and the answer is buried across 5 documents, 3 of which disagree.

Vanilla RAG (search → stuff → generate) breaks spectacularly at this scale. This article presents a 9-step production pipeline that works across any document-heavy domain.

Whether it's legal contracts, medical literature, compliance policies, or technical documentation — the architecture is the same. Only the documents change.

End-to-End Architecture

END-TO-END RAG PIPELINE — DOMAIN AGNOSTIC User Query ① Cache Check (hash+semantic) HIT → Return ② Intent + Scope Classify → type: factual|procedural → scope: policy|both|ref_only ③ Multi-Path Parallel Search QA Pairs Doc Summary Section Vec Chunk Vec Tier Filter ④ RRF Merge (tiered) ⑤ Link Expansion ⑥ Conflict Check (pre-computed table) ⑦ LLM Rerank (tier+conflict aware) ⑧ Structured Answer Generation [Authority] → [Supporting] → [Conflicts] ⑨ Quality + Grounding Check fallback if <0.70 Grounded Answer + Citations
Fig 1: Complete 9-step RAG pipeline — applicable to legal, medical, financial, compliance, and technical domains

The 9 Steps Explained

STEP 1

Cache Check

Hash + semantic match (cosine ≥ 0.92). Context-aware keying by user role/region. Catches 20–40% of repeat queries instantly.

STEP 2

Intent Classification

Lightweight LLM classifies query type (factual/procedural/comparative) and determines search scope across document tiers.

STEP 3

Multi-Path Search

5 parallel paths: Q&A pairs, document summaries, section vectors, chunk vectors, tier-filtered. Each excels at different query types.

STEP 4

Tiered RRF Merge

Reciprocal Rank Fusion with authority weights: primary docs 1.0x, linked references 0.8x, unlinked 0.6x. Dedup at 80% overlap.

STEP 5

Link Expansion

Pre-built document link graph surfaces referenced material that search missed. Single SQL lookup (~5ms).

STEP 6

Conflict Check

Lookup pre-computed conflict table. Annotate which passages are authoritative when contradictions exist. ~10ms.

STEP 7

LLM Reranking

Top 15 → Top 5–7. Tier-aware, conflict-aware scoring. Produces focused, non-contradictory context window.

STEP 8

Structured Generation

Context fed as [Authoritative] → [Supporting] → [Conflicts]. Every claim traced to a source passage.

STEP 9

Quality Fallback

If quality < 0.70 → re-search with broader scope → re-generate. Self-correcting loop. Fires on <5% of queries.

Where This Applies

This architecture is domain-agnostic. It works anywhere you have:

The common thread: thousands of documents, multiple authors, overlapping topics, periodic updates, and users who need one correct answer fast.

Performance at Scale

Cache hit:             ~50ms   (instant)
Intent + search:       ~600ms  (parallel paths)
Merge + expand:        ~25ms   (in-memory + SQL)
Conflict check:        ~10ms   (indexed lookup)
LLM reranking:         ~800ms  (top-15 passages)
Answer generation:     ~1500ms (structured prompt)
Quality check:         ~300ms  (scoring pass)
────────────────────────────────────────────
Total (uncached):      ~3.3s p95
Total (cached):        ~50ms
Key insight: Each step is deliberately ordered to maximize accuracy while minimizing cost. Cache is free. Intent is one cheap call. Search is parallelized. Only the final 2 steps need expensive LLM calls — and they receive clean, conflict-free context.

Takeaway

Production RAG is not "search + generate." It's a layered intelligence system where each stage refines signal: CacheRouteSearchRankValidateGenerateSelf-correct.

The documents change. The architecture doesn't.

RAGLLMSystem DesignSearchAI ArchitectureDocument Intelligence
© 2026 Mudit Kumar. All content is intellectual property of the author. Unauthorized reproduction prohibited.