知识图谱、向量数据库embedding、大模型这三个词放到一块最近几乎成了AI应用开发的必修课。我在这个系列的上一篇聊过纯RAG的做法评论区被问得最多的一个问题就是既然已经有了向量库为什么还要再提知识图谱反过来也一样有了图谱还要向量库做什么这篇文章我就把这三者的关系一次性拆清楚。我会从大模型本身的“记忆短板”讲起再分别说embedding、向量数据库、知识图谱各自的定位最后给出一套在DeepSeek这类基座模型上做混合问答的落地Demo以及我实际跑下来踩过的坑。1. 从大模型的“记忆短板”说起为什么这仨技术总是同时出现1.1 大模型的三个硬伤时间截止、无可引依据、窗口有限想要理解知识图谱、向量数据库embedding和大模型的关系得先搞清楚一个前提大模型并不是一个靠谱的“知识库”。模型参数里存的是训练语料压缩后的统计规律不是原文。你可以把它理解成一个记忆力超强但从不复习的优等生考试范围内的知识他掌握得很好但考试范围之外的内容他会一本正经地现场编。更麻烦的是就算是他真背过的内容他也说不清楚出处因为参数里根本没有“哪句话来自哪个文档”这回事。我实际开发中遇到的典型问题可以归成三类知识陈旧。训练语料有截止时间新出的政策、产品公告、内部制度模型一概不知道。无法溯源。你问一个专业问题模型回答得像模像样但你要他给出文档依据他给不出来。上下文塞不下。理论上可以把知识全塞进提示词但token窗口有限几千字的小文档还好几十万字的企业知识库根本塞不进去。所以“外挂知识”几乎是必然的选择把知识放到模型外部需要回答问题时先检索再把检索结果交给模型组织成答案。1.2 把“记忆”外包出去embedding管记、图谱管关系、模型管说话一旦接受“外挂知识”这个思路三个技术各自的定位就清晰了。embedding负责把文字变成模型能计算的向量向量数据库负责把这堆向量存起来并快速找出语义相近的内容。这套组合解决的是“模糊记忆”的问题你说“怎么开通退款”库里存的是“退款流程操作指引”两者字面上差异不小但语义接近向量检索能捞出来。知识图谱解决的是“精确关系”的问题。向量检索只知道“这两句话意思接近”但不知道“张三负责哪个项目”“项目A和项目B是否属于同一个团队”。这些问题需要实体和关系组成的结构化网络才能回答。大模型则负责最后一个环节把检索出来的零散内容组织成通顺、可读、符合当前问题语境的自然语言答案。所以你看这三者不是替代关系而是链条上的不同环节。2. embedding和向量数据库先让机器能“模糊记住”语义2.1 embedding的本质把句子变成坐标离得近就是意思近embedding这个词听起来玄乎本质其实很简单把一个词、一句话、一个段落映射成一个高维空间里的坐标点。这个映射有个关键特性语义相近的文本在向量空间里的距离就近。我经常用水果摊类比——你可以把向量空间想象成一个巨大的城市地图“水果”相关的句子都住在城东“编程语言”相关的句子都住在城西。你问“怎么挑新鲜苹果”系统去城东找而不是去城西翻索引。还有一个很实用的特性embedding处理的是语义相似不是字面相似。比如“iPhone”和“苹果手机”字面上差很多但向量距离会非常近而“苹果”在句子里的上下文要是“水果批发”向量又会偏向水果那个方向。也就是说同一个词在不同语境下会有不同的向量倾向这是向量检索优于传统关键词匹配的重要原因。2.2 向量检索的工作链路切块、向量化、相似度召回要做一套向量检索链路其实是固定的我拆成四步把原始文档切成合适的块。这一步很关键后面专门讲坑。把每一块文本丢给embedding接口得到一组高维向量。把向量和原始文本一起写入向量数据库。查询时把用户问题同样转成向量在数据库里做相似度搜索取最相关的topk块。这里的核心操作是“相似度计算”。向量数据库会维护一套索引结构用近邻检索算法快速逼近“最相似的topk结果”而不是全量逐个比对。说白了向量数据库其实等于“专门为向量相似检索优化的存储加索引方案”。查询时最常用的相似度是余弦相似度数值范围一般落在0到1之间越接近1代表越相似。我一般把返回阈值设在0.75到0.8附近低于这个阈值的内容基本都会判为“不相关”。2.3 向量库的边界能召回但看不见“关系”向量库很好用但它有一个天然边界它会告诉你“这段话和问题相关”却完全不理解“话里的实体之间是什么关系”。举个例子。库里存了三句话“张三负责项目A的数据接入。”“李四负责项目A的客户沟通。”“王五负责项目A的验收测试。”你问“项目A都有哪些人参与”向量检索可能把这三句都捞出来没问题。但你要是问“项目A里谁负责对外沟通”这就麻烦了——假设库里正好没有“对外沟通”这个原话而是写着“李四经常和客户对接需求、同步进展”向量检索的命中率就开始飘了。它可能把张三和王五的内容也当成相关结果排进来。这类问题涉及“人——职责——项目”的关联判断本质上是关系推理不是语义相似。知识图谱就是来解决这个问题的。3. 知识图谱补上的那一环精确的“关系”而不是模糊的“相似”3.1 从三元组到图图谱到底在存什么知识图谱的存储单位是“三元组”头实体、关系、尾实体。比如张三 — 负责 — 项目A张三 — 属于 — 数据组数据组 — 承接 — 项目A的数据接入把这些三元组连起来就形成了一张图。节点是实体边是关系还可以给节点挂属性比如“项目A的上线时间是3月15日”。跟文档切块embedding那条线比起来图谱更像在做结构化建模。建图之前你得先想清楚本体结构系统里有哪几类实体比如人、项目、组织、文档哪几类关键关系比如负责、属于、承接哪些属性值得记录比如排期、状态。这一步是纯人工设计也是这个系列文章里最难自动化的一部分。大模型能帮你从文本里抽出“张三负责项目A”这类三元组但“人、项目、组织”这一层的本体定义靠的是对业务的理解。3.2 多跳查询向量库答不好图一“跳”就出来图谱最大的价值是支持“多跳查询”。这是它和向量检索差异最明显的地方。回到前面那个例子。你的问题是“数据组的人参与了哪些项目”如果靠向量检索你得指望文档里恰好有一句话把这两件事写在一起。但用图就简单了先找节点“数据组”。沿“拥有成员”这个关系找到张三、李四、王五。再沿“负责”关系找到项目A、项目B、项目C。这三次跳转在图数据库里是常规操作而且结果具有确定性找到了就是找到没找到就是没找到。向量检索做不到这种精确性它只会给你一堆“看起来相关的段落”到底成不成立还得人去看。我在实践中对两者的理解可以凝结成这样一句话向量库回答的是“哪个文档提到了相关话题”图谱回答的是“哪些实体之间存在确定关系”。3.3 图谱的构建成本比想象中重但模型可以帮忙不过你别高兴太早知识图谱的构建成本明显高于向量库。向量库只需要切块、调embedding接口、入库简单粗暴。图谱需要做实体抽取、关系抽取、实体对齐、共指消解。所谓实体对齐指的是“某科技公司”和“某科技股份有限公司”明明同一个实体需要合并成同一个节点。这个活如果全靠人工维护成本非常惊人。好消息是大模型可以大幅降低这部分成本。我现在的做法是让DeepSeek批量从文档中抽取三元组输出成结构化的JSON再走一套清洗脚本做实体对齐去重最后人工抽查关键实体。这样图谱构建速度能快很多但最终的实体对齐质量仍然需要抽检不能完全交给模型。4. 三者真正配合起来的长相三种可落地的搭配模式既然前面说了那么多区别那你可能已经猜到实际项目里不是“二选一”而是根据问题类型来搭配。我梳理了三种自己常用的模式。4.1 模式一纯向量RAG八成的日常问答都够用流程用户提问 → 问题向量化 → 向量库召回topk文本块 → 拼接提示词 → 模型生成答案。适合的场景文档问答、客服知识库、政策解读、合同条款查找之类的对“关系推理”要求不高的场景。这个模式我用了很久最直观的体会是“快”。不需要建本体不需要做实体对齐文档往里一丢就能用。我估计八成以上的知识库问答需求这一步就够满足了。4.2 模式二图谱结果当事实约束模型只负责做表达流程用户提问 → 解析出实体和关系 → 在图谱中执行查询 → 得到结构化结果 → 让模型把结果组织成自然语言。适合场景人事组织查询、项目依赖查询、供应链关系分析、合规关系核查这类“必须精确、可解释”的场景。这个模式里模型不再负责“回忆事实”而是负责把图里查到的“确定答案”翻译成口语化的回复。比如图的查询结果是“张三、李四、王五”模型负责输出“根据项目记录项目A主要由张三、李四、王五参与其中张三负责数据接入李四负责客户沟通王五负责验收测试。”整个回答都有据可查。4.3 模式三图向量混合检索先用“相似”定位再用“关系”校验流程用户提问 → 先向量召回相关文本块/候选实体 → 再把这些候选实体放回图谱做关系路径查询 → 用图谱结果筛选和补充上下文 → 最终拼接给模型。适合场景既需要开放语义召回、又需要精确关系的复杂问题比如“哪些项目存在客户沟通延期风险”这类问题既涉及关系谁负责、哪些项目延期又依赖开放语义理解“延期风险”在文本里的多种说法。我实测混合模式在召回质量上是最稳的但代价是链路更复杂、延迟更高。适合对准确性要求高的中大型系统不适合轻量级Demo。三种模式我经常用一张表格做对比维度纯向量RAG图谱事实约束图向量混合数据建模无固定结构本体三元组两者都要查询方式向量相似度图路径查询向量召回图校验擅长问题语义相关、模糊开放精确关系、多跳推理复杂混合型构建成本低高最高维护成本低中高高回答可解释性一般强强5. 一个最小可跑的DeepSeek混合问答Demo光讲概念会飘我上个自己搭过的混合问答Demo场景是模拟项目X内部的知识问答助手要回答“谁在负责客户成功模块的上线排期”这类问题。5.1 数据准备同一份文档走两条不同的预处理链路文档是同一批项目周报和人员分工说明但预处理必须分两条腿走。第一条链路走向量化把文档按逻辑段落切块每块调用embedding接口转成向量连同一小块原文一起存入向量数据库。这个路径负责“开放语义召回”。第二条链路走图谱化用模型从文档里抽取三元组重点是抽人物、项目、里程碑、负责人这类业务实体把它们之间的“负责”“属于”“排期在”关系清洗后写入图数据库。这个路径负责“精确关系定位”。我把两条链路的输出都暴露成统一接口查询阶段按需组合。5.2 检索阶段的代码骨架向量召回与图谱查询并行下面是核心检索流程的示意代码我用JavaScript写方便你们直接调整。关键点是并行调用两条链路最后做结果合并。// 假设已有以下封装 // vectorSearch(question, topK) —— 向量库召回文本块 // graphQuery(sparqlLikeQuery) —— 图数据库查询 async function hybridSearch(question) { // 1. 向量召回先找出和问题语义最相关的文档块 const vectorHits await vectorSearch(question, 5); // 2. 图谱查询从问题里解析出关键实体如“客户成功模块”“上线排期” const entities extractEntities(question); // 这一步可以用DeepSeek做 const graphHits await graphQuery( MATCH (p:Person)-[:负责]-(m:Module {name: ${entities.module}}) WHERE m.status 排期中 RETURN p.name, m.name, m.deadline ); // 3. 合并图谱结果作为强事实向量结果补充上下文 return { facts: graphHits, contexts: vectorHits, }; }这里有个容易忽略的细节extractEntities这一步是纯规则解析还是用模型解析直接决定效果。我建议对这类固定业务问题优先做一组简单的规则模板解析实在覆盖不了再上模型。规则模板更快、更省token而且结果稳定。5.3 提示词组装强制模型使用检索结果而不是自由发挥检索完成后最后一步是把事实和上下文拼进提示词让DeepSeek生成回答。这一步的灵魂在于你必须明确告诉模型“用检索结果回答禁止自由发挥”。我常用的提示词长这样你是项目知识问答助手。请严格基于下面提供的检索结果回答问题。 【图谱事实】 - 张三 负责 客户成功模块排期至3月15日 - 李四 负责 客户成功模块的客户沟通 【文档上下文】 这里放向量召回的相关文本块用分隔线隔开 要求 1. 只使用上述信息作答不要引入你自己的知识。 2. 如果检索信息不足直接回复“相关信息不足无法确认”。 3. 回答时把事实来源说清楚例如“根据项目周报张三负责……”这样写的效果很明显模型不再“自由发挥”而是老老实实充当一个表达层。你给它的图谱事实越完整它的回答越精确。6. 实测踩坑与选型建议哪些环节最容易翻车6.1 切块与embedding模型的选择直接影响召回质量切块这件事我一开始是图省事按固定字符数切的512个字符一刀切结果效果惨不忍睹一个完整段落被拦腰切断语义不完整embedding出来的向量自然也不准。后来改成按段落切再按小节的二级标题做边界控制召回命中率明显上升。核心逻辑是embedding的输入语义越完整向量表达越准确。给模型喂“半个观点”和“一个完整观点”距离完全不一样。另外embedding模型的选择也很关键。不同模型的向量维度差异很大有768、1024、1536、3072等等。维度高信息容量大但存储和检索开销也高。我自己的建议是先粗测两三个常用模型的召回效果再看维度和成本不能只看名气。6.2 实体对齐是个老实的脏活做不好图谱就白建这是我在图谱项目上吃过的最大暗亏。同一个实体在文档里可能有好几种写法“某科技公司”“某科技股份有限公司”“某科技集团”。如果抽取时不归一化它们会被当成三个不同的节点存进图里。这时候你查“某科技集团负责的项目A”答案是空——但张三明明就在干这个项目。实体对齐没有捷径本质上就是个字段清洗加归一化的脏活。我的处理顺序是先做文本级归一全角半角、大小写、公司后缀统一。再用规则做别名映射维护一张同义实体表。最后用模型做剩余模糊匹配但结果必须有人工抽检。我后来定了一条规矩图谱上线前重点实体的人工核对覆盖率不能低于100%。别嫌麻烦这个坑掉进去一次就长记性了。6.3 什么时候别用知识图谱也别用向量库最后说点反直觉的。我见过不少项目明明问题很简单非要上全套向量库加图谱加模型搞了三个月还在调实体对齐。后来一问核心需求就是“政策文件里有没有提过某某条款”——这其实根本不值得上向量库更不需要图谱。关键词检索加数据库查询一天就能搞定。反过来也别事事都问图谱。如果你业务里几乎没有“关系推理”“多跳查询”这类需求纯RAG的性价比远超图谱。根据我个人实操经验比较好的做法是先收集20到30个真实业务问题做一个小评测集分别用纯向量RAG和图谱方案跑一遍看哪个方案在关键问题上的准确率更高、维护成本更可控。让数据说话而不是凭感觉拍板技术选型。这一步做完你要不要建图谱、怎么建图谱答案基本就自己出来了。