RAG vs. Wiki (Agentic Retrieval)¶
Two strategies for giving an LLM access to a body of knowledge. Retrieval-Augmented Generation (RAG) fetches relevant chunks per query from a vector store; the karpathy-llm-wiki pattern compiles knowledge once into curated, interlinked pages the agent navigates. This wiki deliberately uses the latter.
Side by side¶
| Dimension | Traditional RAG | Compiled Wiki (agentic retrieval) |
|---|---|---|
| When work happens | Per query (retrieve → stuff → generate) | Once, up front (curate → cross-link) |
| Infrastructure | Vector DB + embeddings pipeline | Just markdown files + an agent |
| Cross-references | Rediscovered each time | Already present as wiki-links |
| Contradictions | Not handled | Flagged during curation |
| Retrieval method | Embedding similarity search | Agent reads index, greps, follows links |
| Compounding value | Low — each query independent | High — each ingest enriches the whole |
| Best for | Huge, fast-changing corpora | Personal/domain KBs, ~hundreds of pages |
| Weakness | Chunk relevance is noisy; no synthesis | Curation cost; scales worse to millions of docs |
Verdict¶
For a personal or single-domain knowledge base (this box's use case), the wiki pattern wins: no vector infrastructure, better synthesis, portable markdown you own. RAG remains the right tool for very large or rapidly-churning corpora where up-front curation isn't feasible. They're not mutually exclusive — a wiki can sit over a RAG layer.
Related¶
- karpathy-llm-wiki — the pattern this wiki uses
- ollama — retrieval works with local or hosted models
- hermes — the agent doing the agentic retrieval here