GraphRAG原理 vs 传统RAG 怎么选?

这道题其实是在问，当我们需要回答的不只是'某段文本说了什么'，而是要理解整个知识库里的实体关系和全局主题时，检索方式该怎么升级。传统[[RAG]]检索的是文本片断，适合回答'某文档里提到了什么'这种单点问题。但一旦问'整个数据集的共同主题是什么'或者'A和B有什么间接关联'，它就容易漏掉分散在多处的信息。所以它的边界很清晰：适合局部事实，不适合全局聚合和多跳推理。落地时往往需要跟其他方案组合，比如先用[[GraphRAG]]拿到关系路径，再用传统RAG去原文里验证细节，两者互补。

具体说一下GraphRAG的核心。它本质上是把知识库里的实体和关系抽出来，建成[[Knowledge Graph]]，然后对图做社区检测，比如用Leiden算法，把紧密关联的实体聚成一个社区，再让LLM生成每个社区的摘要。查询时根据问题路由到相关社区，综合多个社区的摘要来生成答案。你可以这么理解：传统RAG像在图书馆里翻书找段落，GraphRAG像先画一张人物关系图，然后顺着关系线找答案。比如问'公司A和公司B有什么关联'，传统RAG可能只找到它们共同出现的文档，而GraphRAG能通过图遍历找到A→中间公司C→B这条路径。

拿金融风控举个例子。假设我们要评估一家企业的隐性关联风险，传统做法是查股权结构、担保关系这些显性信息，但很多风险藏在多层穿透里。用GraphRAG，我们可以把企业、股东、担保人、交易对手都作为实体，把股权、担保、交易作为关系，构建一张企业关系图。然后通过社区检测，把那些虽然直接持股不深但通过多层嵌套形成闭环的担保圈识别出来。查询时问'这家企业是否存在隐性担保风险'，GraphRAG能返回它所在的担保圈以及圈内所有关联方，给出风险路径。这比传统RAG逐份合同检索要高效得多。

不过这里有个坑。GraphRAG的索引构建成本非常高，因为要多次调用LLM来做[[Entity Linking]]和[[Relation Extraction]]，而且图谱质量完全依赖抽取的准确性。如果实体识别不准，或者关系抽错，后面的社区检测和摘要都会跟着偏。所以它的适用前提是知识库相对静态，比如年度财报、合规文档，不太适合每天变动的实时数据。上线时我会特别关注抽取准确率和社区划分的合理性，用一批标注数据做验证，如果社区边界太粗或太细，都要调参。

说到社区检测，社区粒度对效果影响很大。社区太大，摘要会泛泛而谈；社区太小，又丧失了全局性。所以怎么根据查询类型动态调整社区粒度，或者用多粒度社区来覆盖不同层次的问题，这是个值得深挖的方向。

所以整体上，我会把GraphRAG看作一个结构化知识增强组件，适合全局性、关系性的查询，但成本高，不适合高频更新场景。我更倾向于把它和传统RAG组合使用，各取所长。