GraphRAG——从“文档检索”到“知识网络”

AI KNOWLEDGE SYSTEMS · 2026

GraphRAG

从“文档检索”到“知识网络”

为什么下一代企业知识库开始理解实体、关系、主题与全局结构

RAG 升级路线

知识图谱 × LLM

企业知识库 / LLM Wiki

READING GUIDE

先用一分钟认识 GraphRAG

如果把普通 RAG 比作“在一堆资料中找到和问题最相似的几段文字”，那么 GraphRAG 更像是在资料之上先画出一张知识地图：谁与谁有关、哪个项目依赖哪项技术、哪些事件属于同一主题、整个资料库中有哪些重要社区。查询时，系统既能搜索原文，也能沿着关系和主题结构寻找证据。

一句话定义GraphRAG 是一类利用图结构增强检索增强生成（RAG）的技术。以 Microsoft GraphRAG 为代表的实现，会从非结构化文本中抽取实体、关系与声明，构建知识图谱，再进行社区发现与分层摘要，用这些结构帮助大模型回答局部事实问题和跨全库的全局问题。

这并不意味着 GraphRAG 会取代向量检索。恰恰相反，成熟的 GraphRAG 通常仍保留文本切片、Embedding 和向量搜索；图结构负责补上“关系、路径、主题与聚合”这一层能力。因此，它更像是对传统 RAG 的扩展，而不是一次彻底重写。

CONTENTS

01为什么普通 RAG 会遇到瓶颈

02GraphRAG 到底是什么

03知识是怎样从文档“长成图”的

04Community：让图谱拥有主题层级

05查询：Local、Global 与 DRIFT

06GraphRAG 与普通 RAG 的能力边界

07企业落地：何时值得用，何时不值得

08从 GraphRAG 到 LLM Wiki

09未来趋势与结语

01为什么普通 RAG 会遇到瓶颈

从“相似度”到“关系性”的缺口

传统 RAG 的经典流程并不复杂：把文档切成若干 Chunk，将每个 Chunk 转成向量；用户提问时，也把问题向量化，再找出语义最相似的若干段文本，交给大模型生成答案。这种方法非常适合“答案就在某一段话里”的问题。

图 1普通 RAG 与 GraphRAG 的核心差异（示意）

但“语义相似”与“逻辑相关”不是同一件事。假设四份不同文件分别写着：王伟负责星河项目；星河项目使用 Aurora 2.0；Aurora 由基础平台部维护；基础平台部负责人是李明。用户问“王伟负责的项目所用引擎由哪个团队维护”，答案需要跨越多份文档、沿着多条关系完成组合。单纯 Top-K 相似度搜索有可能只召回其中一两段，缺少完整链路。

另一个难点是“全局问题”。例如：“过去两年公司技术架构的主要变化是什么？”“这 5 万份材料反映出哪些核心主题？”这类问题不是寻找某个明确事实，而是对整个语料库做聚合和概括。Microsoft GraphRAG 官方文档明确指出，基线 RAG 对这类需要跨整个数据集聚合信息的问题较弱，因为查询本身并不会告诉向量检索应该召回哪些具体片段。[1][2]

核心矛盾传统 RAG 擅长“找段落”；复杂知识问答常常需要“找关系、找路径、找主题、做聚合”。GraphRAG 就是在这个缺口上增加一层结构化知识索引。

02GraphRAG 到底是什么

它不是“RAG + 图数据库”这么简单

“GraphRAG”现在已经成为一个较宽泛的技术类别：只要检索或上下文组织显著利用了图结构，都可能被称为 GraphRAG。本文主要以 Microsoft 开源 GraphRAG 的经典思路为主线，因为它把“实体图谱 + 社区层级 + 全局摘要”这一范式讲得最完整。

Microsoft GraphRAG 的标准索引流程会从原始文本中抽取实体、关系与 claims（可理解为与实体相关、可能带时间属性的声明），对实体图进行社区发现，并生成不同粒度的社区摘要；同时，它仍然会把文本和部分结构化描述嵌入向量空间。[1][3]

· 实体（Entity）：人物、组织、项目、产品、技术、地点、事件等“节点”。

· 关系（Relationship）：实体之间的“边”，例如“负责”“使用”“依赖”“属于”“维护”。

· 声明（Claim / Covariate）：关于实体的陈述，常用于表达状态、事件、风险或带时间约束的事实。

· 社区（Community）：图中联系紧密的一组实体；可以形成由粗到细的主题层级。

· 社区报告（Community Report）：LLM 对某个社区进行概括后得到的结构化摘要，供人阅读或查询使用。

· TextUnit：原始文档切分后的文本单元，图中的知识仍可回溯到它们。

一个重要纠偏GraphRAG 并没有取消 Chunk。Microsoft 的默认数据流首先把文档组成 TextUnit，然后从 TextUnit 中抽取图结构；TextUnit 还承担来源追溯与原文证据的作用。[3]

03知识是怎样从文档“长成图”的

GraphRAG 的索引过程

图 2GraphRAG 典型索引流水线（基于 Microsoft GraphRAG 数据流概念整理）

第一步仍然是资料接入与切分。PDF、Word、网页、数据库记录或会议纪要会先被转换为可处理的文本，再按一定窗口切成 TextUnit。不同实现的输入格式和解析组件会不同，但“保留来源”和“合理切分”仍然是底层质量的基础。

第二步是实体与关系抽取。LLM 会读每个 TextUnit，把自然语言转成更稳定的结构：实体名称、实体类型、实体描述、关系的起点与终点、关系说明等。原本散落在句子里的“谁负责什么”“哪个系统依赖什么”“哪个事件发生于何时”，开始变成可以被程序遍历的节点与边。

图 3文本事实转化为知识图谱后的关系链示意

第三步往往是最容易被低估的工程环节：实体融合与关系归一。现实文档中，同一个对象可能有多个名字，例如“OpenAI”“Open AI”“OpenAI 公司”；内部项目也可能同时存在项目代号、中文名和英文名。如果不做实体解析（Entity Resolution），图会出现大量重复节点，关系被割裂。

因此，生产系统通常需要把“抽取”与“治理”分开：抽取负责尽可能找到候选知识，治理负责去重、消歧、统一关系类型、标记置信度、保留来源，并处理知识的版本和时间有效性。图谱质量决定了后续检索到底是在“连点成线”，还是在“沿着错误的线越走越远”。

04Community：让图谱拥有主题层级

从百万节点到可理解的知识主题

即使图谱构建正确，几万甚至几百万个节点仍然无法直接进入大模型上下文。GraphRAG 的关键设计之一，是利用图算法识别“联系更紧密的一组节点”，也就是社区（Community），并形成层级化聚类。高层社区代表宏观主题，低层社区则更接近具体项目、技术或事件。

可以把它想象成一个自动生成的企业知识目录：最高层也许是“产品、技术、市场、组织”；技术社区下面又分为“AI 平台、数据基础设施、搜索、推荐”；搜索社区再向下展开为“检索引擎、Embedding 服务、Reranker、维护团队和相关项目”。

为什么 Community 很重要？因为全局问题往往不需要读取所有原文，而需要先读取“全库中有哪些重要主题，以及每个主题大致说了什么”。社区报告就是把大规模图谱压缩成可被 LLM 消化的中间层。

Microsoft GraphRAG 的默认数据模型中，Community 是对实体—关系图进行层次化社区发现得到的聚类；Community Report 则是对每个社区内容生成的报告，可用于人类阅读和下游检索。[3] 这使知识库不仅“存了什么”可见，“知识如何聚集成主题”也变得可计算。

05查询：Local、Global 与 DRIFT

不同问题，需要不同的知识视野

图 4Local、Global 与 DRIFT 三种检索视角

Local Search 适合围绕具体实体的问题，例如“某项目负责人是谁”“Aurora 依赖哪些系统”“客户 A 与哪些项目有关”。它会把与实体相关的图数据和原始 TextUnit 一起组织成上下文，因此回答不仅有关系，也能回到原文证据。Microsoft 官方将 Local Search 描述为“将 AI 抽取的知识图数据与原始文档文本块结合起来生成回答”。[4]

Global Search 面向另一类问题：当用户问“整个数据集中最重要的主题是什么”“过去一年主要风险集中在哪里”时，系统会利用多个 Community Report，以类似 Map-Reduce 的方式分别生成中间答案、排序过滤，再汇总成最终答案。它的优势是能把“整库理解”变成一个可扩展的过程，代价是计算成本通常更高。[2][5]

DRIFT Search 可以理解为一种介于两者之间的探索方式。它在局部搜索时引入社区信息，用较高层的主题洞察扩展问题起点，再逐步生成更具体的后续问题，扩大事实覆盖面。官方文档把它描述为“用社区信息扩展局部查询的起始范围，并通过细化问题获得更丰富事实”。[5]

没有一种检索方式永远最好“谁负责 X？”与“这一年组织发生了什么？”本质上是两种问题。真正好用的系统应先判断问题类型，再选择向量、关键词、局部图遍历、社区摘要或它们的混合策略。

06GraphRAG 与普通 RAG 的能力边界

强项不同，不是简单的“新技术淘汰旧技术”

比较维度	普通向量 RAG	GraphRAG / 混合图检索
核心索引单位	文本 Chunk	Chunk + 实体 + 关系 + 社区 / 摘要
最擅长的问题	答案位于少量相关段落	跨文档关系、多跳问题、全局主题
检索依据	语义相似度为主	语义 + 图结构 + 社区结构
上下文组织	Top-K 文本拼接	图邻域、路径、社区报告与原文混合
建设成本	较低，链路成熟	较高，需要抽取、实体治理和图质量控制
更新复杂度	新增 / 重嵌入 Chunk	还需增量更新图、社区与摘要
可解释性	可给原文引用	可额外展示实体关系和路径
典型风险	召回不全、Top-K 噪声	错误抽取、错误合并、图谱陈旧、成本偏高

最现实的落地路径通常是 Hybrid RAG：保留向量检索和关键词检索，把图检索作为“复杂关系与全局理解”的增强器。原因很简单：很多企业问答仍然是“帮我找到那一段规定”，这时向量或关键词方案更便宜、更直接；只有在关系网络、多源证据或整库归纳真正重要时，图结构的投入才会体现价值。

07企业落地：何时值得用，何时不值得

先看问题结构，再看技术时髦程度

更值得使用 GraphRAG 的场景

（1）知识天然具有强关系网络：研发架构、供应链、客户—项目—合同、组织职责、科研文献、设备与故障等。

（2）关键答案散落在多份材料里，需要跨文档、多跳关系才能拼出完整结论。

（3）用户经常问“整体有哪些主题、趋势、风险、变化”这类全局问题。

（4）希望把知识库从“搜索框”升级为可浏览、可探索的知识地图或自动 Wiki。

（5）需要更强的解释性：不仅给答案和原文，还能展示关键实体、关系路径与来源。

不一定值得使用 GraphRAG 的场景

（1）语料规模小、问题简单，大多数答案都能在一个段落中直接找到。

（2）知识关系变化极快，却没有成熟的增量索引、版本管理和图更新机制。

（3）实体边界极不稳定，或者抽取错误的业务代价很高，但又缺乏人工校验流程。

（4）成本敏感、延迟敏感，而普通 Hybrid RAG 已经满足准确率目标。

（5）团队只是想“上一个图数据库”，却没有明确要解决的关系型问题。

落地判断公式GraphRAG 的价值 ≈ 关系复杂度 × 跨文档推理需求 × 全局归纳需求；它的成本 ≈ 索引 LLM 调用 + 图谱治理 + 增量更新 + 查询复杂度。只有前者明显大于后者，才值得大规模投入。

08从 GraphRAG 到 LLM Wiki

当知识图谱开始自动“长成”页面

GraphRAG 解决的是“如何结构化地组织与检索知识”；LLM Wiki 则进一步把这些结构转换成面向人的知识页面。两者结合后，一个企业知识库可以从原始文件中自动识别核心实体和主题，为项目、技术、团队、客户生成 Wiki 页面，并自动维护“相关项目、负责人、依赖系统、关键事件、引用来源”等模块。

例如，当系统识别到“Aurora 2.0”是一个高频技术实体，它可以沿图收集其维护团队、使用项目、版本事件、依赖组件和相关会议，再由 LLM 生成“简介、技术架构、使用项目、历史变更、相关团队、来源文档”等页面章节。这个页面不是一篇脱离证据的生成文本，而应该保留每个结论到原始 TextUnit 的追溯关系。

从知识库到“组织记忆”传统知识库管理的是文件；普通 RAG 管理的是可检索的文本块；GraphRAG 开始管理实体、关系、事件与主题；LLM Wiki 则把这些结构重新呈现给人。最终目标不是让 AI “知道更多”，而是让组织的知识更容易被发现、连接、验证和持续更新。

09未来趋势与结语

GraphRAG 的终点不是一张更大的图

GraphRAG 仍是一条快速演化的技术路线。随着系统规模增大，大家会越来越关注四件事：图的构建是否足够便宜；实体与关系是否可靠；增量更新是否及时；查询时能否根据问题动态选择最合适的检索策略。Microsoft GraphRAG 目前已经把 Local、Global、DRIFT 和基础向量搜索放在同一个 Query Engine 中，这本身就说明未来更可能是“多路检索协同”，而不是单一路线统治所有问题。[5]

对企业而言，最值得关注的变化不是“图数据库重新火了”，而是非结构化资料正在被转换成机器可计算的组织结构。过去，AI 只能从文件中找句子；现在，它开始知道句子背后有哪些对象、对象之间有什么关系、哪些关系组成主题、一个主题如何与另一个主题相连。

如果把普通 RAG 看成“给大模型装上一个搜索引擎”，那么 GraphRAG 更像是给它配上一张知识地图。搜索引擎告诉它“可能在哪”，知识地图则帮助它理解“这些事情为什么连在一起”。而真正成熟的下一代知识系统，大概率会把搜索、向量、图谱、时间、权限、来源与 Agent 能力一起组合起来。

结论GraphRAG 最有价值的地方，不是让模型多记住几条知识，而是把企业资料从“文档集合”变成“可查询、可遍历、可总结、可追溯的知识网络”。

APPENDIX

术语速查

RAGRetrieval-Augmented Generation，检索增强生成。先从外部知识源检索，再让 LLM 基于检索结果回答。

Chunk / TextUnit文档切分后的文本单元。GraphRAG 仍以文本单元作为抽取、证据追溯和部分检索的基础。

Entity实体，例如人物、组织、项目、技术、事件。

Relationship实体之间的关系，如“负责”“使用”“依赖”“属于”。

Knowledge Graph由实体节点和关系边组成的结构化知识网络。

Entity Resolution实体解析 / 消歧 / 融合：判断多个名称是否指向同一个真实对象。

Community图中连接密集的一组实体，常被用于发现主题结构。

Community ReportLLM 对某一知识社区生成的摘要或报告。

Local Search围绕特定实体组织图数据与原文证据的局部查询。

Global Search对多个社区报告进行分批处理与汇总，回答整库级问题。

DRIFT Search引入社区信息扩展局部查询，并生成更细化的问题来深入探索。

参考资料

[1] Microsoft GraphRAG Documentation — Indexing Overview

https://microsoft.github.io/graphrag/index/overview/

[2] Microsoft GraphRAG Documentation — Global Search

https://microsoft.github.io/graphrag/query/global_search/

[3] Microsoft GraphRAG Documentation — Indexing Dataflow

https://microsoft.github.io/graphrag/index/default_dataflow/

[4] Microsoft GraphRAG Documentation — Local Search

https://microsoft.github.io/graphrag/examples_notebooks/local_search/

[5] Microsoft GraphRAG Documentation — Query Engine Overview

https://microsoft.github.io/graphrag/query/overview/

[6] Edge, D. et al. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130 (2024).

https://arxiv.org/abs/2404.16130

[7] Microsoft Research — GraphRAG: New tool for complex data discovery now on GitHub

https://www.microsoft.com/en-us/research/blog/graphrag-new-tool-for-complex-data-discovery-now-on-github/