完整题目
请解释检索增强生成（RAG）的基本原理，并重点阐述GraphRAG方法如何利用图结构来提升检索效果和生成质量。
本文目录
答案要点
- RAG基本原理（检索+生成两阶段流程）
- 传统RAG的局限性（语义碎片化、缺乏全局关联）
- GraphRAG的核心改进（构建实体关系图、社区发现、分层摘要）
- GraphRAG的检索优势（多跳推理、全局信息聚合）
- 实际应用场景举例
RAG基本原理
RAG = 检索(Retrieval) + 生成(Generation)，解决大模型知识截止和幻觉问题：
- 索引阶段：文档切分→Embedding→存入向量数据库
- 检索阶段：用户查询向量化→相似度搜索→召回Top-K片段
- 生成阶段：将检索结果作为上下文，LLM生成最终回答
传统RAG的痛点：文本切块导致语义碎片化，缺乏实体间的全局关联，难以回答需要多跳推理的复杂问题。
GraphRAG的核心改进
微软提出的GraphRAG，核心是用图结构替代纯向量检索：
1. 图构建阶段（离线）
- 实体抽取：用LLM从文档中提取实体（人、组织、事件等）和关系
- 图建模：构建
(实体)-[关系]-(实体)的知识图谱 - 社区发现：用Leiden等算法检测图中的紧密社区
- 分层摘要：对每个社区生成多粒度摘要（从局部到全局）
2. 检索阶段（在线）
- 全局查询：先匹配相关社区摘要，快速定位大范围
- 局部展开：在目标社区内做多跳图遍历，获取关联实体
- 信息聚合：将图路径上的多源信息整合，形成完整上下文
GraphRAG的优势
| 维度 | 传统RAG | GraphRAG |
|---|---|---|
| 关联能力 | 仅语义相似 | 显式关系推理 |
| 全局信息 | 片段孤立 | 社区摘要聚合 |
| 多跳问题 | 效果差 | 图遍历天然支持 |
| 可解释性 | 黑盒相似度 | 可追溯的关系路径 |
典型场景：企业知识问答中"某部门近半年与哪些供应商有合作纠纷"——需要跨文档关联实体、时间、事件，GraphRAG通过图遍历比纯向量匹配更精准。
换一种问法，检查是否真正理解
场景切入
假设你做一个内部知识库问答系统，用户问‘A部门和B部门去年有哪些合作项目’，传统的向量检索可能把相关文档切得七零八落。你怎么设计才能把跨文档的实体关系串起来，给出一个完整的回答？
层层追问
RAG的基本流程你肯定熟悉，就是把文档切块、向量检索、拼给大模型……但遇到需要多跳推理的问题，比如‘某产品的供应商和哪些客户有纠纷’，传统方法为什么效果差？……如果让你用图结构来改进，你会怎么做？
直球架构
请直接解释GraphRAG的核心原理：相比传统RAG，它怎么构建图？检索时如何利用实体关系和社区结构？它的主要优势体现在哪些方面？
练习口述回答 · 约4分钟
- 本质在问：如何让大模型拥有结构化知识推理能力
- RAG基础与瓶颈：切块导致的语义碎片化
- GraphRAG改进：从向量相似到关系推理
- 落地风险：图构建成本高，适用场景要选对
- 工程师取舍：RAG+GraphRAG混合，优先解决多跳推理
这道题其实在问一个很核心的问题：当大模型需要回答涉及多个实体、跨文档的复杂问题时，纯靠向量相似度检索为什么不够，以及怎么用图结构来补上这个短板。我先说[[RAG]]的基础。RAG就是检索加生成两阶段，离线把文档[[切块]]、做[[Embedding]]、存到[[Vector Database]]，在线拿用户查询去搜最相似的top-K片段，然后喂给LLM生成答案。这个流程能解决知识截止和[[幻觉]]问题，但有个硬伤：文本切块会把语义切碎。比如一份合同里提到“甲方”和“乙方”的权利义务，可能散落在不同段落，切块后两块各自独立，检索时很难把它们关联起来。而且传统RAG只做语义相似匹配，回答不了类似“某部门近半年和哪些供应商有合同纠纷”这种需要跨文档、跨实体、跨时间推理的问题。这就是它的边界，适合单点事实查询，不适合多跳推理。[[GraphRAG]]的核心改进，就是把检索从向量相似度升级成显式的图推理。具体来说，离线阶段先让LLM抽取出文档里的实体和关系，比如从合同里抽“供应商A”、“2024年Q3”、“纠纷事件”，然后构建成[[Knowledge Graph]]。再用社区发现算法，比如Leiden，把紧密关联的实体聚成社区，对每个社区生成多粒度摘要。在线检索时，先匹配社区摘要定位大范围，再在目标社区内做图遍历，把路径上的多源信息聚合起来。举个例子，客服场景里用户问“我上个月退货的订单，退款还没到账，怎么回事”，传统RAG可能只搜到退货政策片段，但GraphRAG能通过图遍历关联到用户ID、订单号、退款记录、物流状态，把整个链条串起来，生成更精准的回复。不过GraphRAG不是银弹。落地有个重要前提：你的文档必须实体密集、关系丰富。如果文档是松散的闲聊记录，或者实体很少，图构建的成本就白花了，效果甚至不如传统RAG。而且图构建依赖LLM做实体抽取和[[关系抽取]]，这一步有精度问题，抽错了会带偏下游。上线我会特别关注两点：一是实体抽取的准确率和召回率，二是社区划分的粒度，太粗会丢失细节，太细又增加检索延迟。所以我的判断是：GraphRAG和传统RAG不是替代关系，而是互补。日常简单查询走向量检索，又快又准；遇到复杂推理、跨文档聚合的场景，才启用图检索。实际落地我倾向先上传统RAG兜底，再对高频复杂查询做GraphRAG增强，这样成本和效果能平衡。
还有一个有意思的点是，GraphRAG的社区摘要其实可以离线预计算，这样在线只做摘要匹配，延迟可控，但摘要的粒度怎么选，是粗放一点覆盖全局，还是精细到每个子社区，这直接影响召回质量，我还在实验不同策略。