Lesson 14 built the RAG pipeline: chunking, indexing, and a two-stage retrieval pattern designed to find the right passage fast. None of that guarantees the system actually works. A perfectly retrieved passage can still get ignored by the model reading it, and the retrieval step itself can miss the right document entirely, for reasons that have nothing to do with how well the index was built.
A RAG system can retrieve the exact right passage and still generate a wrong answer, because retrieval and generation are two separate failure surfaces, and fixing one does nothing to fix the other.
This lesson covers three structural retrieval failure modes with a full worked example of how a document gets split so that the right fact is technically retrieved but never used, the RAGTruth taxonomy for classifying hallucinations that survive retrieval, the OWASP-documented security risks specific to storing knowledge in a vector index, and the traditional and reference-free metrics used to measure retrieval and generation quality separately.
Section 01Three ways retrieval fails
Even with careful chunking and a well-tuned index, RAG pipelines remain vulnerable to three distinct structural failure patterns.
Irrelevant chunks retrieved, or noise injection. The vector index returns passages that score highly on cosine similarity, meaning they share general domain vocabulary with the query, but do not actually contain the specific facts the query needs. Injecting these passages into the prompt does not just fail to help. It actively burns context-window space, covered in Lesson 11, and adds noise the model has to reason around.
Relevant chunk missed entirely, or a retrieval miss. The document containing the actual answer never makes it into the top-K retrieved list at all. This happens for several reasons: a vocabulary mismatch between how the query is phrased and how the source document is phrased, a semantic compression limit in the bi-encoder itself, covered in Lesson 14, or a chunking decision that split a single, critical premise across two separate chunks, neither of which reads as strongly relevant on its own.
Context truncation and middle-loss degradation. Even when the right chunk is successfully retrieved and placed into the prompt, the model may still fail to use it. Liu et al. (2023) documented the “lost in the middle” phenomenon: models reliably use information placed at the very beginning or very end of a long context prompt, but accuracy on facts placed in the middle third of that context drops sharply. Retrieval can succeed completely and generation can still fail, purely because of where in the prompt the retrieved passage happened to land.
A worked example: how a fact gets lost across two of these failure modes at once
Take an enterprise technical support system handling a query about database connection limits.
Raw source text: “Database Cluster Type A supports up to 10,000 concurrent connections under standard operational load. However, when the cluster configuration is modified to enable Automated Replication Mode, the maximum allowable concurrent connection limit drops strictly to 2,500 connections to preserve cross-region consensus latency.”
Chunking failure. The pipeline splits this document at exactly 512 tokens, landing the split boundary right between the two sentences:
- Chunk 1: “Database Cluster Type A supports up to 10,000 concurrent connections under standard operational load.”
- Chunk 2: “However, when the cluster configuration is modified to enable Automated Replication Mode, the maximum allowable concurrent connection limit drops strictly to 2,500 connections...”
Query: “What is the maximum connection limit for Cluster Type A when running with Automated Replication Mode enabled?”
Retrieval outcome. The bi-encoder retrieves Chunk 1 at rank 1, because it shares high vector similarity with “Cluster Type A” and “connection limit,” the general vocabulary of the query. It retrieves Chunk 2, which actually contains the correct answer, at rank 7, placing it in the middle of a 10-document context.
Generation outcome. The model reads Chunk 1 at the top of the prompt and effectively ignores Chunk 2, buried in the middle, exactly where Liu et al.’s middle-loss effect predicts accuracy will drop. It generates: “The maximum connection limit for Database Cluster Type A is 10,000 concurrent connections,” missing the Automated Replication Mode qualifier entirely.
Root cause. Two separate failures compounded: a chunking decision split a single fact across a boundary in a way that made the second, more specific half score lower on retrieval, and the middle-loss effect meant that even successfully retrieving that second half at rank 7 was not enough to guarantee the model actually used it.
Section 02RAGTruth: classifying what still gets through
Niu et al. (2024) built RAGTruth, a benchmark of nearly 18,000 manually annotated LLM responses across question answering, summarization, and data extraction tasks, specifically to quantify hallucination inside RAG systems, not just in unaugmented generation. RAGTruth splits RAG hallucination into four structural categories.
- Evident conflict. The generated output directly contradicts a fact explicitly stated in the retrieved context. This is intrinsic hallucination, in the taxonomy from Lesson 13, made concrete inside a RAG pipeline specifically.
- Subtle conflict. The output makes a small term substitution or introduces a logical nuance that quietly changes the retrieved context’s original technical meaning, without an outright, obvious contradiction.
- Evident baseless information. The output presents a fact or entity with zero grounding anywhere in the retrieved context, a fabrication with no anchor at all.
- Subtle baseless information. The output makes an inference or extrapolation that sounds plausible and consistent with the retrieved context, but cannot actually be verified from it.
RAGTruth’s empirical findings confirm what Lesson 13’s RAG numbers already suggested and add a sharper edge to them: RAG substantially reduces hallucination relative to unaugmented generation, but the rate does not go to zero, and it varies by task complexity. On complex summarization and multi-document question answering specifically, hallucination persists even when the retrieved context genuinely contains the correct source information. The failure mode has shifted. It is no longer primarily about the model lacking the right fact in its parametric memory. It is about context-inconsistency: the model has the right passage sitting in front of it and still fails to adhere strictly to it during generation.
Section 03Security risks specific to a vector index
Storing knowledge outside the model’s weights, in a searchable vector database, solves the update and provenance problems from Lesson 14, but it also creates an entirely new attack surface that a purely parametric model does not have. The OWASP GenAI Security Project formally designates this under category LLM08:2025, Vector and Embedding Weaknesses, in the OWASP Top 10 for LLM Applications.
Vector inversion attacks. An attacker who gains read access to raw embedding vectors can run a vector-inversion neural network against them to reconstruct the original plaintext with high fidelity. This directly undermines a common but incorrect assumption: that storing sensitive data, personally identifiable information, medical records, credentials, purely as embeddings is safe because embeddings are supposedly irreversible. They are not, reliably.
Embedding poisoning, an indirect prompt injection vector. An attacker inserts a malicious document into a public or shared knowledge base, engineered so its embedding lands with deliberately high similarity to expected user queries. When a legitimate user runs a RAG query that happens to match, the poisoned passage gets retrieved and inserted directly into the model’s context, where it can carry an indirect prompt injection payload, hijacking the model’s downstream behavior to exfiltrate data or trigger unauthorized actions.
Cross-tenant vector access. Traditional relational databases enforce row-level security to keep one tenant’s data separate from another’s. Standard vector databases, indexing multiple tenants’ data into one shared, flat ANN graph structure such as HNSW, do not have that same native isolation boundary. Without explicit pre-filtering or post-filtering access control layered on top of the vector search itself, a retrieval query can return document chunks belonging to a different tenant, or a user with a different permission tier, entirely.
(Vector database product security features and specific implementation details change quickly; treat the general risk categories here as durable, and any specific product claim as a dated snapshot to verify independently.)
Section 04Measuring a RAG system: retrieval metrics and reference-free generation metrics
Evaluating a RAG system means measuring two genuinely separate components: how good the retrieval step is, and how good the generation step is, given whatever retrieval actually handed it.
Traditional information retrieval metrics
These require a labeled ground-truth set of which documents are actually relevant to a given query.
Precision@k measures what fraction of the top-k retrieved chunks are actually relevant:
Recall@k measures what fraction of all the relevant chunks that exist anywhere in the corpus were successfully captured within the top-k results:
Mean Reciprocal Rank (MRR) evaluates how quickly the system surfaces the first relevant chunk, averaged across a set of queries Q:
rankᵢ is the position of the highest-ranked relevant chunk for query i. A system that reliably places the correct chunk at rank 1 scores close to 1.0; a system that only manages rank 10 on average scores close to 0.1.
RAGAS: evaluating generation without a human-labeled reference answer
In production, a human-annotated ground-truth answer is rarely available for every real user query. Es et al. (2023) introduced RAGAS (Retrieval Augmented Generation Assessment) specifically to enable automated, reference-free evaluation, using an LLM itself as the evaluator, prompted to check specific, narrow properties rather than to judge overall quality.
Faithfulness measures how strictly the generated answer a(q) is grounded in the retrieved context c(q), directly targeting hallucination. It runs in three steps: an LLM decomposes the generated answer into a set of discrete factual statements, S(a(q)) = {s₁, s₂, ..., sₙ}; for each statement sᵢ, the LLM judges whether it can be logically inferred from the retrieved context, producing a binary verdict v(sᵢ) ∈ {0, 1}; and the final score is the fraction of statements that were verified as supported:
Answer Relevance measures whether the generated answer actually addresses the user’s original query q, independent of whether the answer is factually accurate. It works by reverse-engineering the process: an LLM generates n candidate questions {q₁, ..., qₙ} that the given answer would plausibly be responding to, an embedding model (the same mechanism from Lesson 7) maps both the original query and every generated candidate question into vector space, and the score is the mean cosine similarity between the original query’s embedding and each generated question’s embedding:
A low score here catches evasive, incomplete, or off-topic answers, even ones that are individually faithful to the retrieved context.
Context Relevance measures the quality of the retrieved context itself, penalizing chunks that are redundant or irrelevant to the query, independent of what the generator eventually does with them. An LLM extracts the subset of sentences from the retrieved context, Srelevant, that are actually essential to answering the query, and the score is the proportion those relevant sentences make up of the full retrieved context:
| Metric | Evaluates | Failure it catches |
|---|---|---|
| Precision@k | Retrieval | Excessive noise or a similarity threshold set too loosely |
| Recall@k | Retrieval | Retrieval depth too shallow; a real embedding compression limit |
| MRR | Retrieval ranking | Poor ranking order; missing a reranking stage |
| Faithfulness (RAGAS) | Generation grounding | Hallucination; the model drifting from the retrieved context |
| Answer Relevance (RAGAS) | Generation quality | Evasive, incomplete, or off-topic answers |
| Context Relevance (RAGAS) | Retrieval precision | Chunk sizes too large; context window pollution |
Conclusion
Every failure mode in this lesson traces back to the same structural fact: RAG has two separate stages, and a passing result on one tells you nothing about the other. A chunk boundary can technically retrieve the right document while still splitting the actual fact in half, exactly what the worked example in Section 1 showed. A model can have the correct passage sitting directly in its context and still fail to use it, because of where in that context the passage happened to land. And storing knowledge outside the model’s weights, the very design choice that fixes the staleness and provenance problems from Lesson 14, opens an entirely new attack surface that a purely parametric model never had to defend. RAGAS’s three metrics exist precisely because retrieval quality and generation quality have to be measured as genuinely separate things: a system can score well on Context Relevance and poorly on Faithfulness, or the reverse, and only measuring one would hide exactly where the system is actually breaking.
The next lesson moves from retrieving text to calling a model programmatically: the actual shape of an API request, how sampling parameters like temperature control what gets generated, and what streaming does and does not change about the underlying compute.