GraphRAG · 产品调研
GraphRAG 到底改变了什么？
从图数据库到生成式 AI，一次关于产品价值的研究。
GraphRAG 将图结构与检索增强生成（RAG）结合，让 AI 能够利用实体之间的关联信息回答问题。
它不是 Graph Database 的升级版本，也不意味着比普通 RAG 更先进。
真正值得关注的是：当信息之间的关系变得复杂，GraphRAG 能否帮助人们更有效地理解、利用和发现信息？
这篇文章从技术定位出发，通过几个不同成熟度的应用案例，研究 GraphRAG 的产品价值与边界。具体实现与效果评测，将留到后续的技术实践中讨论。
01｜GraphRAG 的技术定位
数据库、搜索引擎、RAG、GraphRAG 都可以帮助人们获取信息，但擅长处理的问题并不相同。
如果需要查询某个账户的余额，关系数据库就很合适。
如果要查找包含特定内容的文件，可以使用全文搜索。
如果需要分析多个账户之间的资金流转，图数据库能够更直接地处理实体之间的关联。
而当用户希望 AI 结合这些关系与相关资料，回答更复杂的问题时，就可以考虑 GraphRAG。
下面通过四条概念工作流，比较 Naive RAG、GraphRAG、Agentic RAG 与 LLM Wiki 如何处理知识。
四种技术如何处理知识？
Naive RAG
检索相关资料，再让 LLM 生成回答。
公司的出差报销规则是什么？
- 用户提问
- 检索相关文档
- LLM 阅读检索结果
- 生成回答
文档检索 · 上下文 · 生成回答
GraphRAG
利用知识之间的关系辅助检索与回答。
A 项目延期会影响哪些客户？
- 用户提问
- 检索相关实体与关系使用知识图结构
- 获取关联资料
- LLM 综合回答
知识结构也可从原始文本构建，
不要求已有图数据库。
知识图谱 · 实体关系 · 关联检索
Agentic RAG
让 Agent 自主决定如何调查。
A 项目为什么延期？
- 用户提问
- Agent 判断下一步
- 调用工具 / 系统
- 证据是否足够？
- 综合回答
证据不足时，返回 Agent 判断下一步，继续检索或调用工具；证据足够时，综合回答。
否是根据中间结果
继续检索 / 调用工具
Agent · 工具调用 · 动态决策 · 迭代检索
LLM Wiki
使用 LLM 提前整理并持续维护可复用知识。
A 项目现在有哪些最新信息？
提前维护
- 原始资料
- LLM 整理与关联
- Wiki / 知识库
持续更新
LLM 持续整理与更新 Wiki；后续提问查询提前维护的知识库，再生成回答。
后续使用
- 用户提问
- 查询 Wiki
- 生成回答
知识整理 · 持续更新 · 知识复用
流程为概念示意，并非唯一实现。Naive RAG 指基础检索→生成流程，不代表所有非 GraphRAG 方法；Agentic RAG 不必使用图；LLM Wiki 并非统一定义的 RAG 架构。
GraphRAG 更偏向利用关联信息完成检索与综合理解，但这并不代表其他技术无法处理同类问题。
这里还有一个容易混淆的概念：Knowledge Graph（知识图谱）。
知识图谱是一种表示实体、属性及其关系的知识组织方式。它可以存储在图数据库中，也可以为其他检索、分析或 AI 系统提供知识基础。
因此，Knowledge Graph、Graph Database 和 GraphRAG 并不是同一层级的技术。
Graph Database 关注关系数据的存储、查询与管理；GraphRAG 则关注如何利用图结构辅助检索与生成。
两者可以组合，也可以分别使用。
02｜GraphRAG 的发展历史
GraphRAG 的形成，与数据管理、信息检索和语言模型三条技术路线的发展有关。
数据与图技术
关系数据库让企业能够管理和查询大量结构化数据。
随着社交网络、金融交易、企业股权等场景的发展，实体之间的关系本身逐渐成为重要的分析对象。
图数据库为这类关系的存储、遍历与分析提供了更直接的模型。
知识图谱则进一步强调如何组织和表达实体、概念及其语义关系。
信息检索技术
全文搜索让人们能够从大量文档中找到相关信息。
语义检索进一步利用文本的语义表示，不再完全依赖关键词匹配。
这些技术持续改善着一个问题：如何从越来越多的信息中，找到当前任务需要的内容。
语言模型与 RAG
语言模型的发展，让系统逐渐具备更强的自然语言理解和生成能力。
RAG 将外部检索与语言生成结合。
与单纯依赖模型内部知识相比，RAG 可以先从外部资料中获取相关上下文，再据此生成回答。
GraphRAG 则进一步探索：在检索与生成过程中，能否利用图结构更好地组织实体、关系和相关证据？
数据与图1970 · 关系模型里程碑关系模型与图技术
关系模型推动结构化数据的管理与精确查询。图论、网络分析和图查询也有独立的长期发展路线，不是生成式 AI 出现后才获得关系分析能力。
IBM：关系数据库历史 ↗NLP / LLM从统计方法到神经网络语言建模
研究如何根据上下文预测和处理语言。后续模型的生成与摘要能力建立在长期积累上；这条路线没有一个能概括所有方法的单一起点。
Transformer 论文的背景与相关研究 ↗数据与图2012 · Google Knowledge Graph知识的图表示
Google 将 Knowledge Graph 用于搜索产品，是一个公开产品里程碑，不是知识表示或知识图谱的发明日期。知识图谱描述实体及其关系，是知识表示方式。
Google：Introducing the Knowledge Graph ↗NLP / LLM2017 · Attention Is All You NeedTransformer
Transformer 是后续许多语言模型的重要架构基础。它与图数据库不是前后替代关系；生成语言也不等于具备可靠的证据核验能力。
Transformer 原始论文 ↗信息检索2020 · RAG 论文RAG · 检索增强生成基础检索→生成流程常被称为 Naive RAG。
RAG 将检索与生成组合：检索器提供外部资料，生成模型使用这些资料作答。这是重要论文里程碑，不是所有检索增强思想的唯一源头。
Retrieval-Augmented Generation ↗信息检索 + 语言生成：RAG 将这两种能力组合起来。
术语说明：Naive RAG 是基础检索→生成流程的常见称呼，不是 2020 年原始论文的正式名称，也不代表所有非 GraphRAG 的 RAG 方法。 术语参考（综述） ↗
能力组合 · 不是技术继承链
图结构+信息检索+语言生成
不同的 GraphRAG 方法
代表性里程碑 · 2024 Microsoft GraphRAG
Microsoft 的论文与开源项目是其中一种实现，不是三条路线的唯一终点。
这些技术没有简单的替代关系。
普通 RAG 仍然适合大量文档问答场景，图数据库也继续承担关系查询和分析工作。
GraphRAG 的出现，更多意味着一种新的技术组合方式。
03｜GraphRAG 在产品中能做什么？
从产品角度看，GraphRAG 值得研究的潜在价值主要有两个方向。
减少人工工作量。
辅助用户查找关联资料、整理证据和解释复杂信息，减少重复查询与人工汇总。
辅助发现。
帮助用户从大量分散的信息中发现原本没有注意到的关联、共同主题或研究线索。
这两种能力并非 GraphRAG 独有。
下面通过四个不同成熟度的案例，观察相关技术在产品中究竟承担了什么工作。
案例一｜反洗钱：发现异常之后，如何完成调查？
银行需要监测大量交易，识别可能涉及洗钱的异常活动。
单独观察每一笔交易时，一些行为可能并不明显。但把账户、客户与资金流转关系放在同一个网络中，就可能发现值得调查的模式。
例如，一笔资金可能经过多个账户转移，最后又回到相关账户。
图 3 · 完全虚构的账户和交易，用于说明从记录、关系到调查的三个阶段。闭环只是线索，不证明违法。
A · 单独查看交易记录
先看六笔中的三笔；补入其他记录后才能看到完整路径。画图没有创造新的证据。
B · 补齐记录，展开资金关系
点击记录，对照图中的边
尚未选择记录；图中展示全部六笔交易。
C · 沿关系查询客户背景与调查证据
关系查询定位关联账户；检索客户资料与交易记录；AI 整理证据，调查人员核实判断。此处仅示意工作分工，未运行模型或真实检索。
图数据库和图算法已经能够帮助银行分析复杂交易网络。
国际清算银行的 Project Aurora 研究了网络分析、机器学习及跨机构数据协作在反洗钱检测中的应用。这是一项研究性 PoC，而不是 GraphRAG 已经取代传统检测系统的证据。
GraphRAG 更值得考虑的，是发现异常之后的调查工作。
调查人员仍然需要了解关联客户是谁、交易发生在什么时间、是否存在其他可疑记录，以及哪些证据能够支持判断。
这些资料可能分布在不同系统中。
如果 AI 能够结合账户关系、交易记录与客户资料，辅助调查人员检索和整理证据，就可能减少大量重复的信息处理工作。
Neo4j 也公开展示过利用知识图谱与 GraphRAG 构建 KYC 调查 Agent 的方法。不过，该演示使用合成数据，不能直接视为真实银行的应用成果。
这个场景中，图分析负责发现可疑关系，GraphRAG 则可能帮助调查人员理解关系、整理证据。
它并不能仅凭账户之间的关联证明违法行为，也不能代替最终的人工调查判断。
参考资料：
案例二｜公众意见分析：从大量反馈中发现共同问题
有些产品并不是为了寻找一个已经确定的答案，而是希望从大量资料中发现值得关注的问题。
例如，政府可能收到成千上万份关于 AI 政策的公众意见。
其中有人关注就业，有人关注教育，也有人讨论隐私、安全或技术发展。
分析人员不仅希望统计各个话题出现的次数，还希望理解不同群体的观点之间是否存在联系，哪些问题经常一起出现，以及是否有容易被忽略的意见。
关键词统计、主题聚类和传统文本分析能够解决其中一部分问题，但不同观点之间的关联仍然值得进一步探索。
Microsoft 曾公开介绍一项公众意见分析实践，尝试利用 LLM 提取观点、组织关联信息，并通过 GraphRAG 相关方法进行综合分析。
- 大量原始意见
- 提取观点与关联信息
- 组织和综合相关内容
- 形成待验证的研究线索
其中一个值得关注的方向，是帮助分析人员发现原本没有明确提出的研究问题。
例如，分别讨论就业变化和教育机会的意见，可能存在值得进一步考察的共同关注点。
系统可以帮助研究人员注意到这种关联。
但它不能仅凭关联就断定存在因果关系，也不能保证自动生成的主题能够准确代表整体公众意见。
需要注意，这项公开实践涉及实验性的 LazyGraphRAG 等方法，不能将其全部成果直接归因于标准 Microsoft GraphRAG 的 Global Search。
这个场景的潜在价值，不只是加快整理速度，而是扩展分析人员发现问题的能力。
这种思路也可能延伸到市场研究、政策分析或 Scenario Planning（情景规划）等领域。
但从发现关联到形成可靠判断，仍然需要进一步的证据验证。
参考资料：
案例三｜企业经营分析：让业务人员直接使用数据
许多企业并不缺少数据。
真正的问题是，普通业务人员很难直接使用这些数据。
例如，一名游戏公司的业务负责人希望知道：
某次促销活动究竟带来了多少收入增长？
回答这个问题可能涉及销售记录、产品信息、促销活动、时间范围以及多个业务指标。
数据分布在不同的表和系统中，而表结构又未必能直接反映业务人员使用的概念。
因此，即使数据已经存在，业务人员仍然需要向分析师提出需求，等待对方编写查询并整理结果。
Deloitte Consulting LLP、Neo4j 与 AWS 参与的一项公开客户案例，采用了知识图谱和 AI Agent 结合的方式。
系统利用知识图谱表达业务概念及其与数据结构的关系，再让 Agent 根据用户的问题组织查询，并通过 Snowflake 获取数据。
Deloitte：实施方案例参与方还包括 Neo4j 与 AWS；下图只表达已披露的核心分工。
- 提出问题自然语言
业务人员表达分析需求。
- 理解业务语义知识图谱 / Neo4j
提供业务概念与关系，帮助确定需要查询的数据。
- 组织查询SQL
LLM Agent 根据问题及相关语义生成查询。
- Snowflake
执行数据查询，返回经营数据。
- 组织解释答案
基于查询结果回答业务问题，仍需核对口径与正确性。
Neo4j 公开报告了这项应用带来的效率改善，但这些属于供应商披露的客户成果，并非本文独立验证。
这个案例与前面的公众意见分析有一个明显区别。
它不需要先把大量文档划分为不同社区，再生成社区摘要。
它更关注如何利用已有的业务关系，让 AI 正确理解问题并访问企业数据。
这个场景的产品价值，是降低业务人员获取和分析数据的门槛。
不过，知识图谱增强 Agent 只是其中一种实现路径。
企业语义层、数据目录及 Text-to-SQL 等技术，也可能满足类似需求。
因此，应该比较具体方案带来的收益，而不是将全部效果归功于 GraphRAG。
参考资料：
案例四｜《水浒传》：让阅读从查找走向探索
最后是我希望继续研究的一个产品方向。
《水浒传》包含大量人物、事件，以及跨章节延续和变化的关系。
阅读时，我们可能遇到几种不同的需求。
例如，忘记某个人物第一次出现在哪一回，可以通过搜索找到答案。
想知道林冲为什么最终走上梁山，就需要结合多个章节中的事件和人物经历。
而如果想进一步了解哪些人物具有相似经历、不同人物之间存在什么间接联系，就可能需要更加系统地整理关系。
- 按需理解
- 根据当前阅读进度，查询人物、回顾事件、寻找原文证据。
- 主动探索
- 比较人物经历，观察关系如何变化，发现值得进一步阅读的联系。
GraphRAG 可能帮助组织人物、事件与章节之间的关联信息，并结合原文辅助回答。
但这种方式是否真正优于普通 RAG，仍然需要实验。
阅读助手还有一个特别值得注意的约束：
信息越完整，不一定越符合读者需求。
假设读者只读到第十回，系统即使知道后面的所有情节，也不应该未经允许透露未来剧情。
因此，产品不仅要能够找到关联，还需要根据阅读进度决定哪些信息可以提供。
这个案例目前仍处于产品构想阶段。
它值得研究的地方在于：
GraphRAG 是否能够让读者更容易理解复杂作品，并帮助他们发现新的阅读角度？
04｜GraphRAG 是怎么实现的？
前面的案例虽然使用场景不同，但都涉及同一件事：
如何让 AI 利用信息之间的关系，而不只是处理一段孤立的文本？
实现这一目标，并没有唯一的技术架构。
GraphRAG 的共同组成
从不同实现中，可以抽取出三个主要环节。
组织关系
获取实体之间的关联信息。
这些关系可以来自现有数据库、知识图谱，也可以通过文本抽取得到。
不一定需要独立部署图数据库，也不一定需要由 LLM 生成全部关系。
检索信息
根据用户的问题，利用图结构查找相关实体、关系或资料。
系统也可以同时使用向量检索、关键词搜索、数据库查询等方法。
综合回答
将获取的关系与相关证据组织为上下文，交给语言模型生成回答。
用户问题
关系辅助检索
相关上下文
LLM 回答
关系信息可能来自已有知识图谱，也可能从原始资料中提取；实际系统还可能使用不同的检索和生成方式。
这是一张共通概念图，不是所有 GraphRAG 系统必须遵循的固定流水线。
不同产品，可以有不同的实现方式
节点表示逻辑职责，不代表独立服务；Graph 与 DB 可以属于同一系统。实线表示查询中的信息流，虚线表示提前生成的摘要供查询使用。
A关系查询增强
反洗钱调查
可用资料
账户关系、交易记录与客户资料。
查询阶段
检索关联信息与证据
Graph 用来找到信息
沿 Graph 关系查询相关实体，再从 DB 取得资料，组成 Context，交给 LLM 整理回答。
这里辅助异常后的调查；异常检测仍可由独立图算法或规则承担。
B知识图谱增强 Agent
企业经营分析
可用知识
业务概念、指标与数据结构之间的语义关系。
查询阶段
Graph 用来指导查询
Graph 帮助 Agent 理解业务语义、组织查询与工具调用；DB 返回数据后，再由 LLM 生成回答。
Graph 提供查询依据，不一定直接提供最终答案。
C社区摘要增强
大规模文档主题分析
索引阶段 · 提前完成
查询阶段
使用预先生成的摘要
Graph 用来提前组织知识
索引时从资料构建 Graph、划分社区并生成摘要；查询时获取摘要作为 Context，交给 LLM 综合回答。
这是代表性路线，不表示前文 Microsoft 公众意见案例完全采用了标准社区摘要架构。
这些是为了说明技术差异而归纳的代表性模式，并非互斥的标准分类。一个系统可能同时采用多种方式。
其中，Microsoft GraphRAG 提供了社区摘要式架构的代表性实现。
它能够从文档中抽取实体与关系，构建图结构，并通过社区划分和摘要生成，提前组织部分知识。
对于围绕具体实体的问题，可以使用 Local Search 获取相关上下文。
对于需要综合整个资料集合的问题，可以利用 Global Search 组织多个社区报告中的信息。
具体实体问题
Local Search
- 关联实体与关系
- 原文等相关上下文
- LLM 回答
资料集合的整体问题
Global Search
- 多个社区报告
- 分批综合相关信息
- LLM 汇总回答
两种用途并列，不表示升级顺序；此例不代表所有 GraphRAG 架构。
这里不深入介绍社区发现算法、索引参数或检索细节。
重要的是理解：
GraphRAG 可以在检索时利用已有关系，也可以提前组织大量关联知识。
不同方式的适用任务、信息覆盖范围和构建成本都可能不同。
前者不一定能够充分回答全局性问题；后者也会增加预处理、摘要维护和更新成本。
选择哪一种架构，取决于产品需要解决的问题。
参考资料：
05｜GraphRAG 值得使用吗？
结论是：当复杂关联信息确实影响用户完成任务，而现有方案又难以有效处理这些关系时，GraphRAG 才值得考虑。
它可能带来两种价值：
减少工作量：辅助查找、整理和解释复杂关系与相关证据。
辅助发现：帮助用户识别原本没有注意到的关联与研究方向。
但这些能力并不是 GraphRAG 独有的。
普通文档问答可能只需要 RAG。
明确的关系查询可能直接使用图数据库。
实时异常检测可能更适合图算法与机器学习。
结构化业务数据查询，也可以考虑 SQL、语义层或 Text-to-SQL。
而 GraphRAG 还可能增加图谱构建、索引更新、模型调用和事实核验等成本。
因此，真正需要判断的是：
面对相同的用户任务，GraphRAG 是否比更简单的方案提供了值得投入的改善？
如果没有，它就不一定是合适的技术选择。
06｜GraphRAG 的未来
GraphRAG 并不是唯一的技术选择，但它展示了一种值得关注的方向：
让 AI 不只是查找和生成信息，还能够利用信息之间的关系。
随着语言模型的能力不断提高，这种技术组合也可能发生变化。
未来，模型或许能够更有效地直接理解大量原始资料，减少某些场景下提前构建知识结构的必要性。
另一方面，即使模型能够理解复杂信息，企业仍然可能需要可靠、可维护、可追溯的知识关系。
例如，客户与企业之间的关系、业务指标之间的定义、不同数据来源的关联，都不只是语言理解能力的问题。
因此，我想保留一个开放问题：
GraphRAG 会成为 AI 时代长期需要的知识基础设施，还是当前语言模型能力限制下的一种过渡方案？
现在还无法给出确定答案。
接下来：从产品调研走向技术实践
这篇文章先停留在产品层面。
通过不同案例，我们可以看到 GraphRAG 的潜在价值，也能理解为什么它不适用于所有场景。
但仍有一些问题需要进一步验证。
例如，知识图谱应该如何构建？不同的检索策略会产生什么区别？图结构究竟改善了多少回答质量？普通 RAG 是否能够完成相同任务？
接下来，我计划以《水浒传》为题材，继续研究 GraphRAG 的具体技术实现。
从实际的阅读需求出发，逐步研究知识组织、关系检索及生成效果，并尝试与更简单的方案进行对照。
相关的实现过程、实验结果和遇到的问题，也会在后续文章中继续分享。
产品调研帮助我们找到值得研究的问题，技术实践则进一步验证这些判断。