知识图谱作为 RAG 的替代方案：当结构化检索优于向量嵌入时

Most RAG 的实现都以同样的方式失败：向量搜索检索到了看起来合理但并非用户真正需要的内容，LLM 用自信的辞令对其进行包装，最终用户得到一个大体正确但细节错误的答案。令人沮丧的是，这种失败模式是隐形的 —— 余弦相似度分数看起来很正常，检索到的片段也提到了正确的主题，但答案仍然是错的，因为问题需要跨关系进行推理，而不仅仅是语义上的接近。

向量嵌入 (Vector embeddings) 擅长一件事：找到听起来 像 你查询内容的文本。这是一种强大的能力，涵盖了极广的生产用例。但当问题取决于实体之间如何 连接（而非它们的描述有多匹配）时，这种方式就会出现可预见的失效。对于这类查询，知识图谱 —— 一种你可以通过 Cypher 或 SPARQL 遍历的属性图 —— 不仅仅是一种优化。它是一种从根本上不同的检索方式，解决的是另一类问题。

向量搜索失效的五个场景

在选择正确的工具之前，你需要识别出那些超出了嵌入处理能力的特定失败模式。

多跳查询 (Multi-hop queries)。“2023 年收购了竞争对手的公司的创始人曾就读于哪些大学？” 向量搜索会检索语义相关的片段，但没有一个片段包含完整答案。系统需要遍历：公司 → 收购事件 → 创始人 → 人员 → 就读 → 大学。每一跳都是确定性的 —— 边要么存在，要么不存在 —— 但向量搜索无法表示这种链条。它检索关于收购的片段和关于创始人的片段，然后将一堆松散相关的文本交给 LLM，寄希望于它能进行合成。知识图谱则显式地遍历这条路径，并返回链路末端的准确事实。

聚合和分析查询。“我们在医疗垂直领域的企业客户中，哪些正在使用旧版 API？” 这是一个任何 SQL 数据库都能在毫秒内处理的查询。向量搜索没有聚合原语 —— 它无法对检索到的集合进行计数、排序或过滤。常见的替代方案是将所有相关数据塞进上下文并要求 LLM 进行聚合，但这在规模化时会失效，并且当 LLM 遗漏记录或凭空捏造模式时会产生幻觉。

实体歧义。嵌入模型会塌缩多义性。在包含科技公司和农业内容的语料库中，针对“Apple 的第一款产品”的查询会检索到关于 Cosmic Crisp 苹果品种的片段，以及关于 Macintosh 电脑的片段。向量搜索无法区分 Apple Inc. 和 apple (fruit)，除非寄希望于周围的上下文能体现出差异。知识图谱为每个实体分配一个节点类型 —— name='Apple', type='company' —— 且查询指定了类型约束。歧义是在结构上解决的，而不是概率上。

时效冲突的事实。当多个来源对同一事实有不同描述时 —— 例如不同年份的 CEO，或在报告期之间发生变化的监管阈值 —— 向量搜索会将两者都检索出来并将矛盾交给 LLM，而 LLM 通常会含糊其辞或随意选择。图的边带有元数据。查询当前的 CEO 会按 valid_until 降序排列候选人，并返回最新的记录。你得到的是一个确定的答案，而不是模棱两可的推诿。

隐式关系幻觉。语义接近会产生错误的推论。如果 Tesla、Toyota 和 Panasonic 在你的语料库中都出现在“电池”一词附近，LLM 可能会推断出并不存在的合作伙伴关系。图的边是显式类型的 —— PARTNERS_WITH 与 MENTIONS_SAME_TOPIC 是不同的。只有带有正确标签的边会被返回，这使得特定关系的幻觉在结构上是不可能的，而不仅仅是概率上的低风险。

什么时候向量搜索仍是最佳选择

理解知识图谱的优势并不意味着将其视为万能替代品。在以下几种场景中，向量搜索仍然具有明显优势。

对于 开放域或探索性查询，语义相似性正是你所需要的。“本季度客户反馈的主要主题是什么？” 这种查询没有预定义的模式 —— 你希望撒一张大网并检索语义相邻的内容。强行将其放入图模式中需要预先了解客户反馈的本体 (ontology)，而你通常并不知道。

对于 非结构化数据的快速迭代，维护知识图谱的操作开销是真实存在的。构建图谱需要实体提取、关系识别、模式设计，以及随着数据变化而进行的持续维护。向量索引默认是只增的 (append-only)。如果你的检索需求主要是语义化的，且数据没有很强的关联结构，那么图检索带来的 3–5 倍成本溢价就很难证明其合理性。

对于 上下文窗口足以支撑的对话式 AI —— 例如回答有限产品目录问题的支持聊天机器人，或在小型代码库上运行的代码助手 —— 向量搜索的近似误差并不足以支撑对图基础设施的投入。

诚实的决策标准是：如果你的查询可以表达为“查找与此查询相似的文本”，向量搜索就很好。如果它们可以表达为“遍历这些特定类型的关系并返回路径末端的事实”，那么你需要一个图。

映射到 Agent 工具调用的图谱建模设计

引入知识图谱时，最重要的架构决策是模式设计 (schema design)，而最有效的思维框架是思考你希望 LLM Agent 进行哪些工具调用。

配备图遍历工具的 LLM Agent 可以像调用其他函数一样调用它：get_relationships(entity_id, relationship_type, filters)。这之所以强大，正是因为它是显式的 —— Agent 指定了它正在追踪哪种关系，这意味着结果是确定性的且可审计的。因此，模式设计的问题就变成了：Agent 需要追踪哪些关系才能回答它将面临的查询？

以下是跨领域通用的一些原则：

以正确的粒度建模实体。 如果将“文档”作为一个节点，你将失去在文档内部进行遍历的能力。如果将“句子”作为一个节点，图谱会增长到难以管理的规模。对于大多数企业级知识图谱，合适的粒度是该领域意义的原子单位：一个产品、一个人、一个法规、一个合同条款。文本块 (Chunks) 应该是节点的属性，而不是节点本身。

根据业务关系而非文档结构来命名边。 REFERENCES 是一种弱边类型。SUPERSEDES (取代)、AUTHORED_BY (作者为)、APPLIES_TO (适用于)、CONTRADICTS (矛盾) 是 Agent 可以进行推理的强边类型。LLM 不需要理解文档结构 —— 它需要理解领域关系。

为代表变动事实的边添加时间元数据。 在每条边上添加 valid_from、valid_until 和 source，可以将你的图谱从静态快照转变为版本化的历史记录。这使得“事件发生时的政策是什么”这类问题变得可回答。

保持较浅的边深度。 平均查询遍历超过 3–4 跳 (hops) 的图谱会出现查询性能问题，且 LLM 难以对其进行推理。如果一个查询需要 8 跳，那么该模式可能需要一个中间汇总节点。

覆盖两个领域的混合架构

在实践中，大多数生产系统的正确架构是结合这两种检索机制。它们互不替代 —— 而是覆盖不同的查询类别。

行之有效的模式是：第一轮检索使用向量搜索，第二轮使用图遍历。

当查询进入时，路由组件会对它进行分类 —— 可以通过轻量级分类器，也可以让 LLM Agent 决定调用哪个工具。符合结构化模式（多跳、聚合、显式实体查找）的查询进入图谱。需要广泛语义召回的查询进入向量搜索。对于两者都需要查询，图遍历可以优化向量搜索的结果：检索语义相关的候选对象，然后利用图谱检查关系约束，从而将候选对象过滤为正确答案。

这种混合模式还能优雅地处理知识图谱的局限性。图谱无法回答关于未显式建模的实体或关系的问题。向量搜索操作原始文本，从定义上就能处理新奇的查询。保留两者意味着当图谱模式未涵盖某个查询时，你不会遭遇硬性失败 —— 你可以回退到嵌入 (embeddings)，并接受该查询类别较低的精度。

关键的运维要求是保持两个索引同步。图谱中与源文档相矛盾的事实比完全没有图谱更糟糕。大多数生产团队在文档摄入时运行批量图提取流水线，实体和关系提取由运行结构化输出提取的 LLM 处理。图谱与向量索引源自相同的真相源 (source of truth)，因此它们保持一致。

必须诚实面对的运维权衡

知识图谱在其设计的查询类型上显著提高了 LLM 的准确性。代价是基础设施的复杂性和模式维护的开销。你的团队从维护一个数据库（向量库）变成了维护三个：向量库、图数据库以及为图谱提供数据的提取流水线。

这种提取流水线才是真正的持续成本。每当源数据发生变化 —— 增加新政策、废弃产品、组织结构变动 —— 图谱都需要更新。虽然可以自动化，但实体提取存在错误率，而图谱中的错误会产生“充满自信的错误答案”，这比“我不知道”更糟糕。

从知识图谱中获得最大价值的团队，通常处于关系结构稳定、数据变化可预测、且查询系统性地属于多跳或关系型的领域。医疗保健、法律、金融合规和企业软件依赖图谱是典型的例子。而过度投入知识图谱的团队，往往是那些为查询主要属于语义范畴的领域构建了复杂模式，而其实一个经过良好调优的向量索引就已经足够了。

从向量搜索开始。当你有了上述特定失败模式的具体证据时，再添加图谱基础设施 —— 这不应是一次通用的升级，而应该是针对向量搜索明显无法处理的查询类别的定向修复。为了修复特定失败而构建的图谱模式，会比凭空推测构建的模式设计得更好，因为失败案例会确切地告诉你哪些关系才是重要的。