完整题目
请介绍检索增强生成（RAG）的基本原理，并详细解释GraphRAG的技术方案，包括其如何利用图结构来提升检索效果和生成质量。
本文目录
答案要点
- 传统RAG的局限性（语义孤立、全局信息缺失）
- GraphRAG的核心流程（索引阶段构建知识图谱+社区摘要，查询阶段利用图结构检索）
- 社区发现算法在GraphRAG中的作用
- GraphRAG相比传统RAG的三类优势（连接性、全局性、可解释性）
- 实际落地时的权衡（成本、延迟、图谱质量）
传统RAG的局限
传统RAG将文档切分为独立文本块，通过向量相似度检索。问题在于：语义孤立——文本块间的关系丢失；全局信息缺失——无法回答"总结全书主题"这类跨文档问题。
GraphRAG的核心方案
GraphRAG由微软提出，分索引和查询两阶段：
索引阶段（离线）
- 用LLM从文档中提取实体（人、组织、事件等）和关系，构建知识图谱
- 基于图结构做社区发现（如Leiden算法），将相关实体聚类为社区
- 为每个社区生成摘要，形成层次化的"社区摘要树"
查询阶段（在线）
- 全局查询：遍历社区摘要树，自上而下聚合信息，回答宏观问题
- 局部查询：定位相关实体，沿图边扩展检索，回答具体问题
图结构带来的提升
| 维度 | 传统RAG | GraphRAG |
|---|---|---|
| 连接性 | 孤立文本块 | 实体关系显式建模，支持多跳推理 |
| 全局性 | 单点检索 | 社区摘要覆盖文档全局主题 |
| 可解释性 | 黑盒相似度 | 检索路径可追溯（A→B→C） |
实际权衡
- 成本：索引阶段需多次LLM调用，适合静态知识库场景
- 延迟：图遍历增加查询耗时，需结合缓存或预计算优化
- 图谱质量：实体抽取错误会传播，需设计校验机制
换一种问法，检查是否真正理解
场景切入
假设你在做一个企业知识库问答系统，用户问“公司去年各季度营收趋势”，传统RAG可能只返回几段财报片段。你觉得怎么改进才能给出带全局视角的答案？
层层追问
RAG的基本流程你肯定熟悉吧？……那如果用户问“总结一下这场会议的所有关键决策”，传统RAG为什么答不好？……你觉得引入图结构能解决吗，具体怎么做的？
直球架构
请直接讲GraphRAG的技术方案，包括索引阶段怎么构建图、查询阶段怎么利用图结构检索，以及它相比传统RAG在全局性和可解释性上的优势。
练习口述回答 · 约4分钟
- 本质：RAG从平面文本块到图结构，解决全局与多跳问题
- 传统RAG的边界：适合单点查，不适合跨文档总结和复杂推理
- GraphRAG的核心：索引阶段建图+社区摘要，查询阶段按层级检索
- 落地风险：成本高、延迟大、图谱质量敏感，适合静态知识库
- 我的取舍：GraphRAG做全局骨架，传统RAG做细粒度补充，混合才是王道
这道题其实在问，当[[RAG]]从简单的文本块检索进化到需要理解全局关系和进行多跳推理时，图结构是怎么帮上忙的。我先说传统RAG的边界在哪，再解释[[GraphRAG]]怎么突破，最后聊聊落地的真实取舍。
传统RAG的局限很直接：它把文档切成一块块文本，用向量相似度去捞。这适合什么呢？比如客服场景里，用户问“我的订单怎么退款”，你从退款政策里找一段话就行。但一旦问题变成“整个促销季的满减规则是怎么演变的”，或者“总结这份合规文档的核心风险点”，传统RAG就抓瞎了。因为它每块文本是孤立的，没有连接，也没法跨块做推理。说白了，传统RAG擅长单点查，不擅长全局总结和多跳推理。
GraphRAG就是冲着这个来的。它的方案分两段：离线索引和在线查询。索引阶段，先用LLM从文档里抽实体和关系，比如“张三”和“订单123”之间有个“提交”关系，构建出[[知识图谱]]。然后对图做社区发现，比如用Leiden算法，把紧密相关的实体聚成一个社区，再让LLM给每个社区生成摘要，形成一棵层次化的社区摘要树。查询阶段就分两种：全局查询，比如“整个文档讲了什么主题”，就从上到下遍历社区摘要树，把宏观信息聚合起来；局部查询，比如“张三的订单为什么异常”，就定位到“张三”这个实体，沿着图边往外扩，找到关联的订单、支付记录、库存状态，做多跳检索。
图结构带来的提升很实在。一个是连接性，传统RAG里“订单”和“库存”是两块文本，但图里它们有显式关系，支持多跳推理。另一个是全局性，社区摘要直接覆盖了文档的整体主题，不会漏掉宏观信息。还有可解释性，传统RAG是黑盒算相似度，而GraphRAG的检索路径可以追溯，比如“张三→订单123→支付失败→库存不足”，每一步都看得见。
但落地时坑也不少。成本是第一个问题，索引阶段要多次调LLM抽实体和关系，如果知识库每天更新，LLM调用费会很高，所以它更适合静态知识库，比如企业的SOP文档或合规手册，改得不频繁。延迟也需要注意，图遍历比向量检索慢，特别是社区摘要树层次多的时候。我上线时一般会加缓存，把常用社区摘要预计算好，或者限制遍历深度。图谱质量更是敏感，实体抽取错了，比如把“张三”和“张四”合并了，那整个下游检索都会偏。所以我会设计校验机制，比如用[[NER]]做一遍预标注再让LLM修正，或者人工抽检关键实体。
还有一个点值得注意：GraphRAG的社区摘要生成依赖LLM的总结能力，如果LLM自己[[Hallucination]]了，摘要里掺了假信息，那检索出来的结果就会误导用户。所以我会在生成摘要后加一层[[Faithfulness]]校验，确保摘要内容在原始文档里有依据。
所以我的判断是，GraphRAG和传统RAG不是替代关系。。真正落地时，常常混合使用：先用GraphRAG定位到相关社区和实体，再用传统RAG去捞那个实体下的具体文本块。这样才能在成本和效果之间找到平衡。