RAG Evaluation: How to Know Your AI Answers Are Right
How to evaluate a RAG system: build a test set, score retrieval and answers separately, calibrate an LLM judge and set release gates to catch regressions.
Key takeaways
- RAG does not eliminate hallucination: in a Stanford benchmark, two commercial legal research tools that promoted retrieval as a safeguard produced incorrect information more than 17% of the time.
- Score retrieval and generation separately; otherwise you cannot tell whether a wrong answer came from search or from the model.
- An LLM judge can approach human agreement, but only after you calibrate it against human labels and control for position and length bias.
- Write pass thresholds before testing and run the full test set on every prompt, model, chunking or index change.
Why RAG answers still go wrong
Retrieval-augmented generation is often sold as the cure for hallucination: the model answers from your documents, so it cannot make things up. The evidence says otherwise. In 2024, Stanford RegLab and the Stanford Institute for Human-Centered AI benchmarked AI legal research tools whose vendors promoted retrieval as a safeguard, and in one case advertised hallucination-free citations. Lexis+ AI and Ask Practical Law AI produced incorrect information more than 17% of the time, and Westlaw AI-Assisted Research hallucinated more than 34% of the time.
The study's definition is the useful part for any business team. A response could be incorrect, meaning it stated something false, or misgrounded, meaning the statement was right but the cited source did not support it. Both are failures for a system people are meant to trust, and neither shows up when a team tries ten friendly questions in a demo. Measuring them takes a test set, a scoring method and thresholds agreed in advance.
Evaluate retrieval and generation separately
A RAG answer passes through two steps that fail in different ways. Retrieval can miss the passage that holds the answer, or bury it under irrelevant chunks. Generation can then ignore good context, add facts from the model's own memory, or leave out part of what the sources say. A single overall score hides which step broke, so the fix becomes guesswork.
Microsoft's Foundry documentation makes the split explicit. It calls retrieval checks process evaluation and answer checks system evaluation. It also offers a compact way to think about the answer: groundedness measures the precision side, meaning the response contains nothing outside the grounding context, while response completeness measures the recall side, meaning it does not miss critical information from the expected answer. You need both. A short answer can be perfectly grounded and still useless.
How to build a RAG test set from real questions
OpenAI's evaluation guide recommends mixing data sources, including production logs, historical data and human-curated examples, and warns against test data that does not reproduce real traffic patterns. Anthropic's guidance adds that more questions with slightly noisier automated grading beat a handful of perfectly hand-graded ones. For a company assistant, the best raw material is usually already on file: support tickets, sales questions, onboarding queries and the questions employees ask each other in chat.
For each question, record a reference answer written or approved by someone who owns the content, and the document or section that should be retrieved. Those two fields unlock the metrics that need ground truth. Then make sure the set covers the cases that break RAG systems:
- Questions whose answer is in one known passage, to measure basic retrieval.
- Questions that need two or more documents combined, such as a policy and its regional exception.
- Questions the documents do not answer, where the correct behaviour is to say so rather than guess.
- Questions about content that changed, where an outdated version is still in the index.
- Phrasings real users write: abbreviations, typos, internal jargon and product nicknames.
- For bilingual companies, questions in one language against documents in the other, for example an English question about a policy only published in Japanese.
RAG evaluation metrics for retrieval
Two metrics from the open-source Ragas library cover most retrieval questions. Context recall measures how much of the needed information was retrieved: Ragas splits the reference answer into claims and calculates the share that the retrieved context supports. It therefore always needs a reference. Context precision measures whether relevant chunks are ranked above irrelevant ones, as a mean of precision at each rank. Low recall means the answer was never available to the model; low precision means it was there but diluted by noise.
If you label which documents are relevant to each question, ranking metrics such as NDCG become available. Microsoft recommends using them in a parameter sweep: generate retrieval results for different search methods (vector or semantic), top-k values and chunk sizes, then keep the configuration that scores best. This is far cheaper than tuning prompts while the real problem sits in the index.
RAG evaluation metrics for the answer
Faithfulness is the core answer metric. Ragas identifies every claim in the response and checks whether each one can be inferred from the retrieved context; the score is the supported claims divided by all claims, from 0 to 1. An answer with two claims, one supported, scores 0.5. Pair it with a completeness check against the reference answer, and with a relevance check on whether the response addresses the question asked.
The combination tells you where to look when a test fails:
- Low context recall: the answer never reached the model. Fix ingestion, chunking or the search configuration.
- Good recall but low faithfulness: the model added content from memory. Tighten the instructions, require citations and test a different model.
- Good faithfulness but low completeness: the context was used selectively. Check whether relevant chunks are ranked too low or cut off.
- A confident answer to an unanswerable question: refusal is not working. Add explicit instructions and more unanswerable cases to the test set.
Using an LLM as a judge without fooling yourself
Most of these metrics rely on a model grading another model's output, because reading thousands of answers by hand is too slow. The approach has research behind it: the 2023 MT-Bench and Chatbot Arena study found that strong LLM judges reached over 80% agreement with human preferences, the same level humans reach with each other. The same paper documented position, verbosity and self-enhancement biases.
The vendors' own guidance turns that into practice. OpenAI says pass/fail or pairwise comparison is more reliable than open-ended scores, that judges should be calibrated against human feedback before scaling up, and that response length should be controlled for. Anthropic recommends detailed rubrics, a fixed output such as correct or incorrect, letting the grader reason before scoring, and grading with a different model from the one that produced the answer. In practice, have a content owner label a sample of answers, compare the judge's verdicts with theirs, and only trust the judge once the two agree.
Release gates and continuous RAG evaluation
A score only matters if it decides something. OpenAI's guide gives an example target for question answering over documents: context recall of at least 0.85, context precision above 0.7 and at least 70% of answers rated positively. Treat numbers like these as a starting point to adjust for your risk, and write your own before the first test run so the result cannot move the goalposts. A tool that answers HR policy questions deserves a stricter faithfulness bar than one that drafts internal summaries.
OpenAI also recommends running evaluations on every change, logging everything and growing the test set over time. For a RAG system, that becomes a short checklist:
- Run the full test set in CI whenever the prompt, model, embedding model, chunking rules or index changes, and block the release if a gate fails.
- Report each metric separately and list the worst failures, not only the averages.
- Log production questions, retrieved chunks and answers so new failures can be reproduced.
- Add every confirmed production failure to the test set, with a corrected reference answer.
- Re-check the LLM judge against fresh human labels whenever you change the judge model or the rubric.
About the author
Jayson Hao
Founder of Innovation Trigger Lab and a University of Toronto Computer Science graduate with an AI/ML focus. He designs and ships production RAG systems, AI chatbots, web platforms and mobile products.
View profileFrequently asked questions
What are the most important RAG evaluation metrics?
Start with context recall and context precision for retrieval, and faithfulness and completeness for the answer. Add a check that the system declines questions its sources do not answer.
Can I evaluate RAG without reference answers?
Partly. Faithfulness, relevance and LLM-judged retrieval relevance work without ground truth, but context recall and completeness need a reference answer. Writing references for your most important questions is worth the effort.
What is Ragas?
Ragas is an open-source Python library for evaluating LLM applications. It implements RAG metrics such as faithfulness, context precision, context recall and response relevancy, many of which use an LLM to score each item.
How often should a RAG system be evaluated?
On every change to the prompt, model, chunking or index, and continuously in production through logged questions. New failures from production should be added to the test set.
Sources and further reading
- 1.
- 2.Retrieval-Augmented Generation (RAG) evaluators for generative AIMicrosoft Learn, June 2, 2026
- 3.Ragas metrics: Faithfulness, Context Precision and Context RecallRagas, December 9, 2025
- 4.
- 5.AI on Trial: Legal Models Hallucinate in 1 out of 6 (or More) Benchmarking QueriesStanford HAI, May 23, 2024
- 6.Judging LLM-as-a-Judge with MT-Bench and Chatbot ArenaZheng et al., NeurIPS 2023 (arXiv), December 24, 2023
