向量、图谱与混合知识表示:从语义检索到可解释问答的演进

📅 发布时间:2026/10/17 9:42:36
向量、图谱与混合知识表示:从语义检索到可解释问答的演进
1. 知识表示为什么值得反复讨论三个时代其实就是三笔账做AI落地做的久了你会慢慢发现一个规律模型结构再花哨真正卡住项目的往往不是算法而是知识怎么放进机器里。同一份文档、同一套业务规则用什么形式组织起来直接决定了后面搜索、问答、推荐、风控这些环节的天花板。这也是AI知识表示这个老话题每隔几年就被翻出来重新聊一遍的原因——从规则符号到向量从向量到图谱再到今天大家都在提的混合结构表面上是一次次技术换代本质上是在围绕同样三个问题算账机器要理解什么关系要不要显式存下来推理路径有没有地方可以走。这篇文章想聊的就是这个演进过程向量时代怎么把语义变成了可计算的距离图时代怎么把丢失的关系重新捡了回来以及现在所谓混合时代到底混的是什么。适合正在做知识库问答、搜索排序、推荐系统、企业智能助手的工程师和技术负责人看尤其适合那种手里已经有一堆向量检索结果但落地效果总觉得差点意思的团队。开聊之前先摆一个我自己的判断向量、图、混合这三种表示不是替代关系更像是三笔互相补账的账理解每一笔账的收支比追新概念重要得多。为什么这么说因为知识表示的本质是决定系统看得见什么和看不见什么。你用向量表示一段文本系统天然擅长感知相似语义却很难完成多跳推理你用图表示业务实体系统擅长追踪关系链路却对模糊表达束手无策。所谓演变就是每一代表示方法都在放大自己擅长的那部分同时把上一代漏掉的东西想办法补回来。下面我按三个阶段的真实处境把这些账一笔一笔摊开。2. 向量时代Embedding把世界揉成了数字也把关系磨平了2.1 向量表示做对了什么把无序文本变成可检索的语义坐标向量知识表示的核心思想并不复杂把一句话、一段文档、一个用户行为映射到一个固定维度的数值数组里让语义相近的内容在空间里距离更近。这个方向从词向量的词汇类比现象被验证之后一路演化到今天的句向量、指令向量和多模态向量成了几乎所有AI系统的地基。和早期基于关键词的倒排索引相比向量检索的最大进步是解决了用词不同但意思相同的问题比如用户搜怎么退款系统能找到标题是取消订单后款项如何退回的文档这在纯词法匹配时代几乎做不到。它的工程优势也非常明显。一是计算模型成熟余弦相似度配合近似最近邻索引HNSW这类算法可以在百万级甚至亿级向量里做到毫秒级召回二是接入成本低不需要人工整理任何关系结构语料扔进去训练或调一下现成模型就能出向量三是天然适合规模化数据量增长时只需要扩充索引不用重画数据模型。我见过不少团队在早期就把所有文档灌进向量库搭一个简单的搜索或者问答原型效果往往比想象中好这也是向量时代能够快速铺开的重要原因。2.2 单向量结构的三个硬伤相似性不等于逻辑性但用久了你会发现向量表示有个绕不开的问题它擅长像不擅长是。更准确地说单向量结构在处理复杂关系时有三处明显的短板。第一个短板是关系运算缺失。经典例子是国王-男人女人≈王后这套词向量的空间运算在单词级别上看起来很神奇可一旦到了业务级关系就失灵了。例如某项目的负责人同时是另一个项目的审批人这种组合关系用向量只会得到一个模糊的相似度分数系统完全不知道负责人和审批人在逻辑上是两条不同的边。第二个短板是多跳推理困难。用户问和小王有关联的公司里哪些在最近三个月变更过法人这类问题在向量时代基本是无解的。向量检索能找到小王和公司变更法人各自相关的碎片但要跨两跳、三跳做路径追踪单个向量的空间里根本没有边可以走唯一的办法是外部程序去拼接拼接起来既慢又不稳定。第三个短板是约束表达薄弱。业务场景里常有金额大于十万且状态不是待审核这类条件约束向量能表征语义却很难表征精确的阈值和状态枚举。你可以在查询时把条件写成过滤子句但过滤条件一多向量召回的候选集往往被切得七零八落整个检索流程变得又脆又难调。2.3 我只用向量做知识库问答被高相似度碎片坑了一次这些短板在理论上不难理解真正让我印象深刻的是一次实际踩坑。当时在给某企业内部做客服知识库问答资料是全量产品手册加售后政策初版方案很朴素文档切片、向量化、相似度召回、大模型根据召回内容生成答案。原型demo跑起来效果挺惊艳领导看了也觉得行结果一上线真实业务就露馅了。用户问发票抬头能不能修改系统召回的Top片段里全是如何开具发票和发票丢失补办流程每一条的向量相似度都在高位可没有一条真正回答能不能改。大模型只能从这些似是而非的片段里硬挤答案最后经常生成发票开具后无法修改但可以补办这种听上去正确、实际上误导的回复。我后来分析了一下问题就出在向量表示把所有内容都揉成了语义坐标发票开头标题与发票修改离得很近但文档之间真正的内容边界、主题层级和依赖关系被完全压扁了。这件事逼着我做两件事一是重新设计切片的粒度让每个切片只围绕一个明确的主题二是开始研究能不能给碎片之间加上显式的关联。后者正是我走进图时代的直接原因。所以如果你现在用向量纯召回也遇到这种高分但答非所问的情况先别急着换模型可以考虑一下是不是知识表示的结构缺了关系这一层。3. 图时代三元组和图神经网络找回了关系这个变量3.1 图结构保留了AI最缺的上下文链条图知识表示的核心是把知识拆成节点和边节点代表实体或概念边代表关系。一张发票是节点发票抬头是否能改涉及的开票规则是节点它们之间用受约束于属于流程适用条件这些边连起来这就是知识图谱。比起向量那种把所有信息压缩进坐标的做法图结构最大的价值是让关系变得可见、可追踪。推理某个问题时系统可以沿着边一步步走而不是在语义空间里猜距离。为什么这个特性对AI落地那么重要我举个例子。同样是回答这个订单为什么不能取消如果只有文档向量系统看到的是订单状态异常无法取消和取消条件包括未发货两个碎片如果有一张图订单节点连着状态节点状态节点连着取消规则节点规则节点又连着例外条件节点系统就能把整条链路完整展开回答的时候既知道结论也知道结论依赖哪些前置条件。这种可追溯的上下文链条正是企业级应用里最看重的部分也是图时代能站住脚的根本原因。3.2 图神经网络让图从静态数据变成可计算表示早期的知识图谱更多是查询用的查一条路径要写各种图查询语句和图谱无关的文本处理还是靠传统方法。真正让图进入AI表示舞台中心的是图神经网络这类方法的普及。GCN也好、GraphSAGE也好核心思想都是沿着边做消息传递每个节点的表示向量不断聚合邻居节点的特征经过多层传播之后节点向量里自然就带上了多跳邻居的信息。这套机制解决了一个老问题图里的每个节点不再只是一个孤立的ID而是可以像向量一样被计算、被比较。节点之间有没有潜在关联可以算某个新实体应该归类到哪可以算两个看起来毫无关系的子图之间相似度有多高也可以算。这就把图的离散结构拉回到了向量空间里做统一运算。相比之下纯向量不具备这种沿关系传递的机制纯图又难以处理模糊语义两者的优势恰好是互补的。我在实际项目中用过图神经网络做关联交易风险排查。把公司、法人、股东、供应商、银行账户作为节点把持股、任职、交易、担保作为边模型训练完成之后能自动把某公司A通过多层持股关系间接关联到某高风险实体B这样的路径算出来。这在纯向量系统里几乎不可能实现因为向量空间里根本没有持股任职这种可以上下传播的边。3.3 图表示的天花板稀疏、离散、生命周期成本高图知识表示也不是神药它的代价在真实落地时比想象中更大。最常见的三个问题第一是稀疏性新业务上线的头几个月图谱里的节点和边数量少得可怜邻居信息不足图神经网络训练出来的表示质量明显偏差而向量模型反而能在只有少样本的情况下借用预训练语义。第二是强离散性图上的规则和类型体系都需要人工设计新增一种关系类型往往要给整张图做一轮迁移和校准状态流转远不如向量加几条数据那么灵活。第三是建造成本把非结构化文档变成结构化三元组需要写抽取规则或调用大模型做信息抽取准确率不够还要人工复核很多团队建模建到一半就被治理工作拖垮了。所以图时代并没有取代向量时代它更像是一次补课把向量丢失的关系结构补了回来。两者是不同维度上的能力一个管语义感知一个管结构推理。真正有意思的事情从这里才开始既然各有各的短板那能不能把它们拼起来用这就是混合时代要回答的问题。4. 混合时代向量、图和生成模型的三类融合拼法4.1 拼法一向量召回加图扩展把RAG升级成可解释问答最直接、也最容易落地的混合方案是把向量检索和知识图谱串在一条链路上。第一跳先用向量做语义召回把用户的问题映射到一批候选文档、候选实体或候选片段上第二跳根据召回结果在图谱里做扩展把相关的上下游节点、路径和规则拉出来最后把向量召回的文本和图谱扩展出的结构化信息一起交给大模型生成答案。这么做的好处很明显向量负责接住用户的模糊表达图负责提供逻辑支撑。用户问发票能不能改向量先命中发票开具流程这个节点图紧接着把这个节点连着的修改规则例外情形适用场景全部取出来大模型的回答就有了依据而不是凭几个相似片段硬凑。我在客服问答项目里把链路改成这种向量召回图扩展之后同一批测试问题里答非所问的比例下降了一大截而且回答里能明确说出根据某条规则只有未开具的发票允许修改用户和业务方都更容易接受。这套方案对现有系统改造很小基本不需要重新训练模型只需要把图谱和检索逻辑接进去。我建议想做混合方案但还没头绪的团队从这个拼法起步。4.2 拼法二图嵌入与向量嵌入联合训练让两种表示互相校准比串行调用更深度一点的融合是在表示层面直接把图结构和向量语义捏在一起。常见做法是把文本、实体、关系统一嵌入到同一套向量空间里文本片段有文本向量图谱里的每个节点和每条边也有对应的嵌入向量训练时同时用语义相似性和图结构关系做监督信号。这样得到的表示既包含语义信息又保留了拓扑上的多跳关系查询时既可以从文本匹配进入也可以从关系路径进入。这种方案的优势在于表示统一下游模型处理起来省事代价是训练流程复杂需要同时维护语料和图谱还要设计联合训练的损失权重。如果你面临的业务数据规模很大而且文本和图谱都相对完整联合嵌入能带来更平滑的检索效果。我在一个商品推荐场景里试过类似思路把商品名、商品类目、品牌关系、用户行为序列放到统一空间里做召回相比纯向量召回长尾物品的覆盖率提升明显因为它能借助类目和品牌的图结构关系来补足长尾物品的语义稀疏问题。4.3 拼法三大模型负责生成图谱负责前后对账混合时代一个容易被忽略的方向是让大模型和图谱互相做质量保障。大模型擅长生成自然语言和抽取信息图谱擅长存储结构化的确定性事实二者可以形成一个闭环大模型从非结构化文档中抽取实体和关系自动构建或者更新图谱反过来图谱里的结构化约束用来校验大模型生成的内容有没有事实性越界。我印象很深的一次实践是在做行业研报知识库时大模型抽取关系经常会漏掉时间限定和数据口径这些关键前提导致图谱里出现大量某指标持续增长这种缺少上下文的边。后来我们把抽取环节设计成了大模型初抽、规则校验、图谱回灌、人工抽检四步虽然不可能做到百分之百准确但至少让图谱里的每条边都有了可追溯的来源文档。反过来问答时如果大模型生成的结论和图谱里的已知事实直接冲突系统会中断生成并提示该结论与现有资料不一致请更新资料后再提问。这种前后对账的机制就是图时代和向量时代都单独做不到、只有混合结构才能提供的稳定感。4.4 融合排序的实际调参经验从双路召回看精排取舍混合方案踩过的坑里最普遍的是两路结果怎么合并。向量召回返回的是相似度分数图扩展返回的是路径得分或者规则命中数量两者量纲不同直接加和几乎没有意义。我的做法是构建一套简单的两阶段流程先用向量和图各自召回优先候选控制在几十条量级再用一个轻量排序模型或者规则公式统一打分。打分时不要只盯着分数本身最好加入业务实体匹配度、路径长度、规则优先级这些可解释特征。以我的客服项目为例最终打分公式大致是综合分 向量相似度权重 图路径强度权重 业务规则命中加权。三个权重初始按经验设为接近的比例然后靠一批线下标注数据来调。调参本身没有标准答案不同业务差别很大但有两条对大家都适用的经验。第一召回阶段的指标看覆盖率精排阶段才看准确率图扩展主要负责把向量漏掉的多跳相关内容补回来这时候不要过度追求图谱返回的每条记录都精准否则会漏掉真正有用的间接信息。第二评估集一定要带真实业务问题不建议只用公共数据集因为公共集里很少会出现你画边界、设条件这些图关系最占优的问题类型。5. 回到选型哪种知识表示适合你的场景附实际取舍5.1 三种表示的能力对照表聊完演进史最终话题还是要回到决策上我的项目到底该选哪种先把三个方向的典型能力差异摊开方便对照。维度向量表示图表示混合表示擅长任务语义相似检索、模糊匹配、文本分类多跳推理、路径分析、关系约束复杂问答、事实校验、可解释检索数据前提任意文本冷启动快需要有结构的三元组或图谱文本和图谱都要具备一定规模关系能力弱关系被压平强关系显式存在强关系与语义互补推理能力弱需要外部程序拼接中到强可沿路径传播强可解释性强建造成本低调模型灌库即可高建模抽关系工作量大中高两套体系都要维护典型场景RAG、语义搜索、初版召回风控、关联分析、权限链企业知识库、助手问答、业务决策从这个表能看出一条比较清晰的选择路径如果你的业务问题本质上是从一堆内容里找最像的那几段纯向量方案足够不要迷信混合框架如果问题是沿着关系链条查清楚来龙去脉那图表示是刚需向量只能做辅助入口而一旦你的系统既要面对自由输入的模糊问题又要给出精确可追溯的结论混合结构基本是躲不开的方向。5.2 我的默认建议先小步混合再决定深度选型这件事最怕一上来就奔着完整混合架构去设计。我的建议是先做小范围混合跑通再扩。具体操作是保留现有的向量检索不动先把数据里最关键的那部分实体和关系抽出一个小图谱比如只覆盖高频问答涉及的几十个节点然后用向量召回图谱扩展这条链路做一个受控实验拿真实问题集对比纯向量方案的指标变化。小图谱建起来很快一旦发现效果确实提升了再逐步扩大图谱覆盖范围万一效果不升反降损失也有限不会拖垮整个项目。这种渐进式混合的思路也是我踩过几次坑之后的直接体会。过早建设大而全的知识图谱抽出来的关系大半年都用不上纯属沉没成本而不做图谱直接加大模型又会长期困在高分片段误导推理的泥潭里。先把最小闭环跑通让业务反馈来推动图谱扩展方向是比较务实的节奏。5.3 防止技术叙事绑架你的判断最后想聊一个容易被忽略的问题技术圈里的时代叙事有时候会误导决策。每次看到向量时代结束图谱回归混合架构是终局这类说法我都会提醒自己那是叙事逻辑不是选择逻辑。向量没有那么神也没有那么快过时图从来没有真正退出过只是以新的形态回到聚光灯下混合结构也不是银弹它的前提是数据治理能力和图谱维护成本都得扛得住。真实的业务系统里多数情况是三种表示并行存在底层用向量做大规模初筛中层用图做关系精排和解释顶层用大模型做生成和交互。这个状态大概率会延续很久因为它对应的是不同层次各自算得最舒服的那笔账。与其纠结哪个时代赢了不如把注意力放在自己的数据结构和业务问题上——机器能不能看出关系模型能不能给出理由用户能不能信任结果这三个问题永远比用哪种表示更本质。