29 Oct 2026 RAG testing: how to test an AI assistant that answers from your own documents

In short: RAG testing checks an AI assistant that first searches your own documents and then writes an answer from what it found. Most failures sit in the search step. It finds the wrong or an outdated document, half a passage, or a document the user may not see. Test the search and the answer separately, and test again whenever your documents change.

When an AI assistant that answers from your own documents gets it wrong, people blame the model. Most of the time, the model did its job. It wrote a fine answer from the wrong page. That’s why RAG testing starts with the part most teams skip: what the assistant found before it answered. If you only test the final answers, you see that something is wrong, but not where.

What is RAG, and where does it go wrong?

RAG stands for retrieval-augmented generation. The idea was described by Lewis and others in 2020. A RAG assistant works in two steps. First it searches a collection of documents for passages that fit the question. Then it gives those passages to a language model, which writes the answer from them. Companies use it for intranet assistants, customer service bots and help for staff with policies or product data. The search step is where most things go wrong. The assistant may not find the right document at all. It may find last year’s version instead of this year’s. Documents are cut into small pieces before they are searched, so it may find half a passage and miss the exception in the next piece. It may find a document the user isn’t allowed to see. Or it finds nothing useful and answers anyway. Each of these failures can produce an answer that sounds sure of itself.

How do you test the search step?

You test the search step with a set of real questions, and for each question you write down which passage it should find. Then you check whether that passage shows up among the results the assistant uses. This tells you if a wrong answer started with a wrong search. It also tells you whether a change to the search settings made things better or worse. The table shows the main failure types and how to test each one.

Access rights deserve extra attention. If the search step ignores who is asking, the assistant can leak information to people who should never see it. OWASP lists this under vector and embedding weaknesses in its top 10 for LLM applications. Test it with real roles, not only with an admin account.

How do you test the answer itself?

You test the answer by checking whether every claim in it is backed by the passages the assistant found. A good answer adds nothing that isn’t in the sources. If it shows sources, each one must exist and say what the answer claims. When the passages don’t answer the question, the assistant should say so instead of filling the gap. Ask each question more than once, because the wording changes from run to run. Software with AI inside gives answers that aren’t always the same, so a simple pass or fail isn’t enough. We know how to deal with that, and it shapes how we score every answer.

Some of the checking can be automated, but people stay part of it. The colleagues who own the documents know best whether an answer is right. Let them review a sample of answers each round, especially on topics with real risk, such as prices, contracts or HR rules. Documents can also hide instructions meant to steer the assistant. That’s a security topic of its own, so keep it on your list.

When do you test again?

Test again whenever your documents, access rights or search settings change, not only when the model changes. That is the big difference with other AI tests. A new policy, a removed product sheet or a changed folder permission can change answers overnight. Nobody in IT may even know it happened. So treat your question set as a regression set. Run it after every document import and before every release, and look at both the search results and the answers.

After go-live, real users will ask things your set doesn’t cover. Keep watching their questions and the answers they get, and add new cases to the set. That kind of AI monitoring after go-live works in five steps, from picking the questions to reporting the results. It is the RAG side of a wider shift in AI in software testing: testing AI is ongoing work.

One trade-off to name: you can’t test every possible question. Focus on the topics where a wrong answer hurts most. An internal assistant for office questions needs a lighter set than one that answers customers about their contract.

What this means for your team

The documents behind a RAG assistant change every week, and most of them are owned by people outside IT. Each change can quietly break an answer that worked yesterday. So testing it is ongoing work, not a check before launch. Someone has to keep the question set current, run it after every change, and report the results so document owners can act. In many teams nobody has that job.

Our in-house tool VeritasAI is built for this kind of ongoing testing, and we use it to deliver AI testing as a service. It keeps testing your AI application with real questions. An operational dashboard shows which questions fail, and which law, regulation or framework each failure maps to. You see the prompt, the answer and a priority score. A management dashboard shows the overall picture.

A first step you can take this week: pick the ten questions your assistant gets most. Write down which document and passage holds each answer. Then check whether the assistant really finds that passage.

Frequently asked questions

What is the difference between RAG testing and testing the model?

Testing the model looks at how well it writes answers. RAG testing also checks what the assistant found in your documents before it answered. Most failures start there.

How do you test access rights in a RAG assistant?

Ask the same questions while logged in as users with different roles. Check that each user only gets answers from documents they are allowed to open.

How often should you retest a RAG assistant?

After every change to the documents, access rights, search settings or model, and before each release. After go-live, keep monitoring real questions.

Can you automate RAG testing?

Largely. You can automate the question set, the check on which passages are found and part of the answer scoring. Experts still review a sample, because they know what is really right.