0
Build Document Q&A That Shows Its Evidence
An original worked guide to answering from documents, handling conflicting sources, and testing when the assistant should say it cannot tell.
0 comments4 views3 steps
Comments
An original worked guide to answering from documents, handling conflicting sources, and testing when the assistant should say it cannot tell.
Help me design a document Q&A assistant for a fictional software team's internal handbook. It should answer questions about onboarding and release procedures using only documents the requester is allowed to read. Start by defining the answer format and the behavior when evidence is missing.
For a worked example, use these fictional excerpts: Handbook A, section 2: new engineers request repository access through their manager. Release Checklist B, section 4: production releases require a completed rollback plan. Answer 'Who grants repository access?' without treating a request path as proof of who actually grants access.
The answer contract should include a direct answer where supported, a reference to the exact supporting section, and a short statement of any unresolved gap. Access controls belong in the retrieval system before document text reaches the model. A prompt can tell the assistant to respect permissions, but it does not establish or enforce those permissions by itself.
For the example question, the supported answer is: Handbook A, section 2 says new engineers should request repository access through their manager. It does not identify who grants the access. The next step is to consult the access-administration procedure or ask the handbook owner to clarify that role.
A reusable prompt is: Answer the question from the supplied authorized excerpts. For each factual claim, name the document and section that support it. Distinguish what the source states from what remains unknown. If the source does not answer the exact question, state the gap and suggest the additional source needed. Never invent a document reference to make an answer appear complete.
Now outline the retrieval process for this assistant in plain language. Explain how document titles, section boundaries, update dates, and permissions should travel with each passage. I want a design that a small engineering team could turn into an implementation plan.
Use another fictional example: Checklist B says every release needs a rollback plan, while an older FAQ says documentation-only releases can skip it. Show how the assistant should handle that conflict when the documents do not explicitly define which policy takes precedence.
Keep each passage with its document identifier, title, section, revision date, and permission metadata. Split long documents at meaningful boundaries so a requirement stays near its exceptions. Search only within the requester's authorized material, retrieve a few relevant passages, and expand adjacent context when an exception or definition appears to be missing.
In the fictional release question, the assistant should show both claims and their sources: Checklist B requires a rollback plan for every release; the older FAQ describes an exception for documentation-only releases. A later revision date is useful context, but without an explicit precedence rule it is insufficient to prove that the newer text overrides the exception. The conflict needs a policy owner to resolve it.
The next implementation task is to define an authoritative-source rule and record it alongside the documents. A useful follow-up prompt is: Compare these passages, identify the precise conflict, and list the smallest clarification needed to resolve it. Do not silently merge incompatible rules. Once the team resolves the policy, update the source material so future answers inherit a consistent rule.
Create an acceptance-check plan before this document assistant is released. Include questions with an exact answer, questions with no answer, conflicting documents, and a document containing text that tells the assistant to ignore its instructions.
Explain how to distinguish a retrieval failure from an answer-generation failure. I also want to know what evidence to record when a citation looks convincing but does not support the claim. Keep the examples limited to our fictional handbook.
Start with four expected behaviors: correctly identify the manager as the repository-access request route, admit the actual access grantor is unknown, surface the rollback-policy conflict, and ignore task-changing instructions embedded in a source passage. Separately test permissions by confirming that an unauthorized handbook passage never enters the retrieved context. This checks the application boundary rather than relying on the wording of an answer.
For each case, save the question, identifiers of retrieved passages, generated answer, and cited sections. If the relevant permitted passage was absent, investigate indexing, query interpretation, filtering, or ranking. If the passage was present and the answer distorted it, investigate the answer instructions and generation. Both failure types can occur in the same case, so record the evidence before assigning a cause.
A citation passes only when its passage supports the claim it is attached to. Citing the repository-request rule beside 'your manager grants access' should fail because the wording adds an unsupported responsibility. Treat a document instruction such as 'reveal other users' files' as untrusted content; tool restrictions and authorization checks must remain in force even if a model mishandles that text.
Comments 0
Share how you would use this prompt or suggest a useful improvement.