A retrieval-augmented generation (RAG) system that can't show its sources asks users for faith. They give it once. After the first confident wrong answer, they go back to reading the documents themselves, and the feature is dead.
So the useful question isn't "how accurate is it?" It's "how quickly can a user check it?" That question changes what you build.
Why checking is the product
On BoardLens, an AI platform for boards and funds, every insight cites the page it came from. Its users are chairs, committee members and directors preparing from long board packs, with little time. A director who repeats a figure in a board meeting needs to know where it came from, and needs to find it in seconds. A summary they can't trace is worse than no summary: it costs them the time to check it and the risk of being wrong in the room.
The same holds anywhere a wrong answer has a cost: legal, finance, compliance, health, internal policy. In those settings the citation isn't decoration. It is the feature.
Citations that mean something
Most RAG demos cite a document. Users need a citation they can check: a page, a clause, a row in a table.
- Keep the location through parsing. Every chunk should carry the document ID, the page number and the nearest heading. If your parser throws page numbers away, nothing later can get them back.
- Ask for quotes, then check them. Have the model return the exact sentence it relied on for each claim. Then check, in code, that the sentence really is in the cited chunk. It is a string comparison, it costs almost nothing, and it catches a whole class of invented citations before a user sees them.
- Show the source in place. A click on a citation should open the page with the passage highlighted, not a file to download and search.
- Allow "it's not in the documents". If retrieval finds nothing relevant, the right answer says so. A prompt that demands an answer every time will get one, true or not.
- Separate what the documents say from what the model infers. Label analysis as analysis. Users forgive a careful answer. They don't forgive a confident guess.
Parsing: the part that decides everything
Most RAG quality problems start before retrieval. If the text going in is wrong, nothing downstream can fix it.
Board packs, contracts and reports are hard to parse. They have tables that break across pages, two-column layouts, headers and footers repeated on every page, scanned appendices, and charts with the key number inside the image. Plain text extraction turns a table into a list of numbers with no labels.
What helps:
- A layout-aware parser for anything with structure. Go Legal AI's live platform uses unstructured.io for its documents.
- A vision model for the hard pages. Pages that are mostly tables, scans or charts are better read as images, the way a person reads them.
- A second check on what matters. On a document-extraction proof of concept we built for a client, the first model's extraction was cross-checked by a second model, so a disagreement is flagged instead of shipped.
- Chunks that follow the structure. Split on headings, clauses and table boundaries rather than by token count alone, so each chunk is something a person would recognise as one idea.
Retrieval you can debug
When an answer is wrong, you need to know whether the system found the wrong text or misread the right text. They are different bugs with different fixes.
- Log what was retrieved for every answer, with scores. When a user flags a bad answer, you can see exactly what the model saw.
- Combine keyword and vector search. Vector search finds paraphrases. Keyword search finds names, figures and defined terms, and board packs and contracts are full of those. A reranker over the combined results usually beats either one alone.
- Filter before you search. If the question is about this quarter's pack, don't search last year's. A metadata filter is cheaper and more reliable than hoping the embedding works it out.
Evals before tuning
Without an eval set, every prompt change is a guess and every review is an argument about one example. Build the set before you tune anything.
- Collect 30 to 50 real questions from the people who will use the system. For each one, write down the expected answer and the page it should cite.
- Add a set of hard cases. On that same proof of concept, we tested against a 10-document adversarial set: documents picked because they were likely to break it. Ten hard cases teach you more than a hundred easy ones.
- Measure each part on its own:
- Retrieval: did the right page appear in the top results?
- Faithfulness: is every claim supported by the cited text?
- Citation accuracy: does each citation point to the passage that supports it?
- Refusal: when the answer isn't in the documents, does the system say so?
- Run the set on every change, in CI, the same way you run tests. A prompt change that lowers faithfulness doesn't merge.
- Use a model as a judge, and check the judge. A model can score answers at scale, but a person should spot-check a sample of its verdicts every week. Judges drift too.
Measuring the parts separately is what makes the scores useful. If retrieval scores well and faithfulness doesn't, work on the prompt and the model. If retrieval is the weak part, no prompt will save you.
The boring parts that keep it honest
These never make the demo. They decide whether the system still works in six months.
- Re-indexing. When a document is replaced, its old chunks must go. Stale chunks produce answers that cite a version that no longer exists.
- Access control at retrieval time. A user should only retrieve from documents they are allowed to read. Enforce it in the search, not in the prompt.
- Personal data. Decide what reaches the model provider. In the proof of concept above, personal data was removed on a local service before any cloud AI saw the documents.
- Cost per answer. Long contexts are expensive. Track model cost per answer from the start, and trim retrieved context to what the question needs.
- Feedback. A thumbs-down with a reason, linked to the trace, is the cheapest source of new eval questions you will ever have.
A short checklist
- Every chunk carries its document, page and heading.
- Every claim comes with a quote, and the quote is checked in code.
- "It's not in the documents" is an allowed answer.
- Hard pages go through a layout-aware parser or a vision model.
- What was retrieved is logged for every answer.
- An eval set, with a slice of hard cases, runs on every change.
- Access control is enforced in retrieval.
If you are building something like this and want a second opinion on the design, book a free call. Bring one bad answer with you. It is usually the fastest way to find the cause.