5个知识图谱KG和RAG系统的误解 — 构建和使用RAG原生图谱

# 5 Misconceptions of KG & RAG Systems — Building & Using RAG-Native Graphs

说到GraphRAG系统，大家脑子里可能已经冒出不少“想当然”的结论。今天咱们就专门来聊聊这些常见的误解，特别是知识图谱构建里那些容易被忽略的细节，以及我们称之为“RAG-Native Graphs”的东西到底是怎么回事。

常见误解＃A：需要一个大图谱

很多人一提起知识图谱，下意识就觉得那得是个庞然大物——动辄花费数年、投入数百万美元才能建起来的巨型单体数据结构。这个印象其实来自于LLM出现之前的特定场景，比如大规模欺诈检测、生物医药知识发现这些领域，确实需要那样的大规模图谱。

但LLM登场之后，情况完全变了。一方面，LLM可以自动化地完成大量知识图谱构建工作，过去需要几年才能做完的事，现在几秒钟就能搞定。另一方面，LLM系统还催生了“小图谱”的机会——建一个有价值的小图谱，激活成本大大降低，不再需要那么高的启动门槛。

在LLM之前，知识图谱主要扮演着数据字典的角色：强制在不同数据孤岛之间统一语义结构，聚合数据集来揭示隐藏关系，或者做关系挖掘。比如，把大量生物制药学术论文里的信息塞进同一个图谱，以便理解不同论文中概念间的关系——论文1说X=Y，论文2说Y=Z，图谱就能帮你发现X=Z。这种跨文档的关系追踪，一般方法很难搞定。

现在，随着LLM的进步，知识图谱的定位应该调整为：增强语义焦点和提供结构基础，而不是单纯做数据聚合器。由此产生的小图谱不需要追求完整，因为LLM本身就自带了语义理解能力。换句话说，在很多情况下，我们根本没必要去创造一个对世界进行完美描述的版本。

常见误解＃B：知识图谱只对网络类型数据，如支付或社交媒体数据，有效

历史上知识图谱确实主要用在网络类型数据上，比如支付流转、社交关系链这类。这个历史渊源导致了一个惯性思维：知识图谱就是为网络数据而生的。

但真正让局面发生改变的是非结构化数据的爆发。就像向量数据库因为非结构化数据的向量搜索需求而大火一样，知识图谱也在非结构化数据存储和检索领域找到了全新的用武之地——这在以前并不常见。

除了网络数据，非结构化数据中大量存在的分层数据类型其实也非常适合用知识图谱来建模。本文后面会更详细地讨论这种分层数据类型，并给一个具体的例子：用分层知识图谱来表示苹果公司的季度财务报告。

上面这个由Neo4J制作的图谱，涵盖了图结构中可以代表的各种信息类型——当然不是全部，但足以反映图结构对非结构化数据可能适用的多种场景。

一个非常具体的实例是LinkedIn构建的客户服务系统。在这个系统里，知识图谱被用来表示客户支持工单的各种要素：优先级、状态、根本原因、描述、摘要等等。这是一种典型的分层表示，目的是帮助分类查询（比如“问题查询”），并精准检索工单的特定要素（比如“HAS_STEPS_TO_REPRODUCE”）。

这种分层的非网络数据结构，使得基于预定义模式进行非常精确的信息检索成为可能。同时大家也能看到，这里和误解A是重叠的：LinkedIn并没有把工单中所有可能的实体和关系都塞进图谱，他们只关心工单中那些特定的方面，把这些方面表示为边和节点就够了。

市面上还有很多其他GraphRAG系统的例子，比如这个关于患者数据的案例——它不做多跳检索，而是追求确定性和更完整的信息检索。

常见误解 #C：聚类 / 图分析和GraphRAG之间存在重叠

历史上构建知识图谱会用到一系列方法，其中就包括聚类。但在实际搭建KG RAG的过程中会发现，聚类和RAG的关系其实没那么紧密。原因在于：聚类更关注对底层数据的高层次理解，而RAG的核心是精准的信息检索——聚类提供的粒度水平，对精确检索来说远远不够。

聚类大致是指让模型对非结构化数据执行一系列分类，把它们归到模型微调好的若干类别里（比如“人员信息”“工作信息”“公司信息”）。这些类别构成了图谱架构的基础，底层信息再按这个框架填入图中。聚类只是图分析技术的一个子集。有人主张它和RAG相关，理由是它能帮助自动发现潜在可用的架构。

当你想对非结构化文本有一个高层次的理解，想了解不同主题之间如何相互关联时，聚类确实很有用。它的价值更多在于底层数据的性质分析。

但问题也很明显：RAG根本不需要对非结构化数据做高水平分析，它需要的是以粒度和准确性来呈现数据，以便提问时能拿到准确的结果。对数据做高水平分类，哪怕分类本身有用，也很难比简单的向量RAG搜索创造出更准确的检索过程。更何况，当前RAG的问题不是“检索缺失”，而是如何克服难题，实现更精确、更确定性的信息检索。

聚类或许可以提供一个大致的初始架构，但它能不能胜过直接让LLM根据基础数据给出架构，或者胜过其他架构生成技术，目前尚无定论。从为多个客户构建KG RAG的经验来看，一个面向业务需求和问题类型的图架构，往往在粒度层面上就表现不错——这种粒度在RAG中是常见的。

当然，这并非否定聚类和图分析的价值。在很多场景下，你可以先针对特定数据创建知识图谱来做RAG和精细检索，然后再做聚类分析，获得更高层的信息洞察。

常见误解＃D：KG-RAG 只对多跳查询和检索有用

类似图分析，知识图谱历史上常被用来理解不同数据孤岛之间的隐藏关系。这个发现过程可以通过多跳检索来完成——经过多个推理步骤，轻松地获取关联信息。

但一个核心误解是：知识图谱只对多跳检索有用。图结构本身有助于强化关系、表示层次信息，正如在误解B中讨论的那样。有时候这些关系确实体现为多跳检索，但在RAG的很多实际场景里，多跳检索并不是最紧迫的问题。

不少KG&RAG论文把“多跳查询”作为知识图谱与RAG特别相关的理由，这容易让人忽视结构化知识表达的核心价值。可以看到，很多论文会用各种方式刻意强调这个卖点，设置一些不太自然的提问方式和对比基准。

那些作为多跳查询示例的问题，很多其实并不真实反映人们通常的提问习惯。

在实际的KG&RAG系统中（比如前面LinkedIn的例子），核心诉求更偏向确定性检索和关联，而不是多跳推理。这类场景才是企业级RAG应用的典型面貌。

当然，多跳查询确实存在，多跳推理在某些系统中也扮演着重要角色。它应该被视为一种有价值的附加收益，而不是核心收益。如果把多跳的作用过分放大，反而会偏离知识图谱与RAG系统的真正价值。

KG&RAG系统的真正价值在于：可解释性、确定性和完整性。

• 可解释性/确定性：
  相关讨论可以参照“万字长文 GraphRAG技术栈及样例全面解析”这篇文章。

• 完整性：
  相关讨论可以参照“KG RAG vs. Vector RAG：基准测试、优化杠杆和财务分析示例”这篇文章。

常见误解＃E：处理成本降低和更长的上下文窗口减少了对KG RAG的需求，因为错误边际很大

KG RAG 不仅仅是为了减少与RAG无关的信息量。我们面临的最大问题，是如何把那些相关但在语义上并不相似的信息引入上下文窗口。

LinkedIn的例子再次说明问题：没有知识图谱，想把包含“HAS_STEPS_TO_REPRODUCE”这类信息关联到上下文窗口会非常困难，因为那些关键词本身并不会出现在答案中。知识图谱恰恰擅长在“实际重现问题的步骤”之间建立关系，并把它们与“HAS_STEPS_TO_REPRODUCE”这个关系联系起来。换句话说，知识图谱擅长引入相关但语义不相似的信息。

所以，知识图谱不应该被看作是一种降低RAG成本的手段，而应该被视为一种将向量搜索无法检索到的信息引入上下文的方法——它增加的，是答案的确定性、准确性和完整性。