向量检索擅长通过语义相似度找到“意思相近”的内容，但在处理实体间复杂关系（如“A 是 B 的上级”“C 产品由 D 部门负责”）时，单纯的关键词或向量匹配往往力不从心。图检索（基于知识图谱）则恰恰相反，它精于沿着实体关系查询，但难以应对大段文本语义。将二者融合，可以让 RAG 系统兼具语义广度与关系深度。
1. 融合的基本思路
融合方案的核心是一次提问，两路并行召回，结果合并，统一增强。工作流如下：
- 问题解析：识别问题中的实体（人名、产品、地点、政策编号等）和关系意图（属于、负责、包含、依赖等）。
- 向量检索通道：用问题的整体语义，从文档切片向量库中检索最相关的几段文本。
- 图检索通道：以识别到的实体为起点，在图数据库中沿相关关系查询一跳或多跳，获取关联实体及其属性文本。
- 结果合并与重排序：将两路得到的文本片段去重、按相关性重新排序，必要时用图的上下文扩展某些片段。
- 生成增强：将合并后的结果连同问题发给 LLM，生成最终回答。
2. 典型场景：企业知识问答
某制造企业拥有大量技术手册、维修指南（适合向量检索），同时也维护了一份零件-机器-供应商-售后联系人之间的知识图谱（适合图检索）。用户提了一个问题：“发动机型号 XT-200 的密封圈由哪家供应商提供？对应的技术规格在哪本手册？”
纯向量检索可能找到手册中描述 XT-200 的段落，但很难直接锁定密封圈这个子零件与供应商的关系；纯图检索能沿着 (XT-200)-[包含]->(密封圈)-[由..供应]->(供应商) 路径查到供应商名称，但取不到手册里的规格文本。融合方案处理这个问题的步骤：
- 实体识别：从问题中提取出 “XT-200”“密封圈”。
- 图检索：在图中查找到密封圈节点，获取其供应商属性（如“宏达密封”），并取回该关系上的备注文本（如“采购代号 HT-33”）。
- 向量检索：用问题全文检索文档库，得到《XT系列发动机维修手册》第 12 章中关于密封圈安装规格的片段。
- 合并上下文：将图查询结果（供应商信息）以结构化短句形式补充进向量检索结果，形成完整的资料块。
- LLM 回答：“XT-200 发动机密封圈的供应商是宏达密封（采购代号 HT-33），相关技术规格见《XT系列维修手册》第12章第3节，建议装配力矩为 25 N·m。”
3. 工程实现要点
- 图数据库选型：中小规模图谱可用 Neo4j、ArangoDB 等，有成熟查询接口；也可用基于属性图的内存图谱服务，减少延迟。
- 实体识别与链接：需要一个轻量实体链接模块，把问题中的词（如“XT-200”）对应到图谱中的具体节点 ID。可以基于词表规则、Elasticsearch 模糊匹配或小型分类模型实现。
- 避免图查询爆炸：控制图查询的跳数（一般 1~2 跳），并限制返回的关系数量，防止子图过大，导致上下文超长。
- 统一 ranking 策略：向量检索结果通常用相似度分数，图结果可以赋予固定权重或由实体重合度评级。简单实践中，图结果可以直接放在向量结果前面，认为关系查询比语义匹配更具指向性。
- 缓存图谱片段：将图查询到的实体及其一跳邻域预先扩展成文本描述（如“供应商：宏达密封，电话 xxx”），作为文档切片存入向量库，可以在部分场景下直接用向量检索近似图检索，降低实时压力。
4. 优缺点与适用建议
优势：
- 补全了向量检索对精确关系、多跳推理的短板。
- 答案不仅能引用文档，还可附带结构化的实体关联，提升可信度。
- 知识图谱同样可独立更新，维护成本可控。
局限与应对：
- 构建与维护图谱需要额外投入；可以从最核心的实体关系入手（客户、产品、政策编号），量力而行。
- 图查询需要精确匹配实体名称，用户提问中的别名或拼写错误会导致查不到；可以增加简单的别名映射或模糊匹配容错。
- 双路检索增加系统复杂度和延迟；可通过异步并行请求和缓存热点查询来优化。
什么时候适合引入图检索？
如果业务知识中实体间的关系信息量大、且用户经常提出需要跨实体跳转的问题（如“谁负责这个项目？”“这个零件用在哪些机器上？”），那么融合图检索会显著提升答案的准确度，值得投入。如果知识大多是独立文档、少有结构化关系，纯向量检索通常就够了。
通过这种融合，RAG 从“看懂文档”升级为“看懂文档+理清关系”，在面对复杂业务问题时，能够给出更完整、更精准的回答。