AIAndreas IndorfTransformation
Measuring RAG quality: how to check that your knowledge AI answers correctly

Knowledge AI & data protection

Measuring RAG quality: how to check that your knowledge AI answers correctly

A knowledge AI that writes fluently is far from one that answers correctly. This article shows which metrics measure search and answer separately, how to build a test set and how to maintain quality in production.

Andreas IndorfAndreas Indorf November 7, 2026 10 min read

Most knowledge AI projects are signed off on gut feeling: a few colleagues ask questions, the answers sound good, the system goes live. Three months later complaints pile up, and nobody can say whether quality has dropped or the questions have simply become harder. Yet a knowledge AI based on retrieval-augmented generation (RAG) can be measured, at every one of its stages. This article shows which metrics you need, how to build a robust test set and how to maintain quality in production.

In short: Measure search and answer separately. For search, Recall@k and MRR show whether the right sections are found. For the answer, faithfulness, answer relevance and citation accuracy show whether the model sticks to the sources, addresses the question and cites correctly. The foundation is a golden set of real questions with verified answers and source locations, which runs as a regression test with every change and is complemented by human spot checks and monitoring in production.

Why RAG needs its own quality measures

A RAG pipeline consists of two parts that can fail independently of each other. The original RAG paper by Lewis et al. describes combining a language model with a searchable index from which matching passages are fetched for every query. When the answer is wrong, there are two fundamentally different causes: the search did not find the right passage, or the model used the retrieved passage incorrectly or not at all.

A single overall score for "good answers" is therefore of little help. It does not tell you whether you need to work on chunking, the embedding model, the reranker or the instruction to the language model. The paper on the RAGAS evaluation framework separates exactly these dimensions: whether the search delivers relevant and focused sections, whether the model uses those sections faithfully and how good the generated answer is overall.

How RAG works in principle and what matters for data protection is explained in the guide Knowledge AI with RAG in the enterprise. This article is about the next question: how do you know the system is good enough?

The metrics at a glance

StageMetricQuestion it answersNeeds a reference?
SearchRecall@kIs the right source location among the first k hits?yes, expected source location
SearchMRRHow high up is the first correct hit?yes, expected source location
SearchContext precisionHow much of the supplied context is actually relevant?depends on the variant
AnswerFaithfulness / groundednessIs every statement covered by the supplied sections?no
AnswerAnswer relevanceDoes the answer address the question asked?no
AnswerCorrectnessDoes the answer match the verified reference answer?yes, reference answer
AnswerCitation accuracyDo the cited sources really support the statement?partly

Search: Recall@k and MRR

Recall@k measures for how many test questions the expected source location is among the first k sections returned. If your language model receives the top five sections, Recall@5 is the decisive number: whatever does not show up there, the model cannot use. A low Recall@k points to problems in ingestion, chunking or the embedding model.

MRR (mean reciprocal rank) scores the position of the first correct hit. In position 1 it counts as 1, in position 2 as 0.5, in position 4 as 0.25. The average across all test questions shows whether the right passage reliably lands at the top. This matters because a good ranking lets you send fewer sections, which lowers cost and response time and burdens the model with less irrelevant context.

In addition, context recall measures how completely the supplied context covers the information in the reference answer. The Ragas documentation on context recall stresses that this metric always needs a reference for comparison.

Answer: faithfulness, relevance, correctness

Faithfulness, often also called groundedness, is the most important metric against hallucinations. According to the Ragas documentation on faithfulness, the answer is broken down into individual statements, each statement is checked against the supplied context, and the score is the share of supported statements among all statements, on a scale from 0 to 1. An answer with two statements, only one of which is in the context, scores 0.5.

Answer relevance checks whether the answer addresses the question asked. An answer can be fully supported and still useless if it misses the point of the question.

Correctness compares the answer with your verified reference answer. It is the metric business departments understand best, but it requires a maintained test set.

Citation accuracy

A source citation is only worth as much as its accuracy. Check two things separately: does the cited passage actually support the statement (precision)? And is every statement backed by a citation at all (completeness)? That this is no fringe issue is shown by the benchmark paper ALCE on text generation with citations: even the best models studied there failed to fully support their statements in half of the cases on one of the datasets. Citation accuracy therefore belongs in every acceptance test as a metric of its own, especially in legal, quality management and customer service.

The golden set: your most important tool

Without a test set, every assessment remains gut feeling. A golden set is a collection of questions with verified answers and the source locations they come from.

Real questions, not invented ones. Collect questions from tickets, emails, search logs and conversations with the business department. Invented questions are usually too neatly phrased and fit the documents too well.

Include the source location. Every question needs not only the correct answer but also the document, page and section. Only then can you calculate Recall@k and MRR.

Deliberately include hard cases. Questions whose answer is spread across several documents; questions about tables and scans; questions for which there is no answer in the collection. For the latter, the correct result is an honest "I can't find anything on that".

Size and upkeep. 50 to 100 well-chosen questions are enough to start. More important than quantity is that the set grows with the document collection and that a subject-matter owner approves the reference answers.

Automated evaluation and the human in the loop

Many metrics, such as faithfulness and answer relevance, are now calculated with a language model acting as the judge. The RAGAS paper shows that such metrics can work without human annotations, which is what makes fast and frequent testing possible in the first place. But a language model acting as judge can itself be wrong.

A two-stage approach has therefore proven itself:

  1. Automated and complete: Every change runs against the entire golden set, and the metrics are calculated automatically.
  2. Human and sample-based: Subject-matter experts regularly assess a sample, especially answers with low scores and cases where automated evaluation and user feedback diverge.

Human evaluation also serves as calibration: if the automated judge rates answers highly that the experts reject, the judge is the problem. How to design human review steps so that they don't turn into rubber-stamping is described in the article Human in the loop for AI agents.

Regression tests: protecting quality with every change

A knowledge AI changes constantly: new documents, different chunking, a new embedding model, an adjusted instruction, a model change at the provider. Each of these changes can improve some answers and worsen others.

So treat the golden set like a test suite in software development:

  • Before every change, record a baseline run with all metrics.
  • After the change, repeat the same run and compare deviations per metric and per question.
  • Set thresholds below which no metric may fall, for example for faithfulness and Recall@k. If a threshold is breached, the change does not go live.
  • Check individual cases, not just averages. A stable average can hide that ten questions got better and ten others got worse.

How such tests fit into a general testing strategy for AI systems is shown in the article AI testing strategy (in German).

Monitoring in production

The golden set checks known questions. In production, unknown ones arrive. So complement the tests with ongoing observation:

  • User feedback on every answer, at least thumbs up or down, ideally with a reason.
  • Share of "I don't know" answers: if it rises, documents are missing. If it drops to zero, the system may be guessing.
  • Collect questions without suitable hits: they reveal knowledge gaps and are the best candidates for new golden set entries.
  • Response time as a percentile, not as an average.
  • Samples with automated faithfulness scoring on real queries.

The voluntary NIST AI Risk Management Framework treats this kind of measurement as a core function in its own right, alongside governing, mapping and managing risks; the companion profile for generative AI (NIST AI 600-1) addresses its particular risks. For running models in production, the article MLOps strategy (in German) provides the organisational framework.

Typical failure patterns and their causes

SymptomLikely causeWhere to start
Recall@k low, faithfulness highsearch doesn't find the passage, but the model stays honestingestion, chunking, embedding, hybrid search
Recall@k high, faithfulness lowmodel adds its own knowledgeinstruction, model choice, temperature, answer format
Recall@k high, MRR lowright passage ranked too lowreranker, metadata filters
Answers supported but off-topicquestion misunderstood or context too broadquery rewriting, fewer sections
Citations point to the wrong placescitation not tied to the statementcitation logic per statement, page and section metadata
Quality declines graduallyoutdated or duplicate documentsownership for upkeep, deletion from the index

The most common insight from this table: most problems lie upstream of the language model, in ingesting and splitting the documents. Anyone who only swaps the model is often treating the wrong symptom. How to maintain the document collection in principle is described in the article AI in knowledge management (in German).

From my own products

At anirag.io I made source citations down to page and section a core feature, and that changed evaluation. Because every answer points to a specific passage, citation accuracy can be checked per statement rather than per document, and experts can attribute a wrong answer to the search or the model within seconds. The second lesson concerns response time: I measure it at the 99th percentile, and there it is under 800 ms. The average would have hidden the slow outliers by which users actually judge a system.

If you want to safeguard your knowledge AI with a robust test set, you will find my approach under Knowledge AI with RAG.

Frequently asked questions

Which metric matters most for a knowledge AI?

There is no single metric. For search, Recall@k is central, because the model can only use what was found. For the answer, faithfulness matters most, because it shows whether the model stays with the sources. Only the two together show where an error arises.

How large does a golden set need to be?

50 to 100 carefully selected real questions with verified answers and source locations are enough to start. More important than size is the mix: simple questions, questions spanning several documents, questions about tables and questions with no answer in the collection.

Can a language model evaluate answers reliably?

For fast, frequent tests, yes; as the sole authority, no. Automated judges can be wrong. Calibrate them regularly with human spot checks and pay particular attention to cases where automated evaluation and user feedback diverge.

How often should I run the evaluation?

As a regression test with every change to the document collection, chunking, embedding model, instruction or language model. In addition, monitoring in production should continuously capture feedback, response times and questions without hits.

What should I do if faithfulness is low?

First check whether the search returns the right sections. If it does, the problem lies with the model: tighten the instruction to answer only from the context, require a citation per statement and have the system honestly decline when there are no hits instead of guessing.

Andreas Indorf

About the author

Andreas Indorf

Founder & CEO of mysoftwarelab GmbH, AI software architect. 7 AI SaaS products live, 20+ years of enterprise IT.

More about me

Related service

Knowledge AI & RAG

Next step

Let’s build what works for you.

30 minutes, free and without obligation. You’ll find out where AI has the biggest leverage in your company – and how quickly it can be implemented.

Usually answered within 24 hours.