GraphRAG 知识图谱增强

摘要：本文面向被"全局问题"折磨的 RAG 工程师。"这篇文章主要讲了什么主题？""各章节之间有什么关系？"这类需要综览全库的问题，向量 RAG 天然答不好。微软 GraphRAG 通过 LLM 抽取实体/关系、做社区检测、生成社区摘要，支撑 Local/Global/DRIFT 三类查询。我们讲清原理、索引成本与何时才值得上。

GraphRAG 不是朴素 RAG 的替代品

GraphRAG 索引成本远高于向量 RAG（每个 chunk 多次 LLM 调用，官方估计图谱抽取约占索引成本 75%）。它解决的是多跳关系与全局综览问题。简单事实查找仍应用向量 RAG，二者常混合部署（查询分类器路由）。不要为所有场景都上 GraphRAG。

核心概念

概念	含义
TextUnit	切分后的文本块（默认 1200 token）
Entity / Relationship	LLM 抽取的实体与关系（含描述）
Community	用层次 Leiden 算法对实体图聚类得到的社群
Community Report	LLM 为每个社群生成的摘要报告（全局查询的燃料）
Local / Global / DRIFT	三类查询模式

架构与原理

索引流程（来自微软官方文档，访问日期 2026-10-09）

Compose TextUnits：文档 → 默认 1200 token 的 TextUnit（越大越快但保真度越低）。
Graph Extraction：LLM 抽取实体（title/type/description）与关系（source/target/description）；相同实体跨块合并。
Summarization：把同一实体的多条描述摘要成一条。
Community Detection：Hierarchical Leiden 递归聚类到阈值。
Community Report：每个社群每层都生成 LLM 摘要报告。
Embedding：实体/TextUnit/社区报告向量化，供 Local/DRIFT 使用。

三种查询模式

Local：问具体实体（"A 公司做了什么？"）→ 图遍历 + 原文，成本接近向量 RAG。
Global：问全库主题（"数据主要讲什么？"）→ 对社区报告做 map-reduce，资源密集，但比 hierarchical source summarization 便宜得多。
DRIFT（2024 末引入）：先全局定向再局部细化，兼顾覆盖与精度。

生产实践：索引配置

yaml

# settings.yaml（GraphRAG 官方配置，节选）
encoding_model: cl100k_base
chunks:
  size: 1200          # TextUnit 大小（token）
  overlap: 100
extract_graph:
  model: gpt-4o-mini  # 抽取用模型，成本敏感可换小模型
  prompt: default_extract_graph
summarize_descriptions:
  model: gpt-4o-mini
cluster_graph:
  max_cluster_size: 10
  strategy:
    method: leiden    # 层次 Leiden
community_reports:
  model: gpt-4o       # 报告生成，质量敏感用大模型

bash

# 初始化并索引（需先 pip install graphrag，版本相关）
python -m graphrag index --root ./ragtest
# 查询
python -m graphrag query --root ./ragtest --method global "文档主要涵盖哪些主题？"

成本敏感配置

官方估计图谱抽取约占索引成本 75%。可用 FastGraphRAG（NLP 抽取实体、更便宜）替代标准流程，或把抽取模型换小模型。全局查询按社群数量线性计费，控制社群规模阈值可降本。所有成本数字随模型定价浮动，请按自家账单核算[未实测]。

验证

bash

# 全局问题对照：同一问题分别用 向量RAG 与 GraphRAG(global) 作答
# 人工评估 comprehensiveness / diversity（微软研究用的维度）
# 期望 GraphRAG 在全局问题上显著更全；在单跳事实上两者相当

回滚与清理

图谱重建代价高

GraphRAG 索引是重 LLM 调用过程，单文档库可能数小时至数天（取决于规模与模型）。索引产物（Parquet/图库）建议版本化留存，更新少量文档需评估"局部重建 vs 全量重建"——实体变更常需重建相关社群。变更前备份索引目录。

故障排查

索引太慢/太贵：TextUnit 太大或抽取模型太大 → 调小 chunk 重叠、换小模型、试 FastGraphRAG。
全局答案空泛：社群报告质量低 → 抽取/报告模型升级、调整 prompt（微软建议做领域 prompt 调优）。
多跳仍答错：关系抽取漏边 → 检查抽取 prompt 是否覆盖你的实体类型；增加 few-shot。
查询路由错：简单问题走了 global → 加查询分类器（见 generation.md）。

安全与合规

GraphRAG 的额外暴露面

数据出域：索引阶段大量 LLM 调用会把原文发往模型供应商，敏感语料需私有部署模型或本地小模型。
图谱泄露关系：实体关系图本身可能泄露业务结构，应和原文同等级保护。
提示注入：社区报告由 LLM 生成，若源文档含注入指令，可能污染报告 → 生成侧护栏。
成本失控：全局查询 map-reduce 跨全库，易被单请求打爆预算 → 限流 + 社群范围上限。

成本与性能

量级参考，来自微软研究与第三方测算，非实测报价，访问日期 2026-10-09。

微软官方博客：GraphRAG 在全局问题上相对朴素 RAG 有 ~70–80% win rate（comprehensiveness/diversity），且比源文本分层摘要便宜（最高层社群约 2–3% token 用量）。
索引成本：图谱抽取约占 75%；大语料索引可达数小时至数天。
查询成本：Local 接近向量 RAG；Global 随社群数线性上升，需预算护栏。

GraphRAG 知识图谱增强 ​

核心概念 ​

架构与原理 ​

索引流程（来自微软官方文档，访问日期 2026-10-09） ​

生产实践：索引配置 ​

验证 ​

回滚与清理 ​

故障排查 ​

安全与合规 ​

成本与性能 ​

参考资料 ​