知识图谱如何扩展LLM上下文：从向量检索到关系推理

引言：一个被反复提及却少有人讲清的问题

在RAG（检索增强生成）系统日益普及的今天，"知识图谱能增强LLM的上下文能力"几乎成了技术圈的共识。然而当有人直接抛出这样一个问题——"图谱究竟是如何真正增加LLM可用的上下文信息的？"——你会发现，能把这件事讲透彻的人其实并不多。

很多人对GraphRAG的理解停留在"用图谱做检索比向量检索更高级"这一模糊印象上。但图谱到底在信息层面上带来了什么向量检索无法提供的东西？本文将从技术机制出发，系统拆解这个问题。

传统向量检索的核心局限

要理解图谱的价值，首先得看清普通向量RAG的短板。

向量检索的本质：相似度匹配

标准的RAG流程是：把文档切成块（chunks），用嵌入模型转成向量，检索时把用户问题也转成向量，找出语义最相近的若干片段塞进上下文。这套方法在单点事实查询上表现不错，但它有一个根本性缺陷——只能找到与查询语义相似的孤立片段，无法理解片段之间的关系。

这里有必要展开说说嵌入模型（Embedding Model）的工作机制。嵌入模型的核心任务是将任意长度的文本映射到一个固定维度的稠密向量空间中——通常是768维或1536维。在这个空间里，语义相近的文本会被映射到相邻的位置，语义无关的文本则彼此远离。检索时，系统通过计算查询向量与所有文档块向量之间的余弦相似度（cosine similarity）或内积（dot product），返回得分最高的Top-K个片段。这套机制的数学本质是在高维空间中做最近邻搜索（Approximate Nearest Neighbor, ANN），常见的加速算法包括HNSW（Hierarchical Navigable Small World）和IVF（Inverted File Index）。然而，无论算法多高效，它度量的始终是"两段文本说的事情像不像"，而非"两段文本描述的事物之间有什么关联"。此外，chunk的切分策略——固定长度切分、按段落切分、还是带重叠窗口的滑动切分——会直接影响检索质量。切得太细会丢失上下文，切得太粗会引入噪声，但无论怎么切，跨chunk的关系信息都不可避免地被割裂了。

举个例子：如果你问"A公司的CEO和B公司有什么关联？"，而这两条信息分散在不同文档的不同段落里，向量检索很可能只召回了关于A公司CEO的片段，却错过了那条隐藏在别处、说明其曾任职于B公司的关键信息。因为这两段文字在语义空间里并不一定相近。

多跳推理：向量检索的软肋

这类需要跨越多个信息节点、层层递进的问题，被称为多跳查询（multi-hop query）。向量检索天然不擅长处理这类场景，因为它只有"相似"的概念，缺少"关系"这个维度。

多跳推理在NLP领域是一个被长期研究的难题。2018年，杨志林等人发布的HotpotQA数据集首次系统化地定义了这一挑战：该数据集中的每个问题都需要从至少两篇维基百科文章中提取和组合信息才能回答。例如，"《指环王》的导演出生在哪个国家？"就是一个典型的两跳问题——第一跳找到导演是彼得·杰克逊，第二跳才能定位到新西兰。在工业场景中，多跳推理的复杂度往往更高：企业合规审查中"某供应商的母公司的关联方是否在制裁名单上"可能涉及3-5跳的关系链。向量检索在面对这类问题时的根本困难在于：查询文本与最终答案所在的文本段之间可能完全没有语义重叠。你搜索的是"导演的出生国"，但包含答案的段落讲的是"彼得·杰克逊出生于惠灵顿"——如果系统不知道彼得·杰克逊就是那位导演，这个片段根本不会被召回。

知识图谱增加的核心信息维度

这正是知识图谱介入的关键点。它带来的核心增量可以概括为：图谱把信息之间的隐式关系转化为可检索、可遍历的结构化数据。

从孤立节点到关系网络

知识图谱以"实体-关系-实体"（即三元组，如 张三 —任职于→ B公司）的形式存储信息。当LLM需要回答问题时，系统不再只是找相似片段，而是可以：

定位起始实体——先找到问题中提到的核心实体节点
沿关系边遍历——顺着图上的连接找到相关联的其他实体
组装关系子图——把这些相互关联的节点和关系一起作为上下文提供给LLM

知识图谱的概念有着深厚的学术渊源。其理论基础可以追溯到语义网（Semantic Web）和RDF（Resource Description Framework）——万维网之父蒂姆·伯纳斯-李在2001年提出的构想。在形式化定义中，知识图谱本质上是一个有向标记图 $G = (V, E, L)$，其中 $V$ 是实体节点集合，$E$ 是关系边集合，$L$ 是标签函数。每条边都可以表示为一个三元组 $(h, r, t)$，即"头实体-关系-尾实体"。2012年，谷歌正式推出Knowledge Graph产品，将这一概念从学术界带入了工业界的视野。在GraphRAG场景中，图遍历是核心操作。最常用的遍历策略包括BFS（广度优先搜索）和DFS（深度优先搜索）：BFS从起始实体出发逐层向外扩展，适合获取固定跳数内的所有关联实体；DFS则沿着单条路径深入探索，适合追踪特定的关系链条。实际系统中通常会设置遍历深度上限（如2-3跳），以平衡上下文的丰富度和噪声控制。

这意味着，原本在文本中"物理上分离、语义上不相似"的信息，在图谱里通过明确的边被连接了起来。LLM获得的不再是零散的片段，而是带有结构和关系的完整上下文。

关键洞察：增加的是关系维度信息

回到最初的问题：图谱增加的上下文信息，本质上不是"更多的文字"，而是"文字之间原本隐含、如今被显式化的关系"。这些关系信息在纯文本切块中是丢失的，而图谱把它们重新捕获并结构化了。

GraphRAG的实际工作流程

结合主流实现方式，一个典型的GraphRAG系统大致这样运作：

构建阶段

用LLM从原始文档中抽取实体和关系，构建知识图谱
对图谱中的节点做社区聚类（community detection），生成不同粒度的摘要
同时保留向量索引，形成"图+向量"的混合结构

在构建阶段，社区检测算法的选择至关重要。微软在其开源的GraphRAG项目中采用了Leiden算法——这是对经典Louvain算法的改进版本，由荷兰莱顿大学的研究团队于2019年提出。Leiden算法通过"局部移动-细化-聚合"的三阶段迭代过程，将图谱中紧密连接的节点划分为不同的社区（community）。相比Louvain算法，Leiden保证了每个社区内部的连通性，避免了"断裂社区"的问题。在GraphRAG的实现中，社区检测是分层级进行的：第一层可能产生几十个大社区，每个社区对应一个宏观主题；往下细分则产生更小粒度的子社区，对应更具体的话题。系统会用LLM为每个社区自动生成摘要描述，这些摘要后续在全局查询中发挥核心作用。微软在2024年发布的论文中报告，这一构建过程的token消耗大约是原始文档量的数倍——对于一个百万token规模的文档集，构建图谱和社区摘要可能需要消耗数百万token的LLM调用。

检索阶段

局部查询（Local Search）：从问题相关实体出发，遍历邻近节点，获取局部关系上下文
全局查询（Global Search）：利用预先生成的社区摘要，回答需要宏观视角的问题（如"整个文档集的主要主题是什么？"）——这恰恰是纯向量检索几乎无法胜任的场景

局部查询和全局查询在技术实现上有着本质区别。局部查询的流程是：先通过实体名匹配或嵌入相似度定位到图谱中的起始节点，然后执行k跳图遍历（通常k=1或2），收集路径上的所有实体、关系和关联的原始文本块，最后将这些信息按相关性排序后裁剪到LLM上下文窗口的限制内，一并送入模型。全局查询则完全不同——它不从特定实体出发，而是采用Map-Reduce的策略：先将问题分发到所有社区摘要上，让LLM逐一判断每个社区与问题的相关性并生成局部回答（Map阶段），再将这些局部回答汇总，由LLM综合生成最终答案（Reduce阶段）。这种设计使得全局查询能够"鸟瞰"整个知识库的内容，回答诸如"这批研究报告反映了哪些共同趋势"这样的归纳性问题。在实际部署中，许多团队还会采用混合检索架构——先用向量检索快速缩小候选范围，再用图遍历补充关系上下文，两路结果融合后送入LLM。这种"向量初筛 + 图谱增强"的模式在工程实践中被证明是性价比较高的折中方案。

这种"局部关系遍历 + 全局摘要"的组合，让LLM既能处理精细的多跳推理，又能应对需要整体归纳的问题。

理性看待：图谱不是万能方案

说个细节，图谱方案并非没有代价：

构建成本高：用LLM抽取实体关系、构建和维护图谱，token消耗和工程复杂度都远高于简单向量RAG
抽取质量决定上限：如果实体关系抽取出错，图谱本身就是有噪声的，反而可能误导模型
并非所有场景都需要：对于简单的事实问答，向量检索已经足够，上图谱是过度设计

关于构建成本，一些公开的实践数据可以提供参考。据多个团队报告，使用GPT-4级别的模型进行实体关系抽取时，处理1万个文档块大约需要消耗200-500万token，仅API费用就可能达到数十美元，而这还不包括社区摘要生成和后续维护的成本。对于持续更新的知识库，增量图谱构建（即只处理新增或变更的文档）是工程上的一大挑战——新加入的实体可能需要与图谱中已有的实体进行消歧和合并（entity resolution），这一步骤目前仍高度依赖人工审核或额外的LLM调用。

在抽取质量方面，常见的错误模式包括三类：一是实体漏提（false negative），重要实体未被识别出来导致图谱不完整；二是关系误提（false positive），LLM"幻觉"出了文本中并不存在的关系；三是实体指代不一致（coreference failure），同一实体在不同上下文中被识别为不同节点（如"特斯拉""Tesla""马斯克的公司"被当作三个实体）。这些错误会在图遍历过程中被放大——一条错误的边可能将完全无关的信息引入上下文，导致LLM生成错误答案。

在场景选型上，一个实用的决策框架是：如果你的典型查询可以通过检索1-2个文本块直接回答，向量RAG就够了；如果查询经常涉及"A和B有什么关系""C通过什么路径影响了D"这类关系推理问题，或者需要对大规模文档集进行主题归纳，那么引入图谱的投入才是值得的。金融风控、医药研发、法律合规、情报分析等"关系密集型"领域是GraphRAG的典型高价值场景。

因此更务实的观点是：图谱适用于关系密集、需要多跳推理或全局归纳的领域（如企业知识管理、科研文献、合规审计等），而非默认的最优选择。

结语

图谱增加LLM上下文的方式，不在于提供"更多的信息"，而在于提供"更好组织的信息"——它把散落在文本中的隐性关系显式化、结构化，让LLM能够沿着关系网络进行推理，从而突破向量检索"只见相似、不见关联"的天花板。

理解这一点，才算真正抓住了GraphRAG的本质。