知识图谱与向量搜索的融合：提升检索准确率的架构设计
一、向量搜索的盲区
向量搜索(Vector Search)是 RAG 系统的主流检索方式——将文档向量化后,用相似度匹配找到与用户问题最接近的内容。向量搜索在「语义相似」上很擅长——用户问「怎么退钱」,能检索到「退款流程说明」这个文档,即使两句话的用词完全不同。
但向量搜索有明确的盲区:它「不理解关系」。用户问「张三是李四的领导,李四的部门主管是谁？」向量搜索能找到包含「张三」「李四」「领导」「部门主管」的文档,但它不能「推理」出答案——因为文档里可能没有直接写「李四的部门主管是...」这句话,答案需要通过「张三是李四的领导」和「张三的职位是部门主管」这两个信息推理出来。
这就是知识图谱(Knowledge Graph)的用武之地——用结构化的实体关系弥补向量搜索的「关系理解」盲区。
graph TD A[用户问题] --> B[向量搜索<br/>语义匹配] A --> C[知识图谱<br/>关系推理] B --> D[找到相似文档<br/>「退款流程」] C --> E[推理出关系<br/>「李四的主管是张三」] D --> F[合并结果] E --> F F --> G[大模型生成答案] style B fill:#e3f2fd style C fill:#c8e6c9 style F fill:#fff3e0二、知识图谱在 RAG 中的角色
对于一个独立产品的 RAG 系统,知识图谱不需要像 Google 的知识图谱那样庞大和复杂。它的角色是「补充向量搜索无法提供的结构化关系信息」。
典型的知识图谱场景:
- 实体关系查询。「A 公司是 B 公司的供应商,他们的合作关系是什么时候开始的？」向量搜索能找到有关 A 和 B 的文档,但知识图谱可以直接查询
(A公司) -[供应商]-> (B公司)这条关系及其属性。 - 多跳推理。「公司的 CEO 的直属下属有哪些？」这是一个需要两步推理的关系查询——先找到 CEO,再找到直属下属。知识图谱可以遍历节点关系,而向量搜索只能找到匹配的文档。
- 结构化约束查询。「2025 年第一季度,销售额超过 100 万的产品有哪些？」这是典型的结构化查询,知识图谱(或更准确地说,图数据库)可以高效回答。
三、轻量融合架构的设计
对于独立产品,知识图谱与向量搜索的融合不需要引入 Neo4j 这种企业级图数据库。一个轻量的实现方案:用图结构存储关键实体关系,用向量搜索查询自由文本,在查询时并行检索,然后合并结果。
graph TD A[用户问题] --> B[查询路由器] B --> C[向量搜索引擎<br/>Faiss / Milvus] B --> D[轻量图存储<br/>SQLite + JSON / Redis Graph] C --> E[语义匹配文档<br/>Top-K 个段落] D --> F[关系推理结果<br/>实体/关系列表] E --> G[结果融合层] F --> G G --> H{融合策略} H -->|简单合并| I[向量结果 + 图谱结果<br/>拼接为上下文] H -->|增强检索| J[图谱结果作为<br/>向量检索的补充查询] I --> K[大模型生成] J --> C style G fill:#e3f2fd轻量图存储的实现选择:
- SQLite + JSON 字段:用 SQLite 存储实体,一个 JSON 字段存储该实体的所有关系(如
{"manager": "张三", "department": "技术部"})。查询简单,不需要学习新工具。 - Redis Graph:如果已经在用 Redis,Redis Graph 模块提供了图查询能力,不需要引入新服务。
- 内存中的邻接表:如果实体关系不多(< 1 万),可以直接在内存中维护一个邻接表(用 Map/字典结构),每次启动时从数据库加载。
四、什么时候不需要知识图谱
知识图谱不是「越多的结构化数据越好」。它增加了系统的复杂度,需要维护实体关系的更新(当数据变化时,图谱中的关系也要更新)。在以下情况下,不需要知识图谱:
- 产品以自由文本为主。如博客文章、用户评论、产品描述——这些内容的本质是自由文本,实体关系很少,向量搜索已经足够。
- 用户的查询主要是「语义相似」而非「关系推理」。如果你的用户主要问的是「怎么用 XXX」这种操作指南类问题,而不是「谁和谁是什么关系」这种关系类问题,知识图谱的收益很小。
- 文档能够回答用户的问题。如果用户的问题在文档中已经有直接答案,向量搜索能检索到,知识图谱就是冗余的。
事实上,大部分独立产品的 RAG 场景,向量搜索已经足够。知识图谱只在「用户的查询需要关系推理」且「关系信息在文档中以分散的方式存在」时,才带来明显价值。
五、总结
知识图谱与向量搜索的融合,核心是用结构化关系补充语义搜索的不足,但只在真正需要关系推理的场景中引入这种复杂度。
对于独立产品,务实的做法:(1)先只用向量搜索,观察用户的查询中是否出现了「关系推理」类型的失败案例;(2)如果有,从最简单的图结构开始——用 SQLite + JSON 存储实体关系;(3)并行执行向量搜索和图查询,合并结果后送入大模型;(4)持续评估图查询的使用频率和准确率提升,判断这部分投入是否值得继续。
架构的融合,不是「加上更多的组件」,而是在「正确的组件解决正确的问题」这个原则下,做刚好够用的组合。如果你不需要知识图谱的推理能力,就别引入它。
