3 min readGuides
Prepare the documents first, because retrieval only finds real text
Assemble your own documents into a corpus a local assistant can search, prepare the text so retrieval actually works, and understand what the answers cannot tell you.
The short answer
A personal knowledge base is only as good as the text inside it. Extract real text from every source, normalise it into one consistent format, and keep a record of what you deliberately left out. A local assistant can only find what you actually included, and it cannot tell you what is missing.
- Retrieval finds text, not pictures of text, so a scanned page contributes nothing until it has a real text layer.
- Normalise everything into one plain format before you add it, because inconsistent structure is what makes later answers vague.
- Write down what you excluded. A corpus cannot report its own gaps, and neither can anything reading it.
The appeal of a personal knowledge base is obvious: instead of searching your memory for which document said what, you ask a question and get an answer drawn from material you chose to trust. The disappointing part is usually the same for everyone. The answers come back thin, and it is not the model's fault. It is the corpus.
Almost all of the useful work happens before anything is queried.
Retrieval finds text, not documents
A search over your own material can only match text that exists as text. A scanned report, a photographed whiteboard, a slide exported as an image: all of these look like documents to you and are effectively blank to anything reading them. They occupy space in the corpus and contribute nothing to an answer.
So the first pass is mechanical. Take each source and check whether you can select a sentence from it. If you can, pull the text out and keep it. If you cannot, the page needs recognition before it is worth including, and the honest option is often to leave it out and note that you did.
This is the step people skip, and it is why a knowledge base assembled from a folder of scans answers everything vaguely.
One format, consistently applied
The second pass is about shape rather than content. A corpus assembled from half a dozen formats carries half a dozen conventions: different heading depths, different ways of marking quotations, tables that survived in one file and collapsed in another.
Converting everything to a single plain format removes that variance. Plain text has no hidden formatting state, diffs cleanly if you keep the corpus in version control, and renders the same way every time. When you want a readable copy of a note to file or share, export it to a paginated document rather than keeping the formatted version as the source of truth.
Consistency matters more than elegance here. A rough convention applied to every file beats a careful one applied to some of them.
Record what you left out
This is the habit that separates a corpus you can reason about from one you merely trust.
Every knowledge base is a set of decisions about inclusion, and those decisions become invisible almost immediately. Six months later you cannot tell whether a topic is absent because you judged it irrelevant, because the only source was an unreadable scan, or because you never encountered it.
Keep a short exclusions note alongside the corpus: what you decided not to include, and why. It costs a line per decision and it is the only thing that lets you distinguish a genuine gap from an accident.
What the answers can and cannot tell you
An assistant reading your corpus can find, compare, and summarise what is inside it. Two things it cannot do are worth holding onto.
It cannot tell you what is missing. A question about a topic you never added will still produce a confident-sounding answer assembled from adjacent material, because absence is not something retrieval can observe.
And it cannot arbitrate. If two of your sources genuinely disagree, a summary may present one position, both, or an average of them. Asking where sources conflict is a reasonable question, but treat the response as a pointer back to the documents rather than a verdict.
If you want to work this way on individual documents first, it is straightforward to ask questions of a single PDF before committing to a whole corpus, and the practical constraints of running a model on your own hardware are worth understanding before you scale up what you feed it.
On boundaries: the document work described here happens inside this browser workflow rather than through an upload to a conversion service. AI tools do download model files after you choose to use them, and those requests are visible in your browser's network panel if you want to confirm what happens.
Sources and further viewing
Tools used in this guide
Each workspace runs in this browser tab. Open one directly to apply the steps above to your own document.
Written by The PdfEditorOnlineFree team. Published . Product behaviour described here reflects the linked workspaces at the time of review; check the tool page for current limits.