知识图谱回归：为什么 RAG 团队正在为检索添加结构化数据

你的 RAG 管道在回答单一事实问题时表现出色。问它"我们的退款政策是什么？"它每次都能准确回答。但如果问"哪些企业版客户在合同续签后 30 天内提交了关于计费 API 的工单？"它就无能为力了。答案确实存在于你的数据中——分散在三种不同的文档类型中，通过余弦相似度无法捕捉的关系连接在一起。

这就是多跳推理问题，也是越来越多的生产级 RAG 团队在向量检索管道上嫁接知识图谱的原因。不是因为图谱又流行了，而是因为他们遇到了一个具体的准确率天花板——无论怎么调整分块大小或重新排序都无法突破。

多跳瓶颈

向量搜索通过将文本嵌入高维空间并找到与查询最近的分块来工作。对于单跳问题——"功能 X 是做什么的？"——这非常有效。相关分块位于嵌入空间的可预测邻域中。

多跳问题打破了这个模型。考虑这样一个问题："影响了发现 DNA 双螺旋结构的人的导师的科学工作是什么？"回答这个问题需要三个独立的检索步骤：

1. Watson 和 Crick 发现了双螺旋结构
2. 他们的导师是 Lawrence Bragg
3. Bragg 受到了 X 射线晶体学工作的影响

每个事实存在于不同的分块中，且没有一个与原始问题在语义上相似。向量搜索检索与查询嵌入最接近的分块，但桥接事实——连接人物、导师和影响的那些——在余弦相似度上得分很低，因为它们与问题没有表面词汇的共享。

微软的研究量化了这个差距：基线 RAG 在多跳问题上仅能覆盖 22-32% 的综合答案。相比之下，GraphRAG 达到了 72-83%——3 倍的提升来自于保留了向量丢弃的关系结构。

图增强检索的实际工作原理

这个架构比大多数团队预期的要简单。你不是在替换向量数据库——而是在添加一个层来捕获嵌入遗漏的实体关系。

图构建从实体提取开始。LLM（或更轻量的 NLP 管道）读取你的文档并提取实体及其关系：(Watson) --[MENTORED_BY]--> (Bragg)、(Bragg) --[INFLUENCED_BY]--> (X-ray Crystallography)。这些三元组形成一个与向量索引并存的知识图谱。

在查询时，系统运行双重检索路径：

• 向量路径：标准语义搜索，查找与查询相关的分块
• 图路径：对查询进行实体识别，然后通过图遍历找到连接的实体及其关联文本

结果在发送给 LLM 生成之前进行合并。向量路径处理直接的事实检索。图路径处理关系推理——沿着实体之间的边来组装多跳证据链。

最近在 Babilong 数据集上的基准测试表明，使用个性化 PageRank 的 graph-RAG 在多跳问题上显著优于 GPT-4o 的 128k 上下文窗口。优势来自过滤：RAG 仅检索相关子图，而长上下文模型则受到无关噪声的干扰。

三种无需本体学博士学位的构建模式

知识图谱最大的反对意见一直是构建成本。传统的知识图谱项目需要数月的 schema 设计、领域专家访谈和人工审核。LLM 已将这个时间线从数月压缩到数小时——但你仍然需要根据用例选择合适的构建模式。

**模式一：LLM 驱动提取。**将文档输入 LLM，提示词类似"从该文本中提取所有实体和关系，格式为（主语，谓语，宾语）三元组。"GPT-4 或 Claude 在实体关系提取上达到约 65.8% 的准确率。这是质量最高的选项，但也是最昂贵的——你需要对语料库中的每个文档进行 LLM 调用。

**模式二：依存句法分析。**使用传统 NLP（spaCy、Stanford NLP）通过命名实体识别提取实体，通过依存句法分析提取关系。最新研究表明，这种方法达到了 LLM 方法 94% 的质量（61.9% vs 65.8%），成本仅为其一小部分。对于大多数生产用例，这是最佳平衡点——足够好的准确率加上可预测的低单文档成本。

**模式三：LazyGraphRAG。**微软的方法完全跳过了前期图构建。LazyGraphRAG 不是预先构建完整的知识图谱，而是使用轻量级 NLP 提取名词共现，并在查询时动态构建图结构。索引成本降至完整 GraphRAG 的 0.1%，同时保持可比的答案质量。权衡是：查询延迟增加，因为构建发生在检索时，使其最适合探索性或一次性查询，而非高吞吐量的生产服务。

何时 Schema 开销不值得

知识图谱并非普遍优于纯向量 RAG。开销——构建成本、存储、维护、查询复杂度——只在特定场景下才值得。

在以下情况添加图：

• 你的问题经常需要连接 2 个以上文档中的事实
• 你的领域有很强的实体关系（人物 → 组织 → 项目 → 成果）
• 复杂查询的准确率直接影响业务成果（法律研究、合规、医疗决策支持）
• 你的语料库相对稳定，不需要频繁重新索引

在以下情况坚持纯向量：

• 大多数查询是单跳事实查找
• 你的语料库变化频繁，重新提取成本过高
• 延迟要求严格（低于 200ms），无法承受图遍历开销
• 你的文档缺乏清晰的实体关系结构（创意写作、观点文章、聊天记录）

混合方法——将简单查询路由到向量搜索，将复杂查询路由到图检索——正在成为标准模式。轻量级查询分类器判断一个问题是否需要多跳推理，并据此路由。这让你在不需要图结构的 80% 查询上获得向量搜索的速度，在需要图结构的 20% 查询上获得图检索的准确率。

生产现实：成本、延迟和维护

在生产中采用 GraphRAG 的团队面临三个基准测试未能捕捉到的反复出现的挑战。

**索引成本随语料库规模增长。**完整的 GraphRAG 索引比向量索引贵 100-1000 倍，因为每个文档都需要实体提取。对于 1000 万文档的语料库，这意味着几百美元和数万美元之间的差距。KET-RAG 和 LazyGraphRAG 通过多粒度索引和延迟构建来解决这个问题，但你需要提前规划这笔成本。

**图维护是新的运维负担。**当文档更新时，相应的图节点和边也需要更新。不像向量索引那样只需重新嵌入更改的文档，图更新可能会级联——更改一个实体可能会使数十个连接节点之间的关系失效。不自动化此维护的团队最终会得到过时的图，悄然降低答案质量。

**查询复杂度增加。**你的检索管道从"嵌入查询，找到最近邻，完成"变成"嵌入查询，提取实体，遍历图，合并结果，去重，重新排序。"每一步都增加延迟和潜在的故障模式。生产系统需要回退逻辑：如果图遍历超时或返回空结果，回退到纯向量结果，而不是返回空。

在生产中成功使用 GraphRAG 的团队有一个共同特征：他们从纯向量管道中一个具体的、可衡量的失败模式开始，构建图来解决那个特定的失败，并且只在初始用例证明了 ROI 之后才扩展图的范围。那些试图预先构建全面知识图谱——覆盖语料库中每个实体和关系——的团队，无一例外地在 schema 设计决策和提取质量问题的重压下陷入停滞。

未来方向

趋势很清晰：混合检索将成为默认架构，向量搜索处理广度，图结构处理深度。构建成本问题正从多个方向被解决——LazyGraphRAG 的延迟构建、避免 LLM 成本的依存分析方法，以及 KET-RAG 的多粒度索引，为不同文档类型构建不同级别的图细节。

更有趣的发展是与智能体 RAG 的融合。当智能体能够将复杂问题分解为子查询，将每个子查询路由到适当的检索方法，并组装结果时——那就是图增强检索从"基准测试上的准确率提升"转变为"质的新能力"的时刻。一个理解自己需要为一个子查询遍历图、为另一个子查询做向量搜索的智能体，可以回答任何单一方法都无法独立处理的问题。

对于今天正在评估这项技术的团队：从你最难的查询开始。找到你当前 RAG 管道回答错误的问题，按失败模式分类，检查多跳推理是否是瓶颈。如果是，一个轻量级的图覆盖层——即使只是实体共现提取——很可能会在可管理的工程投入下给你带来可衡量的准确率提升。如果你的失败是关于分块质量、上下文窗口或提示工程的，知识图谱无法帮助你，你应该去别处寻找解决方案。