Skip to main content

Retrieval-Augmented Generation (RAG): Architecture, Algorithms & Vector Systems

Target Audience: AI Systems Engineers, Data Platform Architects, and Software Engineers building production-grade enterprise knowledge retrieval systems.
Core Objective: Master the complete architectural, algorithmic, and mathematical mechanics of Retrieval-Augmented Generation (RAG)β€”from high-dimensional vector spaces and distance metrics to advanced chunking, HNSW graph indexing, hybrid search, cross-encoder re-ranking, and the RAGAS evaluation framework.


1. The Core Problem: Why LLMs Hallucinate​

Foundation Large Language Models (LLMs) are statistical text prediction engines. During pre-training, billions of parameters are adjusted to minimize next-token prediction loss over a massive, static training corpus. This architecture introduces two fundamental enterprise vulnerabilities:

  1. Parametric Knowledge Cutoff: An LLM's "memory" is entirely frozen inside its static neural network weights (parametric memory). It is completely blind to private corporate data, customer tickets, internal repositories, and any real-world events occurring after the training cutoff date.
  2. Stochastic Confabulation (Hallucination): When prompted for facts outside its training distribution, the model does not gracefully say "I don't know." Instead, it samples tokens that are syntactically and semantically plausible within the vector manifold, generating confident, well-phrased falsehoods.

Parametric vs. Non-Parametric Memory​

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ PARAMETRIC MEMORY (Model Weights) β”‚ β”‚ NON-PARAMETRIC MEMORY (Vector DB) β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ β€’ Stored in billions of neural weights β”‚ β”‚ β€’ Stored in external document databasesβ”‚
β”‚ β€’ Static; requires costly fine-tuning β”‚ β”‚ β€’ Dynamic; updated in real-time (ms) β”‚
β”‚ β€’ Fuzzy associative recall β”‚ β”‚ β€’ Exact semantic & keyword retrieval β”‚
β”‚ β€’ Prone to hallucinations & confabulationβ”‚ β”‚ β€’ Auditable with exact document citationsβ”‚
β”‚ β€’ Cannot guarantee data access control β”‚ β”‚ β€’ Strict Role-Based Access Control (RBAC)β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Retrieval-Augmented Generation (RAG) bridges this divide. Instead of asking the model to memorize the enterprise's entire knowledge corpus, RAG treats the LLM as an in-context reasoning engine and feeds it verified, freshly retrieved source documents at inference time.


2. The Comprehensive RAG Architecture: End-to-End Pipeline​

INGESTION PIPELINE (Offline / Batch)
+-------------------------+
| Raw Documents |
| (PDF, Markdown, HTML, |
| SQL, Confluence, Code) |
+------------+------------+
β”‚
β–Ό
+-------------------------+ +-------------------------+ +-------------------------+
| Document Parsing & | ───► | Chunking Engine | ───► | Dense Embedding Model |
| Cleaning (Text, Tables) | | (Recursive / Semantic) | | (nomic-embed, bge-large)|
+-------------------------+ +-------------------------+ +------------+------------+
β”‚
β–Ό Vectors (float32)
+-------------------------+
| Vector Database |
| - HNSW Graph Index |
| - Inverted Keyword Index|
| (Chroma, Qdrant, Milvus)|
+------------+------------+
β–²
INFERENCE PIPELINE (Online / Real-time) β”‚
+-------------------------+ β”‚
| User Query | β”‚
+------------+------------+ β”‚
β”‚ β”‚
β–Ό β”‚
+-------------------------+ β”‚
| Query Transformation | ───► Embed Query β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
| (HyDE / Multi-Query) | Vector Representation Top-K Semantic Matches
+-------------------------+ + Keyword BM25 Scores
β”‚
v
+-------------------------+
| Hybrid Fusion (RRF) |
| Combines Dense & Sparse |
+------------+------------+
β”‚
β–Ό Top-N Candidates
+-------------------------+
| Cross-Encoder Re-Ranker |
| (Token-level Attention) |
+------------+------------+
β”‚
β–Ό Top-K Reordered
+------------------------------------------------------------------------------+------------+
| Prompt Synthesizer & Context Assembler |
| "You are an expert system. Answer the query using ONLY the provided verified context. |
| If the answer cannot be deduced, explicitly reply that information is unavailable. |
| |
| [Context 1] (Source: internal_architecture.md#L42): ... |
| [Context 2] (Source: nvme_spec_v2.pdf#page=12): ... |
| |
| User Query: [Transformed User Query]" |
+------------------------------------------------------------------------------+------------+
β”‚
v
+-------------------------+
| Local Foundation LLM |
| (Ollama / Llama 3.2) |
+------------+------------+
β”‚
β–Ό
+-------------------------+
| Grounded Response with |
| Verifiable Citations |
+-------------------------+

3. Vector Embeddings: Semantic Topology in High-Dimensional Space​

What is an Embedding?​

An Embedding is a mathematical mapping of discrete, unstructured human concepts (words, paragraphs, entire technical specifications) into a continuous vector space RD\mathbb{R}^D, where DD represents the dimensionality (typically 384, 768, 1024, or 1536 dimensions).

Unlike traditional keyword hashing (which treats "SSD" and "Solid State Drive" as completely distinct strings), embedding models position semantically related phrases close to each other in Euclidean coordinate space:

Dimension 2 (Hardware vs Software)
β–²
β”‚ β€’ [0.82, 0.91, -0.12] "NVMe PCIe Gen5"
β”‚ β€’ [0.79, 0.88, -0.09] "Enterprise Solid State Drive"
β”‚ β€’ [0.65, 0.74, -0.15] "SAS Hard Disk Drive"
β”‚
β”‚
β”‚ β€’ [-0.42, -0.81, 0.92] "PostgreSQL Relational DB"
β”‚ β€’ [-0.38, -0.79, 0.88] "MySQL InnoDB Storage Engine"
β”‚
└────────────────────────────────────────────────────────► Dimension 1 (Storage vs DB)

Dense vs. Sparse Embeddings​

DimensionDense Embeddings (Neural)Sparse Embeddings (Lexical / BM25)
RepresentationLow-dimensional (384 to 1536 float32 numbers). Nearly all values are non-zero.Ultra-high dimensional (30,000+ dimensions). 99.9% of values are zero.
GenerationDeep neural transformers (e.g., nomic-embed-text, bge-large, text-embedding-3-large).Statistical word-frequency algorithms (TF-IDF, BM25, SPLADE).
StrengthsCaptures deep conceptual meaning, synonyms, cross-lingual concepts, and abstract intent.Infallible precision for exact keyword matches, SKU numbers, variable names, and error codes.
WeaknessesStruggles with rare acronyms, out-of-vocabulary product codes, and exact string literals.Completely blind to synonyms (e.g., fails to link "laptop" and "notebook").

4. Mathematical Vector Distance Metrics​

When a user submits a query vector q∈RD\mathbf{q} \in \mathbb{R}^D and the database evaluates candidate document chunks d∈RD\mathbf{d} \in \mathbb{R}^D, it computes a geometric distance metric to quantify semantic proximity:

1. Cosine Similarity​

Calculates the cosine of the angle ΞΈ\theta between the two vectors:

CosineΒ Similarity(q,d)=cos⁑(ΞΈ)=qβ‹…dβˆ₯qβˆ₯βˆ₯dβˆ₯=βˆ‘i=1Dqidiβˆ‘i=1Dqi2βˆ‘i=1Ddi2\text{Cosine Similarity}(\mathbf{q}, \mathbf{d}) = \cos(\theta) = \frac{\mathbf{q} \cdot \mathbf{d}}{\|\mathbf{q}\| \|\mathbf{d}\|} = \frac{\sum_{i=1}^D q_i d_i}{\sqrt{\sum_{i=1}^D q_i^2} \sqrt{\sum_{i=1}^D d_i^2}}
  • Range: [βˆ’1.0,1.0][-1.0, 1.0].
    • +1.0+1.0: Pointing in identical semantic directions.
    • 0.00.0: Orthogonal (statistically independent concepts).
    • βˆ’1.0-1.0: Diametrically opposed concepts.
  • Cosine Distance: 1.0βˆ’CosineΒ Similarity(q,d)1.0 - \text{Cosine Similarity}(\mathbf{q}, \mathbf{d}).
  • Key Advantage: Completely invariant to document length or vector magnitude; evaluates pure semantic orientation.

2. Euclidean Distance (L2L2 Norm)​

Calculates the straight-line physical geometric distance between two points in DD-dimensional coordinate space:

dL2(q,d)=βˆ₯qβˆ’dβˆ₯2=βˆ‘i=1D(qiβˆ’di)2d_{L2}(\mathbf{q}, \mathbf{d}) = \|\mathbf{q} - \mathbf{d}\|_2 = \sqrt{\sum_{i=1}^D (q_i - d_i)^2}
  • Range: [0.0,∞)[0.0, \infty). Smaller values represent higher similarity.
  • Relationship to Cosine: If vectors are pre-normalized to unit length (βˆ₯qβˆ₯=βˆ₯dβˆ₯=1\|\mathbf{q}\| = \|\mathbf{d}\| = 1), then:
dL22=2βˆ’2cos⁑(ΞΈ)d_{L2}^2 = 2 - 2\cos(\theta)

Under unit normalization, Euclidean Distance and Cosine Similarity yield identical ranking orders.

3. Dot Product (Inner Product / IP)​

qβ‹…d=βˆ‘i=1Dqidi\mathbf{q} \cdot \mathbf{d} = \sum_{i=1}^D q_i d_i
  • If vectors are normalized (βˆ₯vβˆ₯=1\|\mathbf{v}\| = 1), the dot product equals cosine similarity.
  • Hardware Efficiency: Executes with blistering speed on CPU AVX-512/NEON registers and GPU Tensor Cores via fused multiply-add (FMA) instructions.

5. Chunking Strategies: The Determinant of Retrieval Precision​

Chunking is the process of breaking monolithic documents into bite-sized textual segments. Naive chunking destroys RAG performance by either:

  • Severing sentences midway, leaving disjointed thoughts.
  • Creating chunks so large they dilute the embedding vector with unrelated concepts.
Document Text:
"ZFS uses Copy-on-Write. When data is modified, blocks are written to a new location.
The metadata tree is updated up to the uberblock, guaranteeing crash consistency."

Strategy 1: Fixed Chunking (Size=8 words, Overlap=2)
Chunk 1: ["ZFS", "uses", "Copy-on-Write.", "When", "data", "is", "modified,", "blocks"]
Chunk 2: ["modified,", "blocks", "are", "written", "to", "a", "new", "location."]
Result: Fragmented semantic structure; loss of the conceptual relationship to crash consistency!

Strategy 2: Recursive Character Chunking
Splits on structural boundaries: ["\n\n", "\n", ".", " "]
Result: Keeps paragraphs and logical sentences intact while respecting token ceilings.

The 4 Production Chunking Paradigms​

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ 1. FIXED-SIZE CHUNKING WITH OVERLAP β”‚
β”‚ Slices raw text every N characters or tokens with an M-token overlap. β”‚
β”‚ Best for: Unstructured, unformatted text streams. β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ 2. RECURSIVE CHARACTER CHUNKING β”‚
β”‚ Recursively tests split delimiters in descending order of semantic β”‚
β”‚ significance: Paragraphs (\n\n) -> Sentences (\n) -> Words ( ) -> Chars. β”‚
β”‚ Best for: Markdown, documentation, books, and articles. β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ 3. SEMANTIC BOUNDARY CHUNKING β”‚
β”‚ Computes embedding distance between sentence N and sentence N+1. When β”‚
β”‚ distance spikes above a threshold, a topic shift is detected, and a new β”‚
β”‚ chunk is created. β”‚
β”‚ Best for: Academic papers, legal transcripts, transcripts of meetings. β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ 4. PARENT-DOCUMENT (HIERARCHICAL) CHUNKING β”‚
β”‚ Generates small child chunks (e.g., 128 tokens) for hyper-accurate β”‚
β”‚ vector matching, but returns the associated parent section (1024 tokens) β”‚
β”‚ to the LLM for generation context. β”‚
β”‚ Best for: Technical manuals, API references, complex specifications. β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

6. Vector Database Indexing: HNSW vs. IVF​

Exact nearest-neighbor search (kk-NN) computes distance between the query vector and every single vector in the database. For 10 million vectors of 768 dimensions, a single query requires 7.68 billion floating-point multiplications, taking hundreds of milliseconds.

Production vector databases (Chroma, Qdrant, Milvus, Weaviate, pgvector) utilize Approximate Nearest Neighbor (ANN) indexing.

Hierarchical Navigable Small World (HNSW)​

HNSW is the gold standard graph-based ANN algorithm. It adapts the multi-layer concept of Skip Lists into high-dimensional geometric graphs:

Layer 2 (Express Route - Long Distances, Few Nodes)
[Node A] ─────────────────────────────────────────────────────────► [Node Z]
β”‚ β”‚
β–Ό β–Ό
Layer 1 (Regional Highway - Medium Distances)
[Node A] ──────────────► [Node F] ──────────────► [Node M] ─────────► [Node Z]
β”‚ β”‚ β”‚ β”‚
β–Ό β–Ό β–Ό β–Ό
Layer 0 (Local Surface Streets - Dense Multi-Connectivity, All Vectors)
[Node A] ──► [Node B] ──► [Node C] ──► [Node D] ──► [Node E] ──► ... ──► [Node Z]
  • Top Layer (Layer 2): Contains sparse nodes with wide-ranging connections. The search algorithm makes gigantic geometric leaps across vector space.
  • Intermediate Layers: Progressively denser graphs refine the search path toward the target cluster.
  • Bottom Layer (Layer 0): Contains every vector in the database with short, dense neighbor connections. Once the algorithm drops into Layer 0, it performs fine-grained local hill-climbing to find the nearest neighbors.
  • Algorithmic Complexity: Reduces search time from O(N)O(N) linear scan to O(log⁑N)O(\log N) logarithmic graph traversal, executing in sub-5 milliseconds.

Inverted File Index (IVF) & Product Quantization (PQ)​

  • IVF (Inverted File Index): Clusters the vector space into KK Voronoi cells using kk-means. Queries calculate distances only to the nearest cluster centroids, ignoring 95% of vectors.
  • Product Quantization (PQ): Compresses 768-dimensional float32 vectors (3,072 bytes each) into compact 8-byte codes by splitting vectors into sub-vectors and mapping them to quantized codebook centroids, slashing RAM consumption by 95%95\%.

7. Advanced Retrieval: Hybrid Search & Reciprocal Rank Fusion (RRF)​

Dense embeddings alone fail when users search for specific error codes (e.g., ORA-01034), exact file paths (/etc/fio/nvme.fio), or hardware serial numbers.

Hybrid Search queries both a Dense Vector Index (HNSW) and a Sparse Lexical Index (BM25) in parallel, then combines the disparate score distributions using Reciprocal Rank Fusion (RRF):

Query: "Fix nvme0n1 controller timeout error 0x4"
β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β–Ό β–Ό
[Dense HNSW Vector Search] [Sparse BM25 Keyword Search]
Captures: "drive stall reset" Captures: exact "0x4", "nvme0n1"
Rank 1: Doc C (Score 0.88) Rank 1: Doc A (Score 18.4)
Rank 2: Doc A (Score 0.84) Rank 2: Doc B (Score 12.1)
Rank 3: Doc D (Score 0.79) Rank 3: Doc C (Score 9.3)
β”‚ β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
β”‚
β–Ό
[Reciprocal Rank Fusion (RRF)]
RRF Score = 1 / (60 + Rank_Dense) + 1 / (60 + Rank_Sparse)
β”‚
β–Ό Combined Top Results:
Doc A: 1/(60+2) + 1/(60+1) = 0.0161 + 0.0163 = 0.0324 (WINNER!)
Doc C: 1/(60+1) + 1/(60+3) = 0.0163 + 0.0158 = 0.0321

The RRF Formula​

RRFΒ Score(d)=βˆ‘m∈M1k+rm(d)\text{RRF Score}(d) = \sum_{m \in M} \frac{1}{k + r_m(d)}
  • MM: The set of retrieval systems (Dense Vector, BM25, Splade).
  • rm(d)r_m(d): The ordinal rank of document dd in system mm (1-indexed).
  • kk: Smoothing constant (typically k=60k=60) to prevent top-ranked documents from completely overpowering the list.

8. Cross-Encoder Re-Ranking: Beyond Bi-Encoders​

Standard vector search uses a Bi-Encoder architecture: query and document are embedded completely independently into separate vectors. The model cannot compute attention between query words and document words:

Bi-Encoder (Fast, Approximate Retrieval):
Query: "NVMe queue depth" ──► [Encoder] ──► Vector Q ──┐
β”œβ”€β”€β–Ί Cosine Similarity (Fast!)
Doc: "IO depth sets..." ──► [Encoder] ──► Vector D β”€β”€β”˜

A Cross-Encoder Re-Ranker accepts the Query and Candidate Document concatenated together in a single sequence:

Cross-Encoder (Deep, High-Precision Re-Ranking):
[CLS] Query: "NVMe queue depth" [SEP] Doc: "IO depth sets..." [SEP]
β”‚
β–Ό Full Multi-Head Self-Attention
[Transformer Neural Network]
β”‚
β–Ό
Relevancy Probability: 0.964

Every word in the query directly attends to every word in the document. This captures nuanced grammatical negations, conditional clauses, and fine-grained relevance that vector dot products miss.

Production Architecture:

  1. Retrieve: Fetch top-50 candidates via fast HNSW Hybrid Search (<10Β ms<10\text{ ms}).
  2. Re-rank: Pass top-50 candidates through a Cross-Encoder (e.g., bge-reranker-large) to select the top-5 truly relevant chunks (<30Β ms<30\text{ ms}).
  3. Generate: Pass top-5 chunks to the LLM.

9. Query Transformation & Expansion Techniques​

Users often write vague, underspecified, or multi-part queries that fail vector similarity searches. Modern RAG systems pre-process queries before retrieval:

1. HyDE (Hypothetical Document Embeddings)​

  • Concept: Instead of embedding the user's short, question-form query, the system instructs an LLM to generate a hypothetical ideal answer.
  • Even if the hypothetical answer contains factual inaccuracies, its vector embedding resides in the exact manifold of genuine technical documentation, yielding significantly higher vector retrieval recall!
User Query: "How to tune Linux dirty pages for high write workloads?"
β”‚
β–Ό
[LLM Generates Hypothetical Doc]:
"To tune Linux dirty page writeback, modify /proc/sys/vm/dirty_background_ratio
and vm.dirty_ratio to prevent I/O stalls..."
β”‚
β–Ό
[Embed Hypothetical Doc] ──► Dense Vector Search ──► Matches Real Runbook Chunks!

2. Sub-Query Decomposition​

Breaks complex multi-part questions (e.g., "Compare Ceph BlueStore write latency with ZFS ZIL write latency") into independent sub-queries:

  • Sub-query 1: "Ceph BlueStore write path latency architecture"
  • Sub-query 2: "ZFS ZIL SLOG write path latency architecture" Retrieves documents for both sub-queries independently and merges context.

10. Evaluating RAG Systems: The RAGAS Framework​

How do you know if your RAG pipeline is working effectively? Enterprise systems evaluate RAG across four orthogonal metrics (The RAG Triad):

+-------------------+
| User Query |
+---------+---------+
β”‚
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ β”‚
β–Ό β–Ό
+-----------------------+ +-----------------------+
β”‚ Retrieved Context β”‚ ◄───► β”‚ Generated Response β”‚
+-----------------------+ +-----------------------+
β–² β–²
β”‚ β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
β”‚
Evaluation: The RAG Triad
  1. Context Relevance: Did the retrieval engine pull chunks relevant to the user's query, or is the context filled with extraneous noise?
  2. Faithfulness (Groundedness): Can every single claim made in the generated answer be mathematically traced back to the retrieved context chunks? (Detects hallucination).
  3. Answer Relevance: Did the model actually answer the user's specific question, or did it deflect into unrelated tangents?
  4. Context Recall: Did the retrieval system find all the necessary facts required to answer the prompt completely?