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

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 来重新设计了。

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

· · ·

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