RAG Evaluation: Measuring Retrieval and Generation Quality

Anyone building a Retrieval-Augmented Generation (RAG) system quickly makes a painful discovery: manually typing in a few test questions and checking if the answer "looks good" does not scale. To reliably deploy a RAG application to production, you need a robust evaluation strategy. In doing so, it is essential to understand that a RAG system is not a single monolithic piece of AI magic, but consists of two strictly separated pillars: retrieving the correct information (retrieval) and formulating a correct answer (generation).

In this article, we dissect how to systematically evaluate a RAG system. We look at concepts such as precision, recall, groundedness, and the dangers of a model giving the right answer for the wrong reasons. We assume that you already have a working RAG pipeline and are familiar with concepts such as vector databases and chunking, or have basic knowledge through sources like our guide on RAG for beginners.

Why Evaluating Only the Final Answer Fails

Many developers start with end-to-end testing: a question goes into the application, an answer comes out, and they evaluate that final result. However, this method hides where the pipeline actually breaks down when an error is made.

Suppose a user asks an internal HR chatbot: "How many vacation days do I get as a part-timer?" The system gives an incorrect answer. What is the cause? There are roughly three possibilities:

  • The search engine fails: The vector database could not find the HR manual about part-timers (Retrieval problem).
  • The context is too large or cluttered: The correct manual was retrieved, but it was hidden in five pages of irrelevant text, causing the language model to lose its way (Retrieval/Chunking problem).
  • The language model hallucinates: The correct text was perfectly provided, but the model misunderstood the calculation or decided to use its own general knowledge about vacation days in the Netherlands (Generation problem).

If you only measure the final answer, you do not know which knobs to turn to improve the system. Therefore, you must isolate the components.

Pillar 1: Evaluating the Retrieval Step (The Search Process)

Before we even look at the Large Language Model (LLM), we must measure the search quality. The goal of the retrieval step is to retrieve all necessary information, and only that information. This is where two classic concepts from information science come into play: Precision and Recall.

Recall: Did we find everything?

Recall is about completeness. Out of all the text fragments in your database that contain the answer to the question, how many did your system actually retrieve? In plain English: "Did we find the needle in the haystack?"

High recall is crucial in RAG. After all, if the answer is not in the provided context, the language model cannot generate an accurate, source-based answer. A recall of 100% means that all relevant documents for a specific question are in your top-K results (for example, the top 5 documents you add to the prompt).

Precision: Is there no noise?

Precision is about relevance. Out of all the documents the system retrieved, how many were actually useful for the question asked? In plain English: "Did we not just deliver half the haystack in the hope that the needle was in there?"

At first glance, low precision seems less severe than low recall; as long as the needle is in there, right? However, providing many irrelevant chunks has three major disadvantages. First, token costs increase significantly. Second, too much noise in the context increases the chance of hallucinations (the so-called 'lost in the middle' phenomenon). Finally, it can slow down the throughput speed of your application.

Context Relevance

When evaluating retrieval, we often look at 'Context Relevance'. This simply measures the extent to which the retrieved context is directly related to the question asked. This metric is often easy to automate using methods described in our article on LLM-as-a-judge, where you ask a powerful model (such as GPT-4 or Claude 3.5 Sonnet) to give a score from 0 to 1 on the relevance of a document to a specific question.

Pillar 2: Evaluating the Generation Step (The Answer)

Once we have established that the correct documents have been successfully retrieved from the database without too much noise, we shift the focus to the final answer. In a RAG setup, there are two fundamental metrics for generation: Groundedness (or Faithfulness) and Answer Relevance (Completeness).

Groundedness: Is it really in the source?

Groundedness, also referred to as factual grounding or faithfulness, measures the extent to which the claims made by the LLM can be traced back to the provided context. This is your main weapon against hallucinations. If the LLM states that the company closes on Fridays at 4:00 PM, it must be literally stated or clearly deducible somewhere in the retrieved chunks that the office closes on Fridays at 4:00 PM.

If the claim cannot be found in the context, the Groundedness is low. This often happens when the model falls back on its pre-trained knowledge. For more depth on this specific phenomenon, you can consult our guide on measuring hallucinations. High groundedness does not necessarily mean the answer is useful, only that the model did not invent things outside of the sources.

Completeness (Answer Relevance / Completeness)

The second important metric for generation is the relevance and completeness of the answer in relation to the user's question. Does the model answer directly, or does it send the user on a wild goose chase?

Suppose the question is: "What is the notice period for a permanent employee, and must this be in writing?" The retrieved document contains both answers (1 month, yes). If the model only says: "The notice period is 1 month", the Groundedness is perfect (it matches the source), but the Completeness falls short because the second part of the question was ignored.

The Pitfall: Being Right for the Wrong Reason

One of the most dangerous situations when evaluating a RAG application is the phenomenon where the model gives the correct answer, but without having retrieved the required information from your own systems.

If the user asks: "What is the capital of France?" a RAG system without good retrieval will still answer "Paris", because the language model simply already knows this from its training data.

Why is this dangerous? Because your end-to-end tests will mark this as a success. You think your RAG system works great, until a user asks a question about a purely internal business process that the model knows nothing about. Suddenly, the application fails spectacularly. Because your retrieval process (the foundation of RAG) was actually not functioning, but was masked by the general knowledge of the LLM. By measuring retrieval and generation separately, as discussed above, you expose these kinds of hidden flaws flawlessly.

In Practice: Building a Golden Dataset

To measure these metrics structurally, you need a 'Golden Dataset'. This is a collection of carefully compiled question-source pairs that serve as the absolute truth for your tests. Without a golden dataset, you are essentially optimizing blindly.

How do you build such a dataset? This initially requires manual work, but it pays off handsomely:

  1. Collect real questions: Use real-world questions. What do users actually type in? Do not make them up (entirely) yourself at your desk.
  2. Find the source (ground truth): For each question, manually find the specific document or chunk that contains the answer. Note the unique ID (document_id or chunk_id) of this source.
  3. Write the reference answer: Manually formulate the ideal, perfect answer based on this source.

A typical record in your dataset then conceptually looks like this:

{
  "question": "Can I take my lease car abroad?",
  "expected_document_id": "hr_lease_policy_2026_v2",
  "expected_answer": "Yes, you may take the lease car to EU countries, provided you report this in advance to fleet management."
}

Ensure diversity in your questions. Include factual questions, questions that ask for summaries, and especially 'trick questions' or questions where the answer is simply not in the documents. For the latter, the system must be evaluated on its ability to honestly say 'I don't know', instead of hallucinating.

Regression Testing: Prevent Index Changes from Breaking Everything

A RAG system is dynamic. You will undoubtedly adjust the chunk size in the future, switch to a newer embedding model, or change the weighting between semantic search and keyword search (BM25 or hybrid search). Every time you do this, you must re-index the vector database.

A change intended to solve a specific search problem can unintentionally worsen the results for dozens of other queries. This is called regression. To prevent this, you need automated regression testing. You can read more about effectively setting up alerts in our article on regression testing on prompts.

With your golden dataset, you can fully automatically retest recall and precision with every pipeline change. If you switch to a new embedding model and notice that the recall on the golden dataset drops from 85% to 60%, you immediately know that this new model performs less well for your specific documents (probably due to domain-specific jargon), regardless of what the model maker's benchmarks claim.

Conclusion

Evaluating a RAG system requires a systematic approach where you do not measure performance solely by the resulting answer. By breaking down the process, optimizing the recall of your retrieval, enforcing the groundedness of your generation, and continuously monitoring this with a golden dataset, you transform RAG from an experimental prototype into a reliable application for production environments.