Do not approve a knowledge assistant because its best five answers look impressive.
A useful evaluation tests whether the system finds the right evidence, produces supported answers, handles missing or restricted information safely, and improves a real task across representative users and questions.
Define what “good enough to release” means before the demo.
Agree on the users, decisions, source systems, allowed answer types, unacceptable failures, and current performance baseline. A support assistant, policy assistant, and field-operations assistant should not share one generic success score because their consequences and evidence requirements differ.
A release rubric with quality thresholds, zero-tolerance failures, human-review boundaries, and a named decision owner.
Build the evaluation set from work the assistant will actually encounter.
Common requests that establish baseline retrieval and response performance.
Rare terminology, multi-document answers, exceptions, and questions asked differently across roles.
Requests whose supporting information is absent, outdated, ambiguous, or outside the approved corpus.
Restricted sources, conflicting policies, prompt injection, sensitive data, and high-consequence guidance.
Inspect failures in the order the system produces them.
- Verify the corpus: confirm that approved, current evidence exists and the test user may access it.
- Inspect retrieval: check whether the necessary passages appeared and where they ranked.
- Inspect the answer: map material claims to retrieved evidence and validate citations.
- Inspect safe behavior: test abstention, conflict handling, escalation, and restricted requests.
- Inspect task value: compare accuracy, time, review effort, and corrections against the current workflow.
Prompt changes cannot recover evidence that retrieval never supplied. A good evaluation identifies the failing layer before proposing a fix.
Ask for evidence beyond a curated demonstration.
- Can we test with our documents, permissions, terminology, and representative questions?
- Can reviewers inspect retrieved passages and trace claims to citations?
- How are deleted, superseded, or newly restricted documents removed from results?
- What behavior occurs when sources conflict or do not support an answer?
- Can we export logs and rerun a fixed regression set after system changes?
- Which model, prompt, retrieval, and index versions are attached to each result?
A single “accuracy” percentage without the test set, scoring rubric, risk slices, and failure distribution is not enough evidence for a release decision.
A pilot should end with a release decision, not an indefinite experiment.
Critical controls pass, slice-level quality meets thresholds, and the workflow beats its baseline.
Limit users, sources, question types, or answer authority while specific gaps are corrected.
Pause when evidence quality, permissions, failure consequences, or operating ownership cannot be made acceptable.
Turn real failures into controlled regression tests.
Review corrections, escalations, low-confidence behavior, retrieval misses, and permission incidents on a defined cadence. Add representative failures to the versioned evaluation set, rerun it before each material change, and compare results by query and risk category.
Who can stop a release, roll back a change, correct a source, and communicate an incident when evaluation exposes a serious failure?
Evaluate the system as a workflow, not a model response.
The complete RAG and Knowledge-System Evaluation Framework provides the measurement layers and release gates. Use the Workflow Suitability Framework first if the team has not yet established that RAG is the right pattern.