当图结构成为新的语义载体，向量嵌入的护城河还剩多少？

RAG 还没死，但它正在被超越

当图结构成为新的语义载体，向量嵌入的护城河还剩多少？

文 / 一只阿木木

上一篇文章发出去之后，我收到了一条让我印象很深的评论。

一位读者留言说：

「阿木木，你说 Graphify 比 RAG 强，但我们团队已经在 RAG 上投入了大半年，换掉的成本太高了。你能不能说清楚，它们到底哪里不一样？RAG 真的要被淘汰了吗？」

我盯着这条评论看了很久。

因为这个问题，触到了我真正想在这篇文章里讨论的核心——

不是「Graphify 好在哪里」，而是「我们对 AI 记忆的理解，是不是从一开始就走偏了」。

一、先说一件让我困惑了很久的事

我用 RAG 用了将近两年。

说实话，RAG 在很多场景下确实有用——你上传一批文档，然后问它里面的内容，它能找到相关段落，给你一个还算靠谱的答案。

但我一直有一种隐隐的不对劲。

每次当我问的问题稍微复杂一点点，比如——

「这个产品决策，是基于哪几个底层假设推导出来的？」

「为什么我们当时选择了 A 方案，而不是 B 方案？」

「这三个模块之间，存在什么我没有意识到的隐性依赖？」

RAG 开始变得不可靠。它要么给我一堆貌似相关但实际上答非所问的片段，要么干脆坦白：「根据您提供的文档，我无法找到相关信息。」

我以为是我的文档写得不够好。我以为是我的提问方式有问题。

后来我才意识到：这不是我的问题，这是 RAG 的架构性局限。

而理解这件事，需要我们先搞清楚一个问题——

RAG 到底在解决什么？

二、三代 AI 记忆论：我们走了多远？

在聊 RAG 的局限之前，我想先建立一个更大的框架。

因为 RAG 不是凭空出现的，它是一个演化序列里的某一步。

我把过去几年 AI 记忆方案的演化，总结成「三代 AI 记忆论」：

第一代：暴力全塞（2022-2023）

核心逻辑： 上下文窗口有多大，就往里塞多少。

代表做法： 把所有相关文件复制粘贴进提示词，然后问问题。

为什么行得通： GPT-4 刚出来那会儿，大家对它的能力已经震惊到愿意接受任何不便，只要它能给出答案。

为什么走不下去： 贵。慢。而且上下文窗口有上限，你的知识库一旦超过某个规模，这条路就彻底堵死了。

第二代：RAG + 向量数据库（2023-2025）

核心逻辑： 不把所有文件塞进去，而是先把文件拆成小块，做成向量，存进数据库。问问题时，先用向量相似度找到「最相关的块」，再把这些块塞进上下文。

代表做法： Pinecone、Weaviate、Chroma，几乎所有 AI 应用公司在这两年都搭过 RAG 管道。

为什么这么流行： 确实解决了规模问题。你可以把几十万份文档都向量化，但每次只召回几个片段，Token 消耗可控。

为什么有局限： 这里是关键。我慢慢来说。

第三代：知识图谱 + 结构化语义（2025-至今）

核心逻辑： 不只存「内容」，还要存「关系」。把知识编织成网，而不是切成片。

代表做法： Graphify 是这个方向最近最典型的代表。

为什么这是进化： 等我说完 RAG 的局限，你就明白了。

三、RAG 的护城河，到底有多深？

我不想假装 RAG 没用。它有用，而且在很多场景下依然是最合适的选择。

但我需要说清楚，它的护城河，到底建在什么地方，又在哪里开始漏水。

RAG 本质上是在解决一个问题：「如何在大量文本里，找到跟问题最相似的段落？」

注意这句话里有一个词：相似。

向量数据库的核心机制，是把文字转化成高维空间里的一个点，然后通过计算点与点之间的距离，来判断两段文字的语义相似程度。

这个机制有一个根本性的前提假设：

语义相似 = 信息相关。

在很多情况下，这个假设成立。你问「苹果的营养价值」，RAG 能找到讲苹果维生素含量的段落，因为它们语义上确实相似。

但在另一些情况下，这个假设会崩塌。

我给你举一个真实的例子。

假设你的知识库里有这样三个片段：

片段 A： 「我们选择了事件驱动架构，主要是为了解耦各个微服务模块。」

片段 B： 「消息队列的最大延迟设置为 500ms，这是根据用户体验团队的基准测试结果决定的。」

片段 C： 「用户体验团队在 Q3 做了一次大规模的压力测试，测试报告存放在 /docs/ux/q3-test.pdf。」

现在你问：「我们为什么选择了这个架构，它对用户体验有什么影响？」

RAG 会怎么做？

它会找到跟「架构」「用户体验」语义最相似的片段。片段 A 和片段 C 可能会被召回，但它可能不会把这三个片段之间的链式关系告诉你：

事件驱动架构 → 依赖消息队列 → 延迟设置 500ms → 这个数字来自用户体验团队的测试 → 测试报告在这里

这条推理链，不存在于任何单一的片段里。它只存在于片段与片段之间的关系里。

RAG 找到了节点，但看不见边。

而知识图谱，把边本身变成了一等公民。

四、Graphify 的双 Pass 架构：一次工程上的清醒决策

好，现在我们来拆 Graphify 的技术架构。

但我不想只给你讲技术细节，我想讲的是：它的每一个设计决策背后，解决的是什么哲学问题。

Pass 1：确定性解析——先相信语法，再相信 AI

Graphify 的第一个处理通道，用的是 Tree-sitter——一个完全在本地运行的代码语法解析器。

它做的事情非常具体：把你的代码文件变成一棵抽象语法树（AST），然后从中提取：类、函数、导入关系、调用链、文档字符串、设计注释。

这一步，完全不调用任何 AI。

为什么？

因为代码的语法结构是确定的。function A 调用了 function B，这是一个事实，不需要 AI 来推断，也不应该让 AI 来推断——因为 AI 有可能推断错，而语法解析器不会。

这个决策体现了一种工程哲学：能用确定性方法解决的问题，不要引入不确定性。

支持 19 种编程语言：Python、JavaScript、TypeScript、Go、Rust、Java、C、C++、Ruby、C#、Kotlin、Scala、PHP、Swift、Lua、Zig、PowerShell、Elixir、Objective-C。全部走这条确定性通道，全部在本地完成，你的代码不会离开你的机器。

Pass 2：语义提取——让 AI 做 AI 最擅长的事

第二个处理通道，才轮到 AI 出场。

这个通道专门处理：文档、PDF、Markdown、截图、图表、白板照片……所有「非结构化」的内容。

Claude 在这里做的事，是提取概念、关系和设计意图——这些东西不在语法里，只在人类的表达和思考里，只有 AI 才能理解。

两条通道的结果，最终融合进一张统一的 NetworkX 图，然后用 Leiden 算法做社区聚类，把关系密切的节点归为一组。

这里有一个细节值得单独说：

Leiden 算法是基于图拓扑结构来聚类的，不是基于向量嵌入。

这意味着，你不需要再跑一遍嵌入计算，不需要再搭一个向量数据库。图结构本身就携带了足够的相似度信号——因为关系密集的节点，天然就是「语义相关」的。

图结构本身，就是相似度。

这是 Graphify 最漂亮的一个设计决策。

五、我认为最重要的设计：认知诚实性

我现在想聊一个很多技术评测不会聊的话题——

Graphify 的道德设计。

听起来有点奇怪？让我解释。

Graphify 给图谱里的每一条关系，都打上了三种标签之一：

• EXTRACTED
  ：直接从源码或文档中找到的，是事实
• INFERRED
  ：AI 推断出来的，附带置信度分数，是假说
• AMBIGUOUS
  ：存疑的，标记出来等待人工审查

这三个标签，在技术上不复杂。但它背后的哲学，非常深刻：

它在说，AI 知道自己知道什么，也知道自己不知道什么。

我们生活在一个 AI 幻觉泛滥的时代。每天都有人在用 AI 生成的「权威答案」做决策，却不知道那个答案有多大比例是编造的。

大多数 AI 工具的设计，是尽力掩盖这种不确定性，让输出看起来更流畅、更自信。

Graphify 的设计，是把不确定性暴露出来，让你自己判断。

这需要勇气。因为「我不确定」是一个让很多产品经理害怕的设计选择——它可能让用户觉得工具不够强大。

但我认为，在 AI 时代，一个工具的可信度，恰恰来自于它对自身局限的诚实。

六、然后我决定亲自跑一遍

光讲理论没有说服力。我决定亲自跑一遍，看看结果是什么样的。

我选了一个自己的真实项目——一个内容创作的素材管理系统，包括：

• 若干个 Python 脚本（负责抓取、清洗和存储内容）
• 几篇架构设计文档（Markdown 格式）
• 两篇我收藏的关于知识管理的研究论文（PDF）
• 几张系统架构图（截图）

安装过程出乎意料地简单：

Bash

pip install graphifyy
graphify install        # 针对 Claude Code
/graphify .             # 在项目目录下运行

大概等了几分钟，graphify-out/ 目录出现了。

里面有三个文件：

graph.html — 一张可以在浏览器里直接打开的交互式知识图谱。你可以点击每个节点，看它的属性；可以搜索关键词，高亮相关节点；可以按社区筛选，看某个功能模块的所有关联。

GRAPH_REPORT.md — 一份自动生成的图谱分析报告，里面有：God 节点（连接最多的核心节点）、惊喜连接（你可能没有意识到的跨模块关系）、以及建议你问 AI 的问题列表。

graph.json — 持久化的图谱数据文件，这是 AI 每次查询时真正读取的东西。

然后我问了一个我一直没办法用 RAG 回答清楚的问题：

「我的数据清洗模块和存储模块之间，存在哪些隐性依赖？如果我修改清洗逻辑，最可能影响哪些下游模块？」

答案……出乎我的意料。

它不只告诉了我直接依赖，还追踪到了两个我完全没有意识到的间接依赖链。其中一个，指向了我六个月前写的一篇架构笔记里的一个设计决策——而那篇笔记，我已经完全忘记了。

那一刻我有一种奇特的感受：

我的 AI，比我更了解我自己的项目。

七、那么，RAG 真的要被淘汰了吗？

回到那位读者的问题。

我的答案是：不，RAG 不会被淘汰，但它的适用边界正在变得更清晰。

让我直接说：

用 RAG，当你的问题是「找到什么」： 大量文档里找特定信息、合同审查、客服知识库问答——这些场景，RAG 依然是高效的选择。

用知识图谱，当你的问题是「理解为什么」： 代码架构分析、系统设计决策追溯、跨模块依赖分析、研究思路梳理——这些场景，图谱有结构性优势。

真正危险的，是用 RAG 去回答图谱问题，然后得出错误结论，却以为自己做了充分的检索。

这才是我想让你警惕的事。

至于向量数据库公司们，我觉得他们有三条路：

路一： 继续深耕「找相似」这条赛道，把向量检索做到极致，这是他们的基本盘。

路二： 开始融合图结构，把关系信息注入向量空间，混合架构可能是下一个主流形态。

路三： 什么都不做，等待市场教育它们。

我不知道最终会怎样。但我知道，「向量相似度是语义理解的充分条件」这个假设，已经开始被认真挑战了。

八、我的判断

最后，还是说说我的个人判断。

我认为 2026 年会是 AI 记忆架构的分水岭年。

不是因为某一个工具出现了，而是因为整个行业开始认真对待一个之前被忽视的问题：AI 不只要聪明，还要有记忆。而有记忆，不只是存储，是理解关系。

Graphify 是这个方向上一个快速涌现的早期信号。它不完美——图谱会漂移，冷启动有成本，对小项目来说可能是过度工程。

但它证明了一件事：「给 AI 装上结构化记忆」这件事，不是科幻，是可以在今天实现的工程。

而那些今天就开始认真思考「如何为我的项目建立知识图谱」的人，会在半年内获得一个别人没有的优势：

他们的 AI 协作者，有历史。有上下文。有记忆。

这和那些还在每次对话开头复制粘贴背景的人，使用的已经不是同一种 AI 了。

这是 Graphify 系列的第二篇。

第一篇讲了为什么 AI 失忆是一个文明级问题，以及 Graphify 的诞生故事。

下一篇，我会放下理论，聊聊我真正跑通之后发现的5个你意想不到的用法——以及三个差点让我踩坑的地方。

如果你也在用 RAG，或者你已经在考虑知识图谱，欢迎在评论区告诉我：你遇到过「RAG 回答不了」的问题吗？

—— 一只阿木木

一个在 AI 时代，用工具折射判断，用判断建立认知的内容创作者。

💬 这篇文章如果让你重新思考了 RAG 和知识图谱的关系，转发给你的朋友。 📌 系列第三篇即将更新，关注不迷路。

松花酿酒，春水煎茶。

眉上风止，见字如晤。

一只阿木木