原文链接：用 Karpathy LLM Wiki 方法论，为 AI Agent 系统构建结构化知识层

这篇文章讲的不是“再做一个知识库”，而是把知识库当成 Agent 系统的长期知识层来设计。它的核心启发是：企业知识不应该只停留在一堆文档、网页收藏、聊天记录里，而应该被整理成可检索、可链接、可更新的结构化 Wiki。

先说结论

我理解这篇文章的重点有三个：

  1. Agent 需要的不是一次性 RAG，而是长期可维护的知识层。
  2. 检索不应该只靠向量，grep + 向量 + 图谱扩展 可以互相补失败模式。
  3. 中文技术知识里，精确词、缩写、同义词和领域术语非常重要，不能盲目相信 embedding。

传统 RAG 更像“问一次，临时找资料，再回答”。LLM Wiki 的思路更像“先把知识编译成一个持续增长的代码库”。每次新增资料，不只是存进去，而是要抽取概念、建立链接、更新索引，让后续检索和推理都能复用这部分沉淀。

LLM Wiki 的关键变化

Karpathy 的 LLM Wiki 有一个很有意思的比喻：

  • Obsidian 类似 IDE。
  • Wiki 类似代码库。
  • LLM 类似程序员。

这和普通 RAG 的区别很大。

普通 RAG 通常关注“怎么把文档切片后召回”。LLM Wiki 更关注“怎么把读过的内容变成长期资产”。它希望知识不是一次性上下文，而是被持续维护的 Markdown 页面、双链关系和概念网络。

这样做的好处是：

  • 知识不会每次都从零检索。
  • 不同来源的信息可以被合并到同一个概念页。
  • 概念之间的关系可以沉淀下来。
  • 冲突、重复、过时内容更容易被发现。
  • Agent 可以基于一个稳定的知识结构继续工作。

换句话说，RAG 是查询时检索，LLM Wiki 是摄入时整理。

三通道检索：grep、向量、图谱

文章里最值得看的工程点，是它没有押宝单一检索方案，而是组合了三种通道。

第一种是 grep。

grep 负责精确匹配。技术知识里有很多强关键词，比如协议名、框架名、类名、错误码、函数名、缩写。只要词命中，相关性往往很高。尤其在中文技术语境中，很多新词、专有名词、英文缩写和中文混写，对 embedding 并不总是友好。

第二种是向量检索。

向量负责语义召回。当用户问法和文档表述不一致时，向量可以补 grep 的短板。比如用户问“设备通信标准”，原文可能写的是某个协议名；用户问“知识长期记忆”，原文可能写的是 Wiki、图谱或 memory。

第三种是图谱扩展。

图谱负责关系补充。一个页面本身可能没有直接命中查询词，但它和命中的页面存在链接、标签或社区关系。这个时候，通过邻居节点扩展，就能找到“用户没直接搜到但实际应该看的内容”。

这三个通道的分工很清楚：

  • grep 提供精确性。
  • 向量提供语义弹性。
  • 图谱提供结构关系。

为什么不是只用向量数据库

很多人一做知识库，第一反应就是上向量数据库。但这篇文章的价值在于提醒我们：向量检索不是银弹。

向量检索的问题主要有几个：

  • 它可能召回语义相似但任务无关的内容。
  • 它对领域新词、缩写、专有名词不一定稳定。
  • 它很难解释为什么某个结果排在前面。
  • 它不天然理解 Wiki 页面之间的显式链接关系。

如果用户查的是一个很明确的技术词，比如某个协议、某个 API、某个错误码，grep 往往更可信。因为它不是“语义上相似”，而是“文本里真的出现了这个词”。

所以合理的做法不是 grep 和向量二选一，而是先判断问题类型，再融合多路结果。

RRF 融合的意义

文章中提到的 RRF，可以理解成一种“多路排名合并”方法。

它不要求不同检索通道的分数完全可比，而是看各自排名。一个结果如果在多个通道里都排得靠前，就会获得更高综合排名。

这种方法适合混合检索，因为 grep、向量、图谱本来就不是同一种分数体系：

  • grep 的分数来自命中词和覆盖率。
  • 向量的分数来自相似度。
  • 图谱的依据来自链接、邻居、入度或社区。

直接比较这些分数很困难，用排名融合会更稳。

文章里 grep 权重大于向量，我觉得这个决策很符合中文技术知识库的特点：在有明确术语命中的情况下，精确匹配应该更可信；向量更适合作为补充召回，而不是压过精确命中。

对 Agent 系统的启发

这篇文章对我最大的启发是：Agent 的知识层应该像工程系统一样建设，而不是像资料仓库一样堆放。

一个可用的 Agent 知识层至少要考虑：

  • 知识怎么进入系统。
  • 进入后是否被结构化。
  • 概念之间是否建立链接。
  • 检索是否能解释。
  • 检索结果能否通过图关系扩展。
  • 旧知识是否能被更新或淘汰。
  • 新资料是否能持续融入已有体系。

如果只是把文档丢进向量库，短期可能能回答一些问题，但长期会遇到知识重复、语义漂移、上下文碎片化和维护困难。

LLM Wiki 的价值在于，它把知识管理从“存储问题”变成了“持续编译问题”。资料进来之后，系统要像编译器一样，把它变成更清晰的概念、索引和依赖关系。

和我之前看的 Claude Code 检索文章的关系

这篇文章和我之前看的 Claude Code / grep 检索思路可以连起来看。

Claude Code 的重点是：代码库天然结构化，所以动态 grep/ripgrep + 文件读取 很有效。

这篇文章进一步说明：如果对象不是代码，而是企业知识、技术文档和长期经验，那么只靠 grep 又不够，需要再叠加向量和图谱。

可以这样理解：

  • 代码库：文件名、函数名、错误信息天然强结构，grep 权重可以很高。
  • 普通知识库：自然语言表达更多，向量检索更重要。
  • 企业 Agent 知识层：既有技术术语，又有隐性关系，最好用混合检索。

所以不是“RAG 死了”，也不是“grep 万能”，而是不同数据形态需要不同检索组合。

小结

这篇文章真正有价值的地方，不是某个具体工具，而是一套工程判断：

  • 知识要结构化，不只是存起来。
  • 检索要混合，不要迷信单一方案。
  • 精确术语要尊重，不要全部交给 embedding。
  • 图关系要利用，因为很多重要知识藏在连接里。
  • Agent 的长期能力来自持续维护的知识层。

如果以后我要给自己的博客、阅读记录或项目经验做一个更智能的知识系统，这篇文章的方案很值得参考：先用 Markdown/Wiki 形成稳定知识单元，再用 grep 保证精确检索，用向量补语义召回，用图谱补关联扩展。

真正的目标不是“让 AI 搜到一段文本”，而是让 AI 拥有一个会持续变好的知识底座。