“把公司过去三年的所有周报、文档丢进RAG，问’研发和产品团队的主要分歧’——大概率拼不出完整答案”。这不是模型不够强，是传统RAG天生只见树木不见森林。微软2024年7月开源的GraphRAG用知识图谱重构了检索逻辑，目前已超31K Stars，是2026年绕不开的话题。

---

一句话总结

GraphRAG = 把文档转成知识图谱+社区检测+分层摘要。传统RAG搜文本片段，GraphRAG搜知识结构。适合全局性问题、多跳推理、跨文档综合分析——但索引成本是传统RAG的5-10倍，小数据集别用。

---

1. 传统RAG的硬伤

先回顾传统RAG的工作方式：

1. 文档切块（Chunks）
2. 每块向量化
3. 用户问题向量化
4. 找相似Top-K块
5. 喂给LLM生成

这套流程对具体的、指向明确的问题效果不错：

• ✅ “Kubernetes的liveness probe支持哪些参数？”
• ✅ “2024年Q3营收是多少？”

但对全局性、多跳、跨文档的问题就抓瞎：

• ❌ “过去一年里，导致项目延期的根本原因有哪些共性？”（散落在几十份复盘报告中）
• ❌ “张三和李四不在同一部门，但他们之间有什么业务关联？”（需要从组织架构、协作记录、邮件多文档推理）
• ❌ “公司技术栈的演进趋势是什么？”（综合多年技术选型文档）

为什么？ 这些问题的答案散落在文档库各个角落，不是某一两个文本块能覆盖的。向量检索只给"局部最优"——找到几个看起来相关的片段，但没法把散落各处的信息串联起来。

一句话：传统RAG是"只见树木，不见森林"。

---

2. GraphRAG的核心思想

2.1 解法：先画一张知识地图

GraphRAG的解法非常直觉——在检索之前，先用LLM把整个文档集合建成知识图谱，然后在图上做检索。

整个流程分两个大阶段：

索引阶段（一次性，成本高）:
  文档 → 实体关系提取 → 构图 → 社区检测 → 社区摘要

查询阶段（每次查询）:
  问题 → 选择查询模式 → 图遍历/社区摘要 → LLM生成

2.2 索引阶段：从文本到知识图谱

Step 1：文本切块（Text Chunking）

跟传统RAG一样先切块，但目的不是做向量检索，而是喂给LLM做信息提取。

Step 2：实体和关系提取（核心）⭐

对每个文本块，调用LLM提取实体（人/地点/事件/组织）和关系（谁跟谁有什么关系）。

举例，会议纪要片段：

"2024年Q3复盘会上，CTO王刚指出：搜索团队使用的Elasticsearch 7.x集群频繁OOM，
建议迁移到自研的KSearch引擎。搜索负责人林涛表示团队正在与基础架构组合作评估方案。"

GraphRAG提取出：

实体：

• 王刚（人物/CTO）
• 林涛（人物/搜索负责人）
• 搜索团队（组织）
• 基础架构组（组织）
• Elasticsearch 7.x（技术组件）
• KSearch引擎（技术组件）
• 2024年Q3复盘会（事件）

关系：

• 王刚 → 建议迁移 → KSearch引擎
• 搜索团队 → 使用 → Elasticsearch 7.x
• 林涛 → 负责 → 搜索团队
• 搜索团队 → 合作 → 基础架构组
• Elasticsearch 7.x → 存在问题 → 频繁OOM

这些零散的事实被结构化之后，就能"连点成线"。

Step 3：构建知识图谱

把所有文本块中提取的实体和关系汇总，去重、合并，构建完整知识图谱。同名实体在不同上下文中的描述会被合并为一个节点。

Step 4：社区检测与分层（Leiden算法）⭐

💡 Leiden算法：图聚类算法，2019年提出，是Louvain算法的改进版。能在大规模图上高效检测出"紧密关联的节点群"（社区）。GraphRAG用它把知识图谱按主题分层。

顶层社区（粗粒度）:
  "公司技术架构演进" 
    ├── 中层社区: "搜索技术栈"
    │     ├── 底层社区: "KSearch引擎评估细节"
    │     └── 底层社区: "Elasticsearch迁移方案"
    └── 中层社区: "数据库架构"
          └── ...

Step 5：生成社区摘要

对每个社区，调用LLM生成结构化摘要，描述：

• 这个社区的核心内容
• 关键实体
• 主要关系

最终产物：一张分层的、带摘要的知识图谱——相当于给文档画了一张从宏观到微观的知识地图。

2.3 查询阶段：三种模式

模式	适用场景	工作原理	举例
Global Search	全局性、概括性问题	遍历所有社区摘要，LLM综合生成	“过去一年技术决策的方向？”
Local Search	具体实体相关问题	定位实体，结合关系和上下文	“KSearch引擎进展和负责人？”
Drift Search	多跳推理	从起点实体出发，沿图谱关系链探索	“Elasticsearch OOM最终影响哪些业务？”

回到开头那个问题——“研发和产品团队的主要分歧”——用Global Search遍历所有社区摘要就能回答。它不需要找某一段恰好提到"分歧"的文本，而是从知识图谱的全局结构中总结出跨越多个文档的答案。

---

3. GraphRAG vs 传统RAG对比

维度	传统RAG	GraphRAG
索引结构	向量数据库（扁平的chunk集合）	知识图谱（分层的实体关系网络）
检索方式	向量相似度匹配	图遍历 + 社区摘要
全局问题	❌ 很弱，只能找局部片段	✅ 通过社区摘要覆盖全局
实体关系	❌ 无法显式建模	✅ 实体和关系是一等公民
多跳推理	❌ 基本不支持	✅ 通过图遍历天然支持
索引成本	低（仅Embedding计算）	高（大量LLM调用）
查询延迟	低	中（多次图查询）
适用规模	任意规模	中等规模（大数据集成本高）
增量更新	容易	困难（需重建图）

核心差异一句话：传统RAG是"搜文本片段"，GraphRAG是"搜知识结构"。

打个比方：你要了解一家公司——

• 传统RAG像在文件柜里翻找，能找到几份相关文件
• GraphRAG像有一个熟悉公司全貌的老员工，他脑子里有一张完整的"人物关系+事件脉络"地图

---

4. GraphRAG实现项目对比 ⭐ 2026

微软GraphRAG点燃了方向，但社区并没有止步于此。围绕"用图做RAG"这个核心思想，已经衍生出一批各有侧重的实现项目。

4.1 微软 GraphRAG — 开山之作

维度	详情
GitHub	microsoft/graphrag
论文	From Local to Global: A Graph RAG Approach to Query-Focused Summarization
发布	2024.04论文，2024.07开源
Stars	31K+

优点：概念完整、效果强悍，尤其全局性问题甩传统RAG几条街。

缺点：

• 索引阶段LLM调用成本高
• 不支持增量更新
• 大数据集跑起来费时费钱

后续版本已将token成本降低约77%。

4.2 LightRAG — 轻量进化版（HKUDS，29.3K Stars）⭐

💡 LightRAG：香港大学2024年开源，“GraphRAG的轻量进化版”，EMNLP 2025论文。针对微软原版几个痛点做了工程优化。

改进	说明
双层检索	低层做具体实体检索，高层做抽象概念检索
增量更新 ⭐	支持新数据实时接入，不用每次全量重建索引
成本更低	索引阶段LLM调用大幅减少
多模态	通过RAG-Anything集成，支持文本/图像/表格

何时选：觉得微软GraphRAG太重太贵——LightRAG是目前最成熟的替代方案。

4.3 nano-graphrag — 极简实现，学习首选

维度	详情
GitHub	gusye1234/nano-graphrag
特点	代码量极小，把GraphRAG核心逻辑浓缩到最精简

适合想快速理解GraphRAG内部原理的开发者，也是LightRAG的代码基础。

4.4 Fast-GraphRAG — 可解释+可适应（Circlemind AI，3.7K）

创新	说明
PageRank探索	利用PageRank算法做图探索，提升检索准确性
可解释性	提供人类可浏览的知识图谱视图
动态适应	智能适应你的用例、数据和查询

何时选：需要可视化调试图结构的场景。

4.5 Youtu-GraphRAG — 腾讯优图工业级（ICLR 2026）

维度	详情
GitHub	TencentCloudADP/youtu-graphrag
论文	ICLR 2026

提出**“垂直统一代理”（Vertically Unified Agents）**的GraphRAG架构，专注复杂推理场景。

说明GraphRAG的思路已从微软扩展到整个工业界，各大厂都在跟进改进。

4.6 选型决策

你的场景...
├── 入门学习/原理理解 → nano-graphrag
├── 生产部署 + 增量更新 → LightRAG ⭐
├── 大规模工业场景 → Microsoft GraphRAG / Youtu-GraphRAG
├── 需要可视化调试 → Fast-GraphRAG
└── 不想自建 → Kotaemon（集成三种GraphRAG的对话工具）

---

5. GraphRAG实战：用LightRAG跑一个最小Demo

import os
from lightrag import LightRAG, QueryParam
from lightrag.llm.openai import openai_complete_if_cache, openai_embed

# 配置（用Claude Opus 4.7做提取，BGE-M3做嵌入）
async def llm_func(prompt, **kwargs):
    return await openai_complete_if_cache(
        "claude-opus-4.7",
        prompt,
        api_key=os.getenv("ANTHROPIC_API_KEY"),
        **kwargs
    )

async def embed_func(texts):
    return await openai_embed(
        texts,
        model="BAAI/bge-m3",
    )

# 初始化LightRAG
rag = LightRAG(
    working_dir="./graphrag_workspace",
    llm_model_func=llm_func,
    embedding_func=embed_func,
)

# 索引文档
with open("company_meeting_notes.txt") as f:
    rag.insert(f.read())

# 三种查询模式
# 1. Global - 全局性问题
result = rag.query(
    "过去一年公司技术决策的主要方向？",
    param=QueryParam(mode="global")
)

# 2. Local - 具体实体
result = rag.query(
    "KSearch引擎目前的进展？",
    param=QueryParam(mode="local")
)

# 3. Hybrid - 混合模式（LightRAG新增）
result = rag.query(
    "Elasticsearch OOM问题影响了哪些业务？",
    param=QueryParam(mode="hybrid")
)

---

6. GraphRAG的应用项目

GraphRAG的价值不只是"更好地回答问题"。当知识图谱成为系统的核心数据结构，应用边界远超传统RAG。

6.1 MiroFish：群体智能预测引擎（20.3K Stars）

中科大00后开发者BaiFu主导，10天完成核心开发，盛大3000万投资。

定位：“简洁通用的群体智能引擎，预测万物”——给一条种子信息（突发新闻、政策、金融信号、小说剧情），自动构建高保真平行数字世界，让成千上万智能体在其中自由交互、社会演化。

GraphRAG在MiroFish中的角色：第一步图谱构建——把输入文本（如《红楼梦》前80回）转化为结构化知识图谱，注入每个智能体的记忆中。

6.2 Kotaemon：文档对话工具（25.2K Stars）

集成三种GraphRAG实现：Nano GraphRAG / LightRAG / Microsoft GraphRAG，用户根据需求选择。

核心特性：

• 混合索引（向量+图）
• 多GraphRAG后端
• 多模态问答（PDF/图表/图片）
• 内置ReAct和ReWOO推理

Kotaemon的做法很聪明——不强制选择传统RAG还是GraphRAG，两种都提供，让系统根据问题类型自动选择最合适的检索方式。

6.3 Medical-Graph-RAG：医疗领域（ACL 2025）

医疗天然就是实体关系密集的场景——患者同时患糖尿病和高血压时，需要找"哪些降压药与二甲双胍有相互作用"——这就需要从药物/疾病/症状/治疗方案的复杂关系网中推理。

---

7. GraphRAG的工程注意事项 ⚠️

7.1 成本警告

GraphRAG的索引阶段需要大量LLM调用来提取实体和关系。微软官方提醒：

“先用小数据集和低成本模型试水，别上来就索引几百万条文档。”

成本估算（用GPT-5.5）：

• 1000页文档（约150万Token）
• 实体关系提取需要约300万Token输出
• 成本：约$100-200

省钱技巧：

1. 用便宜模型做提取（DeepSeek V4-Pro / GLM-5.1）
2. 限制提取的实体类型
3. 用LightRAG的增量更新替代全量重建

7.2 何时不该用GraphRAG

场景	推荐
文档量<100页	传统RAG
都是FAQ式问答	传统RAG
实时性要求高	传统RAG（GraphRAG索引慢）
数据频繁更新	LightRAG（支持增量）
跨文档全局推理	GraphRAG ✅
多跳关系问答	GraphRAG ✅

---

8. 面试高频问题

Q1：GraphRAG和传统RAG的本质区别？

传统RAG是"搜文本片段"——用向量相似度找Top-K相似块。GraphRAG是"搜知识结构"——把文档转成实体+关系图谱，用图遍历+社区摘要。前者解决局部问题，后者解决全局问题。

Q2：GraphRAG为什么用Leiden算法？

Leiden是图聚类算法（Louvain改进版），能在大规模图上高效检测"紧密关联的节点群"（社区）。GraphRAG用它把知识图谱按主题分层（顶层/中层/底层社区），实现从粗粒度到细粒度的知识地图。

Q3：GraphRAG的索引成本为什么这么高？

每个文本块都要调用LLM提取实体和关系——1000页文档可能要跑数百万Token的LLM输出。后续还要做实体合并、社区检测、社区摘要生成。整个索引流程的LLM调用是传统RAG的5-10倍。

Q4：什么时候必须用GraphRAG？

(1) 全局性问题（“过去一年趋势”）；(2) 多跳推理（A→C→B关联）；(3) 跨文档综合分析。这些问题用向量相似度匹配会"只见树木不见森林"。但小数据集（<100页）或FAQ场景没必要用GraphRAG。

Q5：LightRAG比微软GraphRAG强在哪？

(1) 双层检索：低层实体+高层概念，更灵活；(2) 增量更新：新数据实时接入，不用全量重建（这是微软GraphRAG最大痛点）；(3) 成本更低：索引LLM调用大幅减少；(4) 多模态：支持文本/图像/表格。LightRAG是2026年生产部署的首选。

Q6：Global Search和Local Search的区别？

• Global Search：遍历所有社区摘要，回答"全局性概括"问题（如"过去一年技术决策方向"）
• Local Search：从具体实体出发，结合关系和上下文回答（如"KSearch引擎的进展"）
• Drift Search：多跳推理，沿关系链探索（如"Elasticsearch问题影响了哪些业务"）

---

总结

维度	要点
核心思想	文档→知识图谱→社区检测→分层摘要
索引阶段	切块→提取实体关系→构图→Leiden社区检测→生成摘要
查询阶段	Global/Local/Drift三种模式
vs 传统RAG	搜知识结构 vs 搜文本片段
优势	全局问题、多跳推理、跨文档综合
代价	索引成本高、增量更新难
2026主流	Microsoft GraphRAG / LightRAG ⭐ / nano-graphrag / Fast-GraphRAG / Youtu-GraphRAG
何时不用	小数据集、FAQ场景、实时性要求高

GraphRAG不是替代传统RAG，是补强——补传统RAG"看不到全局"这个短板。最佳实践是混合架构：简单问题走传统RAG，复杂全局问题走GraphRAG。Kotaemon的混合模式就是这个思路的产品化。

2026年的趋势是**“按问题类型自动路由到合适的检索方式”**——这才是真正的"智能RAG"。

---

路易乔布斯 © 2026 | AI Agent & RAG学习计划 · 模块02-RAG · 第二篇

参考文献：

• Edge et al., “From Local to Global: A Graph RAG Approach to Query-Focused Summarization”, Microsoft 2024
• Guo et al., “LightRAG: Simple and Fast Retrieval-Augmented Generation”, EMNLP 2025
• “Youtu-GraphRAG: Vertically Unified Agents for Graph RAG”, ICLR 2026
• Microsoft GraphRAG GitHub: https://github.com/microsoft/graphrag
• LightRAG GitHub: https://github.com/HKUDS/LightRAG