从一次失败的医疗问答说起
一位患者带着一份出院小结问系统：“这位患者正在服用的抗凝药，与他的肾功能指标之间有没有相互作用风险？”传统 RAG 的做法是：把出院小结切成若干文本块，向量化后按相似度检索出最相关的几段，再交给大模型生成答案。结果往往令人失望——检索到的段落可能分别提到“华法林”和“肌酐升高”，但两段之间没有显式关联，大模型只能靠内部知识猜测，甚至编造出“需要调整剂量”的结论，而真实风险可能恰恰相反。
这类问题属于多跳问答：答案需要沿着实体之间的因果关系、时序关系或属性关系跨多个片段推理。传统 RAG 的检索单元是文本块，块与块之间缺乏结构化连接，当问题要求“连接点”时，检索结果往往是碎片化的，推理链因此断裂。Graph RAG 的出发点正是把文本中的实体和关系显式抽取成图结构，让检索从“找相似文本”变成“沿图路径找证据”。
传统 RAG 的瓶颈：为什么向量检索在多跳问题上失效
向量检索的核心是语义相似度：把查询和文本块分别编码成向量，用余弦相似度或内积排序。它擅长回答“这段文本讲了什么”这类单跳问题，但在多跳场景下有三个系统性缺陷。
第一，关系理解缺失。向量空间里的相似并不等于逻辑关联。查询“华法林与肾功能”可能和一段讲“华法林代谢”的文本相似，但真正需要的“肾功能下降导致华法林蓄积”这一关系，可能分散在另一段描述药物动力学的文本里，两段文本在向量空间中的距离未必近。
第二，上下文碎片化。文本被切成固定大小的块，破坏了原文的连贯性。跨文档的实体共现、隐式引用、时间先后关系都无法在块级别显式建模。例如，“2019 年收购 A 公司的企业”和“该企业 2021 年的投资对象”分布在两篇新闻里，块检索很难把两者拼成一条推理链。
第三，检索噪声与幻觉风险。向量检索可能返回部分相关甚至不相关的块，这些噪声进入提示词后，会干扰大模型的判断，甚至诱导它生成与事实不符的内容。资料 1 指出，传统 RAG 在回答“数据集的主要主题是什么”这类全局性问题时表现很差，因为这类问题本质上是查询聚焦摘要，而不是显式检索任务。
这些缺陷的根源在于：文本块是线性序列，而知识是网状结构。Graph RAG 把知识组织成图，节点是实体，边是关系，从而让检索能够沿着显式路径遍历，而不是依赖向量空间的隐式相似。
Graph RAG 的核心机制：从文本到图再到答案
Graph RAG 的流程可以概括为三个阶段：图构建、图检索、增强生成。以医疗问答为例，输入是医学文献、病历、药品说明书等非结构化文本，输出是对患者问题的结构化推理答案。
图构建：用 LLM 抽取实体与关系
图构建的目标是从原始文本中提取实体、关系和属性，形成三元组（头实体，关系，尾实体）。例如，从“华法林通过抑制维生素 K 环氧化物还原酶来抗凝”这句话中，可以抽取（华法林，抑制，维生素K环氧化物还原酶）和（维生素K环氧化物还原酶，参与，凝血因子合成）。
工程上通常用 LLM 或信息抽取管线完成这一步。资料 3 提到，知识抽取包括指代消解、别名归一和术语标准化。例如“华法林”和“Warfarin”需要统一为同一节点；“肌酐”和“Cr”也要归一。实体对齐与去重（Entity Resolution）是保证图质量的关键，否则同一个实体可能被建成多个节点，导致后续检索路径断裂。
图构建的质量直接影响下游检索。资料 4 的 GraphRAG-Bench 评估显示，知识图谱构建的组织度（非孤立节点比例）通常保持在约 90%，而段落图（用实体链接工具建图）的非孤立节点比例最低，因为实体链接工具未能有效建立大多数实体对之间的边。这说明，用 LLM 抽取实体和关系比传统 NLP 工具更能保证图的连通性。
图构建的成本不可忽视。资料 4 指出，知识图谱的 token 消耗适中，因为它需要 LLM 进行实体提取和三元组生成，但三元组获取后图构建速度很快；而丰富知识图谱（额外为实体和关系生成描述）token 消耗最多，时间成本也更高。在医疗场景，如果语料规模达到百万 token 量级，图构建的 token 成本可能成为主要开销。
图检索：从实体定位到路径遍历
当用户提出查询时，Graph RAG 不再做向量相似度检索，而是先在图中定位核心实体，再沿着关系路径扩展。具体步骤包括：
-
实体链接：把查询中的词映射到图中的节点。例如，“患者正在服用的抗凝药”需要链接到具体的药物节点，如“华法林”。实体链接可以用向量检索辅助，也可以直接用规则匹配。
-
子图探索：从命中节点出发，使用图查询语言（如 Cypher）或遍历算法进行邻域扩展、路径发现和约束过滤。例如，查询“华法林与肾功能的关系”可以写成 Cypher：
MATCH (d:Drug {name: '华法林'})-[r:INTERACTS_WITH]->(c:Condition {name: '肾功能不全'})
RETURN d.name, r.description, c.name- 结构化证据抽取：把路径上的节点和关系序列化为可读文本，或生成子图摘要，作为提示词的上下文。
资料 3 区分了三种图检索策略：知识驱动型（直接在图查询，如 Text-to-Cypher）、索引驱动型（把图结构信息拼接到文本索引中）、混合型（同时使用图检索和文本检索）。在医疗问答中，混合型更常见：先用图定位关键实体和路径，再补充相关文本片段，兼顾事实性和细节。
增强生成：把图证据注入提示词
最后一步是把检索到的结构化知识（实体属性、关系路径、子图摘要）与原始查询一起注入 LLM 提示词。资料 3 强调，提示设计应明确要求模型引用“图证据”，并在回答中给出来源与路径。例如，可以要求模型输出“根据路径：华法林→抑制→维生素K环氧化物还原酶→影响→凝血因子，肾功能不全可能影响华法林代谢”。
这种设计有两个好处：一是让模型基于显式证据推理，减少幻觉；二是答案可追溯，提高了可解释性。资料 1 的 GraphRAG 方法更进一步，它用 LLM 构建实体知识图谱后，用社区检测（如 Leiden 算法）对紧密相关的实体分组，预生成社区摘要。查询时，每个社区摘要生成部分响应，再汇总成最终答案。这种方法特别适合全局性问题，如“这个数据集的主要主题是什么”。
向量检索与 Text-to-Cypher：两种图检索路径的对比
图检索有两种典型实现：一种是把自然语言查询转换成图查询语言（Text-to-Cypher），直接在图数据库中执行；另一种是仍然用向量检索定位实体，再在图上扩展。两者在医疗问答中的表现差异明显。
Text-to-Cypher 的优点是精确和可解释。它把“华法林与肾功能不全的相互作用”转换成 Cypher 查询，直接返回路径上的事实，不依赖向量相似度。缺点是需要 LLM 准确生成 Cypher 语法，一旦生成错误，查询就会失败。资料 4 显示，依赖 LLM 进行检索的方法（如 KGP、ToG、DALK）在平均检索时间上显著增加，因为每次查询都要调用 LLM 生成查询语句。
向量检索辅助实体定位则更鲁棒。它先用向量相似度找到最相关的实体节点，再在图上做邻域扩展。这种方式不需要生成精确的查询语句，但可能引入实体链接错误。例如，“华法林”可能被链接到“华法林钠”或“Warfarin”的不同节点，导致路径断裂。
下表从多个维度对比了两种方法在医疗问答场景中的适用性：
| 维度 | 向量检索辅助图遍历 | Text-to-Cypher |
|---|---|---|
| 查询理解 | 依赖向量相似度，对同义改写较鲁棒 | 依赖 LLM 生成 Cypher，对语法要求高 |
| 检索精度 | 中等，实体链接可能出错 | 高，直接执行结构化查询 |
| 可解释性 | 路径可追溯，但实体链接过程不透明 | 查询语句本身可审查 |
| 延迟 | 较低，向量检索快，图遍历可控 | 较高，LLM 生成查询耗时 |
| 实现复杂度 | 需要实体链接和向量索引 | 需要图数据库和查询生成模型 |
| 失败模式 | 实体链接错误导致路径断裂 | Cypher 生成错误导致查询失败 |
| 适用场景 | 实体名称模糊、同义词多的领域 | 实体名称规范、关系类型明确的领域 |
在医疗领域，药品和疾病名称往往有大量别名和缩写，向量检索辅助实体链接更能容忍这种模糊性；但如果知识图谱的关系类型设计得很规范（如“药物-相互作用-疾病”），Text-to-Cypher 可以提供更精确的路径。工程上通常采用混合策略：先用向量检索定位候选实体，再用图查询做精确过滤。
贯穿场景：医疗问答中的多跳推理路径
为了具体说明 Graph RAG 的工作方式，我们设计一个贯穿全文的医疗问答场景。假设知识图谱由 1000 份医学文献和病历构建而成，包含实体类型：药物、疾病、症状、检查指标、基因；关系类型：治疗、引起、相互作用、影响、禁忌。
患者问题：“一名 65 岁男性患者，因房颤服用华法林，近期检查发现肌酐清除率降至 30ml/min，华法林剂量应如何调整？”
这个问题的推理链需要跨越多个实体：
- 华法林 → 经肾脏代谢（关系：代谢途径）
- 肌酐清除率降低 → 肾功能不全（关系：指示）
- 肾功能不全 → 影响华法林清除（关系：影响）
- 华法林清除降低 → 出血风险增加（关系：导致）
- 出血风险增加 → 需要调整剂量（关系：建议）
传统 RAG 可能只检索到“华法林”和“肌酐”的孤立文本块，无法形成这条链。Graph RAG 则通过图遍历，从“华法林”节点出发，沿着“代谢途径”边找到“肾脏”，再通过“肾功能不全”节点连接到“肌酐清除率”，最终形成完整的推理路径。
下图展示了这一查询的图检索流程：
flowchart TD
A[用户问题] --> B[实体链接: 华法林, 肌酐清除率]
B --> C[定位起始节点: 华法林, 肾功能指标]
C --> D[图遍历: 邻域扩展, 关系过滤]
D --> E[发现路径: 华法林-代谢-肾脏-影响-出血风险]
E --> F[结构化证据: 路径序列化为文本]
F --> G[LLM 生成答案: 引用图证据]
G --> H[输出: 剂量调整建议]
在这个流程中，实体链接是关键转折点。如果“肌酐清除率”没有被正确链接到“肾功能”节点，图遍历就会从错误节点出发，导致路径断裂。工程上，实体链接通常结合规则（如医学词典）和向量检索，以提高准确率。
图遍历的深度也需要控制。跳数过多会引入无关实体，增加噪声；跳数过少可能遗漏关键路径。在医疗场景，一般限制在 2～3 跳，因为药物相互作用路径通常不超过这个范围。
工程权衡：索引更新、查询延迟与领域迁移
Graph RAG 的工程实现面临三个主要权衡：索引更新成本、查询延迟和领域迁移难度。
索引更新：图构建是重活
知识图谱的构建不是一次性的。医学知识不断更新，新药上市、新研究发表，都需要更新图谱。但图构建需要调用 LLM 抽取实体和关系，成本高且耗时。资料 4 显示，知识图谱构建的时间成本在各类方法中属于中等，但 token 消耗仍然可观。
增量更新是常见的工程方案：只对新增文档做实体抽取，然后通过实体对齐合并到现有图中。但实体对齐本身可能出错，新实体与旧实体之间的边需要验证。在医疗领域，如果新药与旧药有相互作用，而抽取时没有建立边，就会导致查询遗漏。
查询延迟：图遍历与 LLM 调用的平衡
查询延迟主要来自三部分：实体链接、图遍历、LLM 生成。实体链接如果依赖向量检索，延迟较低；如果依赖 LLM 做实体识别，延迟会显著增加。图遍历在节点和边数量大时可能变慢，尤其是多跳查询。
资料 4 的评估显示，GraphRAG 因需要利用社区信息检索，耗时较长；而依赖 LLM 进行检索的方法延迟更高。在医疗问答中，如果患者等待答案，延迟超过几秒就不可接受。工程上，可以通过预计算社区摘要、缓存热门路径、限制遍历深度来降低延迟。
领域迁移：图谱构建的复用性
Graph RAG 的另一个问题是领域迁移。一个在医疗领域构建的图谱，无法直接用于法律问答，因为实体类型和关系类型完全不同。每次迁移到新领域，都需要重新构建图谱，成本高昂。
相比之下，传统 RAG 的向量索引可以跨领域复用（只要重新切块和向量化），但 Graph RAG 需要重新设计本体（Schema）和关系类型。资料 3 提到，通过模式（Schema）和本体（Ontology）可以约束推理空间，但这也意味着领域专家需要参与图谱设计。
失败模式与可观测性
Graph RAG 并非万能，它在以下场景中可能失效：
- 图构建不完整：如果实体抽取遗漏了关键关系，图检索就无法找到路径。资料 4 显示，段落图的非孤立节点比例最低，说明实体链接工具可能无法建立足够的边。
- 实体链接错误：查询中的实体被错误链接到图中其他节点，导致路径从错误起点出发。例如，“华法林”可能被链接到“华法林钠”节点，而该节点没有“代谢”关系。
- 检索噪声：图遍历返回的路径可能包含不相关实体，尤其是当关系类型定义过宽时。资料 4 指出，GraphRAG 在单项选择问题上准确率下降，因为检索到的冗余信息干扰了模型决策。
- 数学推理失败：资料 4 发现，所有 GraphRAG 方法在数学题上的生成准确率都下降，因为数学问题依赖符号操作，而图检索提供的概念性文档无法匹配符号表示。
在生产环境中，需要监控以下信号：
- 实体链接成功率：如果查询中实体无法链接到图节点，说明图谱覆盖不足。
- 图遍历返回的路径长度分布：如果大量查询只返回单跳路径，可能说明图构建过于稀疏。
- 答案中的引用路径是否有效：可以检查生成答案中引用的节点和边是否真实存在于图谱中。
- 查询延迟的 P95：如果延迟过高，可能需要优化图遍历或缓存。
替代方案与适用边界
与 Graph RAG 竞争的方案包括：传统 RAG（向量检索）、Text-to-SQL（把查询转成 SQL 查关系数据库）、以及基于 LLM 的直接推理（不检索）。
传统 RAG 在单跳问答中已经足够，且实现简单、更新成本低。但在多跳问题上，它无法提供结构化路径，容易产生幻觉。Text-to-SQL 适用于结构化数据，但无法处理非结构化文本。LLM 直接推理依赖内部知识，在私有数据上会失效。
Graph RAG 的适用边界是：语料库规模适中（百万 token 量级）、需要多跳推理和事实一致性、且实体关系相对明确的领域，如医疗、金融、法律。如果语料库过小或问题过于简单，图构建的成本可能超过收益；如果实体关系极其复杂且不断变化，图谱维护会成为负担。
资料 1 的 GraphRAG 在百万 token 量级的数据集上，对全局性问题（如“主要主题是什么”）相比传统 RAG 在全面性和多样性上有显著提升。但资料 4 也提醒，并非所有 GraphRAG 方法都能提升性能，有些方法（如 DALK、G-Retriever）反而降低了 LLM 的准确率，因为它们过度依赖结构信息而牺牲了语义内容。
因此，在实际选型时，需要根据问题类型、语料规模、延迟要求和成本预算，决定是否采用 Graph RAG，以及采用哪种图构建和检索策略。