GraphRAG / Knowledge Graph RAG 解读

面向对象: AI Architect / AI PM / AI BA / Data Product Manager / AML-KYC 产品负责人。 核心问题: 什么时候普通 RAG 不够，需要把实体、关系、社区、路径和图谱推理引入知识系统？ 学习目标: 能判断 GraphRAG 的适用场景、设计数据和架构、定义 eval、控制成本，并把它转换成金融零售作品集案例。

---

Source Anchors

本文不把 GraphRAG 解释成“比 RAG 更高级的万能方案”。它是一种在关系、多跳、全局总结和复杂私有数据理解上更有优势、但也更贵更难治理的架构选择。

---

一句话理解 GraphRAG

普通 RAG 更像:

根据问题找相似文本片段，再让模型基于片段回答。

GraphRAG 更像:

先从文本中抽取实体、关系和关键声明，形成知识图谱与社区摘要；回答时根据问题使用文本、实体邻居、关系路径和社区摘要共同构造上下文。

两者解决的问题不同:

PM / BA / 架构师最重要的判断是:

不要为了显得先进而用 GraphRAG。只有当问题本质依赖关系、路径、社区、跨文档综合或实体网络时，GraphRAG 才值得引入。

---

Baseline RAG 什么时候足够

普通 RAG 足够的场景:

• 用户问某个政策条款。
• 答案主要来自一个或少数几个文档段落。
• 文档结构清晰，metadata 完整。
• 问题不需要跨多个实体建立关系链。
• 主要目标是引用、版本、权限和流程解释。

例子:

• “某贷款产品提前还款手续费是多少？”
• “企业开户需要哪些 KYC 文件？”
• “客服是否可以承诺免除年费？”
• “某促销活动的适用门店和日期是什么？”

这些场景中，hybrid retrieval + metadata filter + rerank + citation 已经可以解决主要问题。GraphRAG 可能增加成本、延迟和维护复杂度，但不会带来足够收益。

---

GraphRAG 什么时候值得

GraphRAG 值得考虑的场景通常有这些信号:

典型问题:

• “哪些客户群体与这个商户风险网络有关？”
• “过去 12 个月的 AML case 中，哪些 typology 在不同地区反复出现？”
• “这起投诉是否和历史营销违规、产品条款、客服话术之间存在模式？”
• “某供应商风险是否通过共同法人、地址、银行账户扩散到多个门店？”

这些问题不是简单相似文本检索，而是关系理解。

---

GraphRAG 的核心数据结构

TextUnit

TextUnit 是被分析的文本单元。它可以是段落、章节、工单、调查记录、政策条款或审计发现。

设计要点:

• 保留来源定位: document_id、page、section、timestamp。
• 保留业务 metadata: product、region、customer_type、risk_tier。
• 保留权限 metadata: owner、classification、allowed_roles。
• 保留版本 metadata: effective_date、expiry_date、status。

如果 TextUnit 设计不好，后续实体和关系都会被污染。

Entity

实体是图中的节点:

• Person: 客户、法人、受益所有人、员工。
• Organization: 商户、供应商、企业客户、合作伙伴。
• Account: 银行账户、钱包、卡号、内部账户。
• Device / Location: 设备、IP、地址、门店。
• Policy / Product: 政策、产品、规则、费率。
• Event: 交易、投诉、调查、审批、处罚。

实体抽取要处理同名、别名、拼写差异、语言差异和隐私脱敏。

Relationship

关系是图的边:

• owns / controls / beneficial_owner_of
• transacts_with
• shares_device_with
• uses_same_address_as
• violates_policy
• mentions_product
• escalated_to
• approved_by
• supersedes_policy

关系要有证据来源、置信度、时间范围和权限标记。金融场景不能只保存“看起来相关”，必须知道依据是什么。

Claim

Claim 是从文本中抽取的关键断言:

• “客户 A 与商户 B 在 30 天内发生 15 笔异常交易。”
• “政策 X 于 2026-04-01 替代旧版本。”
• “该投诉涉及误导性收益表述。”

Claim 必须可追溯到原始 TextUnit。没有来源的 claim 不应进入高风险决策链。

Community

Community 是图中关系密集的实体群组。 GraphRAG 中常通过社区发现和社区摘要帮助回答全局问题。

金融零售例子:

• 一组共享设备、地址和收款账户的商户。
• 一组围绕同一产品和营销话术的投诉。
• 一组相似 typology 的 AML case。

社区摘要适合回答:

• “这一批 case 的主要模式是什么？”
• “这个风险网络的共同特征是什么？”
• “这类投诉背后的根因是什么？”

---

GraphRAG Pipeline

Raw corpus
  -> Parsing and TextUnit generation
  -> Entity extraction
  -> Relationship extraction
  -> Claim extraction
  -> Entity resolution
  -> Graph construction
  -> Community detection
  -> Community summarization
  -> Graph index + text index
  -> Query routing
  -> Local / Global / DRIFT / Basic search
  -> Context building
  -> Grounded answer with citations and paths
  -> Eval + monitoring

每一步都有治理风险:

---

Query Modes: 用业务语言理解

Basic Search

普通 top-k 检索。适合事实查找和政策解释。

业务例子:

• “这个产品是否允许提前还款？”

Local Search

围绕特定实体展开邻居和相关概念。适合 entity-centric 问题。

业务例子:

• “商户 M 的风险关系有哪些？”
• “客户 C 过去关联过哪些高风险账户？”

Global Search

利用社区摘要回答全局问题。适合 corpus-level 综合。

业务例子:

• “过去半年投诉中最常见的销售误导模式是什么？”
• “这批 AML case 中有哪些新兴 typology？”

DRIFT Search

结合局部实体扩展和社区信息。适合既要看实体邻居、又要看更大上下文的问题。

业务例子:

• “商户 M 所在风险社区的共同特征是什么，它和具体交易异常如何关联？”

Query Routing

成熟系统要先判断问题类型:

---

GraphRAG vs Knowledge Graph + RAG

GraphRAG 常指从非结构化文本中用 LLM 抽取图谱，再把图谱用于 RAG。 Knowledge Graph + RAG 更宽，可以包括已有主数据、交易网络、客户关系、产品目录、规则库和本体。

金融机构通常不应只依赖 LLM 从文本中抽图。更好的架构是:

• 核心实体来自可信主数据。
• 交易关系来自系统记录。
• 政策关系来自文档和规则库。
• 非结构化 claim 来自 LLM 抽取但需要证据和置信度。
• 高风险关系需要人工或规则确认。

---

金融零售应用场景

AML Network Investigation

问题:

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

GraphRAG 价值:

• 连接客户、账户、商户、设备、地址和交易。
• 汇总社区风险模式。
• 解释路径: 客户 A -> 账户 X -> 商户 M -> 高风险社区。
• 把历史 investigation narratives 和结构化交易结合。

Eval:

• 是否找出已知 suspicious entities。
• 关系路径是否有证据。
• narrative 是否忠实于图谱和原始记录。
• 是否避免自动 SAR filing 建议。

KYC / Beneficial Ownership

问题:

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

GraphRAG 价值:

• 解析 ownership chain。
• 连接公司、自然人、地址、董事、制裁名单命中。
• 说明缺失文件和需要人工确认的关系。

Eval:

• ownership path accuracy。
• source citation coverage。
• missing evidence detection。
• PII 权限控制。

Merchant Risk Review

问题:

这个商户是否属于某个异常退款/争议网络？

GraphRAG 价值:

• 连接商户、设备、结算账户、地址、交易争议、投诉。
• 发现共享特征群组。
• 解释风险不是单点异常，而是网络模式。

Complaint Root Cause Analysis

问题:

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

GraphRAG 价值:

• 从投诉、客服记录、产品条款、培训材料中抽实体和 claim。
• 形成投诉主题社区。
• 支持全局总结和根因假设。

Retail Supply Chain Risk

问题:

哪些供应商、门店、SKU 和物流事件共同导致缺货或质量投诉？

GraphRAG 价值:

• 连接供应商、SKU、仓库、门店、物流、投诉。
• 发现风险传播路径。
• 支持补货、替换供应商或召回决策。

---

Architecture Decisions

ADR 1: 是否引入 GraphRAG

ADR 2: Graph Source of Truth

金融场景建议使用混合图谱，但给不同边类型标记 provenance 和 confidence。

ADR 3: Community Summary 用途

社区摘要适合:

• 分析模式。
• 形成 investigation brief。
• 辅助 SME 快速理解。

社区摘要不适合:

• 作为唯一处罚依据。
• 替代原始证据。
• 直接生成客户不利决定。

---

Eval for GraphRAG

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

GraphRAG Golden Set

每条 case 应记录:

---

成本与复杂度

GraphRAG 的隐藏成本:

• 抽取成本: LLM 处理大量文本。
• 存储成本: 图谱、向量、文本、摘要多套索引。
• 维护成本: entity resolution、关系 schema、版本管理。
• eval 成本: 图谱评估比普通 RAG 更复杂。
• 延迟成本: local/global/DRIFT search 可能比 top-k 检索慢。
• 治理成本: 图谱路径可能跨越权限边界。

PM 的问题不是“GraphRAG 是否更强”，而是:

它能否在目标 use case 中产生足够的风险降低、效率提升或洞察价值，覆盖额外成本和治理复杂度？

---

GraphRAG Decision Checklist

---

30 秒面试表达

我不会把 GraphRAG 当成普通 RAG 的升级版，而会先判断问题是否依赖实体、关系、路径和全局模式。普通政策问答用 hybrid RAG 就够了；AML 网络、商户风险、投诉根因、供应链风险这类多跳关系问题，才值得引入知识图谱、社区摘要和图谱检索。金融场景还必须控制来源、权限、版本和人工复核。

2 分钟面试表达

Baseline RAG 适合从文本中找相关段落并生成引用答案，但当问题需要连接客户、账户、商户、设备、交易、投诉和政策之间的关系时，单纯 top-k 语义检索容易漏掉路径和全局模式。GraphRAG 的核心思路是从语料中抽取实体、关系和 claim，形成知识图谱和社区摘要，然后按问题选择 local、global、DRIFT 或 basic search。对 AML investigation，它可以解释风险网络和 typology；对投诉分析，它可以发现跨文档根因；对供应链，它可以连接供应商、SKU、门店和物流事件。但我会谨慎使用，因为 GraphRAG 带来 entity resolution、关系证据、权限遍历、图谱版本、成本和 eval 复杂度。我的决策原则是: 单文档事实用普通 RAG，多实体多跳和全局模式才用 GraphRAG 或 KG+RAG。

CTO 深挖回答

技术上我会把 GraphRAG 分成 text index、entity index、relationship store、community summaries、provenance store 和 policy layer。每条 node/edge/claim 都要有 source_id、confidence、timestamp、classification 和 allowed_roles。查询时先做 intent routing，再决定 basic/local/global/DRIFT。高风险场景必须限制 path traversal，不能因为图谱连接而绕过权限。eval 上除了 faithfulness，还要测 entity extraction、relation precision、path correctness、community summary support 和 query router accuracy。

PM 深挖回答

PM 要证明 GraphRAG 的业务价值超过复杂度。比如 AML 调查中，如果它能减少调查员找关系的时间、提高关键关系发现率、降低漏报风险，并保持人工最终判断，那么它值得 pilot。否则，如果用户只是问政策条款，引入 GraphRAG 会让系统更贵、更慢、更难解释。

BA 深挖回答

BA 要定义图谱 schema 和业务语义。比如“关联”不能是模糊词，要区分共同地址、共同设备、共同受益人、交易对手、投诉同源、政策替代关系。每种关系都要定义来源、有效期、置信度、是否可用于客户影响决策、是否需要人工确认。否则图谱会变成漂亮但不可治理的关系网。

---

产出练习

完成本篇后，产出四个资产:

1. 一个 GraphRAG Fit Assessment，判断某个金融零售 case 是否适合 GraphRAG。
2. 一个 Entity-Relationship Ontology v0.1，至少包含 10 类实体和 20 类关系。
3. 一个 GraphRAG ADR，写清为什么不是普通 RAG、SQL dashboard 或纯 KG。
4. 一个 GraphRAG Eval Matrix，覆盖 entity、relation、path、community、answer、permission。

作品集表达:

我设计过一个 AML / 商户风险 GraphRAG 方案，不是把图谱当技术噱头，而是先判断普通 RAG 的失败点，再定义实体、关系、来源、权限、路径解释、社区摘要和 eval gate。这个案例证明我能把复杂 AI 架构和业务风险控制连接起来。