LLM Knowledge Bases
Andrej Karpathy ยท tweet ยท 2026-04-10 Reader ๐ฅ๏ธ
LLMs can serve as compilers and operators of personal knowledge bases โ ingesting raw sources into structured markdown wikis, then answering queries, generating outputs, and self-improving the wiki โ shifting the human role from writer to curator and questioner.
practical ยท informal essay / social media post โ A practitioner's workflow description with implicit theoretical claims about knowledge management and LLM capabilities. Structured as a how-to with commentary on why it works.
Structure
| Part | Role |
|---|---|
| Data ingest | Describes the input pipeline: raw sources are indexed, then an LLM 'compiles' them into a structured markdown wiki with summaries, backlinks, and concept articles. |
| IDE (Obsidian as frontend) | Establishes that the human interacts with the wiki through a viewer, not as a writer. The LLM writes and maintains all wiki data. |
| Q&A | Shows the wiki as a queryable knowledge base. Claims that at moderate scale (~400K words), simple index-based retrieval works without fancy RAG. |
| Output and filing back | Describes a feedback loop where query outputs are filed back into the wiki, making exploration cumulative. |
| Linting / health checks | Introduces LLM-driven quality assurance: consistency checks, imputation, and connection discovery. |
| Extra tools and further explorations | Points toward scaling: custom search engines, CLI tools for LLM agents, and eventually fine-tuning to internalize the data in model weights. |
| TLDR / product vision | Summarizes the pipeline and asserts this workflow deserves to be a product, not a collection of scripts. |
Key terms
- compile Knowledge Base
Transform raw, heterogeneous source documents into a structured, interlinked markdown wiki using an LLM โ analogous to compiling source code into an executable. - wiki Knowledge Base
A local directory of interlinked markdown files maintained entirely by an LLM, serving as a structured knowledge base. - token throughput Token Throughput
The volume of LLM tokens consumed per unit time, here shifting from code generation to knowledge manipulation. - knowledge base Knowledge Base
A personal, LLM-compiled and LLM-queryable repository of structured information on a research topic. - RAG Retrieval & RAG
Retrieval-Augmented Generation โ a technique Karpathy expected to need but found unnecessary at this scale thanks to LLM-maintained indexes.
Propositions
- explicitcorroboratedLLMs are now good enough to autonomously compile raw source documents into structured, interlinked markdown knowledge bases.conf: highsupports โAn LLM wiki changed how I work ยท p1 โ Newton's month-long practitioner report โ roughly 1,440 auto-generated wiki pages, one running past 12,000 words โ is real-world confirmation that LLMs can sustain the autonomous-compilation workflow Karpathy described, at meaningful personal scale.extends โTony Seale's Post ยท p3 โ Karpathy holds that LLMs compile raw documents into structured, interlinked markdown knowledge bases. Vault-LD takes that markdown-KB and extends it with a formal semantic layer: YAML-LD frontmatter projecting the same files into a knowledge graph/ontology, so the base gains inference and validation the flat markdown version does not attempt.
- explicitdevelopedAt moderate scale (~100 articles, ~400K words), LLM-maintained indexes and summaries are sufficient for complex Q&A without vector-search RAG.conf: highextends โMeta's Recipe for Building Agents as "Organizational Second Brains" ยท p8 โ Extends Karpathy's personal-scale (~100 articles) claim that LLM-maintained indexes obviate vector RAG to an enterprise-scale, governance-heavy compliance domain with 200+ files.
- implicitThe human role in knowledge management is shifting from writer/organizer to curator/questioner โ the LLM should own the writing.conf: high
- implicitcorroboratedKnowledge bases should be accretive: every exploration and query should feed back into the base, compounding its value.conf: highsupports โAn LLM wiki changed how I work ยท p3 โ Newton's daily auto-generated concept pages (e.g. 'AI and Congress,' 'tokenmaxxing') that surface story ideas on their own are a concrete instance of the accretive, self-surfacing knowledge base Karpathy describes as the goal.
- explicitThe natural evolution of a context-window knowledge base is fine-tuning โ moving knowledge from context into model weights.conf: medium
- explicitThis workflow represents an unserved product category โ it should be a product, not a hacky collection of scripts.conf: high
- explicitThe most valuable use of LLM tokens is shifting from code manipulation to knowledge manipulation.conf: medium
Arguments
LLM-compiled personal wikis are a superior way to manage research knowledge compared to manual note-taking or traditional tools. strength: medium
Explicit premises:
- LLMs can incrementally compile raw documents into structured markdown wikis.
- The resulting wiki supports complex Q&A without fancy RAG at moderate scale.
- LLM health checks can maintain data integrity and discover new connections.
- Query outputs can be filed back, making the knowledge base accretive.
Implicit premises:
- Manual knowledge organization does not scale as well as LLM-driven organization.
- Markdown is a sufficiently expressive format for structured knowledge.
- The quality of LLM-generated summaries and categorizations is adequate for research use.
Inferences:
- Therefore, practitioners should shift from writing knowledge artifacts to curating LLM-generated ones.
- Therefore, this is a viable product category.
RAG is unnecessary at moderate knowledge base scale if the LLM maintains good indexes. strength: low
Explicit premises:
- The wiki is ~100 articles and ~400K words.
- The LLM auto-maintains index files and brief summaries.
- The LLM reads all the important related data fairly easily at this scale.
Implicit premises:
- Context window sizes of current LLMs are large enough to hold indexes plus relevant articles simultaneously.
- The quality of LLM-curated indexes is comparable to or better than vector similarity search for this use case.
Inferences:
- At small scale, well-structured text indexes outperform or match vector-search RAG.
Narratives
- Karpathy's personal journey from using LLMs primarily for code to using them primarily for knowledge management.
โ Establishes credibility and signals a broader trend โ if a leading AI practitioner is shifting usage patterns, others may follow. - The expectation of needing RAG, followed by the pleasant surprise that simpler LLM-maintained indexes sufficed.
โ Challenges the assumption that sophisticated retrieval infrastructure is always necessary, lowering the barrier to entry.
Questions addressed
- โ
How can LLMs be used for personal knowledge management beyond code generation?
By compiling raw sources into a structured markdown wiki, then querying and enhancing it iteratively. - โ
Is RAG necessary for querying a personal knowledge base?
Not at moderate scale (~400K words) if the LLM maintains good index files and summaries. - โญ What is the natural evolution of a context-window knowledge base?
Fine-tuning is mentioned as a direction but not yet implemented or evaluated.
Gaps
- unstated assumptionThe quality and accuracy of LLM-compiled wiki content is taken for granted. No discussion of hallucination risk, factual drift, or how errors propagate through an LLM-maintained knowledge base over time.
Read next: Literature on LLM hallucination in knowledge-intensive tasks; studies on error accumulation in iterative LLM workflows.closed byYou can't unit test for taste โ That doc takes the quality and accuracy of LLM-compiled wiki content for granted with 'no discussion of hallucination risk, factual drift, or how errors propagate.' Tryggvason supplies exactly that missing discussion empirically: LLM enrichment of wiki-style content hallucinated (Central Park/Decatur conflation, inflated populations and mountains), and the mitigation is to ground the model in metadata, keep deterministic attributable sources (Wikipedia, 'a more known failure model' with attribution) authoritative for facts, and restrict the LLM to subjective scoring. - missing evidenceNo comparison with alternative approaches (manual Zettelkasten, vector-DB RAG, graph databases) to substantiate the claim that this workflow is superior.
Read next: Comparative studies of knowledge management approaches; Zettelkasten methodology literature.closed byAdrien Taravant's Post โ Partially supplies the comparison Karpathy's post lacked: nine named alternative architectures โ including git-based file approaches, a developer memory layer (mem0), self-managing agent memory (Letta), and a validity-dated knowledge graph (Zep/Graphiti) โ each with a one-line characterization of what it optimizes for. The comparison remains shallow (one sentence per system, no benchmarks or head-to-head data), so it closes the gap only partially. - unaddressed questionAt what scale does this approach break down? The '~small scale' qualifier is vague. No discussion of what happens at 1000+ articles or millions of words.
Read next: Benchmarks on LLM context window utilization; scaling properties of index-based vs. vector-based retrieval.closed byAn LLM wiki changed how I work โ Newton reports real-world operation well past the '~100 articles / ~400K words' scale the original idea was tested at โ about 1,440 wiki pages, one exceeding 12,000 words with 1,300 internal links, sustained for over a month โ showing the approach holds up at that larger scale but starts requiring active page compaction and pipeline repair, i.e. rising maintenance cost rather than outright breakdown. - unstated assumptionMarkdown is assumed to be the right format for structured knowledge. No consideration of whether richer representations (knowledge graphs, ontologies, databases) would enable capabilities that flat markdown cannot.
Read next: Knowledge representation literature; comparison of markdown wikis vs. knowledge graphs for LLM-assisted reasoning.closed byTony Seale's Post โ That gap notes Karpathy assumes markdown is the right format and never considers whether richer representations (knowledge graphs, ontologies) would enable capabilities flat markdown cannot. Vault-LD is precisely that consideration and a proposed answer: keep the flat markdown but add optional YAML-LD frontmatter so the same files project into a formal knowledge graph/ontology, unlocking inference/validation/query without abandoning the prose. - missing perspectiveThe workflow is described purely from the solo practitioner's perspective. No consideration of collaborative knowledge bases, version control of LLM-generated content, or multi-agent scenarios.
Read next: Collaborative knowledge management; version control for AI-generated artifacts.closed byTony Seale's Post โ Partially closes it. That gap flags that Karpathy's workflow is solo-only, with no collaborative or multi-agent perspective. Vault-LD supplies exactly that multi-scale story โ team memory, enterprise integration and multi-agent exposure via DPROD data products up to an agentic web โ though it still omits the version-control/provenance mechanics the gap also asks for.
Related documents
- Wow, this tweet went very viral!
- AI 101: Agentic Vector Databases โ What Is That?
- An LLM wiki changed how I work
- Graphify: Unifying Codebase Context to Streamline Agentic Software Engineering
- Someone just built the exact tool Andrej Karpathy said someone should build
- Enterprise Analytics Beyond Dashboards: Intelligent Data Orchestration with LLMs
- Presentation: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs
- Meta's Recipe for Building Agents as "Organizational Second Brains"
- Paweล Huryn's Post