AI and LLM Testing: How to QA RAG Systems Before Users Do

AI products fail in a way classic tests miss

A Playwright, Cypress or Selenium suite will tell you the chat widget opened, the message sent, and a reply appeared. It will not tell you whether that reply was grounded in your documents, invented a policy that does not exist, or cited a source that was never retrieved.

That is the job of AI and LLM testing. RAG is how many of those products are built (search a knowledge base, then generate). It is not the testing method. The method is a labelled query set scored against a source of truth, with retrieval scored separately when the product uses it.

RedQA still specialises in Playwright, Cypress and Selenium. We also test AI chat and LLM products, including RAG systems, and the product around them. This guide is how we approach that work.

Related reading: what LLM testing covers, how to test an AI chatbot, and hallucination testing.

What you are actually testing

Most “AI features” in production are not a naked model. They are a system:

• Retrieval: a query hits an index, vector store or search API and comes back with chunks
• Generation: an LLM writes an answer from those chunks, plus a system prompt
• Product: a UI, streaming, citations, fallbacks, auth, and the path to a human

RAG (retrieval-augmented generation) is the usual pattern: ground the model against your knowledge base instead of letting it improvise from training data. We tested a patient-facing ChatGPT system at Bupa that was grounded against Bupa’s own knowledge base. The failure modes were retrieval misses, fluent answers that went beyond the source, slow replies, and a UI that did not make the limits of the system obvious.

If you only test the last message in the chat, you will ship a confident liar.

Layer 1: retrieval, before the model speaks

If the wrong documents come back, the model cannot save you. Test retrieval on its own, with generation switched off or logged separately.

Build a labelled query set

For each important question, record which document (and ideally which chunk) should be in the top results. Cover:

• Head queries your users actually ask
• Synonyms and messy wording (“what’s the excess” vs “do I pay anything up front”)
• Near-miss questions that sit next to a real document
• Questions with no supporting document at all

What to score

• Recall at k: is the right source in the top 3 or top 5 chunks?
• Ranking: is the best source first, or buried under a similar but wrong page?
• Stale and duplicate chunks: old PDFs, two versions of a policy, marketing copy mixed with the legal text
• Empty or junk retrieval: the index returns nothing useful, but the app still calls the model

A retrieval miss looks like a hallucination downstream. Fix the index first.

Layer 2: grounded generation

Once retrieval is honest, test what the model does with those chunks.

Groundedness

Every claim in the answer should be supportable from the retrieved text. If the model adds a step, a number, a product name or a deadline that is not in the context, that is a fail, even if the sentence sounds helpful.

Refusals and out-of-scope

Ask things the knowledge base cannot answer. The system should say it does not know, or hand off, not invent a plausible policy. Out-of-scope testing is as important as in-scope accuracy.

Citations

If the UI shows sources, check three things: the cited document was actually retrieved, the quoted span exists, and the citation is not a decorative filename on an unrelated paragraph.

Instruction following

Stay in role. Do not give medical, legal or financial advice if the prompt forbids it. Do not dump the system prompt when a user asks. Do not follow “ignore previous instructions”.

Consistency

Run the same grounded query several times at the temperature you use in production. Factual claims should not flip. High variance is a sign the model is filling gaps from training data.

For detection techniques in more depth, see AI hallucination testing.

Layer 3: the product still needs Playwright

LLM quality does not replace UI and API automation. The chat is still a web or mobile product. We keep Playwright, Cypress or Selenium on the paths that protect trust:

• Auth, session, and who can see which documents
• Sending a message, streaming tokens, stop and retry
• Empty states, rate limits, and model or retrieval timeouts
• Citation clicks, “this was not helpful”, and escalate to a human
• Accessibility of the chat: keyboard, contrast, screen reader names

Treat the model as an unreliable dependency. Your suite should assert the shell around it: the request was sent with the right context, a timeout showed a real error, and a refusal rendered as a refusal, not a blank bubble.

That is the same delivery pattern we use on non-AI work: critical path first, then CI/CD. The evals sit beside the suite, not instead of it.

A regression library you can run after every change

AI systems regress when you change any of: the model, the prompt, temperature, chunk size, the index, or the documents themselves. A one-off demo pass is not QA.

Keep a versioned prompt library:

1. Must-pass questions with an expected source and a short gold answer
2. Known failure modes you have already seen in production
3. Adversarial and out-of-scope prompts
4. A handful of multi-turn threads, because follow-ups are where retrieval often drops the original document

Run it on every prompt or index change. Score groundedness and retrieval, not just “the model answered”. Capture traces: query, retrieved chunk IDs, final text, latency to first token, total time.

Latency still matters. In the Bupa work, replies that took more than about 8 to 10 seconds felt broken for anxious users, even when the text was correct. Measure time to first token and total time under concurrent load, not only on a quiet staging box.

What a first AI testing engagement looks like

You do not need a research lab. You need a corpus, traces, and a pass or fail you can defend in a sprint review.

1. Map the pipeline: documents, chunking, retrieval, prompt, model, UI
2. Build a labelled query set from real user questions where you have them
3. Score retrieval and groundedness separately
4. Add Playwright (or Cypress / Selenium) around the chat and failure states
5. Hand over a regression library your team can run after model or content updates

That is the core of our AI and LLM testing work, next to Playwright, Cypress and Selenium. We also build React, Next.js and React Native products when you need the app as well as the tests. The focus is still testing.

Get a quote if you have a RAG or LLM feature in production, or about to go there. Case study: testing Bupa’s ChatGPT patient chat.