这道题其实是在问,当我们从传统[[RAG]]的向量相似度匹配,升级到基于图结构的知识检索时,到底解决了什么本质问题。我觉得核心就一句话:传统RAG擅长找相似,但不擅长做综合推理。[[GraphRAG]]把非结构化文本先转成[[Knowledge Graph]],再基于图结构去检索,这样就能回答那些答案分散在多段、甚至多个文档里的全局性问题。
具体说一下知识组织方式的区别。传统RAG是把文档切成块,每个块单独做[[Embedding]],存到[[Vector Database]]里,查的时候找向量最像的几个块拼起来。这样信息是原子化的,跨段落的关联就丢了。比如两个段落都在讲同一个产品,但一个说功能,一个说售后,向量相似度可能就不够高,检索时它们就碰不到一起。GraphRAG的做法是先抽实体和关系,人、组织、概念这些是节点,它们之间的语义联系比如“投资”、“位于”就是边,然后通过社区发现算法,比如Leiden,把相关的节点聚成社区,每个社区还能生成一个高层摘要。这样知识就不是散落的碎片,而是一个有层次、有连接的网络。
再一个关键是检索机制的差异。传统RAG本质上还是局部匹配,你问一个“XX领域近年有什么发展趋势”,它很难答,因为答案分散在很多文档的不同段落里,向量相似度最高的可能只是其中一小段,拼起来也缺上下文。GraphRAG的检索路径是层次化的:先看社区摘要,定位到相关领域,再展开到具体子图,最后回到原始文本。它还能做多跳推理,比如A投资了B,B收购了C,问A和C的关系,图遍历直接就能把路径显式走通,传统RAG几乎做不到。
举个例子,企业里经常有合规文档,比如几十页的SOP,里面各种政策条款。传统RAG查“退货退款流程”很准,因为答案就在那一两段里。但如果你问“客户投诉后,涉及库存调整和财务扣款,这两步之间有什么前置条件?”,答案分散在库存管理和财务两个不同章节,传统RAG很容易漏。GraphRAG就能通过实体关系找到“客户投诉”和“库存调整”以及“财务扣款”之间的关联,再通过社区摘要把整个流程串起来,给出一个完整的回答。
不过这里有个坑:GraphRAG的构建成本很高。你需要用LLM反复抽实体、抽关系,做社区聚类,这个过程比简单[[切块]]慢得多,也贵得多。所以它的前提是知识库相对稳定,不频繁更新,而且你的查询里有相当一部分是全局性、分析性的问题。如果只是简单FAQ,比如查订单号、查错误码,传统RAG加上[[Hybrid Search]]或者[[BM25]]就够了,根本用不上图。真正落地时,我通常会把它们搭配着用:简单事实查询走传统RAG,复杂推理走GraphRAG,甚至还可以用个路由层,根据问题类型动态选择。
还有一个有意思的延伸点:GraphRAG的社区摘要本身是LLM生成的,这其实引入了[[Hallucination]]风险,摘要可能不准确,导致后续检索都基于错误的前提。所以上线前我会特别关注社区摘要的[[Faithfulness]],用一些自动评估指标比如[[RAGAS]]做验证,必要时还要人工抽检。
所以整体上,我不会把GraphRAG看作传统RAG的替代,而是看成一个互补工具。它特别适合研报分析、医学文献综述这种需要全局视角的场景,但对延迟敏感、或者知识库实时更新的场景就不太合适。我更倾向于把它定位成“复杂分析场景的深度检索层”,和轻量级的传统RAG一起,构成一个分层检索体系。