第五章 · 知识图谱增强
本章定位：前面四章的 RAG 都是「块级」的——把文档切碎、向量化、按相似度召回。但有些问题，块级检索天然答不好。比如「张三负责哪些项目」「订单系统和库存系统是什么关系」「列出所有 Java 相关的技术栈」——这些答案分散在多个文档、多个块里，靠的是实体之间的关联，而非单块的语义相似。知识图谱（Knowledge Graph）就是来补这个短板的。
本章分两部分：
- 上篇 · 概念与原理（科普）：为什么需要知识图谱？它和向量检索怎么互补？知识图谱的基本构成是什么？什么是社区检测？GraphRAG 是什么？
- 下篇 · SparkX 源码落地（实践）：SparkX 怎么在入库时自动抽取实体关系？双存储设计（Neo4j + pgvector）怎么协作？检索时怎么做子图扩展？社区摘要怎么生成？图谱通道为什么在 RRF 融合时降权？
上篇 · 概念与原理
一、向量检索的局限：为什么需要知识图谱
1. 向量检索擅长什么
经过前三章，我们已经知道向量检索的强项：语义相似度匹配。用户问「退货政策」，能召回写着「商品退换规则」的块——靠的是语义相近。
2. 向量检索答不好的三类问题
但有些问题，向量检索天然吃力：
问题一：跨文档的关联关系
文档A（员工档案）：张三是研发部的工程师
文档B（项目档案）：订单重构项目由研发部负责
文档C（系统设计）：订单系统依赖库存系统
用户问「张三参与的项目用了哪些系统」。答案是「订单重构项目 → 订单系统 → 依赖库存系统」，需要跨越三份文档、串起「张三→研发部→订单重构→订单系统→库存系统」这条关系链。向量检索只能找「和这句话相似」的块，找不出这条关系链。
问题二：「A 和 B 有什么关系」
用户问「订单系统和库存系统是什么关系」。两份文档里分别描述了这两个系统，但没有任何一块文本同时包含两者并说明关系。向量检索召回的块要么只讲订单、要么只讲库存，拼不出「依赖」这个关系。
问题三：「列出所有 X」
用户问「公司用了哪些 Java 技术栈」。答案分散在几十份文档里（Spring Boot 在架构文档、MyBatis 在数据层文档、Redis 在缓存文档……）。向量检索只能返回「最相似的几个」，返回不了「全部」——它是 topK 召回，不是全量聚合。
3. 这些问题的共性
这三个问题的共性是：答案靠的是「实体之间的结构化关系」，而非「文本的语义相似」。这正是知识图谱擅长的领域。
💡 一句话区分：向量检索回答「什么内容和我问的像」，知识图谱回答「事物之间有什么关系」。
二、知识图谱是什么
1. 基本构成：节点 + 边
知识图谱用图结构来组织知识，核心是两种元素：
- 节点（Node/Entity）：代表一个实体（人、组织、产品、技术、地点、概念……）
- 边（Relation/Edge）：代表实体之间的关系，边是有类型的
(张三) --[属于]--> (研发部)
(研发部) --[负责]--> (订单重构项目)
(订单重构项目) --[产出]--> (订单系统)
(订单系统) --[依赖]--> (库存系统)
用图把上面的关系链画出来，就能回答「张三参与的项目用了哪些系统」——沿着图走一遍就到了。
2. 和关系型数据库的区别
🔒 以上为本章部分预览（约 10%）
本章剩余 90% 内容包含：关键源码逐行拆解、设计细节与工程权衡、代码示例与生产实践要点。
💡 本次展示的仅为部分预览内容（约 10%）。完整的源码深度解析包含每一个技术点的完整实现细节。点击上方按钮扫码加入知识星球，解锁全部内容。
