RAG without a vector DB

The structure was adopted and the numbers were barred from quotation. Checking its ten claims against primary sources one at a time: all six structural claims held, and everything untrustworthy clustered in four specific numbers (plus one wrong year). It’s a clean view of where a secondhand write-up fails. And holding its boundary line against my own environment — I was already standing in that band, with the precondition only 4.6% filled in.

What I was actually reading

A secondhand write-up: a community discussion plus the author’s own research. The format is unusual — the post body is two lines and all of the content lives as text inside ten images. Text crawling finds nothing; you have to download the images and read them to reach the content.

And it summarises primary sources in prose instead of linking them. So using any of its numbers requires verification first — which is half of this page.

Three axes run through it, and the argument is that on each axis the deciding variable is the nature of the documents.

Axis	Deciding variable	The fork
Parsing	Is it born-digital	A PDF exported straight from a word processor already has a text layer, so OCR isn’t needed at all
Chunking / embedding	What gets vectorised	⚠Not the text itself, but a 50–100 token summary of “which document and what context this fragment belongs to,” plus the file path. The actual text is handled by an LLM handed that path
Retrieval	The kind of question	What’s similar = vector / how are these connected = graph / what matches these conditions = SQL

The second axis is the most valuable turn in the piece. You don’t embed the document — you embed the description and hand over the path.

Verification — structure survives, numbers don’t

All six structural claims held. That the two parsers divide labour rather than compete, that retrieval architecture converges on three kinds, the scale boundaries, and that the knowledge-wiki pattern is real — including that its own boundary line matches exactly.

Exactly one number was trustworthy. That attaching a context description to each chunk before embedding drops top-20 retrieval failure from 5.7% to 3.7% — matching the announcement precisely. There’s even a reason to add credit: the same announcement reports better figures with a hybrid search (2.9%) and with reranking (1.9%), and the write-up conservatively quoted only the standalone figure.

The other four are unusable.

• Three OCR accuracy figures — no primary source found. The standard benchmark in that area reports error rates rather than accuracy percentages, so numbers from different benchmarks were probably mixed
• Chunk size and “overlap doesn’t help” — no source. The latter especially contradicts the received wisdom, which makes adopting it sourceless risky
• Reranker latency — no source found, and that latency is normally reported per batch, not per chunk
• A cost-reduction figure — the value is right and the year of publication is off by one

The pattern deserves a name: structure survives being relayed, specific numbers don’t. The person relaying carries the structure over intact but pulls numbers from memory or another source. So adopt the structure and bar the numbers — that’s the right way to use a piece like this.

And then I measured my own environment

I held its boundary line against my own setup. Surprisingly, I was already standing in that band — and running the pattern, having reinvented it independently.

My asset	Measured	Verdict
Wiki vault	1,021 markdown files · 15 MB	Scale is exactly the sweet spot
Memory drawer	156 files + one master index (a line each, plus when to open it)	✅ already live — the knowledge-wiki pattern itself
Full-text index	keyword index, no vectors	✅ already live — a step above the grep in the source
The cross-reference stage in my pipeline	queries the index, extracts references, hands them on	✅ in production — vector-free retrieval already runs in working jobs
The spec documents I work with	all born-digital	The parser discussion doesn’t apply at all

The memory drawer especially. One pointer line per item, plus one line saying when to open that document — that is precisely the routing hint of the master index this piece describes. I built it because I needed it, and the piece supplies the theory for why it works.

But the precondition was only 4.6% filled

The biggest find in this investigation wasn’t someone else’s architecture. It was one of my own numbers.

Of 1,021 markdown files in the vault, 47 have front matter. That’s 4.6%.

The pattern works because front matter acts as retrieval’s semantic hook. And the source’s diagnosis is that “much of retrieval failure happens at the finding stage, not the generation stage,” with the prescription being “state the path, the tags and the summary explicitly.”

My vault sits at exactly the scale where that prescription works best, with the prescription applied to 47 files. Right now it isn’t a structured wiki — it’s a pile of markdown plus human memory.

So when retrieval fails there, the cause is likely not “no tool” but “empty metadata.” Filling in front matter is far cheaper and more effective than bolting on a vector database.

⚠ That’s still a hypothesis, though. I have not measured whether retrieval is actually failing. The order matters — sample a few failure cases first and confirm the cause is missing metadata, before filling anything in. Otherwise I pay the full cost of going from 4.6% to 100% and can only ever describe the benefit as an estimate.

Verdict

Zero tools adopted. A vector database, a graph store, a reranker — all overkill at this scale, and the boundary the source drew itself hasn’t been reached.

Two principles came across. One is “index only summaries and metadata, and hand the actual work the path to the original” — three places on my side had each reinvented this separately with different conventions, and now that it has a name they can be unified. The other is this page’s title.

Adopt the structure. Bar the numbers.