Build a document Q and A feature with verifiable citations

A document assistant answers a policy question and appends three citations. One cited page discusses a different policy, another source is inaccessible to the user, and the answer includes an exception no document mentions. The presence of citations did not make the answer verifiable.

A useful Q&A feature connects claims to evidence the user can inspect. Retrieval, generation, and citation validation are separate responsibilities. This article uses an illustrative employee handbook assistant and explains how to build a bounded path from a question to an answer with honest limits.

Define the answerable domain

Specify which documents and questions the feature supports. A handbook assistant may answer leave-policy questions from approved handbook versions. It should not infer employment law, negotiate exceptions, or treat informal chat messages as authoritative policy unless the product explicitly includes them.

Define the unsupported outcome. If the documents do not establish an answer, the assistant should say what is missing and point to the appropriate next step. A forced answer can sound helpful while inventing policy.

Include version and jurisdiction context where relevant. Two handbook editions can contain conflicting rules. Retrieval should know which applies to the user or clearly present the conflict. A correct quote from the wrong version is still a bad answer.

Enforce access before retrieval results reach the model

Filter the corpus by trusted user identity and document permissions. Do not retrieve all documents and ask the model to hide restricted ones. The model should only receive content the user is allowed to use.

Store source identifiers, version information, and stable locations with each chunk. A chunk's text alone is insufficient for a reliable citation. The application needs to resolve it back to a document and a meaningful section or page.

Ensure citation links preserve access control. A signed link with excessive lifetime or a public URL for a restricted file can leak material even if retrieval was permission-aware. The answer and the source-viewing path must enforce compatible rules.

Retrieve evidence rather than merely similar text

A semantically similar chunk may mention leave but not answer the question about eligibility. Evaluate retrieval with questions whose required evidence is known. Check whether the relevant rule, exception, and definition are all available.

Use metadata filters where the contract provides them: document type, version, organization, or policy region. Similarity search should not override these boundaries. If the filter is uncertain, ask a clarifying question or present the uncertainty rather than selecting a convenient version.

Choose chunk boundaries that preserve meaning. Splitting an exception from the rule it modifies can lead to an incomplete answer. Include enough neighboring context for interpretation while keeping retrieval bounded. The best chunk size depends on document structure and the questions being asked, not a universal constant.

Generate claims with evidence references

Ask the model to return answer text and source references for factual claims. The references should point to the provided source identifiers, not arbitrary URLs generated from memory. Restrict citation identifiers to the retrieved set.

For the illustrative handbook question, a claim about eligibility should cite the eligibility rule. A claim about an exception should cite the exception. One citation at the end of a long paragraph can obscure which sentences are supported.

Allow uncertainty and disagreement. If sources conflict, the answer should identify the versions and avoid pretending they form one coherent rule. If the evidence supports only part of the question, answer that part and state the unsupported remainder.

Validate citations and important quotations

Check that every referenced source exists in the retrieved set and is accessible to the user. Verify quoted spans against the actual source text using a documented normalization approach. Reject fabricated source identifiers.

Citation existence does not prove entailment. A source can be real and irrelevant. For important claims, use a review step or evaluated claim-support checker, and validate that checker with deliberately unsupported answers. Human review may be appropriate for high-consequence policy applications.

Do not silently replace invalid citations with nearby sources. That can make an unsupported answer appear supported. Prefer regenerating within a bounded attempt limit or returning a failure that preserves the user's question and explains that a reliable answer could not be produced.

Build an evaluation set around evidence failures

Include answerable questions, unanswerable questions, conflicts, outdated versions, and inaccessible-source cases. Store expected evidence identifiers and forbidden claims. This lets you diagnose retrieval failures separately from generation failures.

If the right source was not retrieved, prompt rewriting alone may not fix the problem. If the right source was present but the answer invented an exception, focus on generation and verification. If citations point to unavailable documents, investigate access and link resolution.

Use AI assistance to propose synthetic questions and unsupported claims, then have a domain owner verify expectations. The related guide on prompt evaluation explains how to compare changes without relying on one attractive response.

Make the user experience support verification

Show sources near the claims they support and let users open the relevant document location. Include document version or effective date when it affects interpretation. A citation that opens a long file at an unrelated page creates unnecessary verification work.

Provide a clear unsupported state rather than a generic error. “The available handbook explains eligibility but does not state the approval deadline” tells the user what the system found and what remains unanswered. Do not imply that missing retrieval proves the policy does not exist.

Keep latency and cost proportional. More retrieved text can add context while also adding irrelevant material and provider cost. Measure retrieval quality and answer support as you adjust context size. The useful result is an answer whose evidence can be followed, with a reliable fallback when the corpus cannot support one.

Keep retrieval diagnostics distinct from the public answer. Engineers may need source scores, filters, and candidate identifiers to understand a failure, while users need understandable evidence and a next action. Use safe internal metadata to diagnose whether the correct version was excluded or an irrelevant chunk ranked highly. Avoid exposing raw ranking scores as confidence in the answer: a similarity score describes retrieval behavior, not the probability that a generated policy claim is correct.

Track source versions through the entire answer lifecycle. A document can change between retrieval and the user opening its citation. Where the product requires reproducibility, retain an approved version identifier or immutable source reference rather than linking only to the latest editable file. Make the viewing path show the version that supported the answer, or clearly explain when only the current version is available. This prevents a correct answer from becoming unverifiable because its evidence moved after generation.

Sources

Anthropic: Building effective agents discusses retrieval-augmented model calls and workflow checks.

Anthropic: Demystifying evals for AI agents discusses evaluating tasks and outputs.