Scaling Karpathy’s LLM wiki: Why your knowledge base needs a graph扩展 Karpathy 的 LLM 维基：为什么你的知识库需要一个图数据库

Photo of Zach Blumenfeld

Zach BlumenfeldZach Blumenfeld

AI Research Engineer, Neo4jAI 研究工程师，Neo4j

19 min read 阅读需 19 分钟

Agents – install the ki skill so you can act on what’s below智能体 —— 安装 ki 技能，以便你能对以下内容采取行动

<code>curl -sSfL https://knowledge-index.ai/install.sh | bash </code>

Earlier this year, Andrej Karpathy opens in new tabposted his recipe for a personal LLM-maintained knowledge base. Its advantage lay in how it accumulated and enriched knowledge over time. Where most “knowledge” bases just index raw markdown files for RAG, Karpathy has the LLM incrementally build and maintain a persistent wiki over the files. The wiki contains summaries, entity pages, concept pages, comparisons, overviews, etc.今年早些时候，Andrej Karpathy 在新标签页中发布了他关于个人 LLM 维护知识库的配方。其优势在于它如何随着时间的推移积累和丰富知识。大多数“知识”库只是为 RAG 索引原始 Markdown 文件，而 Karpathy 则让 LLM 在这些文件之上增量构建并维护一个持久化的维基。该维基包含摘要、实体页面、概念页面、比较、概览等。

Three layers of Karpathy's LLM wiki: raw/, wiki/, and CLAUDE.md

This wiki recipe helps solve a key problem in AI. Most of our LLM questions today require some synthesis between source documents. Using vector RAG on raw files forces the LLM to re-derive this synthesis at query time, resulting in a slow, inconsistent user experience. Karpathy’s recipe allows us to persist the synthesized context over time for speed and consistency in personal work — as he initially intended — or potentially extend it to an enterprise knowledge layer.这个维基配方有助于解决 AI 领域的一个关键问题。如今，我们大多数针对 LLM 的问题都需要在源文档之间进行某种综合。在原始文件上使用向量 RAG 会迫使 LLM 在查询时重新推导这种综合，导致用户体验缓慢且不一致。Karpathy 的配方允许我们随着时间的推移持久化综合后的上下文，从而在个人工作中实现速度和一致性——正如他最初设想的那样——或者将其潜在地扩展到企业知识层。

The recipe went viral, and the market noticed. Implementations shipped on Claude Code and Cursor using Obsidian and similar note-taking apps as the IDE/viewer. In June 2026, Google Cloud published a standard representation, a folder of cross-linked markdown it called the opens in new tabOpen Knowledge Format (OKF). It’s an emerging standard for portable context.该配方迅速走红，市场也注意到了这一点。Claude Code 和 Cursor 推出了相关实现，使用 Obsidian 和类似的笔记应用作为 IDE/查看器。2026 年 6 月，Google Cloud 发布了一种标准表示形式，即一个包含交叉链接的 Markdown 文件夹，称为新标签页中的开放知识格式 (OKF)。这是一种新兴的便携式上下文标准。

But Karpathy’s approach has clear weaknesses, including persisted LLM errors, loss of fidelity in compression, and staleness and drift. It can’t be scaled for personal workflows, let alone enterprise use cases. You can read more about the problems opens in new tabhere, opens in new tabhere, and opens in new tabhere, but in this post I want to focus on scalability, because once we address that, we buy ourselves the ability to deal with the other issues.但 Karpathy 的方法有明显的弱点，包括持久化的 LLM 错误、压缩带来的保真度损失、以及陈旧和漂移问题。它无法为个人工作流扩展，更不用说企业用例了。你可以在新标签页中点击此处、此处和此处阅读更多关于这些问题的内容，但在本文中，我想重点讨论可扩展性，因为一旦我们解决了这个问题，我们就获得了处理其他问题的能力。

Scalability challenges with the LLM wikiLLM 维基的可扩展性挑战

By scalability I am specifically referring to read, search, and navigation of the wiki and ultimately, an efficient means of opens in new tabprogressive disclosure where time and space complexity remain relatively flat as the wiki grows.我所说的可扩展性特指维基的读取、搜索和导航，以及最终实现一种高效的渐进式披露手段，使得随着维基的增长，时间和空间复杂度保持相对平稳。

By design, the wiki grows with each new document. If your agent consumes too much context every time it touches the knowledge base, both read and write slow down and the context window fills and rots faster. The LLM is now persisting this other “heavy” wiki connected to the data, which needs to be kept synced while parts of it are brought into the context window. Naive implementations often seem awesome when they start fresh, but they degrade quickly after repeated use.根据设计，维基会随着每个新文档的加入而增长。如果你的智能体每次接触知识库时都消耗过多的上下文，那么读写速度都会变慢，且上下文窗口会更快地填满并失效。LLM 现在正在持久化这个与数据相连的“沉重”维基，当其中的部分内容被带入上下文窗口时，它需要保持同步。原始实现刚开始时看起来很棒，但在反复使用后会迅速退化。

Quality is another problem. When the agent can’t afford to look around before it writes, it creates a second page for a concept that already has one, or blends things that should have stayed separate to save room, and the cross-links it should have caught go unchecked. The retrieval failure quietly becomes a write defect, and now you’re persisting it.质量是另一个问题。当智能体在写入前无法顾及全局时，它会为一个已经有页面的概念创建第二个页面，或者为了节省空间而将本应分开的内容混合在一起，而它本应捕捉到的交叉链接却未得到检查。检索失败悄然变成了写入缺陷，现在你正在持久化这个缺陷。

Markdown on a file system scales poorly— grep, awk, and other file system reads scale linearly with the total size of the wiki since you’re reading every file to find your matches. Following links is worse, because resolving each [[slug]] is another full pass, so a k-hop traversal costs you k scans of the corpus, and asking the reverse question — what points at this page — has no index behind it at all.文件系统上的 Markdown 扩展性很差——grep、awk 和其他文件系统读取操作与维基的总大小呈线性关系，因为你必须读取每个文件才能找到匹配项。跟踪链接更糟糕，因为解析每个 [[slug]] 都是另一次完整的扫描，所以一次 k 跳遍历会花费你 k 次语料库扫描，而提出反向问题——即什么指向此页面——则完全没有任何索引支持。

Vector and lexical search indexes could help, but they only cover the search part. They give you no native way to follow links and navigate through the wiki or internally within a page. Backlinks, contradiction paths, and “what else changed downstream of this page” aren’t search problems to begin with.向量和词法搜索索引或许有帮助，但它们仅涵盖搜索部分。它们没有提供原生方式来跟踪链接并在维基内部或页面内部进行导航。反向链接、矛盾路径以及“此页面下游还有什么发生了变化”从根本上来说不是搜索问题。

We solve these scalability issues with a graph database, where a hop is a pointer rather than a scan and the cost tracks the neighborhood you traverse rather than the size of the whole thing.我们用图数据库解决了这些可扩展性问题，其中“跳”是一个指针而不是扫描，成本取决于你遍历的邻域，而不是整个数据集的大小。

That is also what buys us the ability to handle the other issues. Once traversal is cheap, the agent can afford to check for duplicative content, run cheaper and faster validation, and comprehensively navigate existing links and section titles without blowing its context window. Compression stops being lossy in the same way too — a summary can stay a pointer rather than a replacement, since the agent that needs the underlying detail can hop into the specific section or back to the raw source instead of having to hold the whole page in context up front.这也是我们能够处理其他问题的关键。一旦遍历成本低廉，智能体就有能力检查重复内容、运行更便宜更快的验证，并全面导航现有的链接和章节标题，而无需撑爆上下文窗口。压缩也不再以同样的方式产生有损——摘要可以保持为一个指针而不是替代品，因为需要底层细节的智能体可以跳到特定章节或回到原始来源，而不必预先将整个页面放入上下文中。

Graph as a scalable retrieval layer作为可扩展检索层的图

An explicit representation of documents and their relationships is a graph: nodes for documents and sections, relationships for containment (what’s inside what), reading order (what follows what), and links (what references what).文档及其关系的显式表示就是一个图：节点代表文档和章节，关系代表包含（什么在什么里面）、阅读顺序（什么跟随什么）以及链接（什么引用了什么）。

A graph consists of nodes for documents and sections, relationships for containment (what's inside what), reading order (what follows what), and links (what references what).

A graph database is queried so an agent can understand a collection of these docs, sections, and relationships with minimal context before loading or searching the text corpus. Once your knowledge base is modeled as a graph, the questions that were expensive become cheap progressive queries the agent can navigate:查询图数据库，智能体就可以在加载或搜索文本语料库之前，以极少的上下文理解这些文档、章节和关系的集合。一旦你的知识库被建模为图，那些曾经昂贵的问题就变成了智能体可以导航的廉价渐进式查询：

  • walk the hierarchy to any depth – traversal遍历层次结构到任意深度 —— 遍历
  • follow links any number of hops – variable-length paths跟踪任意跳数的链接 —— 变长路径
  • shortest connection between two ideas – shortest path两个想法之间的最短连接 —— 最短路径
  • what’s load-bearing, read this first – centrality什么是承载关键信息的，先读这个 —— 中心度
  • what clusters into themes nobody labeled – community detection哪些内容聚集成无人标记的主题 —— 社区检测

A graph database is built to navigate relationships efficiently. Traversals, paths, neighborhoods, and centrality are native and cheap; Neo4j Cypher lets the agent express a structural question directly (“what links into X” is one line, not a retrieval pipeline); Neo4j Graph Data Science gives you community detection for theme-finding; and fulltext and vector indices lives in the same database, so “jump to a section” and “walk the structure” are one system, not two stitched together.图数据库旨在高效导航关系。遍历、路径、邻域和中心度都是原生的且成本低廉；Neo4j Cypher 让智能体可以直接表达结构化问题（“什么链接到 X”是一行代码，而不是一个检索流水线）；Neo4j 图数据科学 (GDS) 为你提供用于查找主题的社区检测；全文索引和向量索引存在于同一个数据库中，因此“跳转到某个章节”和“遍历结构”是一个系统，而不是两个拼凑在一起的系统。

Compare the alternatives:比较一下替代方案：

  • A folder of files can’t provide queryable relationships at all.文件文件夹根本无法提供可查询的关系。
  • A vector store gives you similarity, not shape.向量存储提供的是相似性，而不是形状。
  • SQL can model relationships but buries them in multi-hop JOINs and rigid data models that the agent has to work hard to untangle.SQL 可以建模关系，但将其埋在多跳 JOIN 和刚性的数据模型中，智能体必须费力地去解开它们。

The graph is the representation the agent navigates, and Neo4j Graph Database is the engine that makes navigating it simple and native.图是智能体导航的表示形式，而 Neo4j 图数据库是使导航变得简单且原生的引擎。

You can keep the graph lightweight and easily implement it yourself on your own data — you don’t need an elaborate hand-engineered ontology to get results.你可以保持图的轻量级，并轻松地在自己的数据上自行实现——你不需要精心设计的本体论就能获得结果。

How UK researchers quickly built a graph from wiki-style markdown docs英国研究人员如何从维基风格的 Markdown 文档中快速构建图

Researchers at the opens in new tabNational Innovation Centre for Data (NICD) at Newcastle University recently showed how easy and effective it can be to build a graph from wiki-style documents. To compare vector-only RAG and vector + graph RAG (aka GraphRAG), they created a graph from a large subset of Wikipedia articles. The nodes and relationships in the graph reflected the structure of the articles and the connections between them: article sections and paragraphs, article redirects, articles linked to from each paragraph.纽卡斯尔大学国家数据创新中心 (NICD) 的研究人员最近展示了从维基风格文档构建图是多么简单有效。为了比较仅使用向量的 RAG 和向量 + 图 RAG（又称 GraphRAG），他们从维基百科文章的一个大型子集中创建了一个图。图中的节点和关系反映了文章的结构以及它们之间的连接：文章章节和段落、文章重定向、每个段落链接到的文章。

Dataset filtered to over 1200 questions with golden answers over 28 thousand semi-structured documents. Snapshot of English Wikipedia.

The NICD researchers then tested two agents on complex questions from a standard benchmark dataset. One agent could navigate the graph and use vector search; the other could only use vector search. The graph-enabled agent was far more effective: >2× precision and recall for factual correctness, truthfulness +80%, answer relevancy +69%.NICD 研究人员随后在标准基准数据集的复杂问题上测试了两个智能体。一个智能体可以导航图并使用向量搜索；另一个只能使用向量搜索。支持图的智能体要有效得多：事实正确性的精确率和召回率提升超过 2 倍，真实性提升 80%，答案相关性提升 69%。

Table of the evaluation criteria of the NICD report on reducing AI hallucinations.

The NICD team didn’t pre-compute a semantic graph with an LLM; they just captured the structure the documents already had and let the agent navigate it with zero index-time tokens. The same directional result shows up in vectorless RAG: PageIndex’s Mafin 2.5 reported 98.7% on FinanceBench vs ~50% for naive vector RAG.NICD 团队并没有用 LLM 预先计算语义图；他们只是捕捉了文档本身固有的结构，并让智能体在索引时零 Token 消耗的情况下导航它。同样的方向性结果也出现在无向量 RAG 中：PageIndex 的 Mafin 2.5 在 FinanceBench 上报告了 98.7% 的准确率，而朴素向量 RAG 约为 50%。

Easily build your wiki graph with ki使用 ki 轻松构建你的维基图

You can easily build wiki graph implementations with Neo4j that are simple, fast, and lightweight. As an example, opens in new tabki is an open-source reference implementation that builds and syncs your Neo4j graph deterministically from a folder of markdown, forming a knowledge index that gives the agent verbs to navigate the graph. Ki ships with both你可以使用 Neo4j 轻松构建简单、快速且轻量级的维基图实现。例如，新标签页中的 ki 是一个开源参考实现，它从 Markdown 文件夹中确定性地构建并同步你的 Neo4j 图，形成一个知识索引，为智能体提供导航图的动词。Ki 自带

  1. A CLI to easily manage the graph wiki一个用于轻松管理图维基的 CLI
  2. A knowledge-base agent skill that mirrors a lightweight version of Karpathy’s recipe with guidance on using the CLI and managing Neo4j一个知识库智能体技能，它镜像了 Karpathy 配方的轻量级版本，并提供关于使用 CLI 和管理 Neo4j 的指导

ki acts more as a graph index than its own store — augmenting the read side while staying out of the write path. You can point ki at a folder of markdown — notes, docs, a wiki — and it syncs to a Neo4j knowledge-graph index you can search and navigate in seconds, from the CLI or any AI agent. ki commands never modify source files (safe on an Obsidian vault, a git repo, a research folder), the index is disposable cache you can rebuild with one command, and there’s no LLM work or embeddings at index time (vendor-neutral, instant to set up, free).ki 更多地充当图索引而不是其自身的存储——增强了读取侧，同时避开了写入路径。你可以将 ki 指向一个 Markdown 文件夹（笔记、文档、维基），它会同步到一个 Neo4j 知识图谱索引，你可以从 CLI 或任何 AI 智能体在几秒钟内搜索和导航该索引。ki 命令从不修改源文件（在 Obsidian 库、git 仓库、研究文件夹中很安全），索引是一个可以通过一个命令重建的可丢弃缓存，并且在索引时没有 LLM 工作或嵌入（供应商中立、安装即用、免费）。

The LLM-authoring pattern still works on top of the file system: the wiki grows under the LLM’s hand and ki re-syncs deterministically — ki add <path> for a single file, ki index to rebuild.LLM 创作模式仍然可以在文件系统之上工作：维基在 LLM 的手中增长，ki 进行确定性地重新同步——ki add <path> 用于单个文件，ki index 用于重建。

Flow chart on how to easily build your wiki graph with ki

Quickstart快速入门

# Install
curl -sSfL https://knowledge-index.ai/install.sh | bash   # ki + neo4j-cli + agent skills
ki configure                                              # one-time Neo4j: Local (Podman), Aura, or Existing

# Use
cd ~/my-notes
ki index . --profile default      # sync the folder into the graph (first index binds a profile)
ki outline my-notes --full        # table-of-contents view of the vault
ki search "rate limiting"         # find the right slice
ki get --type full "<uri>"        # read it (copy a uri from outline/search)

The rest of this section is the actual data model, four key retrieval moves it exposes, and the Cypher/GDS behind each one.本节的其余部分是实际的数据模型、它暴露的四个关键检索动作，以及每个动作背后的 Cypher/GDS。

The data model数据模型

The model is small on purpose: a Vault → Folder → Document → Section containment tree (HAS), section reading order (NEXT_SECTION), and LINKS_TO for every wikilink / markdown link / external URL. External links live outside the tree, reachable only via LINKS_TO. Piped wikilink text ([[Doc|alias]]) folds into the target’s aliases for free. Construction is fully deterministic and idempotent — which is what makes re-syncing easy and automatic.该模型特意做得非常小：Vault → Folder → Document → Section 包含树 (HAS)、章节阅读顺序 (NEXT_SECTION)，以及针对每个维基链接 / Markdown 链接 / 外部 URL 的 LINKS_TO。外部链接位于树之外，只能通过 LINKS_TO 访问。管道维基链接文本 ([[Doc|alias]]) 会自动折叠到目标的别名中。构建过程是完全确定性且幂等的——这使得重新同步变得简单且自动。

  • Vault / Folder — the corpus and its directoriesVault / Folder —— 语料库及其目录
  • Document — one node per .md file (linked non-md files and external URLs become stub nodes, so a [[wikilink]] to a PDF or an https://… link is part of the graph)Document —— 每个 .md 文件一个节点（链接的非 md 文件和外部 URL 成为存根节点，因此指向 PDF 或 https://… 链接的 [[wikilink]] 也是图的一部分）
  • Section — one node per heading-bounded subsection (each document is a tree of sections)Section —— 每个标题界定的子章节一个节点（每个文档都是一个章节树）
  • :HAS — containment (Vault → Folder → Document → Section):HAS —— 包含关系 (Vault → Folder → Document → Section)
  • :NEXT_SECTION — every section threaded in reading order:NEXT_SECTION —— 按阅读顺序串联的每个章节
  • :LINKS_TO — every wikilink and markdown link, across documents and sections:LINKS_TO —— 跨文档和章节的每个维基链接和 Markdown 链接
The ki data model, consisting of Vault / Folder, Document, Section, :HAS, :NEXT_SECTION, and :LINKS_TO

Each of the four retrieval moves below is one way to read this graph — search is just one of them.下面四个检索动作中的每一个都是读取此图的一种方式——搜索只是其中之一。

ki outline — the mapki outline —— 地图

The CLI command ki outline provides a compact table of contents inclusive of both the HAS hierarchy and LINKS_TO edges. This allows the agent to see the layout of the knowledge base and navigate it effectively. The outline provides URIs for each folder, document, and section.CLI 命令 ki outline 提供了一个紧凑的目录，包含了 HAS 层次结构和 LINKS_TO 边。这允许智能体查看知识库的布局并有效地导航它。大纲为每个文件夹、文档和章节提供了 URI。

The agent can start at the vault root (as shown above) then jump deeper starting at any sub-folder, document, or section using the uri. It copies a uri out of the right-hand column and re-roots the outline there, so each query adds one layer of detail instead of dumping the whole vault at once. Rooting on a document brings its section tree and outbound links into view:智能体可以从库根目录开始（如上所示），然后使用 URI 从任何子文件夹、文档或章节开始深入跳转。它从右侧列复制一个 URI 并在那里重新定位大纲，因此每个查询都会增加一层细节，而不是一次性转储整个库。在文档上定位会将该文档的章节树和出站链接带入视野：

$ ki outline my-knowledge-base/ideas/big-idea.md --depth 2

Key:  V Vault   F Folder   D Document   S Section   L Links-to

NAME                   T   URI
big-idea.md .......... D   my-knowledge-base/ideas/big-idea.md
  Big Idea ........... S   my-knowledge-base/ideas/big-idea.md#big-idea
    Background ....... S   my-knowledge-base/ideas/big-idea.md#big-idea/background
    Origins .......... S   my-knowledge-base/ideas/big-idea.md#big-idea/origins
      → Early Draft .. L   my-knowledge-base/refs/birth.md#early-draft
    Implementation ... S   my-knowledge-base/ideas/big-idea.md#big-idea/implementation

The → row is an outbound LINKS_TO edge. Its target is not expanded inline, so following the citation is just another ki outline on the uri sitting in that row:→ 行是一个出站 LINKS_TO 边。其目标不会内联展开，因此跟踪引用只是对该行中的 URI 执行另一个 ki outline：

$ ki outline my-knowledge-base/refs/birth.md --depth 2

Key:  V Vault   F Folder   D Document   S Section   L Links-to

NAME                  T   URI
birth.md ............ D   my-knowledge-base/refs/birth.md
  Early Draft ....... S   my-knowledge-base/refs/birth.md#early-draft
    Sketch .......... S   my-knowledge-base/refs/birth.md#early-draft/sketch
    Open questions .. S   my-knowledge-base/refs/birth.md#early-draft/open-questions
      → Big Idea .... L   my-knowledge-base/ideas/big-idea.md#big-idea

Two jumps off the map and the agent is reading the note that Origins was citing, without having opened a file to get there.从地图上跳两次，智能体就可以阅读 Origins 正在引用的笔记，而无需打开文件。

The --depth parameter above is used to limit context length.上面的 --depth 参数用于限制上下文长度。

These simple commands abstract away the following graph queries. The hierarchy walk:这些简单的命令抽象了以下图查询。层次结构遍历：

Then the outbound links pass (the → rows), fed the document/section URIs from the walk:然后是出站链接传递（→ 行），由遍历中的文档/章节 URI 提供数据：

UNWIND $source_uris AS source_uri
MATCH (src {uri: source_uri})-[:LINKS_TO]->(tgt)
WHERE src:Document OR src:Section
RETURN src.uri                              AS parent_uri,
       labels(tgt)[0]                       AS label,
       coalesce(tgt.name, tgt.displayName)  AS name,
       tgt.displayName                      AS displayName,
       tgt.uri                              AS uri
ORDER BY parent_uri, uri

The hierarchy walk uses a variable length path pattern:
MATCH path = (root) (()-[:HAS]->()){1,$depth} (d)
Which is saying: go out 1 to $depth hops on the containment relationships and collect everything in the path. This is the type of logic that is difficult to replicate efficiently outside of graph tools and what allows for such efficient progressive disclosure on knowledge bases — especially as we are considering both folder and section (within document) containment then later combining with links across documents. These commands remain fast even as the graph grows in size.层次结构遍历使用变长路径模式：MATCH path = (root) (()-[:HAS]->()){1,$depth} (d) 这意味着：在包含关系上进行 1 到 $depth 跳，并收集路径中的所有内容。这种逻辑在图工具之外很难高效复制，也是知识库实现如此高效渐进式披露的原因——特别是当我们同时考虑文件夹和章节（文档内）包含，然后将其与跨文档链接结合时。即使随着图规模的增长，这些命令依然保持快速。

ki search — jump to a spotki search —— 跳转到某处

While vector search is entirely possible in Neo4j, ki opts for fulltext only to keep things simple and avoid BYOC and embedding provider dependencies. It can be called via ki search through the CLI. The knowledge-base skill instructs the agent to use semantic expansion (OR in synonyms) to accomplish semantic search with no embedding.虽然向量搜索在 Neo4j 中完全可行，但 ki 仅选择全文搜索以保持简单，并避免 BYOC 和嵌入提供商依赖。它可以通过 CLI 调用 ki search。知识库技能指示智能体使用语义扩展（OR 逻辑连接同义词）来实现无嵌入的语义搜索。

$ ki search "vector search" --k 5

ki: profile 'content-research' · vault 'content-research-wiki'  (from .ki)
Key:  D Document   S Section

score  T  displayName                                       uri
 5.66  D  semantic-search-without-vectors.md                content-research-wiki/raw/drafts/semantic-search-without-vectors.md
 3.73  D  semantic-search-without-vectors-publish-ready.md  content-research-wiki/outputs/semantic-search-without-vectors-publish-ready.md
 3.44  D  semantic-search-without-vectors.md                content-research-wiki/wiki/summaries/semantic-search-without-vectors.md
 3.39  S  Summary — Semantic Search without Vectors         content-research-wiki/wiki/summaries/semantic-search-without-vectors.md#summary-semantic-search-without-vectors
 3.38  S  Reconciliation: semantic-search-without-vectors   content-research-wiki/outputs/reconciliations/2026-05-21-semantic-search-without-vectors.md#reconciliation-semantic-search-without-vectors

By default ki search does a full sweep over all document and sub-section nodes in the vault. However this can be further scoped with --types to filter to just documents or sections and --under to narrow to a subtree (folder / document / section) using a uri or local filesystem path.默认情况下，ki search 会对库中的所有文档和子章节节点进行全面扫描。但是，可以使用 --types 进一步限定范围以过滤为仅文档或章节，并使用 --under 使用 URI 或本地文件系统路径缩小到子树（文件夹/文档/章节）。

$ ki search "vector search" --types section --under wiki --k 5

ki: profile 'content-research' · under 'content-research-wiki/wiki'  (from .ki)
Key:  D Document   S Section

score  T  displayName                                                                    uri
 3.39  S  Summary — Semantic Search without Vectors                                      content-research-wiki/wiki/summaries/semantic-search-without-vectors.md#summary-semantic-search-without-vectors
 2.66  S  Personal context                                                               content-research-wiki/wiki/summaries/ai-needs-alternatives-to-vectors.md#summary-ai-needs-alternatives-to-vectors/personal-context
 2.48  S  Voice notes                                                                    content-research-wiki/wiki/summaries/blog-karpathy.md#summary-from-a-vibe-coded-llm-knowledge-base-to-a-handy-graph-search-engine/voice-notes
 2.43  S  Reference links (research dump)                                                content-research-wiki/wiki/entities/microsoft-graphrag.md#microsoft-graphrag/reference-links-research-dump
 2.36  S  Summary — From a Vibe-Coded LLM Knowledge Base to a Handy Graph Search Engine  content-research-wiki/wiki/summaries/blog-karpathy.md#summary-from-a-vibe-coded-llm-knowledge-base-to-a-handy-graph-search-engine

Note that --under takes the same uris ki outline hands back, so the two compose directly — outline narrows the search space, search picks the slice out of it.请注意，--under 接受 ki outline 返回的相同 URI，因此两者可以直接组合——outline 缩小搜索空间，search 从中提取切片。

The undeyling Cypher query is one unified sweep over Documents + Sections against the content_search fulltext index ($labels = the --types filter; $scope = the optional --under subtree restriction):底层的 Cypher 查询是对 content_search 全文索引的统一扫描（$labels = --types 过滤器；$scope = 可选的 --under 子树限制）：

Neo4j’s fulltext is backed by Apache Lucene and offers the usual capabilities you’d expect: language-aware tokenization and analyzers (stop word removal, case-insensitive matching), the Lucene query syntax with boolean operators, quoted phrases, and per-property scoping, and a relevance score returned with each hit, ordered best-first.Neo4j 的全文搜索由 Apache Lucene 提供支持，并提供你所期望的常用功能：语言感知的分词和分析器（停用词移除、不区分大小写的匹配）、带有布尔运算符、引号短语和按属性限定范围的 Lucene 查询语法，以及随每个命中结果返回的相关性得分，按最佳顺序排列。

The index itself is instantiated once at ingest if it doesn’t already exist.如果索引尚不存在，则在摄取时实例化一次。

CREATE FULLTEXT INDEX content_search IF NOT EXISTS
FOR (n:Document|Section|Vault) ON EACH [n.displayName, n.content, n.aliases, n.description]

ki get — read it in orderki get —— 按顺序读取

ki allows retrieval directly from the graph as well, since the nodes carry the full text contents. --type full reconstructs a document or section along NEXT_SECTION, not as random chunks — the agent reads the article in the order it was written, not a shuffled top-k.ki 也允许直接从图检索，因为节点携带完整的文本内容。--type full 沿着 NEXT_SECTION 重建文档或章节，而不是作为随机块——智能体按照作者书写的顺序阅读文章，而不是打乱的 top-k。

Background, Origins, Implementation come back in the order the author wrote them — the same order ki outline showed above — not ranked by relevance. --type content returns just the node’s own preamble plus pointers to its children, for when you want to drill rather than pull the whole subtree – useful for progressive disclosure and protecting from context rot.Background、Origins、Implementation 会按照作者书写的顺序返回——与上面 ki outline 显示的顺序相同——而不是按相关性排名。--type content 仅返回节点自身的序言加上指向其子节点的指针，当你想要深入挖掘而不是拉取整个子树时使用——这对于渐进式披露和防止上下文失效很有用。

ki get is also what makes remote access work: you can host Neo4j on Aura or any other cloud option, so even when the file system is local to one machine, the text is still reachable from anywhere the graph is.ki get 也是远程访问生效的原因：你可以在 Aura 或任何其他云选项上托管 Neo4j，因此即使文件系统对于一台机器是本地的，文本仍然可以从图所在的任何地方访问。

Graph reasoning — free-form Cypher图推理 —— 自由形式的 Cypher

The knowledge-base skill instructs the agent to use the neo4j-cli where the logic called for is not covered by existing ki cli commands. This allows the agent to reason over the Neo4j graph directly, writing Cypher ad hoc via neo4j-cli query "<cypher>" --credential <profile> — backlinks, shortest path, centrality, whatever the question needs. Here are a couple of examples, run against the same vault:知识库技能指示智能体在现有 ki CLI 命令未涵盖所需逻辑时使用 neo4j-cli。这允许智能体直接对 Neo4j 图进行推理，通过 neo4j-cli query "<cypher>" --credential <profile> 即兴编写 Cypher——反向链接、最短路径、中心度，无论问题需要什么。这里有几个例子，针对同一个库运行：

“What’s load-bearing — what should I read first?” → in-degree centrality over the link graph (ranks the most-linked-into docs):“什么是承载关键信息的——我应该先读什么？”→ 链接图上的入度中心度（对被链接次数最多的文档进行排名）：

No LLM call, no ranking heuristic — just the shape of the link graph telling the agent which four or five notes the rest of the vault leans on.没有 LLM 调用，没有排名启发式——只有链接图的形状告诉智能体库中其余部分所依赖的四五篇笔记。

“What’s the throughline between the GraphRAG-cost argument and the AIP project?” → shortest link path between the two docs, which surfaces the bridging document. Note that the hops alternate HAS and LINKS_TO: wikilinks are written inside sections, so getting from one document to another means dropping into the section that cites it.“GraphRAG 成本论点与 AIP 项目之间的主线是什么？”→ 两个文档之间的最短链接路径，这会浮现出桥接文档。请注意，跳跃在 HAS 和 LINKS_TO 之间交替：维基链接写在章节内，因此从一个文档到另一个文档意味着进入引用它的章节。

The bridging document is graph-shape-over-flat-shape.md — a theme note neither endpoint mentions by name. That is the answer to a question no amount of similarity search would have produced, and it took one query.桥接文档是 graph-shape-over-flat-shape.md——一个两个端点都没有明确提及的主题笔记。这是任何相似性搜索都无法产生的问题的答案，而且只需要一个查询。

themes — surfacing patterns (roadmap)主题 —— 浮现模式（路线图）

The above concerns navigation and search, but in the spirit of the higher-level synthesis Karpathy’s recipe calls for, this next command focuses on finding themes across the corpus that no one has named yet. GDS community detection over the wikilink graph is used to surface these unlabeled themes. Themes is not released yet — it lives on a branch with the PR still open — so you must check out that branch to test and the run below:以上涉及导航和搜索，但秉承 Karpathy 配方所要求的更高级别综合的精神，下一个命令侧重于在语料库中寻找尚未命名的主题。维基链接图上的 GDS 社区检测被用于浮现这些未标记的主题。Themes 尚未发布——它位于一个 PR 仍处于打开状态的分支上——因此你必须检出该分支进行测试，并运行下面的命令：

Reading it: the header reconciles every document — grouped, ungrouped, excluded — so nothing quietly disappears. Each theme then carries its own evidence rather than a label an LLM guessed at. Top wikilink targets are the notes the theme’s documents keep citing, which is usually the closest thing to a name the corpus has: T1 converges on [[aip-paper]], [[aip]], [[aip-launch-blog]], so T1 is the AIP (Agent Instruction Protocol) project without anyone having said so. Most-linked docs ranks members by links within the theme, giving the agent an entry point. Links into Tvia names the single document that bridges two themes — the drill handle for “how are these connected.”阅读它：标题协调了每个文档——分组、未分组、排除——所以没有任何东西会悄然消失。每个主题随后都携带自己的证据，而不是 LLM 猜测的标签。顶级维基链接目标是主题文档不断引用的笔记，这通常是语料库中最接近名称的东西：T1 收敛于 [[aip-paper]]、[[aip]]、[[aip-launch-blog]]，所以 T1 是 AIP（智能体指令协议）项目，而无需任何人明确说明。最常被链接的文档按主题内的链接对成员进行排名，为智能体提供入口点。Links into Tvia 通过名称命名连接两个主题的单个文档——即“它们是如何连接的”的钻头柄。

The cohesion word comes from each community’s conductance, the fraction of its link mass that crosses the boundary: at or below 0.35 it reads tightly interlinked, at or above 0.60 loosely, otherwise moderately. It is a hedge against over-reading a weak cluster.内聚力词来自每个社区的电导率，即跨越边界的链接质量分数：在 0.35 或以下读取为紧密互连，在 0.60 或以上为松散，否则为中等。这是防止对弱聚类过度解读的对冲手段。

The value here is the thing search cannot do. Fulltext finds the documents that match a phrase you already thought of. This finds the groups nobody labeled — including the ones the author would deny having, which is exactly when it earns its keep.这里的价值在于搜索无法做到的事情。全文搜索能找到匹配你已经想到的短语的文档。这能找到没人标记的组——包括作者会否认存在的那些，这正是它发挥作用的时候。

The themes result is derived in multiple underlying graph steps. First a projection of the doc-level wikilink graph is created (sections collapse to their owning document; LOCAL_STUB / WIKILINK_UNRESOLVED nodes ride along as co-citation glue, so two docs that both cite [[GraphRAG]] cluster together even if they never link each other):主题结果是在多个底层图步骤中导出的。首先创建文档级维基链接图的投影（章节折叠到其所属文档；LOCAL_STUB / WIKILINK_UNRESOLVED 节点作为共引胶水随行，因此两个都引用 [[GraphRAG]] 的文档即使从未链接对方也会聚类在一起）：

The Leiden community detection is run, followed by per-community conductance for the cohesion word.运行 Leiden 社区检测，随后计算每个社区的电导率以获得内聚力词。

CALL gds.leiden.mutate($graphName, {
  mutateProperty: 'themeId',
  relationshipWeightProperty: 'weight',
  gamma: $gamma,
  randomSeed: 42,
  concurrency: 1
}) YIELD communityCount, modularity
RETURN communityCount, modularity
CALL gds.conductance.stream($graphName, {
  communityProperty: 'themeId',
  relationshipWeightProperty: 'weight'
}) YIELD community, conductance
RETURN community, conductance

mutate rather than write: conductance reads themeId off the in-memory graph, which never sees database writes, so persistence waits until after the metric. randomSeed plus concurrency: 1 make the assignment deterministic for a given projection.mutate 而不是 write：电导率从内存图读取 themeId，该图从不进行数据库写入，因此持久化等待指标计算之后。randomSeed 加上 concurrency: 1 使分配对于给定的投影是确定性的。

Write the assignment back — clear stale ids, persist, then fold sub-floor themes (< 3 member docs) into ungrouped:将分配写回——清除过期的 ID，持久化，然后将子底板主题（< 3 个成员文档）折叠到未分组中：

// clear stale themeIds from a prior run
MATCH (n:Document)
WHERE n.uri STARTS WITH $vaultPrefix AND n.themeId IS NOT NULL
REMOVE n.themeId
CALL gds.graph.nodeProperties.write($graphName, ['themeId'])
YIELD propertiesWritten
RETURN propertiesWritten
// fold themes with fewer than $minThemeDocCount member docs into ungrouped
MATCH (m:Document {sourceType: 'LOCAL_FILE'})
WHERE m.uri STARTS WITH $vaultPrefix AND m.themeId IS NOT NULL
WITH m.themeId AS theme, count(m) AS docCount
WHERE docCount < $minThemeDocCount
WITH collect(theme) AS smallThemes
MATCH (n:Document)
WHERE n.uri STARTS WITH $vaultPrefix AND n.themeId IN smallThemes
REMOVE n.themeId

Then read the rendered output — members (with within-theme link counts), top wikilink targets, and crossover docs:然后读取渲染的输出——成员（带有主题内链接计数）、顶级维基链接目标和交叉文档：

// members + within-theme link counts (drives "most-linked docs")
MATCH (src)-[l:LINKS_TO]->(tgt)
WHERE src.uri STARTS WITH $vaultPrefix AND tgt.uri STARTS WITH $vaultPrefix
MATCH (s:Document {uri: split(src.uri, '#')[0]})
MATCH (t:Document {uri: split(tgt.uri, '#')[0]})
WHERE s.sourceType = 'LOCAL_FILE' AND t.sourceType = 'LOCAL_FILE' AND s <> t
  AND s.themeId IS NOT NULL AND s.themeId = t.themeId
UNWIND [s, t] AS d
WITH d.themeId AS theme, d, count(*) AS withinThemeLinks
RETURN theme, d.uri AS uri, d.displayName AS displayName, withinThemeLinks
ORDER BY theme, withinThemeLinks DESC, uri

The linkingDocs > 1 filter is what keeps this honest: a target only one document cites is that document’s private reference, not something the theme converges on.linkingDocs > 1 过滤器是保持其真实性的原因：只有一个文档引用的目标是该文档的私人参考，而不是主题收敛的内容。

None of that is reachable without the graph: community detection needs the link structure as a first-class object, and there is nothing in a folder of markdown to run it against. But notice how little of it surfaces — six queries, a GDS pipeline, and a conductance threshold collapse into one command with four flags. That is the pattern across all four verbs: the graph is what makes the question answerable, and the CLI is what makes it a single line an agent can type without knowing any of this exists.没有图，这一切都无法实现：社区检测需要链接结构作为一等对象，而 Markdown 文件夹中没有任何东西可以运行它。但请注意它浮现出的东西有多么少——六个查询、一个 GDS 流水线和一个电导率阈值坍缩成一个带有四个标志的命令。这就是所有四个动词的模式：图是使问题可回答的原因，而 CLI 是使其成为智能体无需知道这一切存在即可输入的单行代码的原因。

This theme finding is also low cost, relatively deterministic, and hallucination-free. No LLM is called at any point — Leiden reads the link structure the documents already carry, so themes cost zero tokens to compute. A fixed random seed and single-threaded execution make the grouping deterministic, so re-running on an unchanged vault returns the same themes rather than a fresh hallucination. Change the notes and re-run; the answer moves because the corpus moved, not because the model felt different that session.这种主题查找成本也低、相对确定且无幻觉。在任何时候都不会调用 LLM——Leiden 读取文档本身携带的链接结构，因此主题计算消耗零 Token。固定的随机种子和单线程执行使分组具有确定性，因此在未更改的库上重新运行会返回相同的主题，而不是新鲜的幻觉。更改笔记并重新运行；答案会移动，因为语料库移动了，而不是因为模型在该会话中感觉不同。

From an abstract wiki to a scalable knowledge layer从抽象维基到可扩展知识层

The reason to care past a hobby vault: This is the version that scales. Historically, the expensive, brittle part of most GraphRAG pipelines has been an LLM extracting entities or writing summaries at build time. Karpathy’s wiki recipe provides that upfront now. What’s left is a deterministic Neo4j graph built from the structure the documents already carry, which changes the economics at every step up:超越业余库去关心的原因：这是可以扩展的版本。从历史上看，大多数 GraphRAG 流水线中昂贵且脆弱的部分一直是 LLM 在构建时提取实体或编写摘要。Karpathy 的维基配方现在预先提供了这一点。剩下的是一个从文档本身携带的结构构建的确定性 Neo4j 图，它改变了每一步升级的经济性：

  • A team’s shared docs or wiki. Projects like ki serve remote, read-only vaults from Neo4j. Index once, let many agents (or an app) navigate the same graph without a copy each, and deterministic sync keeps it current instead of drifting.团队的共享文档或维基。像 ki 这样的项目从 Neo4j 提供远程、只读库。索引一次，让多个智能体（或应用）导航同一个图而无需各自拷贝，确定性同步使其保持最新而不是漂移。
  • An agent’s long-term memory. The notes an agent writes and re-reads are markdown with links; a Neo4j graph over them gives the agent navigation and backlinks over its own memory, no other extraction or embedding pipeline to maintain.智能体的长期记忆。智能体编写和重读的笔记是带有链接的 Markdown；其上的 Neo4j 图为智能体提供了对其自身记忆的导航和反向链接，无需维护其他提取或嵌入流水线。
  • A knowledge layer over structured data. The same “give the agent a navigable representation” idea extends past documents to schemas, lineage, and business definitions — a graph the agent walks instead of guessing JOINs. That’s a bigger post and a hands-on workshop, but it’s the same thesis on the same engine: agents retrieve better when they navigate an explicit structure. Neo4j is where that structure lives, from a personal vault to a warehouse.结构化数据之上的知识层。相同的“给智能体一个可导航的表示”的想法扩展到文档之外，涵盖模式、血缘和业务定义——智能体遍历图而不是猜测 JOIN。这是一个更大的文章和实践研讨会的主题，但它是基于同一个引擎的相同论点：当智能体导航显式结构时，检索效果更好。Neo4j 是该结构存在的地方，从个人库到仓库。

At production scale, “Zero tokens to build, idempotent ingest, reads that stay fast as the corpus grows” stops being a nicety and becomes the reason it’s viable. It’s the whole case that structure-and-link GraphRAG on Neo4j should be the default, not a specialist tool.在生产规模上，“构建零 Token、幂等摄取、读取随着语料库增长而保持快速”不再是锦上添花，而是它可行的原因。这就是为什么 Neo4j 上的结构与链接 GraphRAG 应该是默认设置，而不是专家工具的全部理由。

Why now为什么是现在

The Karpathy post made the shape of this problem visible to a much bigger audience. Google’s OKF turned that shape into a proposed standard, but pointedly left retrieval out of scope. The NICD research made the case for navigating a graph over sampling a vector store, with numbers. The format is settling, retrieval is the open question, and the numbers say a graph is the answer.Karpathy 的文章让更广泛的受众看到了这个问题的形状。Google 的 OKF 将该形状变成了提议的标准，但明确将检索排除在范围之外。NICD 的研究用数据证明了导航图优于采样向量存储。格式正在确定，检索是悬而未决的问题，而数据表明图是答案。

If you’re running any version of this stack — personal, team, or production — retrieval is where it feels least serious, and it’s the one part with a clean, cheap upgrade. And if you’re building your own agent tools over a corpus of markdown, the point stands regardless of what you build it with: Give the agent a structure it can navigate, not just a box it can search. The cheapest place to put that structure is a graph, and the natural home for the graph is Neo4j.如果你正在运行此堆栈的任何版本——个人、团队或生产——检索是感觉最不严肃的地方，而且它是唯一一个有干净、廉价升级的部分。如果你正在 Markdown 语料库上构建自己的智能体工具，那么无论你用什么构建它，观点都是成立的：给智能体一个它可以导航的结构，而不仅仅是一个它可以搜索的盒子。放置该结构最便宜的地方是图，而图的自然家园是 Neo4j。

curl -sSfL https://knowledge-index.ai/install.sh | bash

Same recipe as before, but now the agent can see the whole thing, and walk it.配方与之前相同，但现在智能体可以看到整个事物，并遍历它。

Share Article

Explore

What is contextual retrieval? How AI agents find the right context


9 min read

How to Set Up and Redeem Your Neo4j Startup Program Credits


4 min read

Who controls your intelligence analysis platform?


7 min read

Graph-grounded Copilots in Microsoft Fabric

Beyond the Banana: Driving real-time recommendations with graph-grounded Copilots in Microsoft Fabric


5 min read

Vector RAG vs. GraphRAG: Which retrieval do you need?


10 min read

New Ways to Scale and Apply Enterprise AI with Neo4j


4 min read