How to build a powerful LLM knowledge base (TDS)
A Towards Data Science how-to (Eivind Kjosbakken, 2026-06-27) on standing up an LLM knowledge base — an LLM reasoning over your own accumulated organizational/personal context. It sits squarely in the llm-wiki / gbrain lineage (it cites both — Karpathy’s LLM wiki and Garry Tan’s GBrain as its examples), and it sharpens that thread in two ways: it names the retrieval dichotomy explicitly, and it argues the real bottleneck is capture, not retrieval. T4: a practitioner how-to (no original data/benchmark); the value is the framing, not authority.
Two inference methods
The article frames the read side as a choice between two approaches, which map cleanly onto the llm-wiki ↔ gbrain spectrum:
- Grep-based inference. A top-level markdown file indexes the knowledge base and the LLM finds
context by text search — no embeddings. This is the index-only, maximally-legible end
(and, reflexively, exactly how this wiki-hub works: an
index.mdthe agent greps). - Embedding-based inference. RAG-style retrieval over embeddings, with gbrain as the cited production example — the autonomous, hybrid-search end.
Capture is the bottleneck, not retrieval
The article’s distinctive claim: information-capture completeness is the primary challenge, not the retrieval architecture. Its prescriptions are about getting context in, automatically:
- Automation-first capture. Context should flow from many sources — meetings, project tools (Linear), coding agents, office discussions — into the base via automated daily cron jobs. “You need to figure out a way to automatically do this to have your knowledge base up to date.”
- Passive agent integration. Coding agents should continuously draw on the base while they work, rather than waiting to be explicitly queried.
So the verdict is practical automation over sophisticated architecture — a useful counterweight to a thread that has mostly debated retrieval and representation (retrieval-augmented-generation gaps, typed edges); here the harder problem is the unglamorous ingestion pipeline.
Why it matters here
It is a fifth independent voice on the llm-wiki/gbrain “LLM + persistent markdown brain” pattern, and the first to foreground the capture/ingestion side of that loop — Bush’s “who fills the trails?” rather than “who maintains them?”. The grep-vs-embedding framing also gives the spoke’s autonomy spectrum a clean read-path axis.
Related
llm-wiki · gbrain · andrej-karpathy · garry-tan · retrieval-augmented-generation · knowledge-graph · llm-wiki-agent · memex