Ch11: Graph RAG 与知识图谱增强检索
Part 6: 进阶专题 前置章节：Ch04: 检索三路军——BM25、向量、知识图谱的协奏 后续章节：Ch12: Agentic RAG——让 LLM 自主编排检索 返回目录：README
结论先行：Graph RAG 解决的是 BM25 和向量检索都搞不定的「关系推理」类问题——答案不在 query 的关键词里，也不在语义近邻里，而在实体之间的链路上。WeKnora 用 PMI 统计自动建图，RAGFlow 用 LLM 抽取实体关系，两条路线代表「低成本统计」与「高精度语义」的取舍。
一、为什么需要第三路检索
日常类比：你在公司 Wiki 里找「谁负责过 ERR_OOM_KILL_001 的修复」。Wiki 全文搜索「ERR_OOM_KILL_001」能找到错误码说明页，但修复者的名字可能只在另一篇「张三的技术分享」里出现——两页之间没有共同关键词，向量检索也可能因为主题差异而漏掉。如果你有一张「错误码 → 修复者 → 相关文档」的关系网，就能从错误码跳到张三，再跳到他的其他文档。
这就是 Graph RAG 的定位：补 BM25/向量在「间接关联」上的盲区。
| 查询类型 | BM25 | 向量 | 知识图谱 |
|---|---|---|---|
| 精确错误码 / SKU | 强 | 弱 | 中 |
| 概念性问答 | 弱 | 强 | 中 |
| 多跳关系（A 的 B 还做过什么） | 弱 | 弱 | 强 |
| 全新实体（库里第一次出现） | 中 | 中 | 弱（冷启动） |
二、三种建图策略对比
| 策略 | 代表项目 | 构建方式 | 精度 | 成本 | 维护 |
|---|---|---|---|---|---|
| PMI 统计共现 | WeKnora | 实体共现 → 点互信息 | 中 | 低 | 增量更新 PMI |
| LLM 关系抽取 | RAGFlow Graph RAG | 文档 → NER + 关系三元组 | 高 | 高（每文档调 LLM） | 需重跑抽取 |
| 社区摘要（Microsoft GraphRAG） | 社区方案 | 聚类 → 社区摘要节点 | 高（宏观） | 很高 | 全量重建为主 |
PMI 的直觉（WeKnora 路线）
\[PMI(x, y) = \log_2\left(\frac{P(x,y)}{P(x) \cdot P(y)}\right)\]- PMI 高：两实体「总是结伴出现」，如「BM25」与「关键词检索」
- PMI 接近 0：偶然共现，不建边
- PMI 低：互斥，少见
WeKnora 管线概要：
文档 chunk → 实体抽取（分词+词性 / 可选 LLM）
→ 段落内共现统计
→ PMI 过滤 + 建边
→ 1–2 跳图遍历 → 召回含关联实体的 chunk
→ 与 BM25、向量结果一起 RRF 融合
详见 Ch04 §4 与 精读: WeKnora。
RAGFlow Graph RAG 路线
RAGFlow 在 DeepDoc 解析后，用 LLM 从结构化文本中抽取 (头实体, 关系, 尾实体) 三元组，写入图数据库。优势是关系类型明确（「负责」「属于」「引用」）；劣势是 LLM 抽取有幻觉风险，且大库全量抽取成本高。
三、Graph RAG 在 RRF 融合中的角色
WeKnora 三路并行检索后，用 Reciprocal Rank Fusion (RRF) 合并排名：
def rrf_score(rank: int, k: int = 60) -> float:
"""rank 从 1 开始；k 越大，排名靠后的结果权重衰减越慢"""
return 1.0 / (k + rank)
def fuse_three_way(bm25_ranks, vector_ranks, graph_ranks, k=60):
scores = {}
for doc_id, rank in bm25_ranks:
scores[doc_id] = scores.get(doc_id, 0) + rrf_score(rank, k)
for doc_id, rank in vector_ranks:
scores[doc_id] = scores.get(doc_id, 0) + rrf_score(rank, k)
for doc_id, rank in graph_ranks:
scores[doc_id] = scores.get(doc_id, 0) + rrf_score(rank, k)
return sorted(scores.items(), key=lambda x: -x[1])
关键设计点：图谱路单独贡献排名分，而不是把图结构硬编码进 prompt。这样某一路检索失败时，其他路仍可兜底——比「只信图谱」更稳健。
四、Graph RAG 的典型失败模式
| 失败模式 | 根因 | 缓解思路 |
|---|---|---|
| 噪声边泛滥 | 实体抽取把停用词当实体 | 提高 PMI 阈值、共现次数下限 |
| 冷启动图谱稀疏 | 文档量 < 数百篇 | 前期依赖 BM25+向量，图谱作加分 |
| 关系方向丢失 | PMI 无向边 | 需要因果/层级时用 LLM 抽取有向关系 |
| 与向量重复召回 | 三路结果高度重叠 | RRF 已部分解决；可设 dedup |
| 维护滞后 | 文档更新未同步图谱 | 增量 PMI 重算 + Wiki 巡检（WeKnora 自维护） |
WeKnora 的 自维护 Wiki 与图谱联动：矛盾检测、覆盖缺口检测会用到实体共现模式——图谱不只是检索工具，还是知识库健康度信号源。
五、何时该上 Graph RAG
适合：
- 企业知识库实体密集（产品、错误码、法规条款、人物组织）
- 用户常问「X 和 Y 有什么关系」「谁负责过 Z」
- 已有 WeKnora / RAGFlow 等原生支持，边际成本低
不适合：
- 纯 FAQ、短文档、实体稀疏的笔记库
- 团队无法承担图谱增量维护
- 延迟预算极紧且图谱路无法与其他路并行
选型可参考 RAG 平台选型决策树 与 Agentic RAG 模式 中的 Graph RAG 节。
章末自检
- 用一句话说明 Graph RAG 补的是 BM25/向量哪类盲区
- 解释 PMI 高/低各意味着什么，并举一个你熟悉领域的例子
- 画出 WeKnora 三路检索 + RRF 的数据流（至少 5 个节点）
- 对比 PMI 建图与 LLM 关系抽取：各适合什么规模的知识库？
- 若 issue 涉及「多跳问答质量差」，你会先查解析层、图谱层还是融合层？
延伸阅读
- Ch04: 检索三路军 — PMI 与图谱检索基础
- 精读: WeKnora — PMI 图谱与 Wiki 自维护
- 精读: RAGFlow — DeepDoc + Graph RAG
- Agentic RAG 模式 — Graph RAG 在六种模式中的位置
- 技术挑战 — 知识图谱构建与维护成本（难点 #4）