GraphRAG适用场景 vs 传统RAG 有哪些?

这道题其实是在问，什么时候应该放弃纯向量检索的灵活，转向更结构化的知识表示。我的理解是，[[GraphRAG]]和传统[[RAG]]没有谁取代谁，它们各自有最适合的领地。真正落地的时候，我往往会看数据本身有没有天然的图结构，以及查询是不是涉及多跳关系。如果只是搜个产品描述，传统RAG就够了；但如果问题是'某药物通过哪些靶点影响某疾病'，那向量检索很难跨文档把因果链串起来，这时候GraphRAG就自然得多。

具体说一下。我最先想到的场景是复杂多跳问答。比如在企业合规场景里，一条SOP说'退款超过1000元需要主管审批'，另一条说'主管审批后还需法务复核'，用户问'我退款1500元，流程该怎么走'。传统RAG可能分别召回两条文档，但很难自动组合成完整路径。GraphRAG把实体和关系显式建模，图遍历一次就能拿到'退款→超1000元→主管审批→法务复核'这条链，结果天然是结构化的。再一个场景是关系密集型查询，比如组织架构、供应链。问'这个零件供应商的供应商是谁'，向量检索很难表达这种两层关系，但图里一条边就搞定了。

GraphRAG相比传统RAG，核心优势我觉得有两个。第一是可解释的推理路径。在金融风控或者医疗诊断里，你不能只给一个答案，还要展示推理过程。GraphRAG返回结果可以附带'实体A→关系B→实体C'这样的路径，审计合规的时候很有用。第二是全局聚合能力，比如问'总结我们公司所有供应商的分布'，传统RAG会零散地返回各个供应商片段，而GraphRAG可以通过社区摘要先聚类再回答，结果更完整。

但是，GraphRAG有很严的使用前提。数据层面，要么已经有结构化知识，要么能从非结构化文本里高质量地抽取实体关系。如果[[NER]]和[[Relation Extraction]] pipeline不准，图谱里一堆噪音，那查询结果反而更差。我见过一个失败案例，团队硬把一堆杂乱的文档抽成图，结果实体对齐一团糟，同一个公司名出现好几个节点，关系也连错，最后召回效果还不如直接向量检索。所以上线前我会特别关注实体消歧和关系置信度，宁可少抽一些，也别抽错。

落地的时候，我一般不会二选一，而是把GraphRAG和传统RAG混合。简单查询走向量检索，复杂多跳走图查询，然后合并结果。成本上，图谱构建是一次性投入，换来查询时的精准度和可解释性，但如果数据变化快，维护图结构的成本会很高。

说到混合，其实还有一个有意思的点：GraphRAG的社区摘要生成本身依赖LLM，这又引入了[[Hallucination]]风险。如果摘要总结不准确，全局查询就会出错。所以我在设计时，会对社区摘要做一层[[Faithfulness]]校验，用事实一致性检查过滤掉幻觉内容，再返回给用户。