GraphRAG 实践：用知识图谱增强检索的生成效果

传统 RAG 擅长"找一段相似文本"，但在需要跨文档推理、全局性总结的提问上偏弱。GraphRAG 在向量检索之外引入实体关系图谱，把"片段相似"升级为"关系可达"，显著提升多跳推理类问题的回答质量。下面从流程、关键组件、工程要点三个维度落地。

一、为什么传统 RAG 不够。 向量检索本质是"语义最近的片段"，适合"某概念怎么定义"这类点查。但当问题变成"公司上半年各业务线的风险趋势是什么""哪几类客户投诉最集中"，答案分散在几十份文档里、需要归纳与关联，单纯 top-k 召回的片段拼不出全局结论。GraphRAG 的解法是：先把文档里的实体（人、组织、地点、概念）和关系抽出来建成图，再对图做社区划分与摘要，查询时既能走局部实体检索，也能走全局社区摘要。

二、GraphRAG 的核心流程。

1. 文本切分与实体抽取：用 LLM 从每个 chunk 抽取实体及关系，输出 (实体A, 关系, 实体B) 三元组；可限定实体类型白名单（如 PER/ORG/LOC/GEO/CONCEPT）以减少噪声。
2. 建图：三元组写入图数据库（Neo4j / NetworkX / Cosmos DB），节点带描述与原文出处。
3. 社区检测：用 Leiden 算法对图做层次化社区划分，分辨率参数 gamma 通常取 0.1–1.0，值越小社区越大、摘要越宏观。
4. 社区摘要：对每个社区用 LLM 生成摘要，形成"社区→摘要"的层级索引。
5. 查询路由：局部查询走向量+图遍历取相关实体邻域；全局/综述查询直接聚合相关社区摘要。

三、关键组件与参数。

• chunk size：实体抽取建议 600–1200 token/块，过大实体遗漏、过小关系断裂。
• 实体类型约束：开放域易抽爆，建议限 5–10 类核心类型。
• Leiden 分辨率 gamma：0.1 粗粒度（适合全局总结）、0.5–1.0 细粒度（适合局部定位）。
• 社区层级：一般取 2–4 层，顶层摘要覆盖全貌，底层摘要保留细节。
• 摘要模型与抽取模型：抽取可用小模型降本，摘要用强模型保质量。

四、两类查询模式。

• 全局查询（Global / Summary）：问题需要跨文档归纳，如"整体趋势""主要风险"。路由到社区摘要逐层上卷，再让 LLM 综合。召回的是摘要而非原文片段。
• 局部查询（Local / Specific）：问题指向具体实体，如"项目 X 的负责人是谁"。先向量检索定位实体节点，再图遍历其邻域关系，拼接精确答案。

五、工程要点。

1. 成本：GraphRAG 建图与摘要有大量 LLM 调用，百万字语料的一次性建图成本可能是传统 RAG 的数倍，适合静态知识库周期性重建，而非实时写入。
2. 更新：文档变更时，增量抽取新实体并局部更新图，避免全量重跑；摘要层按需重算受影响社区。
3. 图存储选型：中小规模用 NetworkX 内存图即可；生产高并发用 Neo4j 或支持图索引的向量库。
4. 与传统 RAG 混合：很多场景不需要全量 GraphRAG，可只对"需推理的长文档集"启用图谱，普通 FAQ 仍用向量检索，按数据性质分层。
5. 评测：用全局类问题的人工评分（完整性、忠实度）对比纯向量 RAG，量化增益；常用 Faithfulness 与答案覆盖率做自动指标。

六、什么时候该用。 文档量大、实体关系密、问题偏"归纳/对比/趋势"时用 GraphRAG 收益明显；文档少、问题都是点查的场景，传统 RAG 足够，上图谱是过度工程。

小结：GraphRAG 不是替代向量检索，而是补上"关系推理"这一环。把实体关系建成图、对社区做摘要，能让 AI 在跨文档问题上给出有依据的综合答案。按数据规模和问题类型决定是否启用，别为用而用。