知识图谱 RAG：沿关系找证据

知识图谱 RAG 是利用实体及其关系查找证据的一类检索增强生成方案。它把文档中的对象表示为节点，把对象之间的关系表示为边；查询时找到符合问题要求的节点和路径，再取回对应原文，交给模型生成回答。本篇重点讲其中的关系约束查询：让来自不同文档的记录通过共同实体连接，并筛出同时满足多个条件的证据。

例如，“北辰材料供应的哪批隔膜用在 S2 上，质量复核该联系谁？”包含供应、使用和职责三种关系。向量检索可以找到相关段落，还需要确认这些记录说的是同一批货、同一款产品。如果采购记录提到“供应商供应批次”，装配记录提到“批次用于产品”，两份记录就可以通过同一个批次节点连接。

查询时，候选批次必须同时满足“由北辰材料供应”和“用于 S2”。只提到 S2 的工单不会因此成为答案。这种关系约束适合证据分散在不同文档、需要连接多个事实的问题，也可以与文本检索结合使用。

完整过程分为建库和查询两部分：

建库：文档分块 → 抽取实体和关系 → 合并相同实体 → 保存图及原文映射
查询：识别问题中的实体和关系 → 查询相关路径 → 取回路径对应原文 → 生成回答

后面的 Microsoft GraphRAG 和 LightRAG 也使用实体关系图，分别侧重社区报告驱动的归纳、实体与关系的双层检索。它们的查询过程不必都转成这里展示的显式关系约束。

建库：从原文抽取节点和边

以星河制造资料库中的四段原文为例：

证据 ID	原文内容
C1	采购记录：北辰材料供应隔膜批次 B-771。
C2	装配记录：B-771 用于储能柜 S2 的本批生产。
C3	职责表：周宁负责 S2 产品的质量复核。
C4	工单：华东客户报告一台 S2 温升报警，原因待查。

从中可以抽取带来源的三元组：

(supplier:beichen, SUPPLIES, batch:B-771)       <- C1
(batch:B-771, USED_IN, product:S2)             <- C2
(person:zhou-ning, REVIEWS_QUALITY, product:S2) <- C3
(ticket:T-9, REPORTS_ON, product:S2)            <- C4

三元组依次表示主体、关系、客体。例如第一条对应供应商节点、SUPPLIES 边和批次节点。第二条复用 batch:B-771，于是原本分开的采购记录和装配记录连成了一条路径。

抽取可以由 LLM、规则或已有结构化数据完成。抽取结果存入图结构，原文保存在文档存储中，两者通过 C1 这样的来源 ID 关联。检索图只需要读取节点和边；生成答案时再按来源 ID 取回完整表述，避免把原文中的条件、时间和例外丢掉。

关系类型应围绕要回答的问题设计。这个例子只需要供应、使用、复核、报告对象；抽取器没必要把每个形容词都变成节点。为 SUPPLIES 约定“供应商指向批次”，还可以拒绝方向颠倒或类型不匹配的输出。

同一个对象必须落到同一个节点

假设另一份合同把供应商写成“北辰材料有限公司”。如果采购主数据明确给出相同供应商编号，就应映射到 supplier:beichen。仅仅名称相似还不够：“北辰材料”和“北辰新材”也可能是两家公司。

可以先用编号、员工号等权威键匹配，再用别名、地址、所属机构和上下文生成待确认候选。模糊匹配的作用是发现可能相同的对象，合并仍需要足够依据。同名人员也不能因为都叫“周宁”就共享一个节点。

错误合并会让两家公司的合同、批次和事件互相连通；错误拆分则会让本来连续的路径断开。显示名称用于阅读，稳定 ID 用于连接。涉及时间变化的关系还应保存来源版本和有效时间，例如旧职责表中的复核人不能一直作为当前答案。

查询：把问题转成关系约束

回到开头的问题。系统先把“北辰材料”“S2”匹配到图中的节点 ID，再识别要查的关系：找到该供应商提供且用于 S2 的批次，同时找到 S2 的质量复核人。实体定位可以结合精确编号、别名匹配或实体描述的向量检索；关系查询可以使用预定义模板，也可以由模型生成受约束的图查询。

这里需要匹配的图结构是：

北辰材料 --SUPPLIES--> 批次 --USED_IN--> S2
                                        ^
                                        |
                                  REVIEWS_QUALITY
                                        |
                                       人员

查询先沿 SUPPLIES 找到供应商提供的批次，再只保留拥有 USED_IN → S2 关系的批次，得到 B-771。随后从 S2 反向查找 REVIEWS_QUALITY 的人员节点，得到周宁。反向遍历只改变查找方向，边表达的含义仍然是“人员负责产品”。

这种匹配相当于在图上连接多份记录。它不要求三段原文都与整句问题有很高的向量相似度，但要求每段关系已经被正确抽取并连接到同一个实体。

从匹配路径取回原文并回答

路径找齐后，取回 C1、C2、C3，逐条核对实体、方向和当前有效期。答案才可以写成：“采购和装配记录显示，北辰材料供应的 B-771 用于 S2；职责表列出的质量复核人是周宁。”三项事实分别绑定对应引用。

不需要围绕 S2 遍历全部邻居。产品可能连着客户、仓库、销售团队和旧工单，继续扩展容易把无关资料带进来。查询应限定关系类型、展开跳数和候选数量；路径缺一段时，返回已知部分并指出缺少的记录，不能让生成模型补边。

需要补充文本检索时

向量检索可能找到 C4，图检索返回的却是一条由多条边组成的路径。两者的单位不同，不能把“路径第一名”和“文本块第一名”直接放进同一个 RRF 排名表。

一种易于核查的做法是先把图路径映射回统一的证据 ID：

图路径候选 -> [C1, C2, C3]，另存每个片段支持的边
向量候选   -> [C4, C2, C1]
共同单位   -> 证据片段 ID

先在每个通道内部按证据 ID 去重并形成排名，再融合、重排。同一个 C2 即使支持几条路径，也只是一份来源；它被多个通道命中不能算多份独立证据。最终打包上下文时仍需保留路径映射，避免截断某个片段后，模型继续引用一条已缺少支持的完整路径。

关系查询的边界

C4 只说明 S2 出现过温升报警。结合前三段资料，仍然不能断言“北辰材料导致报警”：工单没有确认故障设备使用 B-771，更没有给出因果调查结论。

同样，“周宁负责质量复核”只支持联系周宁。若用户问“谁有权决定召回”，必须检索召回制度或授权记录。图路径不能替代缺失的职责规定。

对于“疑似”“已否定”等陈述，要保留原文状态。可以把“调查报告怀疑 B-771 与报警有关”记为待核实 claim，并绑定报告来源；不能因抽取模型给出高置信度就把它改成已确认事实。模型对抽取结果的把握与业务事实是否成立，是两件需要分别核对的事。

来源变化也要反映到图中

如果 C1 和另一份记录都支持同一条供应关系，删除 C1 时应移除它的来源贡献，并用剩余来源重算关系描述；直接删除整条边会误伤仍有依据的事实。最后一个有效来源消失后，边及相关派生描述才应失效。

权限也要跟着来源走。某用户能看到供应商名称，不代表能看到由保密调查报告生成的实体摘要。检索边和返回描述时都只能使用用户可见的贡献；跨多个权限范围生成的摘要，需要按允许的来源重建或隔离，不能靠最后删掉引用来隐藏敏感内容。

若问题主要是查一个精确编号，关键词检索通常更直接；若合同和批次关系本来就在业务数据库中，可以直接查询权威记录。图增强检索更适合反复出现的跨文档关系问题，同时需要承担抽取、实体合并和来源更新的成本。

继续阅读

• Microsoft GraphRAG：社区报告与全局问答：如何在实体关系图上组织全局主题。
• LightRAG：实体与关系的双层检索：如何通过实体与关系索引找到不同范围的证据。
• Microsoft GraphRAG 索引数据流：具体实现中实体、关系、TextUnit 与来源映射的例子。本文采用通用的三元组表示和查询流程，不对应该项目的 API。