Back to blog
ImplementationJuly 17, 20268 min readUpdated July 17, 2026

Measuring AI Chatbot Answer Quality: Golden Set, RAG Tests, and Review Workflow

A website chatbot only becomes reliable when its answers are regularly checked against sources, expected answers, and real user questions. This guide shows how teams build a Golden Set, RAG tests, and a lean review workflow.

An AI chatbot on a corporate website is not automatically good just because it answers fluently. For website operators, something else matters: Does the answer agree with their own sources? Does the bot understand the question? Does it recognize limits? And is an error noticed early enough before customers read incorrect prices, deadlines, or responsibilities?

That is exactly why a chatbot needs not only a knowledge base, but a measurable quality process. Modern RAG systems link answers to verifiable sources. Google describes Grounding as connecting model answers with verifiable information sources so that answers become more helpful and factual. In its RAG evaluators, Microsoft distinguishes, among others, Retrieval, Groundedness, Relevance, and Response Completeness. For a website team, a pragmatic workflow can be derived from this: create a Golden Set, check answers against sources, classify errors, and improve regularly.

Zwei Fachleute prüfen anonymisierte Chatbot-Antworten an einer QA-Wand gegen Quellenkarten.
Answer quality becomes tangible when chat histories, sources, and expected answers are visibly checked against one another.

Why answer quality is more than just a good tone

Many teams initially evaluate chatbots based on language: sounds friendly, answers quickly, is formulated cleanly. This is important, but not sufficient. A politely formulated error remains an error. For support, sales, and product communication, four questions are more decisive: Is the answer correct, complete, current, and appropriate to the user's intent?

An example: A visitor asks about the conditions for an appointment, a return, or a demo. If the bot cannot find the appropriate help text, it can still sound convincing. Without quality measurement, it is only noticed later that it used an old rule, an inappropriate page, or even a completely invented restriction. Answer quality must therefore be measured at the points where real damage occurs: false promises, missing escalation, outdated information, poor sources, and overlooked user intention.

OWASP lists misinformation as a separate risk for LLM applications and recommends, among other things, RAG, cross-checking, human oversight, automatic validation, and clear risk communication. This fits well with website chatbots: The closer an answer is to prices, contracts, health, finance, law, or safety-critical processes, the less it should be published without a source and review layer.

The Golden Set: Your small, hard collection of truths

A Golden Set is a curated collection of test questions with expected answers, permitted sources, and clear evaluation criteria. It is not large, but deliberately chosen. It contains the questions where the bot must be reliable: frequent support requests, purchase-related questions, risky edge cases, ambiguous formulations, and cases where a Human Handoff is necessary.

For the start, a few dozen examples per important area are often sufficient. The decisive factor is not the quantity, but the coverage. A good Golden Set contains normal questions, difficult edge cases, and deliberately unsolvable questions. The unsolvable questions are particularly valuable because they show whether the bot answers with clean boundaries: "I have no reliable source for this in the stored information" is in many cases better than an invented answer.

Which fields a test case should contain

  • User question: the actual or realistically formulated question.
  • Intent: for example price, delivery, appointment, data protection, integration, or cancellation.
  • Expected answer: a short, professionally verified target answer.
  • Permitted sources: URLs, documents, FAQ entries, or internal knowledge pages.
  • Risk class: low, medium, or high, depending on the potential damage.
  • Expected action: answer directly, ask a follow-up question, provide a link, or hand over to a human.

If you are just starting to structure your sources, the article about training with FAQs, documents, and website content helps. For ongoing maintenance, the guide to the current AI chatbot knowledge base is the natural next step.

Viewing RAG tests separately: Search first, answer second

In Retrieval-Augmented Generation, errors occur at two different points. First, the search may deliver the wrong or too few sources. Second, the model may still generate an incomplete, exaggerated, or poorly formulated answer from good sources. Those who only evaluate the final answer see the symptom, but not necessarily the cause.

Microsoft's RAG evaluator documentation therefore separates process evaluation and system evaluation: Retrieval and Document Retrieval check the quality of the found contexts, while Groundedness, Relevance, and Response Completeness evaluate the final answer. For website teams, this translates to: For each test case, save not only the answer but also the retrieved sources. Otherwise, after a failure, you will not know whether crawling, index, chunking, ranking, prompt, or model behavior needs to be adjusted.

The five core metrics for website chatbots

  • Retrieval hits: Were the correct source pages or document sections found?
  • Groundedness: Does the answer stick to what is in the sources?
  • Relevance: Does it answer the actual user question instead of a neighboring topic?
  • Completeness: Are important conditions, exceptions, deadlines, or next steps missing?
  • Handoff behavior: Does the bot hand over in case of uncertainty, complaint, personal case, or high risk?

Not all of these metrics need to be automated immediately. A spreadsheet-capable review with clear labels is better than no process at all. Automated evaluators become particularly valuable when they repeatedly run the same test cases against new sources, new prompts, or new models.

A review workflow that works in everyday life

The best quality process is the one that a small team actually maintains. For many websites, a weekly rhythm is sufficient: anonymize real chat questions, select conspicuous cases, run them against the Golden Set, categorize errors, and specifically improve one thing. Then the same test is executed again. This creates a measurable curve instead of a gut feeling.

A meaningful review distinguishes at least four types of errors. Source errors mean: The knowledge base is outdated, contradictory, or incomplete. Retrieval errors mean: The correct source exists but is not found. Answer errors mean: The source is available, but the answer twists, shortens, or invents something. Process errors mean: The bot should have asked a follow-up question or handed over to a human.

This separation prevents hectic pseudo-solutions. If the source is wrong, a better prompt will not help. If the source is correct but not found, indexing, search parameters, or chunking must be checked. If the answer is poorly formulated from good sources, system instructions, answer format, or model choice are the better levers. And if users actually need personal help, the case belongs in the Human-Handoff-Workflow.

What you should check before every publication

Before major changes to the chatbot, knowledge base, or model, a short release check should be run. First, check the most important Golden Set questions. Then, test risky new sources, for example, updated price, product, data protection, or support pages. Finally, check real user questions from the last few days, because they show what language visitors actually use.

For the evaluation, reviewers should not just click "correct" or "incorrect". Short structured labels are more useful: source found, answer substantiated, important information missing, wrong URL, wrong language, too confident, handoff missing, tone inappropriate. After a few weeks, these labels show which error class dominates and where work is worthwhile.

Quantitative metrics remain helpful as long as they are not viewed in isolation. A resolution rate also increases if the bot answers too optimistically. Therefore, operational KPIs from the article on AI chatbot KPIs should always be combined with quality labels. A high automation rate is only good if groundedness, completeness, and handoff behavior remain stable.

Common mistakes in quality measurement

  • Only testing nice demo questions: Users rarely ask as neatly as a sales demo script.
  • Not saving sources: Without retrieval context, the cause of an error is hard to find.
  • Never updating old test cases: A Golden Set must grow with products, prices, processes, and search intentions.
  • Wanting to automate everything: Human reviews remain important, especially for sensitive or ambiguous answers.
  • Only looking at average values: A single high-risk error can be more important than many harmless formulation errors.

Pragmatic start plan for the next two weeks

Begin with the ten most frequent support questions, the ten most purchase-related questions, and five deliberately difficult edge cases. Document the permitted sources and the expected action for each case. Let the bot answer, save the answer and sources, and mark errors with the labels above. Then, do not improve everything at once, but only the most visible bottleneck.

In week two, supplement with real chat histories that caused effort in support or sales. Pay particular attention to questions where users expect a concrete promise. If the bot is uncertain here, it should remain transparent, name a source, ask a follow-up question, or hand over to a human. The goal is not to solve every question automatically. The goal is to distinguish reliable answers from uncertain cases.

Conclusion

AI chatbot answer quality is not created by a one-time prompt, but by repeatable testing. A Golden Set makes expectations visible. RAG tests show whether the correct sources are found and used correctly. A review workflow ensures that errors are not only detected but traced back to the knowledge base, retrieval, prompt, or handoff rule. In this way, the website chatbot becomes more reliable step by step, without the team having to rely on mere feeling.

Sources

Turn website visits into better conversations

Reduce support load while keeping answers consistent

Give visitors instant website support, route edge cases to your team, and keep every answer aligned with your approved knowledge base.

Related articles

Keep reading