Goodbye Vector DBs - building a Local LLM Wiki with OKF and Hermes

🧗 The Challenge
Too many AI architectures are hyper-fixated on high-overhead retrieval models. We are told we need a vector database, embedding pipelines, chunking heuristics, and complex search infrastructure just to help an agent answer basic questions.
The problem? RAG is a loop of constant rediscovery. Every single time you ask a subtle question, your agent retrieves isolated, raw text chunks and attempts to piece the context together from scratch. Nothing compounds. Nothing accumulates.
(For details on configuring the local models and hardware engines powering this pipeline, see Run AI Locally, It Works!).
💡 What's cool?
Instead of RAG lookups at query-time, compile your knowledge at ingest-time. By using Google’s simple Open Knowledge Format (OKF), you can replace vector database subscriptions with a plain directory of markdown files. Obsidian becomes your IDE, a local LLM compiler updates interlinked concepts automatically, and your knowledge graph compounds cleanly over time.
⚠️ Disclaimer & Scope
This setup runs entirely locally on your local machine. It replaces high-latency embedding models, vector database subscription bills, and chunk-retrieval drift with an elegant, file-based markdown graph that compiles knowledge once and keeps it evergreen.
🎯 The Solution
I dismantled my vector search and QMD setup for my openClaw agent. Instead, I migrated to a local, file-based LLM Wiki structured around Google’s Open Knowledge Format (OKF). Here is how the hands-off macOS pipeline works:
1. Capture (Telegram to TODO.md)
When I find an article or a YouTube video on my phone, I share the link directly to a private Telegram chat. The Hermes agent listens to this chat, extracts the URL, and appends it to a centralized TODO.md file on my Mac.
2. Scraping (TODO.md to RAW)
A local cron job runs on a schedule to monitor TODO.md. When new entries appear, it runs a Python scraper (or YouTube transcript downloader) to pull the full text, raw transcript, and metadata. This raw, immutable payload is dumped directly into a RAW/ folder.
3. Compiling (The LLM Wiki Job)
Once the raw source is stored, a local LLM-driven indexing job processes the new file. Instead of chunking it into vector database embeddings, it reads the source, identifies key concepts, and translates them into the Open Knowledge Format (OKF).
4. IDE Layer (Obsidian Visualizer)
Because OKF is just a directory of markdown files, I open my wiki folder directly in Obsidian. As noted in Andrej Karpathy’s LLM Wiki paradigm, Obsidian acts as the IDE, the LLM acts as the compiler/programmer, and the wiki is my persistent codebase. For a visual setup guide, refer to Wanderloots’ tutorial on building an LLM Wiki in Obsidian.
/my-second-brain/
├── RAW/ # Immutable source files (transcripts, markdown scrapes)
├── schema/ # System rules, templates, and agent guidelines
│ └── AGENTS.md # The agent constitution & behavior rules
├── wiki/ # The compounding OKF-compliant concept graph
│ ├── Concept-A.md
│ ├── Concept-B.md
│ ├── index.md # The flat master catalog of all concepts
│ └── log.md # Sequential audit trail of ingest & maintenance jobs
└── TODO.md # Ingestion queue populated by Hermes
Why OKF and Simple Folders Beat Vector DBs
Google’s OKF (Open Knowledge Format) is simple and transparent (you can watch a Google OKF format overview for more details). An OKF bundle is a folder of markdown files where each file represents a single curated concept (a tool, a runbook, an API, or a metric). Each concept file contains a small block of YAML frontmatter detailing its metadata (type, title, tags, timestamp) and plain markdown below. The concepts link to each other using standard wiki links ([[Concept]]).
When these markdown links interlock, they turn a flat directory into a rich, flattened knowledge graph that is lightweight and natively version-controlled via Git.
Query Flow Comparison: Vector RAG vs. LLM Wiki
To see why this distinction matters in practice, consider how both approaches handle different types of user questions:
-
Semantic Vector Search (Chunk Retrieval):
- Query Type: “Find specific quotes or past mentions of Hermes configuration.”
- Flow: Question → Text Embedding → Vector Cosine Similarity → Pull top 3 raw chunks → LLM synthesizes answer.
- Failure Mode: Fails when asked synthesis questions across 50 articles (e.g., “What are all the trade-offs we’ve documented for local LLMs across our research?”), because top-k chunking clips context boundaries.
-
LLM Wiki Search (Compiled Concept Graph):
- Query Type: “What is our architecture strategy for local agent memory?”
- Flow: Question →
index.mdcatalog lookup → Follow curated[[OKF-Concept]]links → Read pre-compiled concept file. - Payoff: The agent reads pre-synthesized, interconnected concepts compiled at ingest-time, eliminating retrieval hallucination.
📊 Conclusion & Insights
Because the local agent compiles knowledge at ingest-time rather than query-time, the wiki is a compounding artifact. When a new raw source is ingested, the agent doesn’t just write a single summary; it updates existing concept pages, flags contradictions with older articles, and weaves new facts directly into the graph.
The maintenance is cheap, local, and completely transparent. A missed lookup is just a bad line in index.md that I can easily edit myself—no mysterious black-box vector drift to debug.
When to Use Each Method & Hybrid Mode
| Search Method | Ideal Use Case | When to Avoid |
|---|---|---|
| Vector DB / RAG | Needle-in-a-haystack raw text lookup (e.g., “Find exact log line from yesterday”). | Synthesizing broader architectural topics or evolving system state. |
| LLM Wiki (OKF) | Compounding second-brain knowledge, architectural decisions, & concept graphs. | Rapid non-indexed log parsing or large unstructured raw PDF dumps. |
| Hybrid Mode | Use Vector Search over RAW/ dumps for point queries, and LLM Wiki over wiki/ for reasoning. |
- |
Hybrid Architecture Tip: Run a fast local vector search (e.g., QMD or sqlite-vec) strictly over your RAW/ dumps as a discovery assistant for the LLM compiler job. Then let the LLM write the compiled, verified output directly into your OKF concept graph in wiki/.
For enterprise multi-user environments where single-user markdown files hit concurrency limits, consider scaling out using database-backed memory layers like Redis Iris with Context Retriever MCP.
⏭️ Suggested Next Steps
If you want to transition from vector search to a local LLM Wiki:
| Stage | Implementation Step | Tooling / Strategy |
|---|---|---|
| 1. Capture Queue | Set up a central markdown queue file | Telegram bot + Hermes CLI or local webhook listener |
| 2. Storage Structure | Initialize a local directory schema | Separate RAW/ dumps from compiled wiki/ concept pages |
| 3. Compiling Engine | Run an LLM indexer job on new files | Local LLM script generating [[WikiLinks]] and updating index.md |
| 4. Visualizer | Mount folder into Obsidian | Graph view + file search for human-in-the-loop navigation |
🙏 Acknowledgments
Foundational LLM Wiki & Architecture
Open Knowledge Format & AI Operating Systems
- Google Cloud Platform: Open Knowledge Format (OKF)
- Cloud Codes: Google’s OKF Format Overview
- AI Impact: I Turned Karpathy’s Second Brain Into an AI Operating System
Scaling & Enterprise Context
Get new posts straight to your Gmail.


