知识图谱 + LLM：超越向量检索
向量检索擅长"语义相似"，却搞不定"关系推理"——"谁是谁的上级"、"A 产品依赖哪些组件"。知识图谱补上这一刀。本文讲清知识图谱相对向量库的优势、GraphRAG 的思路、什么场景值得上图谱，以及务实的落地建议——别为了酷而上图谱，多数场景向量库够。
本文要点
- 主题聚焦：大模型、RAG
- 适合人群：独立开发者、全栈工程师、AI 应用开发者
- 核心价值：快速理解背景、实践路径、常见误区和工程建议
向量检索是 RAG 的主力，但它有个结构性短板：它理解"语义相似"，不理解"关系"。
问"张三的直属下级是谁"——向量库只能找"提到张三"的文档片段，很难精准答出关系链。问"这个功能依赖哪些模块"——向量召回的是"提到依赖"的文字，不是真实的依赖图。
知识图谱（Knowledge Graph）补上这一刀。这篇讲它和 LLM 怎么结合，以及什么时候值得上。
一、向量检索的天花板
向量检索的本质是"语义相似度匹配"。它强在：
- 模糊语义（"部署"≈"上线"）。
- 跨语言、跨表达。
- 找"相关"内容。
但它弱在：
- 多跳关系。"A 的经理的经理是谁"——要顺着关系链走两跳，向量做不了。
- 结构化约束。"2023 年 Q3、华东区、销售额 > 100 万的客户"——精确条件组合，向量召回不准。
- 全局视图。"整个产品线的组成结构"——需要图的全局，不是片段。
这些恰恰是知识图谱的强项。
二、知识图谱补的是什么
知识图谱用"实体 + 关系"结构化知识：
(张三)-[管理]->(李四)
(李四)-[属于]->(销售部)
(销售部)-[负责]->(华东区)
它能：
- 多跳推理：沿关系链走 N 跳（张三 → 李四 → 销售部 → 华东区）。
- 精确查询：结构化条件（WHERE region='华东' AND role='销售'）。
- 全局结构：整个图的拓扑（产品依赖树、组织架构）。
向量管"模糊相关"，图管"精确关系"。 复杂知识问答，两者结合比单用任一都强。
三、GraphRAG：图谱 + 生成的结合
GraphRAG 的思路：先从文档构建知识图谱，检索时图查询 + 向量检索结合，生成时把两者的结果都喂给模型。
流程：
- 建图：用 LLM 从文档抽取实体 + 关系，入图数据库（Neo4j、memgraph，或 PG + Apache AGE）。
- 查询：用户问题拆解——结构化部分走图查询（Cypher），语义部分走向量检索。
- 融合：图查询的精确结果 + 向量召回的相关片段，一起作为上下文。
- 生成：模型基于融合上下文回答。
举例："我们产品 X 用了哪些开源组件，各自许可证是什么？"
- 图查询：
(产品X)-[依赖]->(?组件)-[许可证]->(?许可)精确拿到依赖链和许可。 - 向量：补充"这些许可证的注意事项"的语义文本。
- 融合答：精准且完整。
纯向量做这个，要么召回不全（漏依赖）、要么不准（把"提到许可证"当答案）。
四、什么场景值得上图谱
知识图谱不是免费午餐——建图、维护、查询都有成本。别为了"先进"上图谱。值得上的场景：
- 关系密集。组织架构、供应链、产品依赖、知识体系——实体间关系是核心。
- 多跳推理常见。用户经常问"A 的 B 的 C"这类链式问题。
- 结构化约束多。精确条件组合查询（时间/区域/属性过滤）。
- 全局视图重要。要看整体结构，不是单点。
不值得上的场景：
- 文档型问答（"这份手册写了什么"）——向量够。
- 单跳事实查询——向量 + rerank 够。
- 数据量小、关系简单——杀鸡用牛刀。
经验：90% 的 RAG 场景，向量 + rerank 够用。只有那 10% 关系密集、多跳推理的场景，图谱才值得。 别被"GraphRAG 更先进"的话术带偏。
五、落地的现实门槛
上图谱的真实门槛：
- 建图成本。从非结构化文档抽实体/关系，要 LLM + 人工校验，质量决定图谱可用性。抽错了，图就是错的。
- 维护成本。数据变了，图要更新（增量建图比向量索引复杂）。
- 查询复杂度。Cypher/图查询要专门技能，比 SQL/向量检索门槛高。
- 和现有栈集成。多数团队栈是 PG/向量库，加个图数据库是额外运维。
务实路径：先用 PG + pgvector + Apache AGE（PG 的图扩展）小规模试，真需要再上专门图库（Neo4j）。别一上来 Neo4j 重型部署。
六、轻量替代：用结构化表代替图
很多时候你以为需要图，其实结构化关系表就够：
- "用户 → 部门 → 区域"这种层级，PG 里几张关联表 + JOIN 就能查，不必上图。
- "产品 → 组件"依赖，关系表 + 递归查询（PG 的 WITH RECURSIVE）能做多跳。
图数据库的价值在"任意复杂的、网状的、高频多跳"的关系。简单的层级/树/一对多，关系型数据库足够。别把"关系数据"等同于"需要图数据库"。
七、混合检索的正确姿势
生产级复杂知识问答，正解常常是三层混合：
用户问题
→ 意图判断: 结构化查询 / 语义检索 / 都要?
→ 并行: 图查询(精确关系) + 向量(语义) + 关键词(精确词)
→ 融合(RRF / 加权)
→ 生成(带引用)
不是"向量 vs 图谱"二选一，而是按问题类型路由到最合适的检索方式，再融合。这才是当前知识问答的前沿做法。
小结
知识图谱 + LLM 是向量 RAG 的有力补充，但不是替代：
- 向量：模糊语义、相关检索（90% 场景的主力）。
- 图谱：精确关系、多跳推理、全局结构（10% 关系密集场景）。
- 混合：按问题类型路由 + 融合，是复杂问答的正解。
记住一句：别为了"先进"上图谱。 先把向量 RAG 做扎实，确认关系推理是瓶颈（用户真在问多跳关系），再上图谱——而且优先用 PG 的轻量方案试。图谱是"向量不够用时"的利器，不是 RAG 的默认配置。把它用在真正需要它的地方，才是它的价值。
Related