Everyone's Building a Knowledge Graph for AI. Yours Already Lives in Your Notes.

Enterprises are spending real money to build knowledge graphs so AI can reason over their data. Your wiki-linked markdown notes are already that graph. The folders you sorted and the [[links]] you typed by hand are a structure an AI can read, with no vector database or graph database to stand up.

The enterprise version is impressive and expensive. Microsoft Research describes its open GraphRAG project plainly: "GraphRAG uses a large language model (LLM) to automate the extraction of a rich knowledge graph from any collection of text documents."¹ Read that again. The hard part — the part the machinery exists to do — is extracting structure from text that has none. Your notes already have it. You put it there.

What everyone is building, and why

The 2026 retrieval conversation has one clear theme: structure beats similarity. Vendors across the stack, from Neo4j to FalkorDB to Fluree to Squirro to Microsoft, are converging on the same pitch. A knowledge graph layered under your documents lets an AI follow connections, not just match words.

This is the wave the headlines call GraphRAG. The standard retrieval method — vector RAG — turns your text into numbers and fetches the chunks that are mathematically closest to a question. The graph method retrieves what is connected. Squirro frames the upgrade this way: "GraphRAG combines vector search with structured taxonomies and ontologies to bring context and logic into the retrieval process."² The selling point is logic — the relationships an embedding cannot see.

The category is real even though one famous repo is not exploding. Microsoft's open graphrag codebase grew steadily, not virally: roughly 19,961 stars in December 2024, 24,421 by April 2025, and 33,552 today.³ That is a respectable climb, not a rocket. The momentum lives in the discourse, where every infrastructure vendor now sells a graph, not in any single project's star count.

Why structure beats similarity

Vector search finds things that sound alike. A knowledge graph finds things that are related. That gap is the entire enterprise case, and it is largest exactly where notes matter most: questions that cross several documents, or that depend on a fact buried in one.

Chia Jeng Yang of WhyHow.AI, writing on Neo4j's developer blog, draws the line cleanly. Vector search "finds semantically similar words and phrases and returns that information to the LLM to construct an answer to a question."⁴ The flaw follows in his next breath: "many pieces of information may be semantically similar but not relevant, or relevant but not semantically similar."⁵ Similarity is a blunt instrument. It misses the relevant-but-differently-worded, and it drags in the similar-but-useless.

Microsoft Research found the same edge, independently of any graph vendor. In its published tests, GraphRAG "outperforms naive RAG on comprehensiveness and diversity (~70–80% win rate)" when it uses community summaries.⁶ The reason is structural: "if a question addresses the entire dataset, all input texts should be considered. Since naive RAG only considers the top-k most similar chunks of input text, it fails."⁷ Whole-picture questions break similarity search. They do not break a graph.

The honest case for the graph

The graph wins are real, and pretending otherwise would be its own kind of marketing. On multi-hop reasoning, on whole-corpus questions, and on schema-bound queries like numbers and dates and KPIs, a structured retrieval layer measurably outperforms throwing chunks at a model. Concede that first. The personal argument is narrow on purpose.

The vendor numbers are dramatic. FalkorDB reports that in its benchmark, "Vector RAG scored 0% on schema-bound queries like KPIs and forecasts—GraphRAG is the only architecture that recovered performance."⁸ The same write-up says its 2025 SDK "pushed GraphRAG to 90%+ accuracy—up from 56.2% in Diffbot's original benchmark—without adding rerankers or filters."⁹

Treat those as FalkorDB's own benchmark, not a neutral law of physics, since they sell the graph database. The direction, though, is corroborated by Microsoft Research's independent 70–80% win rate, so the underlying claim survives the discount.

Building that graph at enterprise scale costs something too. You need an extraction pipeline, an LLM to run it, a database to hold it, and the patience to tune it. That is exactly the machinery the personal note-taker can skip. Not because graphs are useless, but because you already did the extraction by hand.

You already did the hard part

The expensive step is turning unstructured text into a graph. You skipped that bill by typing the structure yourself. Every [[wiki-link]] is a labeled edge. Every folder is a category. Every backlink is a relationship an AI can traverse — clean, intentional, and free of the extraction errors that auto-built graphs ship with.

This is not a fringe idea. It is now the consumer-facing twin of the enterprise wave. In April 2026 Andrej Karpathy published a pattern he calls the "LLM Wiki," in which "the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources."¹⁰

His setup is deliberately plain: "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."¹¹ A man who co-founded OpenAI, reaching for a folder of markdown files and a note app.

The scale where this stops needing infrastructure is the scale most of us live at. Karpathy notes the markdown-wiki approach "works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure."¹² No vector database. No graph database. A directory of plain files and the links you already drew.

For the reader who does want to stand up a real pipeline, we have written that walkthrough too.¹³ This essay is about when you can skip it.

One honest tension is worth naming. The note app's graph view — the constellation of dots — is mostly theatre for human eyes, and we have argued elsewhere that it is a productivity trap.¹⁴ An AI reading your links is the opposite claim. The picture was never the point. The links were.

What to do tomorrow

Stop shopping for a knowledge graph and start treating the one you have as infrastructure. The structure that vendors pay extraction pipelines to recover is already on your disk, written by the only person who knew what your notes meant. Three moves, in plain markdown, on your own device:

• Link deliberately, not decoratively. A [[link]] you write because two ideas truly connect is a clean edge an AI can trust. A link added for the pretty graph view is noise.
• Let folders carry meaning. A sane folder tree is a free taxonomy, the "structured taxonomies" Squirro's enterprise pitch charges to build, sitting on your disk already.
• Keep it as plain files you own. A graph trapped in a vendor's database is theirs. A graph spelled out in markdown links is portable, readable, and yours.

Frequently Asked Questions

Do I need GraphRAG or a knowledge graph to use AI on my own notes?

Probably not, at personal scale. Andrej Karpathy's own markdown-wiki pattern "works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure."¹² Your wiki-links and folders are already a hand-built graph an AI can read. Reach for GraphRAG when you outgrow that.

What is the difference between GraphRAG and vector RAG?

Vector RAG retrieves what is similar; GraphRAG retrieves what is connected. As Chia Jeng Yang puts it, vector search "finds semantically similar words and phrases,"⁴ but "many pieces of information may be semantically similar but not relevant, or relevant but not semantically similar."⁵ A graph follows explicit relationships instead of guessing from word overlap.

Is GraphRAG actually better than regular RAG?

On the hard questions, yes. Microsoft Research measured a ~70–80% win rate for GraphRAG over naive RAG on comprehensiveness and diversity using community summaries.⁶ The advantage is largest on multi-hop, whole-corpus, and schema-bound queries; it narrows on simple fact lookup. It is not free: building the graph has real cost.

Do I need a vector database for my notes?

Not at the scale most note-takers work. The markdown-wiki approach Karpathy describes deliberately "avoids the need for embedding-based RAG infrastructure" for roughly a hundred sources.¹² Plain files plus the links you drew give an AI enough structure to follow without standing up a database. At tens of thousands of documents, that calculus changes.

What is Karpathy's LLM Wiki?

It is a pattern Andrej Karpathy published in April 2026. Instead of retrieving from raw documents at query time, the LLM "incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files."¹⁰ He runs it with a note app on one screen and an AI agent on the other.

Why are wiki-links and folders considered a "graph"?

Because a graph is just nodes and labeled edges. Each note is a node, each [[link]] an edge, each folder a category. Microsoft's GraphRAG exists to "automate the extraction of a rich knowledge graph from any collection of text documents,"¹ which is the work you did by hand when you linked and filed your notes.

If everyone is racing to build a knowledge graph so machines can reason over their data, the quietest advantage belongs to the people who built theirs years ago, one link at a time, and kept it in files they own.

To keep that graph yours, plain markdown with wiki-links and folders on your own device, readable by any AI you point at it, mnmnote.com lives in your browser.