In the past, it was enough for a chatbot to recognise the intention and run the appropriate script — a quick, uneventful conversation, similar to interacting with a ticket machine. Today, however, artificial intelligence is operating in a different league. Nowadays, there are generative language models that can write poetry, solve math puzzles, and provide legal advice — sometimes even more convincingly than a human lawyer. But things get really interesting when AI not only “talks” but also demonstrates understanding of the subject matter because it has just read company documents. This is where RAG — Retrieval-Augmented Generation — steps in.
So, what exactly is RAG?
It is architecture that combines two elements: an information retrieval mechanism and generative artificial intelligence. To put it simply, when a user asks a question, the system first searches the knowledge base: comprising documents, articles, and notes to find relevant fragments (the retriever’s role). Then, the language model (e.g., ChatGPT) uses these fragments as context to generate a response. The key point is that the answer does not come from the knowledge “encoded” in the model during its training, but from the data provided at the time of the query. In theory, this approach combines the flexibility of AI with the reliability of source data.
At first glance, RAG systems appear to be magical. The user asks a question and AI responds based not on knowledge from two years ago, but on current company documents, a knowledge base, or a website. In reality, it is a clever combination of two worlds: the search system scans the database, finds relevant text fragments, and uses this information as context to create a response. The result? A natural-sounding response that is rooted in real data.
However, this theory often clashes with practice. While the user only sees the final answer, software testers know that the RAG system is actually a multi-layered puzzle, where any single element could fail.
Consider, for instance, an insurance company that has implemented an internal knowledge assistant for its call centre employees. Rather than having to dig through dozens of pages of regulations, the AI assistant was supposed to answer questions such as “Can a customer cancel their policy after 30 days?” and provide a specific answer with a reference to the relevant document. The business was delighted: consultants saved time, customers waited less on the line and managers welcomed the modernisation. However, the testers were more cautious, asking tricky questions and checking answers in less obvious scenarios. They also compared the content provided by the assistant with the actual records in the documents and investigated whether AI was coming up with its own interpretations.
If the data the system quotes is outdated, no one maynotice this until a customer files a complaint. If AI fails to mention an important exception in the procedure, it could result in real financial loss. If it answers two similar questions in two completely different ways, something has clearly gone wrong. Testing RAG is therefore not only about checking that it ”works”, but also that it “works smartly”.
The tester must examine each layer of the system individually. Retrieval? Make sure it finds the right documents, doesn’t lose important information, and ranks results sensibly. Generator? Check that it doesn’t “add” facts from outside the context. Ideally, you should test both components separately and in tandem.
In practice, this often resembles an investigation. The tester prepares a set of documents with deliberate changes or errors and checks whether AI can identify them. For example, we might change a fragment of a document by introducing an incorrect date or condition and then check whether the system notices, ignores, or says something meaningful about it. This would raise the question: how did it work that out?
RAG is not completely immune to the known issues of large models, such as hallucinations and overconfidence. Sometimes it is confident about it, even when there is no basis for it. This is why negative tests are so important. There are questions that the system should not be able to answer because the information is not in the knowledge base. In such situations, a good system should simply admit its lack of knowledge. If it starts to ramble, however, it’s a sign that the retriever has lost the battle with the generator’s creativity.
However, testing RAG systems is not just about identifying errors. It is also about evaluating the quality of the responses. Are the answers concise? Do they relate to the context? Does the style of expression match the company’s tone? Testers are increasingly becoming involuntary content editors — after all, you can’t give a customer an answer that sounds like a report from a code of law? This is where an idea that is becoming increasingly popular in testing communities steps in: vibe testing. Rather than measuring anything with a ruler or counting BLEU points, we just ask ourselves: does it sound good? Do I “feel“ that the answer is helpful, human-like, and on point?
Of course, there are also metrics and tools that allow you to partially automate the evaluation of responses, ranging from classic measures such as Exact Match or F1 Score to more sophisticated approaches that assess the degree to which the response matches the context. A lot of support is available in today’s open-source ecosystem — libraries, such as Ragas and TruLens, allow you to test how much of the generated response is the actual content from documents and how much is the model’s creative invention.
Nevertheless, RAG testing will never be fully automated. It is not a deterministic system that will always produce the same result from the same data. It is a complex system in which the retrieval process can sometimes be surprising, the generator can take shortcuts, and the user can request something atypical that the entire system breaks down.
This is why a RAG system tester is not just a quality controller, but also a partner to designers, data scientists, and copywriters. They must understand data, intentions, language, UX, and human emotions. It’s an interdisciplinary role full of challenges but also incredibly rewarding. This game is not just about making AI work. It’s about making it work properly.
