A Personal Knowledge Base with AI

The tool that deliberately left AI out

The example in this article is one specific note-taking program, because there is something worth knowing about it that is rare in 2026.

Obsidian is alive and actively developed: the latest release is 1.14.1, dated 8 September 2026. The releases of recent weeks are about the editor, quick capture on mobile and accessibility.

It has no official AI feature, and that is a direction, not a gap. AI capability comes exclusively from community plugins — meaning you decide whether anything goes to the cloud at all. In a folder that holds everything from your clients' names to your salary negotiations, that is not a small consideration.

On top of that the notes are plain markdown files in a folder on your own machine. If the program disappears tomorrow, your notes stay.

The measurement that matters most: structure makes a tenfold difference

This is the spine of the article, and it is far more general than any single program.

When an AI searches through your notes, it does not read the whole file. It cuts it into chunks, turns the chunks into numbers, and hands back the chunk closest to your question. The way it cuts decides how good the hit is.

A March 2026 study compared 36 chunking methods across six domains, with five different embedding models:

A tenfold difference — out of the same material. The study's own wording is that content-aware chunking meaningfully improves retrieval compared with naive, fixed-length splitting.

What follows for practice: a three-thousand-word wall of untagged notes gets cut into fixed lengths by the system, and that is where the 2–3% comes from. The same material, arranged into sensible paragraphs under headings, gives twenty-four.

So the question is not how many notes you have. It is whether your paragraph boundaries line up with your units of thought.

What runs locally

One of the main arguments for a personal knowledge base is that nothing has to go to the cloud. That is genuinely workable today, and it is worth knowing what it means in practice.

It takes two different models, and this is where people get confused:

• An embedding model, which turns your notes into numbers so they can be searched. This one is small and fast. The most popular model of this kind is the fourth most downloaded model on the local runtime, with eighty-five million downloads — meaning local semantic search is established practice today, not an experiment.
• A language model, which writes an answer out of the chunks it found. This one is the big, slow one.

The language models meant for a laptop start at around 7 GB today in the largest open families, with a 128,000-token context; the workstation versions run between 8 and 20 GB, with a larger context. The makers explicitly mark which version they intend for laptops and phones.

One thing, though, is not worth believing from anyone: the big runtimes publish no concrete memory-requirement table. The download size is known, the minimum machine spec is not — your own machine will tell you that.

What the plugins can do

Three live, verified plugins, as of September 2026:

The multilingual local embedding model is the most important row in that table. For notes in a language other than English, English-tuned models are noticeably weaker, and until now that was the main limit of the local setup.

When does it slow down?

This has to be answered honestly: there is no published size limit or performance curve.

What exists is user reports on the official forum — with no sample size and no method, so not data. Two recurring patterns can still be read out of them:

• the complaints tend to be tied not to the number of notes but to attachments;
• filename quick search stays fast even when full-text search slows down — which makes sense, since the two use different indexes.

But the more important answer comes from the measurement above: what ruins search quality is not primarily volume, it is structure. The 2–3% hit rate does not come from having a lot of notes.

What the knowledge base solves, and what it does not

Here is the most common exaggeration, and it is worth shooting down straight away.

Search built on your own vault improves retrieval: it makes the model look at your material instead of guessing from its head. That is real and measurable.

But it does not eliminate hallucination. The best evidence does not even come from note-taking: the market-leading research tools wired to their own legal databases — systems built in exactly this shape — hallucinated in 17–33% of cases in a preregistered measurement. The study's wording is precise: hallucination drops compared with general chatbots, but it does not disappear. There are numbers on that in the drafting contracts, offers and reports post, one document type at a time.

And on whether a personal vault improves answer quality, there is simply no published measurement. What we do know: structure makes a tenfold difference in retrieval, and if the model cannot find the note, the note improves nothing.

So the knowledge base solves finding, not truth.

The how-to

1. ONE NOTE = ONE TOPIC
   If it covers two things, make two files. The split
   respects file borders and headings — not your ideas.

2. BREAK IT UP WITH HEADINGS
   Not formatting: this is what says where it can cut.
   This is the difference between 24% and 2–3%.

3. PARAGRAPH = ONE THOUGHT
   Four to eight sentences. Three thousand words of
   unbroken prose is the worst case.

4. PUT THE DATE IN THE TEXT
   Not just in the file metadata. In the measurements
   this is the metadata that helps.

5. SEARCH FIRST, ASK SECOND
   Look at what it finds for your question. If it pulls
   the wrong notes, the answer will be wrong too.

6. LOCAL EMBEDDING IF THE CONTENT IS SENSITIVE
   The small model is enough for search. Bringing in
   the big one is a separate decision.

The sixth point gives the best practical compromise: let indexing and search run locally, and let the drafting go to your usual subscription — that way your whole vault never leaves the machine, only the few paragraphs you are asking about.

The fifth point is the one check that genuinely counts. If the system shows you which notes it worked from, you can see in two seconds whether the answer is backed by anything. If it does not show you, you cannot know — and that setting matters more than any choice of model.

Common misconceptions

• "The more notes I have, the better it gets." The measurement says structure counts, not volume. Out of untagged material the hit is ten times worse.
• "A heading is just formatting." Chunking uses headings and paragraph boundaries as cut points. This is the cheapest quality improvement that exists.
• "If it works from my own notes, it cannot hallucinate." It can. Professional systems wired to their own database hallucinated in 17–33% of cases in a preregistered measurement.
• "Running it locally is complicated." The small model needed for search is in mass use today. It is the big model that is hardware-hungry — and search does not need it.
• "You need an AI note-taking app." You do not. The note-taker can be one with no built-in AI at all — the capability comes from the plugin, and that way you decide what goes to the cloud.

What to take away

With a personal knowledge base, most of the work is in the note-taking, not in the choice of tool. Headings, one topic per file, readable paragraphs, a written-out date — and the structural half of that, the headings and the paragraph boundaries, is what makes a tenfold difference to whether the machine finds what you are looking for.

And one boundary worth keeping clean: the knowledge base improves finding, it does not replace checking. The answer coming from your own note does not save you from looking at whether it really says that.

How the note-taking itself should be built for this is what the note-taking that feeds your AI post walks through step by step; and the order of reading and research is handled by the reading and researching faster post.