Think about revisiting items you’ve saved to Pocket, Notion or your bookmarks. Most people don’t have the time to re-read all of these things after they’ve saved them to these various apps, unless they have a need. We are excellent at collecting tons of information. However, we are just not very good at making any of those places interact with each other or add a cumulative layer that connects them together.
In April of 2026, Andrej Karpathy (former AI Director of Tesla and co-founder of OpenAI) suggested a solution to this issue: use a large language model (LLM) to build your wiki in real-time.
This idea became viral and was ultimately followed with a GitHub gist describing how to do this using an LLM. This guide will provide all of the support (with example code) for building your own living, evolving personal wiki.
A large number of modern AI knowledge tools use Retrieval-Augmented Generation (RAG). In simple terms, you upload documents, ask a question, and the system retrieves relevant text to help the AI generate an answer. Tools like NotebookLM, ChatGPT (file uploads), and most enterprise AI systems follow this approach.
On the surface, this makes sense. But as Andrej Karpathy points out, there’s a key flaw: the model doesn’t accumulate knowledge. Each query starts from scratch.
If a question requires synthesizing five documents, RAG pulls and combines them for that one response. Ask the same question again tomorrow, and it repeats the entire process. It also struggles to connect information across time, like linking an article from March with one from October.
In short, RAG produces answers, but it doesn’t build lasting knowledge.
Karpathy’s approach will change the way we look at models. Rather than processing raw documents after our queries, we will now process those documents at the time of ingestion. The results of this processing will be a permanent, structured wiki-like product (which will allow you to store and retrieve documents with a high degree of control over their location).
When you add a new document source to the LLM, the LLM does not merely create an index of that source for later retrieval. Instead, the LLM reads, understands, and integrates that source into the knowledge base, updating all relevant existing pages (where necessary). It notes down any contradictions between the new and existing claims or knowledge, creating any necessary new concept pages, and reinforcing the complex relationships across the entire wiki.
According to Karpathy, “With LLMs, knowledge is created and maintained continuously and consistently rather than being able to use individual queries to create knowledge.” Here is a simple comparison that illustrates this difference further.
| Dimension | Traditional RAG | LLM Wiki |
|---|---|---|
| When knowledge is processed | At query time (for every question) | At ingest time (once per source) |
| Cross-references | Discovered ad hoc or missed entirely | Pre-built and continuously maintained |
| Contradictions between sources | Often overlooked | Detected and flagged during ingestion |
| Knowledge accumulation | None — resets with each query | Builds over time with every new source |
| Output format | Temporary chat responses | Persistent, editable Markdown files |
| Data ownership | Stored within provider systems | Fully controlled on your local machine |
Let’s review how an individual would develop one of these wikis.
You need to accumulate everything – articles that you have saved, books enjoyed, notes you have created, transcripts from discussions, and even your very own historical conversations. All these materials are your raw materials, just as ore must undergo refining before use.
One of the best practices from this community is to not treat all documents in the same fashion. For example, a 50-page research white paper requires extraction on a section-by-section basis while a tweet or social media thread only requires a primary insight and corresponding context. Likewise, a meeting transcript requires extraction of decisions that were made, action items that are to be carried out and key quotations. By first classifying the type of document will help extract the right type of information to the correct amount of detail.
You will feed your source materials into your AI’s LLM via a structured query. It will allow the LLM to produce one or more wiki pages that conform to the established template of having: a frontmatter block (YAML), a TLDR sentence, the body of the content, and the counterarguments/data gaps.
A central index.md will serve as a table of contents, and link directly to each page of the wiki. This is how an AI agent can efficiently traverse the entire knowledge base; it starts at the index, reads through the tldr’s, then drills down into only those pages that are relevant to its specific question.
This is one of the most under-appreciated features of the system. When you ask the LLM a well-formed question and receive a response that provides valuable insight. For example, a comparison between two frameworks, or an explanation of how two concepts are related, you save that response as a new wiki page tagged with the label query-result. As time goes on, your best thinking has been collected rather than lost in chat logs.
At appropriate intervals, you ask the LLM to audit the entire wiki for contradictions or inconsistencies between pages, and to indicate those statements which have been rendered obsolete by a more recent source. Additionally, the LLM will provide input on identifying orphan pages (i.e., pages that have no links pointing to them), and for providing a list of concepts that are referenced within the existing content but are not yet represented by their own respective pages.
Karpathy talks about lots of specific tools in his Gist. Below you will find what each tool does and how they fit into his overall workflow.
Obsidian is a free markdown knowledge management application which uses a local directory as a vault. For Karpathy, this is the viewing interface used for the wiki because it has three distinct features that matter for his system:
# In any Obsidian note, Dataview renders this dynamically:
# List all concept pages ordered by number of sources
TABLE length(sources) AS "Source Count", confidence, updated
FROM "wiki/concepts"
SORT length(sources) DESC
# Find low-confidence pages that need review
TABLE title, sources
FROM "wiki"
WHERE confidence = "low"
SORT file.mtime ASC
# Find pages not updated in the last 2 weeks
LIST
FROM "wiki"
WHERE updated < date(today) - dur(14 days)
SORT updated ASCThe LLM can use the index.md file to access the wiki content without problems at small scale. The index becomes unreadable in one context window when you have more than 100 pages because it reaches excessive size.
The local search engine qmd enables Markdown file searches through three search methods which Tobi Lutke (CEO of Shopify) developed. The system operates entirely on your device because it uses node-llama-cpp with GGUF models which require no API connections and protect your data from leaving your computer.
# Install qmd globally
npm install -g @tobilu/qmd
# Register your wiki as a searchable collection
qmd collection add ./wiki --name my-research
# Basic keyword search (BM25)
qmd search "mixture of experts routing efficiency"
# Semantic search, finds related concepts even with different words
qmd vsearch "how do sparse models handle load balancing"
# Hybrid search with LLM re-ranking, highest quality results
qmd query "what are the tradeoffs between top-k and expert-choice routing"
# JSON output for piping into agent workflows
qmd query "scaling laws" --json | jq '.results[].title'
# Expose qmd as an MCP server so Claude Code can use it as a native tool
qmd mcpThe MCP server mode enables Claude Code to use qmd directly as a built-in tool which results in smoother workflow integration throughout your data ingestion and query processing tasks.
Because your entire wiki is a folder of plain Markdown files, you get version history branching and collaboration for free with Git. This is quite powerful:
# Initialize the repo when you start
cd my-research && git init
# Commit after every ingest session
git add .
git commit -m "ingest: MoE efficiency article — flags dense-vs-sparse contradiction"
# See exactly what changed in any ingest
git diff HEAD~1
# Roll back a bad compilation pass
git revert abc1234
# See how your knowledge evolved over time
git log --oneline wiki/concepts/mixture-of-experts.md
# Share with a team via GitHub (the wiki becomes collaborative)
git remote add origin https://github.com/yourname/research-wiki
git push -u origin mainIf you’re excited about this concept there is an easy way to begin:
Use Claude with Claude Code, or any AI with file access, to build and maintain the wiki. Start at your index file when querying. Let the agent navigate.
Let’s be realistic, Constructing an LLM powered wiki is no easy task as it comes with several obstacles as well:
The most important advice for building your first LLM wiki is the same advice Karpathy gives in his gist: don’t overthink the setup. The schema template from this guide can be easily copied after which you can create the directory structure by executing the bash commands.
The system achieves its magical effect through multiple architectural improvements which develop from the first day onwards. The wiki becomes more valuable with each new source material you include. The data belongs to you. The files exist in formats which can be used by any system. You can use any AI you want to query it. The LLM takes care of all maintenance tasks instead of you needing to handle them which creates a different experience from other productivity tools.
Your knowledge, finally, working as hard for you as you worked to acquire it.
Q1. What problem does RAG have with knowledge retention?
A. It doesn’t accumulate knowledge; every query starts from scratch without building on past insights.
Q2. How does an LLM wiki differ from traditional RAG?
A. It processes knowledge during ingestion, creating a persistent, structured system that evolves over time.
Q3. Why is classifying documents before ingestion important?
A. It ensures the system extracts the right level of detail for each document type, improving accuracy and usefulness.
Data Science Trainee at Analytics Vidhya
I am currently working as a Data Science Trainee at Analytics Vidhya, where I focus on building data-driven solutions and applying AI/ML techniques to solve real-world business problems. My work allows me to explore advanced analytics, machine learning, and AI applications that empower organizations to make smarter, evidence-based decisions.
With a strong foundation in computer science, software development, and data analytics, I am passionate about leveraging AI to create impactful, scalable solutions that bridge the gap between technology and business.
📩 You can also reach out to me at [email protected]
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。