GraphRAG 與 LLM Wiki 的取捨：小規模知識庫可先從 LLM Wiki 開始

TL;DR: GraphRAG and LLM Wiki both "distill" raw data with an LLM, and they hit similar problems: wrong summaries, stale knowledge, lost sources, and hard evaluation. I could not find a clear answer on how thick the distilled layer should be. If you start small, I would go with an LLM Wiki.

I needed to figure out how to build a knowledge base that keeps growing, so I looked into it again and tried to sort things out. I searched widely for existing products, the main methods, and recent papers, and then deepened my understanding by talking with an AI.

When I think of LLM knowledge bases, I think of two families: GraphRAG and LLM Wiki. I dug into both and found that they have more in common than I expected, so I am leaving these notes. I will go through them in this order: the GraphRAG family, the LLM Wiki family, the problems they share, and which one to choose.

Here is my understanding.

• GraphRAG and LLM Wiki both "distill" raw data with an LLM to build a higher-level representation of knowledge. The difference is the structure of what is distilled: a Graph structured by entities, relation edges, and communities, or a Wiki organized by directories, index pages, and links between documents.
• They run into similar problems: mistakes in the generated knowledge, knowledge going stale over time, losing track of the source, and the difficulty of evaluating it for a specific use case (more in "Shared problems" below). I was especially curious about how thick or thin the distilled layer should be (how much should we go back to the raw data?), but I could not find a clear answer.

The GraphRAG family: build summaries first, so it can see the whole

• 2023: Vector RAG. Split documents into chunks and retrieve the ones closest in meaning to the question. It spread widely. But its weak points also showed: it struggles with proper nouns and code, for example. Hybrid Search, which combines it with traditional keyword search, became common.
• April 2024: GraphRAG. A paper from Microsoft Research, "From Local to Global". Vector RAG was weak at questions about the whole, such as "What are the main themes of this set of documents?" GraphRAG extracts entities and relations from raw data with an LLM, builds a Graph, splits it into communities (strongly related groups), and writes summaries in advance. This lets it answer questions about the whole.
• October 2024: LightRAG. A paper from a group called HKUDS at the University of Hong Kong. It was accepted to Findings of EMNLP 2025, a top conference in AI and NLP. Conventional RAG treats data as flat text, so it has trouble capturing context. LightRAG brings a Graph into indexing and retrieval, combines the Graph with vector search, and retrieves in two levels: individual facts and overall topics. It also supports incremental updates, so it does not rebuild everything when new data arrives.
• November 2024: LazyGraphRAG. An improved version, also from Microsoft. GraphRAG uses an LLM heavily to extract entities and relations, so building the index was expensive. LazyGraphRAG delays the use of the LLM until query time, and the index only does light work such as extracting noun phrases. Microsoft's blog says the indexing cost is the same as vector RAG, 0.1% of full GraphRAG (a self-reported number).
• January 2026: Relink. A paper accepted to AAAI, a top AI conference. It criticized earlier methods because their Graph is static, incomplete, and mixed with unrelated facts (noise). It proposes building only the part of the Graph the question needs, on the fly, while reasoning. Missing facts are filled in from the original text, and unhelpful facts are dropped. This research points toward a thinner distilled layer.

Search itself has also changed. Since around 2025–2026, Agentic Search has spread: instead of searching once, an agent repeats search, read, think, and search again. This is not an evolution of GraphRAG. It is about making search multi-step, and the search underneath can be a plain grep, Hybrid Search, or GraphRAG.

So, does the search underneath need to be GraphRAG? There is actually a paper that evaluates this: "Do We Still Need GraphRAG?" (April 2026). It is an unreviewed arXiv paper and has few citations, but I found the content interesting and the evaluation looked reproducible, so I want to share it. It runs Agentic Search on both GraphRAG and plain RAG and compares them. The gap narrows a lot, but for complex multi-step reasoning (questions that cannot be answered in one search, where you use the first result as a key to connect a second and third related document), GraphRAG keeps an advantage. That was the conclusion.

The LLM Wiki family: let an LLM grow a Wiki that humans can read

• April 2026: LLM Wiki. An idea proposed by Andrej Karpathy in a GitHub Gist. An LLM reads raw data, builds a Markdown Wiki that both humans and agents can read, and keeps growing it. It has three layers: raw data that is never rewritten, the Wiki managed by the LLM, and a file with the rules (like CLAUDE.md or AGENTS.md). It has three operations: ingest, query, and lint (a check of the whole). It is presented as an alternative to ordinary RAG, which rediscovers knowledge from the raw data on every question. It came after GraphRAG, but the Gist does not mention GraphRAG.
• June 2026: Google's Open Knowledge Format (OKF) v0.1. It standardizes the LLM Wiki pattern into a format that many tools can exchange. According to Google Cloud's blog, the starting point was that the context AI agents need is scattered across metadata catalogs, wikis, shared drives, and so on, each with its own format. The format is simple. One concept is one Markdown file, and the YAML at the top (frontmatter) holds type, title, description, resource, tags, and timestamp. Only type is required. Concepts link to each other with ordinary Markdown links, so the whole thing becomes a Graph. It turns the "directories and links" of LLM Wiki directly into a spec. Citations were just a section in the body.
• July 2026: OKF v0.2. The starting point in the v0.2 blog is that knowledge written by an agent does not have the implicit guarantee of knowledge written by a person: that someone is accountable for it. So fields were added to answer these questions: What was this made from (provenance)? How much can I trust it (trust)? Is it still true (freshness)? Is it the latest version (lifecycle)? Was this number produced the way it was supposed to be (attestation)? Concretely, they are: sources (the original materials, with objective signals such as author and usage count), generated and verified (separating who made it from who confirmed it), status (draft, stable, deprecated), stale_after (a date after which the concept counts as stale), and a type called Attested Computation, which mechanically checks that a prescribed computation was actually run. They deliberately did not add a trust score. The blog explains that a score is subjective, differs by consumer, and goes stale the moment it is written.

Shared problems: once you distill, both hit the same wall

Both families try to fix the following problems by adding metadata. I left this out above, but GraphRAG also adds metadata to its nodes and edges. For example, Microsoft's GraphRAG gives each relation (edge) a reference to the text chunks it came from (text_unit_ids). Its claims also have a confidence (status) and a period (start_date, end_date) (official docs). LightRAG also links entities and relations to the original chunks and files, and added citation support in March 2025.

• The generated summaries or knowledge are wrong.
• It gets old over time. Updates and diffs are hard to reflect.
• You lose track of the source or the evidence.

There are other problems too.

• Fine details of the original data are lost.
• Upfront processing is expensive.
• You cannot know what information you will need in the future when you build it.
• It is hard to evaluate for a specific use case.

The worst one is that mistakes persist. If the distilled layer contains wrong data, that error is used as fact every time you search afterward.

Which one to choose: if you start small, I would go with an LLM Wiki

So, which one to choose? As I kept researching, I found my own criteria.

First, the scale of the data. I think an LLM Wiki gets unstable in quality and cost, because the work of keeping the whole Wiki consistent grows with the number of documents. Karpathy himself writes that it works well at around 100 sources and a few hundred pages, and that you should add proper search when it gets bigger. Next, how easy it is to iterate on improvements. A Wiki is Markdown, so people can read it and fix it. Then, complexity. GraphRAG is complicated, including building the index and the data representation.

If the goal is to start small and run an improvement loop, I think the LLM Wiki family has the advantage. When the data is large and the relations are complex, I think GraphRAG would need to be considered.

But the improvement loop needs human review. I run an LLM Wiki myself, and even after cutting what I review down to the core, I cannot keep up with reading it. Then, if I tune the prompt toward higher information density, I can no longer understand the content. I end up like a boss who only gives orders and does not answer questions.

One more interesting thing. In August 2026, RAGFlow, an OSS RAG (about 93,000 GitHub stars; Dify has about 159,000, as of October 2026), released a feature called Knowledge Compilation. It can build distilled data in various forms from raw data: Tree and Mindmap, in addition to Graph and Wiki.

It made me think that technology that lowers the cost of combining and switching the form of the distilled layer may also matter.

Originally published on my blog.