完整题目
请解释RAG中GraphRAG的实现原理和方法，包括如何构建知识图谱、进行图检索以及与传统向量检索的区别和优势。
本文目录
核心思想
GraphRAG 把文本证据与实体、关系或社区结构关联起来，用显式图结构补充向量检索的局部语义匹配。它可以支持关系检索和全局摘要，但不保证关系抽取正确，也不等于自动获得可靠的多跳推理。
1. 图构建
- 解析和分块文档，并保留到原文的来源映射。
- 抽取实体、关系及描述，同时记录证据片段和置信度。
- 做实体消歧、别名合并和冲突处理，避免同名实体误合并。
- 构建属性图，并按实现选择社区检测和层次摘要。微软 GraphRAG 的一种实现使用 Leiden 社区检测，但这不是所有 GraphRAG 的必选定义。
LLM 抽取和摘要会传播错误，因此需要抽样审核、规则约束、来源追踪和增量更新策略。
2. 检索模式
- 局部检索：从查询实体或命中节点扩展邻居、关系和关联文本，适合实体关系问题。
- 全局检索：检索或聚合社区报告、主题摘要，适合数据集级主题与趋势问题。
- 实际系统通常把图候选、原始文本和向量候选融合，再由重排或生成器使用；图路径只说明检索过程，不自动证明最终 claim。
3. 与向量检索的取舍
向量检索结构简单、更新成本通常较低，擅长局部语义相关内容；GraphRAG 增加关系与全局视图，但构建、更新、实体解析和质量控制成本更高。向量检索也能通过多查询、迭代检索或层次索引处理复杂问题，因此不能把它限定为“单点事实”。
4. 评测
分别评估实体/关系准确率、证据 Recall@K、路径或社区命中、答案正确性、Faithfulness、构建成本和更新延迟，并与向量 RAG 及混合方案做同集对照。
结论：GraphRAG 是对证据组织和检索方式的扩展，是否优于向量检索取决于查询类型、图质量和端到端评测。
图解
换一种问法，检查是否真正理解
场景切入
假设你做一个企业知识库问答系统，用户问“去年的营收是多少”你从向量库里找到了相关片段。但接着他问“那和竞争对手比呢”，这时候多个文档的关联信息怎么组织？传统的向量检索处理这种跨文档的对比分析是不是有点吃力？
层层追问
RAG里面如果用户问一个需要综合多个文档才能回答的问题，比如“总结整个行业趋势”，你会怎么设计？……那如果我把这些文档中的实体和关系抽出来建成图，检索时在图上做多跳遍历或者用社区摘要，你觉得和纯向量检索比优势在哪？……具体说说这个图怎么构建、怎么检索？
直球架构
请你讲一下GraphRAG的实现原理和方法，包括知识图谱怎么构建、图检索的两种模式，以及它和传统向量检索的核心区别和优势。
练习口述回答 · 约4分钟
- GraphRAG的动机：解决传统RAG全局推理弱
- 知识图谱构建流程：分块、抽实体关系、社区检测
- 图检索两种模式：局部和全局
- 与向量检索对比：适用场景不同
- 总结：适合深度分析，成本高，留个可延伸点
[[GraphRAG]] 的核心动机，是弥补传统向量 [[RAG]] 在跨文档关系和全局分析上的不足。传统 RAG 把文档切成一个个 chunk，再用向量相似度找相关片段；它做事实问答很有效，但每个 chunk 基本是独立的，实体之间的关系、文档之间的联系没有显式建模。所以遇到“这个行业有哪些主要趋势”“A 公司和哪些机构有间接关系”这类问题，单纯向量检索就比较吃力。
GraphRAG 的做法是先把文本变成图。流程一般是：文档清洗和[[分块]]之后，用模型抽取实体，比如人、公司、产品、概念；再抽取实体之间的关系，比如投资、隶属、竞争、因果、引用。抽完以后要做实体消歧和合并，比如“OpenAI”“Open AI”“这家公司”可能指同一个实体。最后把实体作为点，关系作为边，构建属性图，并保留来源文档、时间、关系置信度这些信息。
在微软 GraphRAG 那类方案里，还会做社区检测，比如用 Leiden 算法把联系紧密的实体聚成社区，然后对每个社区生成摘要。社区可以分层，底层是局部实体关系，上层是更宏观的主题摘要。这样系统不仅能查某个实体附近的关系，还能回答更全局的问题。
检索时主要有两种模式。第一种是 local search，适合具体实体问题。比如问“公司 A 投资过哪些项目”，系统先识别实体“公司 A”，再沿着图里的投资关系做一跳或多跳遍历，把相关节点和证据文档拿出来给模型。第二种是 global search，适合宏观总结。比如问“这些研报反映出哪些行业趋势”，系统会先查社区摘要，再逐层下钻到相关社区和原文证据。
和向量检索相比，GraphRAG 的优势是关系显式、路径可解释、跨文档聚合能力更强。向量检索擅长找“语义相似的文本块”，GraphRAG 擅长找“实体之间怎么连接、主题之间怎么聚合”。但它的代价也很明显：构建成本高，要抽实体关系、做消歧、做社区摘要；更新也更复杂，新文档进来不只是加向量，还要更新图结构和摘要。
所以我不会把 GraphRAG 当成传统 RAG 的替代品。简单事实问答、数据频繁更新的知识库，用向量检索加 [[BM25]] 加 reranker 往往更务实；关系密集、相对静态、需要分析报告或关联挖掘的场景，GraphRAG 更有价值。
真正落地时，我会关注两个风险：一个是抽取错误会污染整张图，必须有置信度和人工质检；另一个是社区粒度，如果分得太粗，摘要空泛；分得太细，又失去全局视角。这两个点通常决定 GraphRAG 的实际效果。