Getting Trustworthy Answers Out of Your Own Documents

Why the model answers anyway

A language model predicts likely continuations of text from a lossy impression of its training data. Your own documents are almost certainly not in that training data — and where something like them is, the model still cannot tell you which version it is recalling. Ask about a clause that lives only on your file server and there is nothing to recall, but the model knows what such clauses usually say, and that is what comes back: something like the consensus of the termination clauses it has read, in the vocabulary of your question.

Confidence is the problem, not the error. Abstention is learned behaviour, not a built-in property, and nothing in the output separates a sentence taken from your contract from one imagined out of a thousand similar ones. A long context window changes the shape of the failure rather than removing it: instead of inventing a clause, the model may attend to the wrong one of several that look alike. How badly accuracy degrades with length is contested, so "it fits" is a starting point, not a guarantee.

What retrieval actually does

Retrieval reverses the order. Documents are split into passages and indexed in advance; when a question arrives, the system finds the passages likely to bear on it, puts them in the prompt, and asks the model to answer only from those and to say when they do not. The job shifts from remembering to reading — easier, but not free, since the same attention failures return once the retrieved set grows.

Finding them usually means combining two mechanisms that fail in opposite directions. Lexical search matches actual words: ideal for an invoice number, blind to paraphrase. Vector search compares embeddings — numerical representations trained so that similar meanings land nearby — and connects "can we exit early" to a passage headed "termination for convenience", while missing a rare literal string. Hybrid retrieval with a reranker that scores question–passage pairs directly is the common arrangement, at the cost of a second model in the path. Nothing downstream repairs a passage that was never retrieved: the model is handed an absence, and an absence looks exactly like a question the documents do not answer.

Most of the quality is in the chunking

A chunk is both the smallest unit the system can retrieve and the entire context the model gets about that part of the document. Split a table of lab values by character count — the default in most quick implementations — and the header row ends up in one chunk with forty data rows in the next, so the numbers arrive without their columns and the model borrows whichever labels are nearby: a tidy table with the values under the wrong headings.

Legal text breaks differently. "Either party may terminate this Agreement on thirty days' written notice" is a complete sentence and a natural boundary; the next begins "provided that no termination shall take effect while a Statement of Work remains open". Retrieve the first without the second and you are told, with a citation, that you have a thirty-day exit.

Two mitigations carry most of the weight: split on the document's own structure rather than on length, and keep tables whole or repeat the header on every serialised row. Neither has a universal setting: what suits contracts is wrong for lab reports and wrong again for slide decks exported to PDF, so write questions with known answers from your own material and measure.

Citations, and what they do not prove

An answer that names its source — page 61, this sentence — can be checked against the original in the time it takes to scroll there. For a contract, a policy or a medical report, checking is not optional, so an untraceable answer is worth close to nothing: you can neither act on it nor skip verifying it.

Citations prove less than they appear to. One tells you which passage the system had in front of it, not that the sentence it wrote follows from that passage. What helps is making the check cheap: quote the exact span rather than pointing at a page, and highlight it in the original layout, so the reader compares two texts instead of trusting a footnote number.

Scans and Arabic text

A scanned PDF contains pictures of pages, not text, so everything above rests on optical character recognition, which adds errors of its own before retrieval starts. Character mistakes are expected; the dangerous ones are well formed — a 1 read as a 7, a stray decimal point. A misread dose still looks like a dose, flows into the answer, backed by a citation pointing faithfully at the passage it came from.

Arabic contributes three problems usually discussed as one. The first is extraction order: a PDF stores glyphs with coordinates, not sentences, and the extractor reconstructs reading order. Mixing Arabic with Latin — a product name, a URL, a Western-digit figure in an Arabic paragraph — is where that reconstruction fails; some producers also store runs in visual rather than logical order, so a naive extractor returns reversed words.

The second is shaping. Arabic letters take different forms by position, and some PDFs encode those presentation forms — Unicode U+FB50–FDFF and U+FE70–FEFF — not the base letters, so lam-alef arrives as one ligature and a normally spelled query matches nothing. Normalisation belongs at index time and query time alike: presentation forms mapped back to base letters, alef variants unified, tashkeel stripped, Arabic-Indic digits folded against Western ones. Some extractors also lose word boundaries, returning a line as one run-on string that defeats a lexical index built on whitespace tokens.

The third is recognition quality. Arabic is cursive, letters overlap vertically in ligatures, and the baseline is only semi-continuous — which is why the segment-then-classify pipelines that once carried Latin OCR never worked for it. Today's engines read a whole line at once and skip the problem, but those properties still make recognition harder: several letters differ only in their dots, and a speck of scanner noise turns a word into a different, perfectly valid word. The accuracy figures people quote come from clean printed pages, and the gap against Latin widens on the worn paperwork real archives are made of.

What this approach cannot do

Retrieval answers questions a handful of passages can answer; it does not reason across a corpus. "How many of our four hundred contracts auto-renew" requires reading four hundred documents, while a retriever returns the ten passages most like the question, and a model given ten passages produces something shaped like a count. Aggregation and "find every instance of" are extraction-and-database problems wearing a chat interface.

It is weakest on absence and on implication. Nothing can be retrieved for a clause that is not there, so the honest output is "I found nothing", which is not "there is nothing". And documents mean more than they say: a radiology report may list findings a clinician reads at once as concerning without the word appearing. The system reads what is written; someone has to know what it implies.

Document-grounded tools, MentronX's Firas Brain among them, are built for this shape of problem: index your own material, answer from retrieved passages, cite them. The limits above are theirs too.