Better answers begin with better documents

A retrieval-augmented system does two things. It finds passages in a document collection, then asks a language model to answer from them. When the answer is wrong, attention goes to the model. Often the fault sits earlier: the search found an old draft, a table that lost its columns, or a scan read as noise.

This article covers the preparation work that decides answer quality. It reflects public tools and guidance available in July 2026. Tool behaviour changes between versions, so every pipeline deserves its own test.

Start with an inventory

Before anything is indexed, someone lists what exists: the shares, mail archives, scanned records and exports that might go in. For each source, the inventory records its owner, its languages, its format, how often it changes, and who may read it.

The inventory also records what stays out. Not every file helps. Personal folders, obsolete templates and bulk exports add noise and risk without adding answers. Monaco’s Loi n° 1.565, Article 4, asks that personal data be adequate, relevant and limited to what the purpose needs, and accurate and kept up to date where necessary. How that applies to a given collection is a question for the firm and its counsel. As a design habit, a smaller, deliberate collection is easier to protect and gives cleaner answers.

One document, one current version

Firms keep drafts. A clause may exist in six versions across mail threads and folders. If all six are indexed, the search may return the first draft, and the answer will cite it with confidence.

Three measures reduce this:

• Remove exact duplicates before indexing, by file hash.
• Mark status where the firm’s records allow it: draft, signed, superseded.
• Prefer the governing version in retrieval, and show the version and date beside every cited passage, so the reader can see what the answer rests on.

Some duplication is legitimate. A signed agreement and its annotated copy may both matter. The rule is not to delete, but to make the difference visible.

Scans need reading before they can be searched

A scanned page is an image. Until optical character recognition turns it into text, the system cannot find a word in it. OCR quality depends on the scan. The Tesseract documentation, as revised in February 2026, advises images of at least 300 DPI, explains that skewed pages sharply reduce line segmentation quality, and covers noise, borders and binarisation. Each of these is fixable at the scanning or preprocessing stage, not after indexing.

OCR also needs the right language setting. A French page read with English settings loses accents and misreads words. For collections that mix languages, the language of each document belongs in its metadata, set before OCR runs.

A sample check pays for itself: pull a handful of OCR outputs from each source and read them against the original pages. Where text is unreadable, the page is either rescanned or flagged as unsearchable, so an answer never rests on garbled text.

Layout carries meaning

PDFs store text by position on the page, not by reading order. Two columns can merge into nonsense. A table can flatten into a stream of numbers with no headers. Headers and footers repeat on every page and pollute search.

Layout-aware conversion tools address this. The Docling technical report describes an open-source, MIT-licensed PDF converter that uses dedicated models for layout analysis and table structure recognition, and runs on commodity hardware. Tools like this run locally, which suits a private deployment. Any converter still needs checking on the firm’s own documents: forms, financial statements and signed scans each behave differently.

Chunk along the document’s own structure

Documents are split into passages, or chunks, before indexing. Split at arbitrary lengths, and a clause loses its heading, a definition loses its term, a table row loses its column names. Split along headings, articles and sections, and each passage carries its own context. A good chunk also keeps metadata: document title, date, version, section heading and access label.

More context is not a fix. Liu and colleagues found that language models often use information best when it sits at the beginning or end of a long input, and worse when it sits in the middle, even for models built for long contexts. Precise retrieval of the right few passages tends to serve better than feeding the model everything.

Access labels travel with every passage

Each chunk must carry the permissions of its source. The OWASP entry on vector and embedding weaknesses calls for permission-aware vector stores with strict partitioning between user groups. It also calls for data validation and source authentication, since poisoned or unverified content in a knowledge base can steer answers. A document that enters without an owner or a label should wait until it has both.

Upkeep is part of the system

A collection drifts. Files are added, contracts are superseded, people leave. A maintained system re-indexes on a schedule, removes deleted files from the index, updates permission labels when access changes, and keeps a log of what went in and when. Each change of converter, OCR engine or chunking rule gets tested against a fixed set of questions before it reaches users.

A useful practice closes the loop. When a user flags a bad answer, the reviewer traces it to its cause: the model, the retrieval, or the document itself. When the cause is the document, the fix belongs in the collection, not in the model.

To prepare a document collection for a private system, write to contact@desgarde.com.