Paper 14: GraphRAG and Knowledge Graph RAG

Source Anchors

核心导读

GraphRAG 的原理是把文本切片、实体、关系、claim 和 community summary 组织成图谱，再把图谱检索与文本检索结合。普通 RAG 主要依赖相似片段，GraphRAG 则让系统可以沿实体邻居、关系路径和社区结构构造上下文，回答多跳关系和全局模式问题。

它的价值出现在关系密集、证据分散、需要解释路径的场景中。AML 网络、商户风险、KYC beneficial ownership、投诉根因和供应链风险，往往不是某一段文本能回答，而是需要连接客户、账户、设备、商户、政策、事件和历史 case。GraphRAG 能把“找相似资料”升级为“解释结构关系和群体模式”。

边界同样重要。GraphRAG 不是默认更高级的 RAG；它会引入抽取、实体消歧、关系证据、图谱版本、社区摘要、路径权限和评测成本。LLM-derived relationship 只能是候选关系，不应直接成为客户影响决策依据。引入 GraphRAG 前，应先证明 baseline RAG 为什么不够，再设计 ontology、provenance、path-level permission、graph eval 和人工复核边界。

---

1. 核心问题：top-k 文本片段看不见关系结构

Baseline RAG 的典型工作方式是：

question -> retrieve similar chunks -> pack context -> generate answer

这对许多政策问答、流程解释、FAQ 和单文档事实查找足够有效。 例如：

• “某贷款产品提前还款费用是多少？”

• “企业开户需要哪些 KYC 文件？”

• “客服是否可以承诺免除年费？”

• “促销活动在哪些门店适用？” 这些问题的答案通常存在于一段或少数几段文本中。 GraphRAG 要解决的是另一类问题。 答案分散在多个文档、实体和事件之间。 问题关心的不是某个句子是否相似，而是实体之间如何关联、关系路径如何形成、某个群体是否呈现共同模式。 金融零售中典型问题包括：

• 某商户是否处于异常退款网络中？

• 多个投诉是否指向同一营销话术或产品条款缺陷？

• 某企业客户的受益所有人、关联公司和高风险实体如何连接？

• 一批 AML case 中有哪些跨地区反复出现的 typology？

• 某供应商风险是否通过门店、SKU 和物流事件扩散？ 这些问题不是普通相似文本检索的强项。 它们需要把证据组织成图。

---

2. 技术贡献：从文本检索到图谱检索

2.1 Baseline RAG 的能力边界

Baseline RAG 对单点事实很有效。 它的问题在于 top-k chunk 通常是局部的。 当答案需要多跳关系时，正确证据可能分散在多个文档中。 检索系统可能召回其中一些片段，但没有显式表示它们之间的关系。 模型需要在上下文窗口里临时拼接关系，这容易漏掉路径、混淆实体或过度推断。

2.2 GraphRAG 的核心思路

GraphRAG 通常先从语料中抽取：

• TextUnit。
• Entity。
• Relationship。
• Claim。
• Community。
• Community summary。 然后把这些结构与文本索引结合。 回答问题时，系统不只找相似文本，还可以围绕实体邻居、关系路径和社区摘要构造上下文。 它把“检索相关段落”扩展成“检索相关结构”。

2.3 Knowledge Graph + RAG 的更宽范畴

GraphRAG 常指从非结构化文本中用 LLM 派生知识图谱。 Knowledge Graph + RAG 更宽。 它可以使用企业已有主数据、交易网络、产品目录、客户关系、规则库、本体和文档抽取结果。 金融机构通常不应只依赖 LLM 从文本中抽图。 更可靠的做法是混合：

• 客户、账户、商户、产品来自主数据。
• 交易关系来自交易系统。
• ownership 关系来自 KYC / UBO 系统。
• 政策关系来自文档和规则库。
• 非结构化 claim 来自 LLM 抽取，但必须保留来源和置信度。

2.4 Community detection 和 global summary

图谱中的社区是关系密集的节点群。 社区发现算法可以把大图划分成更有结构的群组。 GraphRAG 使用社区摘要帮助回答 corpus-level 问题。 例如：

• “过去半年投诉中最常见的销售误导模式是什么？”
• “这批 AML case 中有哪些共同 typology？”
• “这个商户风险网络的共同特征是什么？” 这类问题很难靠 top-k chunk 完成，因为它需要全局归纳。

---

3. 机制原理：GraphRAG 的数据结构

3.1 TextUnit

TextUnit 是图谱抽取的文本单元。 它可以是段落、章节、工单、调查记录、投诉、政策条款或审计发现。 一个可治理的 TextUnit 至少应保留：

• document_id。
• page / section。
• timestamp。
• source_system。
• product / region / customer_type。
• classification。
• allowed_roles。
• effective_date / expiry_date。
• status。 TextUnit 设计不好，后续实体、关系和 claim 都会被污染。

3.2 Entity

实体是图中的节点。 金融零售常见实体包括：

• Person：客户、法人、受益所有人、员工。
• Organization：商户、供应商、企业客户、合作伙伴。
• Account：银行账户、卡号、内部账户。
• Device：设备、IP、浏览器指纹、终端。
• Location：地址、门店、地区、仓库。
• Product：贷款、信用卡、基金、保险、促销。
• Policy：政策、规则、费率、话术。
• Event：交易、投诉、调查、审批、处罚。 实体抽取难点在于同名、别名、拼写差异、语言差异、脱敏和 entity resolution。

3.3 Relationship

关系是图的边。 它描述实体之间如何连接。 例如：

• beneficial_owner_of。
• transacts_with。
• shares_device_with。
• uses_same_address_as。
• mentions_product。
• violates_policy。
• escalated_to。
• approved_by。
• supersedes_policy。 金融场景中，每条关系都要有来源、时间范围、置信度和权限标签。 没有证据的关系不应进入高风险决策链。

3.4 Claim

Claim 是从文本或系统记录中抽取的关键断言。 例如：

• “商户 M 在 30 天内出现异常高退款率。”
• “政策 P 于 2026-04-01 替代旧版本。”
• “投诉 C 涉及保证收益话术。”
• “客户 A 与账户 X 存在授权关系。” Claim 必须能追溯到原始 TextUnit 或系统记录。 它还应标记是否已确认、是否由 LLM 抽取、是否可用于客户影响决策。

3.5 Community

Community 是图中关系密集的实体群。 它不等于真实组织或犯罪团伙。 它只是图结构上的聚类，需要业务解释和验证。 金融零售中，社区可能代表：

• 共享设备、地址和结算账户的一组商户。
• 围绕同一产品话术的一批投诉。
• 相似交易 typology 的 AML case。
• 同一供应链问题影响的门店和 SKU。 Community summary 可以帮助快速理解模式，但不能替代原始证据。

---

4. Pipeline：GraphRAG 如何工作

Raw corpus and enterprise data
  -> parsing and TextUnit generation
  -> entity extraction
  -> relationship extraction
  -> claim extraction
  -> entity resolution
  -> graph construction
  -> community detection
  -> community summarization
  -> text index + graph index
  -> query intent routing
  -> local / global / DRIFT / basic search
  -> context building with paths and citations
  -> grounded answer
  -> eval and monitoring

每一步都有风险。

---

5. Query modes：用业务语言理解

GraphRAG 的查询模式应由业务意图触发，而不是默认全量启用。

---

6. 为什么 GraphRAG 有效

6.1 它显式保存关系

普通 RAG 依赖文本相似性。 GraphRAG 把实体和关系显式保存下来。 当问题问“为什么相关”时，系统可以返回路径，而不是只返回相似段落。 路径让回答更可解释：

客户 A -> 账户 X -> 商户 M -> 共享设备 D -> 商户 N

每条边都有来源和置信度，才可能被审计。

6.2 它支持多跳综合

多跳问题需要连接多个证据点。 GraphRAG 可以从 seed entity 开始扩展邻居和路径，找到分散证据之间的结构关系。 这对 AML、KYC、商户风险、投诉根因和供应链风险尤其有价值。

6.3 它把大语料压缩成可检索的结构

Community summary 把大量文档和关系压缩成更高层的主题、模式和群体特征。 这让系统能回答“整体上发生了什么”，而不只是“哪个片段相似”。 但摘要必须带来源。 没有来源的全局总结不适合高风险决策。

---

7. 局限、误用和反模式

7.1 为了先进而上 GraphRAG

如果问题主要是单文档政策问答，hybrid retrieval、metadata filter、rerank 和 citation 往往足够。 GraphRAG 会增加抽取、存储、评估、权限和运维复杂度。 不应为了技术标签引入图谱。

7.2 LLM 抽取关系被当成事实

LLM-derived edge 是候选关系，不一定是事实。 金融场景必须区分：

• 系统记录确认的关系。
• 规则推导的关系。
• LLM 从文本中抽取的关系。
• 人工确认的关系。 不同来源有不同可用范围。 LLM 抽取关系不应直接用于客户不利决定。

7.3 Entity resolution 错误

图谱系统最危险的问题之一是错合并。 把两个同名客户合并，会造成严重隐私和决策风险。 漏合并也会让风险网络断裂。 Entity resolution 需要确定性 key、相似度、人工复核和审计日志。

7.4 权限穿透

图谱遍历可能跨越权限边界。 用户有权查看商户 M，不代表有权查看与 M 关联的所有客户、账户、员工或 AML case。 GraphRAG 必须有 path-level ABAC。 权限过滤不能只在最终答案阶段做。

7.5 社区摘要过度解释

Community 是算法聚类，不等于因果关系。 社区摘要可能把相关性写成原因，把模式写成结论。 高风险输出必须保留：

• 这是模式假设还是确认事实。
• 哪些证据支持。
• 哪些证据缺失。
• 是否需要 SME review。

---

8. 架构和产品价值

8.1 GraphRAG fit assessment

引入 GraphRAG 前，先回答：

8.2 Hybrid KG + RAG reference architecture

Hybrid KG + RAG 的参考链路是：文档、case、交易和主数据先进入 ingestion 与 metadata 层；文本进入 text index，非结构化资料进入 entity / relation / claim extraction，主数据和交易系统进入 enterprise KG；entity resolution 后形成可查询图谱，并生成 community summaries。查询时先做 intent routing，再选择 text index、KG 或 community summary 构造上下文；最后经过 permission and path policy，生成带 citation 和 path 的 grounded answer，并进入 graph / RAG eval。关键是把图谱和文本都放在权限和证据控制下。

8.3 图谱治理对象

GraphRAG 的治理对象包括：

• entity schema。
• relation ontology。
• claim schema。
• provenance。
• confidence。
• effective time。
• classification。
• allowed roles。
• graph version。
• extraction model version。
• human validation status。 没有这些字段，图谱会变成漂亮但不可审计的关系网。

---

9. 金融零售系统案例

9.1 AML network investigation

客户 A 是否处在可疑交易网络中？这个网络的主要 typology 是什么？

GraphRAG 的价值是把客户、账户、商户、设备、地址、交易和历史 investigation narrative 连接成路径，并用社区摘要解释 typology。控制边界是：每条路径必须有证据，不自动提交 SAR/STR，不把相关性写成犯罪结论，无权限节点在遍历前过滤。

9.2 Merchant risk review

商户 M 是否属于异常退款或争议网络？

系统应连接共享设备、地址、结算账户、IP、争议率、退款率和投诉主题，解释商户与群体模式的关系。图谱建议只能帮助风险团队优先检查路径，不能直接冻结商户；误合并商户必须有纠正流程。

9.3 Complaint root cause analysis

最近投诉是否指向某个产品条款、营销话术或培训缺陷？

GraphRAG 可以从投诉、客服记录、产品条款和培训材料中抽取实体与 claim，形成投诉主题社区，连接话术、产品、渠道、地区和培训缺陷。社区摘要只能作为根因假设和整改优先级输入，客户补偿、纪律处分和监管回复仍需正式流程。

9.4 KYC beneficial ownership

企业客户的受益所有人、关联公司和高风险关系如何解释？

图谱可以解析 ownership chain，连接自然人、企业、地址、董事、制裁命中和文件证据，并标记缺失文件或待确认关系。ownership 来源必须明确，LLM 抽取关系需要人工复核，PII 权限按角色和 case 限制。

---

10. Eval for GraphRAG

GraphRAG 不能只沿用普通 RAG 指标。 需要增加图谱特有维度。

10.1 GraphRAG golden case

一个高质量 golden case 可以这样写：

10.2 Failure tags

常见 failure tags 包括 entity_missing、entity_false_positive、entity_merge_error、relation_unsupported、path_overextended、community_not_meaningful、summary_hallucination、permission_path_leak、wrong_query_mode、unsupported_risk_conclusion。它们能把“图谱不好用”变成可修复问题。

---

11. 学习验证

用自己的话回答：

• Baseline RAG 和 GraphRAG 解决的问题有什么不同。
• TextUnit、Entity、Relationship、Claim、Community 分别是什么。
• Local、Global、DRIFT search 分别适合什么业务问题。
• 为什么 LLM-derived relationship 不能直接当事实。
• GraphRAG 为什么需要 path-level permission。 做一个 GraphRAG assessment package：分别评估 KYC 政策问答、AML 网络调查、信用卡费用 FAQ、投诉根因分析、供应链质量风险是否适合 GraphRAG。每个场景写出 baseline RAG 是否足够、是否需要实体关系或全局模式、需要哪些数据源、主要风险和控制。 再设计一个 ontology v0.1，至少包含 10 类实体和 20 类关系；每类关系标明来源、置信度、是否可用于客户影响决策、是否需要人工确认。 最后为 AML network GraphRAG 写 eval matrix，覆盖 entity extraction、entity resolution、relation evidence、path correctness、community summary、permission traversal、answer groundedness 和 human review trigger。

---

12. 读完后应形成的判断

GraphRAG 的价值不是“更高级”，而是显式建模文本背后的实体、关系、路径和群体模式。 当问题只是查一条政策，baseline RAG 更简单、更便宜、更可靠。 当问题需要连接客户、账户、商户、设备、交易、投诉、政策和调查记录时，GraphRAG 或 Hybrid KG + RAG 才有明显价值。 金融零售落地必须谨慎处理图谱关系的证据和来源、实体解析和权限遍历、社区摘要和风险结论的边界。 成熟判断不是“要不要用 GraphRAG”，而是先证明普通 RAG 为什么不够，再设计图谱结构、治理字段、查询模式、eval 和人工责任链。

---

SOTA 检查 (2026-07-01)

• Microsoft GraphRAG 库仍在活跃维护，已演进到 v3.0.0（2025 年下半年发布，前一大版本 v2.7.1；v3 重构了 workflow 组织并移除 NetworkX 依赖改用 DataFrame 实现，graphrag init --force 生成新版配置布局）。本篇正文的 TextUnit / entity / relationship / claim / community 数据结构与 local / global / DRIFT / basic 四种 search mode 在官方文档中仍是现役概念，正文机制描述未过时。
• LazyGraphRAG 是官方给出的成本路线更新：索引成本与向量 RAG 相同、约为完整 GraphRAG 索引成本的 0.1%，在可比查询成本下于 local query 上超过 GraphRAG local search 和 DRIFT search（Microsoft Research 博客）。截至 2025 年它仍是实验性的内部 fork（未并入开源库），对外通过 Microsoft Discovery（2025-08-05 起提供）和 Azure Local 公开预览（2025-06-06）落地。含义：本篇第 7.1 节“抽取/索引成本是引入 GraphRAG 的主要门槛”这一判断已被官方自己承认并针对性优化，选型时应把 LazyGraphRAG / 轻量图谱方案列入对比。
• 2025 年的 RAG vs GraphRAG 对照实验支持本篇的 fit assessment 结论：在统一任务集上两者互有胜负——单跳、细节型问题 vector RAG 更强，多跳与 corpus-level sensemaking 问题 GraphRAG 更强（2026 年多篇 practitioner guide 综述引用该结果）。即“先证明 baseline RAG 为什么不够”仍是正确的引入前提，而非过度保守。
• 2025-2026 研究主线转向降低图谱构建成本与细粒度子图检索：LightRAG、KET-RAG、MiniRAG、LeanRAG 等简化图结构或按查询检索子图，StepChain GraphRAG（2025）把逐步推理与图遍历结合并在 multi-hop QA 基准上报告 SOTA；完整 GraphRAG 对大语料的一次性索引成本（社区报告中有大规模语料约 $33K 的案例）是这波工作的直接动因。本篇未覆盖这批轻量变体，做 build-vs-buy 对比时需补充。
• 不随版本过时的框架性结论：GraphRAG fit assessment（8.1）、LLM-derived edge 只能作候选关系、path-level ABAC / provenance / graph eval 维度（第 10 节）、以及“社区是算法聚类而非因果结论”这些治理判断与具体库版本无关，仍然成立。金融零售落地的检索评测与图谱 RAG 决策细化可交叉参考库内 docs/AI_RETRIEVAL_EVAL_GRAPH_RAG_PLAYBOOK.md。