“把公司过去三年的所有周报、文档丢进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对比维度传统RAGGraphRAG索引结构向量数据库扁平的chunk集合知识图谱分层的实体关系网络检索方式向量相似度匹配图遍历 社区摘要全局问题❌ 很弱只能找局部片段✅ 通过社区摘要覆盖全局实体关系❌ 无法显式建模✅ 实体和关系是一等公民多跳推理❌ 基本不支持✅ 通过图遍历天然支持索引成本低仅Embedding计算高大量LLM调用查询延迟低中多次图查询适用规模任意规模中等规模大数据集成本高增量更新容易困难需重建图核心差异一句话传统RAG是搜文本片段GraphRAG是搜知识结构。打个比方你要了解一家公司——传统RAG像在文件柜里翻找能找到几份相关文件GraphRAG像有一个熟悉公司全貌的老员工他脑子里有一张完整的人物关系事件脉络地图4. GraphRAG实现项目对比 ⭐ 2026微软GraphRAG点燃了方向但社区并没有止步于此。围绕用图做RAG这个核心思想已经衍生出一批各有侧重的实现项目。4.1 微软 GraphRAG — 开山之作维度详情GitHubmicrosoft/graphrag论文From Local to Global: A Graph RAG Approach to Query-Focused Summarization发布2024.04论文2024.07开源Stars31K优点概念完整、效果强悍尤其全局性问题甩传统RAG几条街。缺点索引阶段LLM调用成本高不支持增量更新大数据集跑起来费时费钱后续版本已将token成本降低约77%。4.2 LightRAG — 轻量进化版HKUDS29.3K Stars⭐LightRAG香港大学2024年开源“GraphRAG的轻量进化版”EMNLP 2025论文。针对微软原版几个痛点做了工程优化。改进说明双层检索低层做具体实体检索高层做抽象概念检索增量更新⭐支持新数据实时接入不用每次全量重建索引成本更低索引阶段LLM调用大幅减少多模态通过RAG-Anything集成支持文本/图像/表格何时选觉得微软GraphRAG太重太贵——LightRAG是目前最成熟的替代方案。4.3 nano-graphrag — 极简实现学习首选维度详情GitHubgusye1234/nano-graphrag特点代码量极小把GraphRAG核心逻辑浓缩到最精简适合想快速理解GraphRAG内部原理的开发者也是LightRAG的代码基础。4.4 Fast-GraphRAG — 可解释可适应Circlemind AI3.7K创新说明PageRank探索利用PageRank算法做图探索提升检索准确性可解释性提供人类可浏览的知识图谱视图动态适应智能适应你的用例、数据和查询何时选需要可视化调试图结构的场景。4.5 Youtu-GraphRAG — 腾讯优图工业级ICLR 2026维度详情GitHubTencentCloudADP/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跑一个最小DemoimportosfromlightragimportLightRAG,QueryParamfromlightrag.llm.openaiimportopenai_complete_if_cache,openai_embed# 配置用Claude Opus 4.7做提取BGE-M3做嵌入asyncdefllm_func(prompt,**kwargs):returnawaitopenai_complete_if_cache(claude-opus-4.7,prompt,api_keyos.getenv(ANTHROPIC_API_KEY),**kwargs)asyncdefembed_func(texts):returnawaitopenai_embed(texts,modelBAAI/bge-m3,)# 初始化LightRAGragLightRAG(working_dir./graphrag_workspace,llm_model_funcllm_func,embedding_funcembed_func,)# 索引文档withopen(company_meeting_notes.txt)asf:rag.insert(f.read())# 三种查询模式# 1. Global - 全局性问题resultrag.query(过去一年公司技术决策的主要方向,paramQueryParam(modeglobal))# 2. Local - 具体实体resultrag.query(KSearch引擎目前的进展,paramQueryParam(modelocal))# 3. Hybrid - 混合模式LightRAG新增resultrag.query(Elasticsearch OOM问题影响了哪些业务,paramQueryParam(modehybrid))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.51000页文档约150万Token实体关系提取需要约300万Token输出成本约$100-200省钱技巧用便宜模型做提取DeepSeek V4-Pro / GLM-5.1限制提取的实体类型用LightRAG的增量更新替代全量重建7.2 何时不该用GraphRAG场景推荐文档量100页传统RAG都是FAQ式问答传统RAG实时性要求高传统RAGGraphRAG索引慢数据频繁更新LightRAG支持增量跨文档全局推理GraphRAG ✅多跳关系问答GraphRAG ✅8. 面试高频问题Q1GraphRAG和传统RAG的本质区别传统RAG是搜文本片段——用向量相似度找Top-K相似块。GraphRAG是搜知识结构——把文档转成实体关系图谱用图遍历社区摘要。前者解决局部问题后者解决全局问题。Q2GraphRAG为什么用Leiden算法Leiden是图聚类算法Louvain改进版能在大规模图上高效检测紧密关联的节点群社区。GraphRAG用它把知识图谱按主题分层顶层/中层/底层社区实现从粗粒度到细粒度的知识地图。Q3GraphRAG的索引成本为什么这么高每个文本块都要调用LLM提取实体和关系——1000页文档可能要跑数百万Token的LLM输出。后续还要做实体合并、社区检测、社区摘要生成。整个索引流程的LLM调用是传统RAG的5-10倍。Q4什么时候必须用GraphRAG(1) 全局性问题“过去一年趋势”(2) 多跳推理A→C→B关联(3) 跨文档综合分析。这些问题用向量相似度匹配会只见树木不见森林。但小数据集100页或FAQ场景没必要用GraphRAG。Q5LightRAG比微软GraphRAG强在哪(1)双层检索低层实体高层概念更灵活(2)增量更新新数据实时接入不用全量重建这是微软GraphRAG最大痛点(3)成本更低索引LLM调用大幅减少(4)多模态支持文本/图像/表格。LightRAG是2026年生产部署的首选。Q6Global 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 2024Guo et al., “LightRAG: Simple and Fast Retrieval-Augmented Generation”, EMNLP 2025“Youtu-GraphRAG: Vertically Unified Agents for Graph RAG”, ICLR 2026Microsoft GraphRAG GitHub: https://github.com/microsoft/graphragLightRAG GitHub: https://github.com/HKUDS/LightRAG