--- title: "How to test the accuracy of an AI knowledge base" description: "Test an AI knowledge base with a held-out question set, retrieval checks, groundedness, citations, abstention and role-aware regression tests." canonical: "https://innovate-blog.com/articles/test-ai-knowledge-base-accuracy" last-updated: "2026-09-10" --- # How to test the accuracy of an AI knowledge base > Test an AI knowledge base with a held-out question set, retrieval checks, groundedness, citations, abstention and role-aware regression tests. By Moez Zhioua. Published 2026-09-10. Updated 2026-09-10. Category: Business Brain. Estimated reading time: 12 minutes. ## In brief - To test the accuracy of an AI knowledge base, use a held-out set of real questions with an approved answer, expected source and user role. Measure five things separately: did retrieval find the right evidence, is the answer grounded in it, are the facts correct, do citations point to the evidence, and does the assistant abstain when the source is not enough? A single "looks good" review or one aggregate score will hide the failure you need to fix. - Accuracy is a system property. A correct document can be missed by retrieval. A relevant chunk can be ignored by generation. A well-written answer can expose a fact to the wrong role. A citation can exist but point to a source that does not support the sentence. Test each boundary before you decide that the knowledge base is ready. - Start with the decision the assistant supports. A support answer may need an exact current limit. An internal search assistant may need to find the right policy owner. A sales summary may need a useful citation and a clear "not found" response. Do not mix these into an unexplained score. ## The short answer To test the accuracy of an AI knowledge base, use a held-out set of real questions with an approved answer, expected source and user role. Measure five things separately: did retrieval find the right evidence, is the answer grounded in it, are the facts correct, do citations point to the evidence, and does the assistant abstain when the source is not enough? A single "looks good" review or one aggregate score will hide the failure you need to fix. Accuracy is a system property. A correct document can be missed by retrieval. A relevant chunk can be ignored by generation. A well-written answer can expose a fact to the wrong role. A citation can exist but point to a source that does not support the sentence. Test each boundary before you decide that the knowledge base is ready. ## Define accurate for one workflow Start with the decision the assistant supports. A support answer may need an exact current limit. An internal search assistant may need to find the right policy owner. A sales summary may need a useful citation and a clear "not found" response. Do not mix these into an unexplained score. Write an evaluation record with the question, role, approved answer, expected source IDs, acceptable alternatives, sensitivity and abstention rule. Keep the answer key outside the prompt used to test the assistant. Otherwise the test can accidentally teach the answer it is meant to measure. The MindsDB discussion of predefined questions and answers is a useful model for making the answer key explicit. Its named SQL feature is product-specific, so copy the discipline of an answer key rather than assuming the same command exists in your stack. ## Build a representative, held-out set Use questions from real work, but remove personal or confidential values. Include short lookups, multi-document questions, conflicting versions, synonyms, misspellings, dates, numbers and questions that the sources cannot answer. Split the set into development examples and a held-out set that the team does not tune against every day. Balance the set by workflow and risk, not only by the number of documents. If production questions are mostly about onboarding, adding hundreds of generic trivia prompts will not prove onboarding coverage. Add reviewed failures back to the set so the evaluation becomes more useful over time. - Field: Question; What to record: The exact user wording and a few realistic variants.; Why it matters: Retrieval can change when wording changes. - Field: Role; What to record: User, team, tenant and relevant source permissions.; Why it matters: A correct answer for one role can be a data leak for another. - Field: Answer key; What to record: Required facts, acceptable wording and forbidden claims.; Why it matters: Reviewers need a stable standard. - Field: Expected evidence; What to record: Source IDs, versions, sections or record fields.; Why it matters: You can test retrieval and citation support separately. - Field: Abstention rule; What to record: When the assistant must say that evidence is missing or conflicting.; Why it matters: A safe refusal is better than a confident invention. - Field: Risk; What to record: Impact if a detail is wrong or exposed.; Why it matters: High-risk cases deserve stricter release gates. ## Score retrieval before the answer First ask whether the expected source or an evidence-bearing passage appears in the retrieved results. Record the rank of the first useful passage and whether it contains the needed fact. This is retrieval hit rate, not answer accuracy. If the passage is missing, inspect the source before changing the model. Stale content, vague headings, oversized chunks, bad metadata, an embedding mismatch or a permission filter can all produce a miss. AWS describes a reranking experiment for Amazon Bedrock; that is a useful reminder to test retrieval changes with your own held-out cases, not proof that reranking always improves every system. Do not collapse these into "accuracy" until you have inspected the distribution. A system can have strong retrieval and weak generation, or good answers for an administrator and unsafe answers for a contractor. - Dimension: Retrieval hit; Question: Did a top result contain the fact needed?; Example evidence: Expected source ID and rank. - Dimension: Groundedness; Question: Does each material claim follow from the retrieved text?; Example evidence: Claim-to-passage review. - Dimension: Correctness; Question: Does the answer match the approved facts and current version?; Example evidence: Human comparison with the answer key. - Dimension: Citation quality; Question: Does the link or source label support the nearby sentence?; Example evidence: Citation target and supporting span. - Dimension: Abstention; Question: Did the assistant decline when evidence was absent or conflicting?; Example evidence: Refusal, uncertainty and escalation route. - Dimension: Permission safety; Question: Was the evidence allowed for this role?; Example evidence: User, policy decision and retrieved IDs. ## Check groundedness and factual correctness For each answer, mark every material claim as supported, unsupported, contradicted or not applicable. Numbers, names, dates, thresholds and "always" statements deserve special attention. Compare the answer with the current approved source, not with another model's opinion. An LLM judge can help sort a large queue, but it is not a truth oracle. A judge may reward fluent wording, overlook a missing exception or share the answer model's blind spot. Use a rubric, sample the disagreements, and require a human check for high-risk workflows. Product pages from Glean and Cleanlab describe useful metric and monitoring ideas, but their vendor context means you should validate the method on your own failures. ## Test citations, abstention and permissions Ask questions whose answers are not present. Ask about an old version when the current source changed. Ask with a role that should not see a restricted field. These negative cases are often more revealing than easy lookups. The answer should name the limitation, avoid filling the gap from general model memory, and route a source update or human review when the business process needs one. Q13 in this series covers keeping sources fresh; Q14 covers the permission checks that must happen before retrieved text reaches the model. ## Review failures by cause Store the question, model and retrieval settings, source versions, retrieved IDs, answer, citations, scores and reviewer decision. Hash or redact sensitive test data. When a case fails, label the cause before editing a prompt. - Observed failure: No relevant passage retrieved; Likely first check: Source freshness, headings, chunking, filters.; Safe next move: Fix the source or retrieval configuration, then rerun held-out cases. - Observed failure: Relevant passage retrieved but answer invents detail; Likely first check: Grounding instruction, context order, answer rubric.; Safe next move: Require claim support and add a negative test. - Observed failure: Answer is correct but citation is wrong; Likely first check: Citation mapping or source metadata.; Safe next move: Block release until the citation points to supporting evidence. - Observed failure: Administrator passes, ordinary user sees restricted data; Likely first check: Identity propagation and ACL enforcement.; Safe next move: Stop the workflow and test permissions before generation. - Observed failure: Assistant answers an unsupported question confidently; Likely first check: Abstention policy and fallback prompt.; Safe next move: Add an explicit no-evidence case and a human route. - Observed failure: Quality drops after a content or model change; Likely first check: Regression set and version comparison.; Safe next move: Compare failure categories, then approve or roll back deliberately. ## Set a release gate and rerun it Choose thresholds by risk. For a low-risk internal lookup, you may accept a few ambiguous cases with a visible citation. For a customer-facing or regulated workflow, require review of every high-risk case, zero permission leaks and a tested abstention path. Publish the thresholds with the test set so nobody can move them after seeing a bad result. Run the regression set after changing documents, chunking, embeddings, reranking, prompts, models, connectors, permissions or retention behavior. Keep a small fast set for every change and a broader scheduled set for coverage. A retrieval tester such as the one documented by GoHighLevel can be useful for a product-specific preflight, but it does not replace answer-key review or role-aware tests. ## Start with evidence you can explain You do not need a complex evaluation platform to start. A versioned table, a repeatable test script and a reviewer who can open the source are enough for the first workflow. Add automation when the manual process becomes slow, and preserve the raw failures so a dashboard does not erase the context. The goal is not to make an AI knowledge base produce a perfect score. The goal is to know when it is supported, when it is wrong, when it is not allowed to answer, and what changed. That evidence lets a team improve retrieval, documentation, permissions or prompts without guessing which layer broke.