第17课：GraphRAG —— 知识图谱增强 RAG

本节目标：理解普通 RAG 的天花板、掌握 GraphRAG 的核心思想与微软实现流程、知道什么时候该用 GraphRAG。

普通 RAG 擅长单点查询，但在"多跳问题"上捉襟见肘。GraphRAG 就是来解决这个问题的。

1. 普通 RAG 的天花板

Code

普通 RAG 擅长：
  "酸枣仁汤治什么？" ← 单点查询，一个 chunk 能回答

普通 RAG 不擅长（多跳问题）：
  "黄帝内经中提到的与肝相关的脏腑关系有哪些？"
  → 需要：找肝相关 → 找关联脏腑 → 找关系类型 → 整合
  → 普通 RAG 召回的 chunks 是离散的，无法表达"关系"

2. GraphRAG 核心思想

Code

普通 RAG：
  文档 → chunks → 向量库 → 召回 chunks

GraphRAG：
  文档 → 抽取实体和关系 → 构建知识图谱 → 召回子图

  例：肝 ─主─→ 疏泄 ─→ 调畅情志
       ├─藏─→ 血
       ├─开窍于─→ 目
       └─主─→ 筋

关键区别：GraphRAG 不仅找节点，还找路径。查询不再是"相似文本匹配"，而是"子图遍历"。

3. 微软 GraphRAG 流程

Phase 1：索引构建（离线，一次性）

Code

① 文档切片 → chunks
② LLM 抽取实体和关系 → 三元组 (E1, R, E2)
   例：(酸枣仁汤, 主治, 不寐)
③ 实体消解（"肝"和"肝脏"合并）
④ 社区检测（Leiden 算法）→ 把图分成多个主题社区
⑤ 对每个社区用 LLM 生成摘要

Phase 2：查询（在线）

局部查询（Local）：找相关实体 → 取其邻居子图
全局查询（Global）：用所有社区摘要 → Map-Reduce 整合

4. 何时该用 GraphRAG？

场景	推荐度
关系密集领域（中医/医学/法律/企业知识图谱）	推荐
多跳推理问题（A→B→C 的链式问答）	推荐
全局性问题（"这本书讲了什么主题？"）	推荐
单点查询为主（FAQ、文档问答）	推荐（不需要）

5. 中医场景的图谱设计示例

cypher

// Neo4j Cypher 示例
(疾病:不寐)-[:常用方剂]->(方剂:酸枣仁汤)
(方剂:酸枣仁汤)-[:组成]->(药材:酸枣仁)
(药材:酸枣仁)-[:性味]->(性味:甘酸平)
(药材:酸枣仁)-[:归经]->(经络:心经)
(疾病:不寐)-[:相关脏腑]->(脏腑:肝)
(脏腑:肝)-[:藏]->(物质:血)
(物质:血)-[:养]->(精神:神)

// 多跳查询：找到与不寐相关的所有节点和关系
MATCH (d:疾病{name:'不寐'})-[*1..3]->(related)
RETURN d, related

实现路径

可在现有 PostgreSQL 基础上加表存图谱（轻量），或引入 Neo4j（专业图数据库）。

6. GraphRAG 的代价

代价	说明
索引构建慢	LLM 抽取实体+关系，大规模文档需要数小时
Token 消耗大	实体抽取 + 社区摘要都要调 LLM
工程复杂度高	实体消解、社区检测、双模式查询
需要维护	新文档需要增量更新图谱

建议：不要一上来就用 GraphRAG。先用多路检索+Rerank 做到 90 分，确实有多跳需求再引入。

核心要点

GraphRAG 解决多跳问题：普通 RAG 找"相似文本"，GraphRAG 找"关系路径"
微软流程：LLM 抽取实体→构建图谱→社区检测→LLM 生成社区摘要
中医/法律/医学等关系密集领域受益最大
先做到 90 分再考虑 GraphRAG——不要过早优化

下一课：微调方法论 —— LoRA / QLoRA / DPO。