Give the assistant a narrow job
“Answer questions about the company” is not a testable job. “Help support agents find the current returns policy and cite the controlling document” is. The second version names the user, source boundary, answer type, and evidence requirement.
Define what the assistant must refuse or escalate. Legal interpretation, policy exceptions, safety questions, personal data requests, and conflicting sources often need an accountable person. Refusal is part of the product, not an embarrassing edge case.
Fix source ownership before retrieval
Retrieval can find a document. It cannot decide that an undated slide deck outranks a signed policy. Those governance decisions belong in metadata and source rules before a model generates an answer.
- Name the repository and document collections in scope.
- Identify an owner for each authoritative source.
- Remove duplicates, obsolete versions, and files without a clear status.
- Attach dates, document type, audience, region, and access metadata.
- Define refresh, removal, retention, and legal-hold behavior.
Design chunks around meaning
Chunk size is not a magic number. A chunk should preserve enough context to answer a question without mixing unrelated rules. Headings, clauses, tables, page boundaries, and document type can all influence the split.
Store metadata that supports filtering and investigation. Source URL, document version, section heading, permission group, and effective date are often more valuable than a slightly different embedding model.
Test queries that require a single precise passage, several passages from one document, and a comparison across approved sources. Watch for retrieval that is semantically similar but operationally wrong.
Preserve permissions
A shared index can become a quiet data leak if source access is lost during ingestion. The requesting user should receive only passages they are authorized to view. That may require per-user filtering, collection boundaries, or retrieval through the source system.
Minimize what is indexed. Sensitive identifiers, draft contracts, private personnel records, and unrelated attachments do not become safer because they are converted to embeddings. Document where content is processed, stored, logged, and deleted.
Test retrieval and answers separately
Build an evaluation set from real questions, awkward phrasing, missing answers, permission boundaries, and known conflicts. Keep expected sources and acceptable answer characteristics. A single thumbs-up button cannot diagnose which layer failed.
| Layer | Question | Useful measure |
|---|---|---|
| Source | Is the controlling material current? | Owner and review coverage |
| Retrieval | Did the right passage appear? | Relevance at tested rank |
| Generation | Does the answer stay within evidence? | Unsupported statement rate |
| Citation | Can the user verify the claim? | Claim-to-source coverage |
| Escalation | Did uncertainty reach a person? | Correct escalation rate |
Make citations useful
A citation should open the relevant source or passage, not a generic home page. The answer should distinguish quoted facts, synthesis, and a recommendation that still needs judgment. If the sources disagree, show the conflict rather than averaging it into a confident sentence.
High confidence should not come only from the model’s self-assessment. Retrieval scores, source quality, policy rules, and tested failure patterns can inform escalation, but none removes the need for review in material decisions.
Launch as a measured service
Reliability is an operating practice. The assistant will need source owners, evaluation, change control, and an incident route for as long as people depend on it.
- Start with a controlled user group and a documented source collection.
- Log questions, retrieved passages, feedback, and escalation without retaining unnecessary personal data.
- Review unsupported answers, missed sources, and stale content on a fixed cadence.
- Version prompts, retrieval settings, and source changes.
- Pause or narrow the assistant when a failure pattern cannot be contained.
Frequently asked questions
What makes a RAG system reliable?
Reliable RAG starts with controlled sources, permissions, representative evaluation, citations, monitoring, and clear escalation. A strong model cannot compensate for stale documents or unrestricted access.
How many documents do we need?
Enough authoritative material to cover the defined job, but no more than necessary. A smaller governed collection is often more useful than indexing every file in the company.
Does RAG stop hallucinations?
No. Retrieval gives the model relevant evidence, but it can still ignore, distort, or overextend that evidence. Test unsupported statements and require citations and human review where the consequence matters.
How often should a RAG assistant be evaluated?
Evaluate before launch, after meaningful model or source changes, and on a recurring schedule based on risk and usage. Review real failures and corrections, not only a static benchmark.
Primary sources and further reading
If this topic maps to a real process, document the current volume, exceptions, systems, data sensitivity, owner, and consequence of error before selecting a tool.
Request an automation audit
