🔍 RAG Pipeline Testing

RAG Pipeline Testing: Testing a RAG pipeline is grading a research paper, not fact-checking a single sentence — and the mechanism matches one-to-one, not loosely: a reviewer does

Testing a RAG pipeline is grading a research paper, not fact-checking a single sentence — and the mechanism matches one-to-one, not loosely: a reviewer does not just ask "is this conclusion true?", they ask three separate questions that can each fail independently — were the RIGHT sources cited (retrieval), does each CLAIM actually trace back to a cited source (grounding/faithfulness), and does the paper actually ANSWER the research question (relevance)? A brilliant, well-written paper that cites the wrong sources fails just as hard as a sloppy one that cites the right sources but draws unsupported conclusions from them. Here is the question worth sitting on: your RAG chatbot retrieved the correct policy document AND its answer sounds completely confident — so why isn't a single "does the answer look right?" check enough? Because a model can retrieve the perfect context and still invent a detail that was never in it — the retrieval succeeding tells you nothing about whether the GENERATION step stayed faithful to what it was given, which is exactly the gap between the previous tab's "prompt vs RAG vs fine-tune" decision and this one: choosing RAG only solves WHERE the model gets facts from, not whether it actually uses them correctly. Java comparison: this is not one assertTrue(response.contains(expected)) — it is three independent assertions, like assertSourceMatches(), assertClaimsAreGrounded() and assertAnswersQuestion(), each catching a failure the others would miss. The QA stake: a RAG-powered support bot that hallucinates a wrong refund window is worse than one that says "I don't know" — measuring grounding separately from relevance is how you catch a fluent-sounding, confident, and completely wrong answer before a customer does, which is the exact mechanism you exercised in the Token Lab's orange low-probability path, now applied to a real business document.

Three Independent Failure Points

A RAG pipeline has three stages, and each one can fail on its own: (1) Retrieval — did the system fetch the passage that actually contains the answer, out of everything in the knowledge base? (2) Grounding / Faithfulness — does every concrete claim in the generated answer trace back to something actually present in the retrieved context, or did the model add details that were never there? (3) Relevance — does the answer actually address the user's question, independent of whether it's grounded? A model can be perfectly grounded (every word traceable to the source) while being irrelevant (answering a different question than the one asked), and it can be relevant and fluent while being completely ungrounded (a confident hallucination). RAGAS and similar evaluation frameworks score these as separate numbers for exactly this reason — collapsing them into one "quality" score hides which stage actually broke.

🎬 RAG Pipeline: The Journey of a Query

The user asks: "How many days is the return window?" — the query enters the pipeline. The model does NOT know this by heart; it will have to fetch the fact from a company document.

Step 1 — Embed: the query is converted into an array of numbers (a vector) by the embedding model. Semantically similar texts produce similar vectors.

Step 2 — Retrieve: the vector is searched in the vector store; the passages semantically closest to the query are found. If the wrong passage comes back, the rest of the chain cannot save the answer.

Retrieval succeeded: the correct policy passage was found — "Returns are accepted within 14 days." But note: this is NOT the end of the journey; whether the model will stay faithful to it is still unknown.

Step 3 — Augment: the retrieved passage + the user's question are merged into a single prompt. The instruction "answer based ONLY on this context" is also injected here.

Step 4 — Generate: the LLM produces the answer from the context in the prompt: "Your return window is 14 days." The fact in the context was rephrased for the user — a happy ending... so far.

Final scene — same pipeline, different run: retrieval worked correctly AGAIN, but this time the model invented a detail that is nowhere in the context: "same-day refund". Successful retrieval does not guarantee grounding — which is exactly why RAG testing measures retrieval, grounding and relevance SEPARATELY (you will try it yourself in the lab below).

Below, the same return-policy knowledge base is used to answer the same question with two candidate answers — one grounded, one that quietly invents extra policy details. Run the analysis on both and watch which of the three rings drops: the grounded answer scores high on all three; the hallucinated one keeps a reasonable relevance score (it is still "about" the right topic) while grounding and faithfulness collapse, because the invented details (a longer window, a same-day refund, a policy exception) simply are not in the source text — the same mechanism as the Judge Playground's "vague report", but applied to an entire generated paragraph checked against a document instead of a rubric of testable properties.

Step by Step: The Three Layers of a RAG Pipeline

The most relevant document chunks are SEARCHED for in a vector database, based on the user's question.