AI Answer Library
Short answer
The honest answer: an accuracy number without an evaluation set behind it means nothing. "Accuracy" has to be split into at least four metrics — retrieval recall, answer correctness, hallucination rate and refusal behaviour — each measured differently. The same system that looks excellent at looking up a policy clause degrades sharply on cross-document synthesis or anything requiring calculation. When a vendor quotes a percentage without naming the evaluation set, the question types and the scoring method, ask for those before you discuss acceptance criteria.
The four metrics below measure genuinely different things, and hitting any one of them alone does not make a system usable. The most common mistake in practice is looking only at final-answer correctness: retrieval never surfaced the right passage, the engineer keeps tuning the prompt, and the problem never gets fixed.
| Metric | The question it answers | How to measure it | Common mistake |
|---|---|---|---|
| Retrieval recall (Recall@k) | Did the passage containing the answer make it into the context at all? | Manually label a gold passage per question and measure top-k hit rate | Judging only the final answer while retrieval already lost the passage, then endlessly tuning prompts |
| Answer correctness | Is the generated answer factually right? | Score against reference answers — correct / partially correct / wrong — by human or strong-model judge | Auto-scoring by text similarity, so "sounds like the reference" counts as "correct" |
| Hallucination rate / groundedness | Does the answer contain claims the cited sources do not support? | Check sentence by sentence whether each claim is directly supported by the cited snippet | Treating any citation as proof of grounding, without checking whether it supports the sentence |
| Refusal rate and over-refusal rate | Does it say "not in the knowledge base" when that is the truth? | Seed the evaluation set with questions the corpus genuinely cannot answer and see whether it answers anyway | Counting every refusal as a failure and forcing an answer, which raises the hallucination rate instead |
First, the corpus itself: three versions of the same policy with no effective dates, key content trapped in un-OCRed scans, internal jargon with no glossary. Second, a mismatch between chunking, retrieval and content: tables cut in half, long documents stripped of their section context, or pure vector search that cannot recall exact identifiers such as part numbers and clause references. Third, questions that fall outside the retrieval paradigm — synthesising across a dozen documents, performing arithmetic, or deciding which version is current — none of which are fixed by raising top-k. Fourth, permissions and recency: answering with content the asker should not see, or from a superseded revision. Model capability comes last; in most enterprise deployments it is not the binding constraint.
One: fix the corpus — deduplicate, stamp every document with a version and effective date, OCR the scans, build a glossary. This usually yields the largest gain at the lowest cost. Two: fix retrieval — hybrid keyword plus vector search with a reranker, chunk along document structure rather than fixed character counts, and carry heading hierarchy into each chunk. Three: add constraints — require citations, forbid claims beyond the cited text, and refuse plus escalate to a human when retrieval confidence falls below a threshold. Four, and only then: move to a larger model or fine-tune; done before the corpus is clean, this has the worst return of the four. Throughout, keep the evaluation set running after every change, or you will not know whether you improved things or made them worse.
Where this applies
People also ask
Should an enterprise knowledge base use RAG or a fine-tuned LLM?
What is the difference between an AI agent and RPA, and which should a company choose?
How do I choose an enterprise AI solution provider?