# OpenAI 创始人说"我们用 AI 的方式全错了"——他给出了什么方案？

> 龙虾AGI通用实验室 · 2026-04-24

2026 年 4 月，OpenAI 联合创始人 Andrej Karpathy 发了一个 GitHub Gist，一周内收获 5000+ Star，引爆了整个 AI 社区的大论战。他说：我们一直在用 RAG，但 RAG 的方式根本就是错的。

这篇文章，带你彻底搞懂这场论战背后的核心问题：**当信息多到人脑装不下的时候，怎么设计一个好的结构，让 AI 帮你找到你需要的东西？**

· · ·

## 一、一个你每天都在面对的问题

先别管什么 RAG、Wiki、知识图谱这些术语。我们从一个生活场景说起。

假设你是一个疯狂的读书人。过去三年，你读了 500 本书，记了几千条笔记，存了上万篇文章。现在有人问你一个问题："关于人工智能对就业市场的影响，你怎么看？"

你知道你读过相关的内容，但散落在十几本书、几十篇文章、上百条笔记里。你要怎么找到它们，然后综合出一个有深度的回答？

这不是一个假设性问题。这就是**每一个知识工作者每天面对的现实困境**——我们很擅长"收集"信息，但很不擅长在需要的时候"找到"信息、"连接"信息。

AI 领域过去几年一直在试图解决这个问题。解决方案经历了好几代演化，各有优劣。今天我们就把这条线彻底梳理清楚。

· · ·

## 二、最原始的方案：传统 Wiki——"人肉整理，人肉搜索"

在 AI 介入之前，人类解决知识管理问题的经典方案就是 **Wiki**。

最著名的例子是维基百科（Wikipedia）。企业里常见的 Confluence、Notion 的文档功能、飞书文档，本质上都是 Wiki 的变体。

Wiki 的工作方式很简单：

**人来写**——你读完一篇论文，手动把要点整理成一个页面

**人来组织**——给页面分类、打标签、建链接

**人来搜索**——需要信息时，自己去搜关键词、翻目录

这就像一个**图书馆**：书是人编写的，分类是人做的，找书也要人自己去书架上翻。

**Wiki 的问题很致命**：全靠人维护。团队一忙起来，没人更新文档，三个月后一半内容就过期了。新员工去搜索，找到的信息可能是两年前的。久而久之，Wiki 就变成了一座"知识坟场"——信息都在，但没人相信它是对的，也没人愿意花时间去更新它。

· · ·

## 三、第一次进化：RAG——"AI 帮你翻书，但每次都从头翻"

2020 年前后，随着大语言模型（LLM）的崛起，一种叫 **RAG（Retrieval-Augmented Generation，检索增强生成）** 的技术架构成了行业标准。

RAG 这三个词拆开看：

**Retrieval（检索）**——从知识库里找到相关内容

**Augmented（增强）**——用找到的内容增强模型的能力

**Generation（生成）**——模型基于这些内容生成回答

简单说：**你问问题，AI 先去知识库里翻找相关内容，然后带着这些参考资料来回答你。**

这就像从"自己去图书馆翻书"升级到了"有一个助手帮你翻书、然后口头给你总结"。

## RAG 的具体流程是什么？

业界常说的"RAG 管道（pipeline）"指的就是从提问到回答的整个流水线。典型步骤是：

**用户提问**："特斯拉的电池技术和比亚迪比怎么样？"

**查询改写**：把问题优化成更适合检索的形式

**检索**：从知识库里找到最相关的文档片段

**重排序**：对找到的片段按相关性重新排列

**拼接上下文**：把最相关的片段和原始问题拼在一起

**LLM 生成回答**：模型读完这些参考资料后生成答案

这条流水线里，**"检索"这一步最关键**——找不对资料，后面的回答再好也没用。

## 检索怎么做？——向量数据库登场

传统的关键词搜索有个致命缺陷：你搜"怎么让电动车跑得更远"，它找不到讲"续航里程优化"的文章，因为**字面上没有匹配的词**。

向量数据库解决了这个问题。它的原理是：

把每段文本转化成一串数字（向量），这串数字代表了文本的"含义"

搜索时，把你的问题也转化成向量

然后计算你的问题和所有文档之间的"距离"

距离最近的就是最相关的

这样，"让车跑更远"和"提升续航里程"在向量空间里距离很近，即使字面上完全不同，也能被找到。

**向量数据库擅长"模糊匹配"**——理解同义词、理解语义。但它也有问题：有时候语义上沾边但实际不相关的东西也会被捞出来，产生"检索噪音"。

## RAG 的问题在哪里？

RAG 用了两三年，大家发现了一个根本性的问题：**它没有记忆，不会积累。**

每次你提问，RAG 都要从头翻原始文档、重新拼凑答案。就像一个考生，每次考试都要从头翻教科书，从来不做笔记，从来不总结。哪怕你昨天刚问过几乎一样的问题，今天它还是要重新走一遍全流程。

更麻烦的是，当答案需要综合五六篇文档里的信息时，RAG 经常力不从心——因为它只是随机捞了几个"碎片"出来，碎片之间的关联是丢失的。

## 这就是 Karpathy 想解决的问题。

· · ·

## 四、第二次进化：LLM Wiki——"先做笔记，再开卷考试"

2026 年 4 月，Karpathy 提出了一个看似简单但很有深度的思路：**为什么不让 LLM 先把知识整理成一个结构化的百科全书，查询时直接读百科全书，而不是每次都翻原始教材？**

他管这个叫 **LLM Wiki**。

## 它是怎么工作的？

**第一步：扔原料。** 你把所有原始材料——论文、PDF、网页、笔记——丢进一个 raw/ 文件夹。这些文件永远不会被修改，它们是"真相来源"。

**第二步：LLM 编译。** 这是核心创新。LLM 读取所有原始材料，然后像一个百科全书编辑一样工作：

为每个关键概念写一篇结构化的 Markdown 文章

在文章之间建立交叉引用（"详见 [[电池技术]] 页面"）

生成一个 index.md 索引文件，相当于目录

比如你扔了三篇关于特斯拉、电池技术和电动车市场的文章进去，LLM 就会分别创建三个词条页面，并且把它们关联起来——特斯拉的页面会引用电池技术页面，电池页面会链接到市场趋势页面。

**第三步：查询。** 用户提问时，LLM 先读 index.md（目录），判断需要看哪几篇文章，然后只读那几篇，就能回答了。

**第四步：持续维护。** 定期让 LLM 做"健康检查"——检查有没有过时的内容、断掉的链接、概念之间的矛盾，然后自动修复。

## 用 Karpathy 的原话来理解

Karpathy 用了一个软件工程的类比来解释这个思路：**编译。**

写程序时，你不会每次运行都重新解释源代码——你会先编译成可执行文件，然后直接运行。编译这一步虽然费时间，但之后每次执行都很快。

RAG 就像每次都在"解释执行源代码"——每次查询都重新读原始文档。LLM Wiki 就像先"编译"——把原始文档一次性编译成整理好的百科全书，之后每次查询都直接读编译产物。

## LLM Wiki 的核心其实是索引设计

说到底，Wiki 的灵魂在于那个 index.md 索引。它本质上是一个精心设计的目录，让 LLM 在查询时能快速定位到相关内容。

如果你仔细想想，RAG 做的事情在逻辑上其实很类似——也是先通过某种索引（向量索引）找到相关内容，再交给 LLM。两者的差异在于：

**RAG 的索引指向原始文档碎片**——未加工的、可能是 PDF 第 14 页的某一段

**Wiki 的索引指向预编译的文章**——已经被综合、提炼、交叉引用过的内容

如果有人问你："Wiki 不就是带预处理的 RAG 吗？"——你可以说：**没错，Wiki 可以看作一种"预编译的 RAG"，关键区别在于索引指向的内容质量不同。**

## LLM Wiki 的局限

**规模天花板。** Wiki 的工作方式是把索引和相关页面都塞进 LLM 的上下文窗口，让模型"通读"后回答。但 LLM 的上下文窗口是有限的——大约在 5 万到 10 万 token 的时候，Wiki 就开始吃力了。超过这个规模，要么塞不进去，要么模型对中间部分的内容关注度下降，回答质量变差。

**错误会传播。** 如果 LLM 在"编译"阶段理解错了某个概念，这个错误会被写进 Wiki 页面，后续所有基于这个页面的回答都会跟着出错。不像 RAG 每次都读原始文档，至少不会"以讹传讹"。

但错误传播不是无解——可以通过**溯源追踪（provenance tracking）** 来缓解：每篇 Wiki 页面都记录它的内容来自哪些原始文档，出错时可以追溯到源头。配合定期的"健康检查"和版本控制（用 Git），大部分问题是可控的。

**单人使用。** Karpathy 原始设计是给个人研究者用的，没有考虑多人协作。两个人同时编辑同一个 Wiki 会冲突。当然，这个问题可以通过 Git 分支、Pull Request 或 CRDT 等技术解决，只是需要额外的工程投入。

· · ·

## 五、第三次进化：GraphRAG 和知识图谱——"画一张知识地图"

如果说 Wiki 是把知识整理成**文章**，那 GraphRAG 就是把知识整理成**地图**。

## 什么是知识图谱？

先理解"图"（Graph）这个概念。这里的"图"不是图片，而是数据结构——由**节点**（点）和**边**（线）组成的网络。

知识图谱就是专门用来表示知识的图：

节点代表**实体**：马斯克、特斯拉、锂电池

边代表**关系**：马斯克 —CEO→ 特斯拉、特斯拉 —使用→ 锂电池

关键在于，**边是有明确语义含义的**——不只是说"有关系"，而是说清楚这个关系是什么。"马斯克和特斯拉有关"vs"马斯克是特斯拉的 CEO"，后者才是知识图谱的表达方式。

Google 搜一个名人时右侧出现的信息卡片，就是典型的知识图谱应用。

## GraphRAG 怎么工作？

GraphRAG 在 RAG 的基础上加了一步：不是直接从原始文档检索碎片，而是**先从文档中提取实体和关系，构建知识图谱**，然后查询时通过图上的遍历来找到相关内容。

它的"编译"产物是一个**结构化的图数据库**，里面存的是一个个"三元组"——(实体A, 关系, 实体B)。

## GraphRAG vs LLM Wiki：图结构 vs 自然语言

两者最本质的区别是**知识的表达形式**不同：

## GraphRAG 用结构化的三元组：

(特斯拉, CEO, 马斯克)

(特斯拉, 竞争对手, 比亚迪)

(特斯拉, 使用, 锂电池)

(锂电池, 可能被替代, 固态电池)

## LLM Wiki 用自然语言文章：

特斯拉是全球领先的电动车制造商，由马斯克领导。其核心技术优势之一是电池管理系统，目前主要使用锂电池方案，但业界普遍认为固态电池可能在未来 5-10 年内逐步替代锂电池……

同样的知识，两种完全不同的表达方式。**图结构更精确但更刚性，自然语言更灵活但更模糊。**

具体来说：

## 图结构的优势——

**精确查询：** "马斯克担任 CEO 的所有公司"——沿边一查就出来了，确定性的，不遗漏

**多跳推理：** "特斯拉的电池供应商的矿产来源国"——图上跳两步就到，Wiki 里这信息可能散落在好几篇文章里

**可扩展：** 图天然适合扩展，节点越多、关系越丰富，价值越大，不受上下文窗口的限制

## 图结构的劣势——

**表达力受限：** "特斯拉**可能在 2026 年考虑**进入印度市场"——图里可能变成 (特斯拉, 进入, 印度市场)，那个"可能""考虑"的不确定性就丢了

**构建成本高：** 实体识别、关系抽取、消歧……一堆 NLP 任务要做

**不直观：** 人类读一篇文章比看一张几千个节点的图容易得多

**自然语言文章的优势和劣势正好反过来：** 保留了完整的语境和微妙含义，人机都能读，构建简单；但不能精确计算，跨文档推理靠"运气"。

## 一个关键洞察：两者可以结合

一个很自然的想法是：**每个概念既有一个图节点，也有一篇 Wiki 文章。**

图节点存结构化关系，用于精确查询和多跳推理。Wiki 文章存丰富的自然语言描述，用于深度理解和上下文保留。简单问题查图，复杂问题读文章。

这就像一本教科书——索引和目录是结构化的（图），正文是自然语言的（Wiki）。你找"哪一章讲了光合作用"用目录，真正理解光合作用要读正文。两者并不矛盾，恰恰互补。

已经有开源项目（如 Graphify）在做这样的尝试——从文档中既生成知识图谱，也导出 Wiki 式的 Markdown 文档，两层共存。

· · ·

## 六、深入探讨：如何设计一个好的知识检索结构？

到这里，我们已经走过了整个技术光谱。现在回到最核心的问题：**当信息量很大时，到底怎么设计一个好的结构来检索？**

## 先理解三种基本的组织方式

信息可以用三种基本结构来组织，各有各的性格：

**树形结构（分层文件夹）**——就像公司的组织架构图。每个信息只属于一个分类，层级清晰，适合"这个东西是什么类别"的问题。缺点是一个东西往往属于多个类别，树形结构处理不好这种情况。

**网状结构（知识图谱）**——就像人际关系网。任何两个节点之间都可以有关系，适合"这个东西和那个东西有什么关系"的问题。缺点是规模大了以后，网络变得极其复杂，人类很难直接理解。

**语义空间（向量数据库）**——就像一个高维空间，每个信息是空间里的一个点，距离近的就是含义相似的。适合"和这个最相关的内容有哪些"的问题。缺点是完全是"黑箱"，你不知道为什么模型觉得两个东西相似。

**这三种结构不是互斥的，而是可以叠加的。** 一个好的检索系统往往同时使用多种结构。

## 树形 + 网状：可以共存吗？

完全可以，而且效果很好。

文件夹做**粗分类**（树形），图谱做**细关联**（网状）。文件夹相当于图书馆的"楼层和区域"，图谱相当于书和书之间的"引用关系"。

举个例子：

/电动车行业/

  /公司/

    特斯拉.md

    比亚迪.md

  /技术/

    锂电池.md

    固态电池.md

这是树形结构。然后在这之上，用图谱表达网状关系：特斯拉 —使用→ 锂电池、特斯拉 —竞争→ 比亚迪、固态电池 —可能替代→ 锂电池。

树形管"归类"，图谱管"关联"。两者解决不同维度的问题。

## 能不能让文件夹也有"相似度"能力？

文件夹本身只是个存储结构，不具备"相似度"概念。但你可以在文件夹之上**叠加一层搜索机制**：

**给文件加标签/元数据**：比如 特斯拉.md 标注 tags: 电动车, 美股, 自动驾驶，通过标签重叠度算相似

**给文件生成向量嵌入**：文件物理上还在文件夹里，但搜索走向量索引

**用 LLM 理解文件夹结构**：用户搜"续航优化"，LLM 理解这和电池技术相关，自动导航到正确目录

本质上，**相似度检索需要某种数学表示（向量、标签权重等），纯文件夹提供不了**。但文件夹可以当"存储层"，在上面叠"搜索层"。

## 关键词匹配 + 语义检索：混合检索为什么是最佳实践？

前面提到的"混合 BM25/向量检索"是目前 RAG 系统公认的最佳实践。

**BM25** 是经典的关键词匹配算法，可以理解为"高级版的 Ctrl+F"。它根据关键词出现的频率、文档长度等因素打分。优点是精确——搜"锂电池"就找包含这三个字的文档。缺点是死板——搜"让车跑更远"找不到讲"续航"的文档。

**向量检索** 把文本转成向量，通过计算向量距离找语义相似的内容。优点是理解同义词。缺点是可能过度泛化。

**混合检索** 两种一起用：BM25 负责精确命中，向量检索负责语义扩展，最后综合排序。

混合检索的缺点是**两个分数怎么合并成一个排序**没有万能公式，需要根据数据反复调权重。开发上倒不算太难，现在 Elasticsearch、Weaviate 等工具都内置了混合检索能力，不用从零实现。

· · ·

## 七、灵魂问题：知识图谱能让大模型自己构建吗？

看到这里你可能会想：构建知识图谱这么复杂，一定需要一堆专用模型和工具吧？

## 不一定。现在的 LLM 完全可以直接干这个活。

你可以给 LLM 这样一个 prompt：

"读这篇文章，提取出所有实体和它们之间的关系，输出 JSON 格式。"

LLM 就能直接输出结构化的图谱数据。这正是 Graphify 等工具的做法。

但**"重不重"取决于规模**：

**几十篇文档**：不重，LLM 跑一遍就行

**几百篇文档**：有点重，需要并行处理，token 成本不低

**几万篇文档**：很重，纯靠 LLM 成本太高，这时用轻量专用模型做初步抽取，LLM 做精细化处理更经济

至于图数据库，也不是必须的。小规模场景下，把关系存成 JSON 文件用代码遍历就够了。只有需要复杂的图查询（比如"找所有和特斯拉有两度以内关联的公司"）时，Neo4j 这样的图数据库才值得引入。

**总结：小规模用 LLM 一把梭，大规模再引入专用组件。** 先跑起来，再优化。

· · ·

## 八、语义图谱的阴暗面：别只看优点

知识图谱和语义图谱听起来很美好，但缺点同样明显：

**构建质量难保证。** "苹果"是水果还是公司？"他"指的是谁？实体识别和关系抽取本身就容易出错，错误会直接污染图的质量。

**维护是个无底洞。** 一个人换了公司，一个政策被废除，图里的关系就要更新。很多知识图谱项目就是死在维护上——构建容易，保鲜太难。

**不擅长模糊知识。** "这篇论文的方法比较有创新性"——这种主观判断很难用三元组表达。图谱更适合事实性的、结构清晰的知识。

**冷启动成本高。** 构建一个有用的图谱需要大量初始数据和调优，不像 Wiki 那样扔几篇文章就能开始用。

· · ·

## 九、全景图：这些方案到底怎么选？

梳理完所有方案，我们可以画一张全景图了。这些技术不是互相替代的关系，而是一条**从简单到复杂的光谱**：

纯文本搜索 → RAG → LLM Wiki → Wiki + RAG 混合 → GraphRAG → 企业级知识图谱

从左到右：**越来越结构化、越来越精确、越来越可扩展，但也越来越复杂、越来越贵、越来越难维护。**

怎么选？看你的场景：

**个人笔记/小型知识库（< 100 篇文档）**——LLM Wiki 就够了。简单、直接、零基础设施。Karpathy 自己就是这么用的。

**中型团队知识库（100-1000 篇文档）**——Wiki + RAG 混合方案。Wiki 做预编译提升质量，RAG 做检索解决规模问题。

**大型企业知识管理（1000+ 篇文档，多人协作）**——GraphRAG 或完整的知识图谱方案。需要精确查询、权限控制、多人并发。

**通用问答/客服场景**——标准 RAG 管道。成熟、稳定、生态好。

最重要的认知是：**不要追求一步到位。** 先用最简单的方案跑起来，遇到瓶颈了再升级。从 LLM Wiki 起步，发现规模不够就加 RAG 检索层，发现关系推理不够就加图结构。这些技术本来就是可以渐进叠加的。

· · ·

## 十、最终思考：我们真正在解决什么问题？

回到开头那个场景：你有 500 本书的知识，怎么在需要时找到并综合它们？

RAG 说：我帮你翻书，每次都翻。 LLM Wiki 说：我先帮你做笔记，以后翻笔记就行。 GraphRAG 说：我帮你画一张知识地图，沿着地图走就能找到。

没有哪个方案是完美的。RAG 不积累，Wiki 有规模上限，GraphRAG 构建成本高。

但有一件事是确定的：**我们正在从"人找信息"走向"信息找人"的时代。** 过去你得知道去哪儿搜、搜什么关键词，现在你只需要说出你的问题，系统会帮你找到、整理、综合所有相关信息。

Karpathy 的 LLM Wiki 之所以引爆讨论，不是因为它是一个完美的解决方案，而是因为它让大家重新思考了一个根本问题：**我们和知识的关系，应该由 AI 来重新设计了。**

而你只需要知道这些方案各自擅长什么、不擅长什么，然后根据自己的需求选择最合适的那个——或者，把它们组合起来。

· · ·

如果这篇文章帮你理清了思路，欢迎分享给同样在知识管理道路上挣扎的朋友。关注我们，后续还会深入拆解每种方案的具体实现和踩坑指南。