2026年，知识库重新回归

自从Karpathy发布了他的私人知识库方案，整个LLM圈子都在热议这个话题。说实话，这个方案确实有意思——不是那种堆砌向量数据库的老套路，而是让LLM本身来接管知识管理这件事。

作为OpenAI创始团队成员、刚刚加入Anthropic的研究员，Karpathy在LLM领域的每一次动态，几乎都是风向标。这次也不例外：他直接在GitHub上开源了一个名为“llm-wiki.md”的文件，没有完整的项目仓库，没有可复现的demo，就是一份方法论描述。但就这一份文件，获得了千万级的阅读量。

方案的核心理念，是把知识库拆成三个目录：raw存原始文档，wiki存摘要、实体、概念等结构化内容，schema存规则、提示词和约束。操作层面也是三重：

（摄入新文档）、（查询）、（健康检查，清理过时内容）。

如果要做个类比，传统基于向量召回的知识库，是知识的“

”——每次回答都要重新读取和理解原始材料。而Karpathy这套方案，更像是知识的“”：它会先将原始知识“编译”成结构化的wiki摘要，后续查询只需要基于这些摘要来回答，效率自然大幅提升。

把代码塞进知识库

方案出来后，社区里的复现实践层出不穷，但绝大多数都局限在文本数据上，比如学术论文、技术文档、学习笔记。这其实没有充分发挥LLM Wiki的潜力——它之所以有效，核心在于可以轻松将整篇文档放入上下文，直接理解并抽取关键信息。

恰好，我们团队的工作流经常需要调研竞品代码并进行横向对比。于是就产生了一个新想法：

怎么让LLM读透代码仓库

先来看看我们打算分析的三个仓库：

（6.36GB）、（958 MB）、（38MB）。再长的上下文窗口也容纳不了这么多信息。所以，我们需要从根本上重构LLM Wiki的数据管理逻辑，确保不遗漏任何细节。

三层目录

在raw目录中，我们不再直接存储原始代码，而是通过

关联到远程仓库。这样做的好处很明显：默认情况下，Submodule只是一个指向特定仓库特定分支的链接，只有LLM确实需要检查原始代码时，才会去拉取。而且，通过Submodule管理的代码天然支持增量更新，直接对比两个分支的diff就完成了更新。

在wiki目录中，我们把代码仓库划分成多个

，每个模块生成一个独立的wiki页面，各自描述对应的功能。这些wiki页面和其他类型的页面（比如实体、对话页面）一样，同样包含丰富的引用链接，还可以关联到特定的概念页面。

在schema目录中，所有的

和都会永久保存，确保可复用性和一致性。

三重操作

LLM Wiki提供的三种核心操作——

、、。其中查询和健康检查都可以直接复用在wiki之上，真正的难点在于知识摄入阶段如何建立准确的wiki。

我们广泛调研了现有工具，比如DeepWiki和RepoWiki，最终设计了一套两阶段生成方案：

• 架构生成阶段
  ：LLM扫描仓库的元信息，例如README文件和项目目录，先理解整体架构，然后自主划分模块。

• 细节生成阶段
  ：针对每一个模块，LLM阅读具体代码，生成详细的wiki内容。

这种分步方式，既让LLM可以自主决定模块划分，确保每个模块的代码规模适中、不会超出上下文限制，也给了用户一个中间审查的机会——在昂贵的细节生成环节之前，可以先看看模块划分是否合理。

怎么对齐概念和模块的名称？

“

”，这是把数据存入知识库的核心步骤。不同文档通过相同的概念建立关联，从而实现知识的图谱化。

在LLM出现之前，概念抽取与对齐堪称噩梦。比如“数据修改”和“数据更新”可能对应同一操作，而“量化交易”和“量化压缩”里的“量化”含义则完全不同。现在，强大的LLM基于对上下文的理解，几乎可以确保概念的对齐。具体来说，概念抽取遵循三条规则：

阅读LLM wiki中已有的所有概念；
从该文档中总结3～5个概念；
最多只允许出现一个新的概念。

受此启发，我们在解析代码仓库之前，会提前把其他仓库的wiki目录注入上下文，要求LLM在划分模块时必须参考已有的模块标题。这样一来，模块划分从“填空题”变成了“选择题”，最终抽取的模块自然能够更好地对齐。

实践案例：一次查询节约6倍token

这次我们选取了两个知名数据库产品

和，以及我们团队的开源数据库产品，让LLM Wiki横向对比这三个数据库在方面的能力。

回答质量对比

从结果来看，在事务处理的核心模块（

、、、），两组实验都能精准提取。差别在于对照组因为使用了原始代码，输出中包含了更多；而实验组基于wiki回答，更倾向于介绍。如果以“”为评判标准，两组的回答质量都相当不错。

资源开销对比

接下来看资源消耗。为了统一标准，我们以最终出账的credit为基准进行对比。结果显示，使用wiki之后，用极少的token就能解答问题，

。

这还不只是省钱的问题。由于token生成速度相对固定，token消耗量和整体执行时间大致成正比，所以执行时间同样存在

。一个更省token的方案，节省的不仅是开销，还有等待的时间。

总结与展望

这次LLM Wiki与代码仓库结合的实践，是我们将wiki数据管理方式扩展到

的一次尝试。这里的逻辑很清楚：既然LLM本身能够接收和输出任意格式的数据，那么由LLM管理的wiki也应该具备同样的能力。

此外，这种知识库管理方式打破了数据的边界。借助LLM的理解能力，

——无论是文本、代码、图片还是其他形态。

下一步，我们会把这套流程整合进CodeGraph（基于NeuG），让coding Agent在调研源码、跨仓库对比时，可以直接使用预编译好的代码知识库。这样一来，知识本身的获取、管理和复用，都会变得更加高效和体系化。