检索增强生成（RAG）本质上是为大语言模型配备一个外部知识库。当用户提出问题时，模型会先在这类知识库中检索相关内容，再结合上下文生成答案。这个流程看似直观，但在实际应用中，很多人发现简单的向量检索效果并不稳定，远未达到预期。

1. 回顾：大模型的短板与RAG的出场

大语言模型（LLM）虽然功能强大，但其“智能”完全依赖训练数据。一旦遇到内部知识库未覆盖的信息，或需要精确引用私有文档的场景，便容易出现“一本正经地胡说八道”的情况。RAG架构正是为弥补这一缺陷而生：它将外部数据源（如企业知识库）与LLM结合，具体分为两个步骤——

第一步，检索。利用用户的问题从数据库中获取相关片段，这部分信息通常被称为“上下文”。第二步，生成。将检索到的上下文传递给LLM，令其据此生成回答。

这套逻辑本身并无问题，但在实际操作中，传统的向量检索过于依赖语义相似度。它只能判断“这些句子在含义上接近”，却无法理解“两个实体之间究竟存在何种关系”。例如，用户询问“张三在哪个部门？”，简单的RAG系统可能检索到大量包含“张三”和“部门”的文档，但答案未必准确。根本原因在于，系统缺少一个能够理解“人物—组织—关系”的结构化索引。

知识图谱：把“关系”也装进索引里

知识图谱的引入正好弥补了RAG在关系理解方面的不足。通俗而言，知识图谱以“节点”表示实体（如人员、文档、项目），以“边”表示它们之间的关联（例如“张三”属于“研发部”）。这样一来，检索不再仅依赖语义相似度，而是可以沿着关系链路精准定位。

试想：当用户进一步追问“张三的汇报对象是谁？”时，传统RAG只能依靠关键词的向量匹配来猜测；而引入知识图谱后，系统可以直接沿“员工→部门→领导”这条关系路径一步得出答案。这就像从一个只有书名索引的图书馆升级为配备人物关系地图的图书馆——后者显然能处理更复杂的查询。

Graph RAG：性能到底提升了什么

那么，加入知识图谱的RAG究竟提升了哪些方面？实际测试表明，改进主要集中在两个维度：

• 多跳查询的准确率。例如“张三所在部门去年参与的项目有哪些”这类问题，需要跨实体、跨关系多次跳转。传统检索容易遗漏中间环节，而图谱结构天然适合此类查询。
• 模糊问题的消歧能力。当“苹果”既可以指水果也可以指公司时，知识图谱能够通过关联上下文（例如“库克”“iOS”）锁定正确含义。

当然，Graph RAG并非完全取代传统RAG，而是作为增强手段嵌入其中。可以把这种组合想象成给检索环节配备了一台“关系导航仪”——向量检索负责海选相关文档，知识图谱则负责在文档之间建立精确的路线图。两者协同工作，才能使生成结果既全面又精准。

话说回来，知识图谱的构建与维护本身存在成本。哪些实体和关系值得入库、图谱的更新频率如何设计，都需要根据实际业务场景来定。但可以确定的是，对于需要处理复杂关系型查询的RAG系统而言，知识图谱已逐渐从可选项变为必要组件——毕竟在信息爆炸的环境里，仅靠“语义近似”去猜测用户需求，终究是不够的。