知识图谱推理和向量检索怎么选 —— 两类本体查询的工程差异与适用边界

引言相似不等于相关相关也不等于有关系企业把本体语义接入 AI 后常见的选型问题是已经有向量检索了为什么还要做知识图谱。答案不在“哪一种技术更先进”而在两种查询回答的不是同一个问题。向量检索擅长从名称和描述中找到语义相近的本体知识图谱推理擅长沿实体和关系找到业务链路。向量空间JBoltAI的代码把这两条路径分成独立服务再通过本体语义工具和流程日志协同。理解这个边界才能避免把跨系统关系问题继续交给相似度匹配。一、向量检索解决的是“先找到谁”本体语义检索能力的职责很明确接收关键词返回本体的基本信息。它不是完整的本体查询也不负责解释实体之间的业务关系。默认的检索参数包含前 10 个候选本体、相似度阈值 0.4。这个默认值只能说明当前实现的起始参数不能直接当成所有业务域都适用的推荐值。业务术语短、同义词多或描述不完整时仍然需要根据运行日志调整检索范围。底层向量库使用独立的集合保存本体向量。向量内容只由本体名称和描述组成不包含属性。集合的创建、删除旧向量和写入新向量由统一的底层服务负责。这带来一个经常被忽略的限制如果用户问“订单有哪些状态以及每个状态允许什么操作”仅靠向量检索是不够的。它可以把“订单”这个本体找出来却不会因为相似度高就自动补出状态属性、规则和关系。属性查询需要走另一条专门的结构化路径关系查询需要走图谱推理工具。向量检索适合三个入口。第一用户使用自然语言描述业务概念系统还不知道对应的本体 ID。第二多个本体名称相近需要用描述做初步筛选。第三作为图谱查询前的候选发现先把问题映射到少量核心实体再进入结构化关系查询。二、知识图谱推理解决的是“它们怎么连接”图谱查询的输入不是一段模糊关键词而是业务模型 ID 和一组核心本体 ID。关系查询工具描述要求调用方只传与问题直接相关的种子本体。后端再根据图中的关系补全中间节点而不是让智能体把模型中的全部实体一次性传入。关系查询方法内部会组织节点和连线列表。在查询前代码会确认业务模型存在并调用图数据库连接可用性校验方法检查连接。连接不可用时关系查询不会假装返回一个空的正常结果而是进入明确的错误路径。图谱扩展分为几层。种子之间优先用最短路径查连接路径限制在最多六跳并且要求关系属于当前业务模型。没有连通的种子再取一度邻居作为兑底。若发现共享本体枢纽还会把另一个业务模型中的直接邻居接入结果。最终返回的关系链可以表达“客户—订单—订单明细—产品—批次”这样的业务路径。这里有一个常见的判断图谱不是越大越好。种子过少会漏掉关键中间节点种子过多会扩大查询边界增加无关属性和数据源。底层实现对最短路径查询失败还保留了一度邻居降级逻辑因此验收时要同时记录正常路径、降级路径和图数据库不可用三种情况。向量空间JBoltAI的这条实现说明图谱推理的价值不在于展示一张漂亮的关系图而在于把“为什么查到这条数据”变成可追踪的路径。业务人员可以回看中间实体、关系标签和数据源坐标工程师也能判断问题出在建模、同步还是查询阶段。三、两类查询的工程差异对比项向量检索知识图谱推理入口关键词、自然语言描述业务模型 ID、核心本体 ID主要对象本体名称和描述实体、属性、关系、数据源返回重点相似本体候选节点、连线与关系路径适合问题这是什么、可能对应哪个概念它和谁有关、关系经过哪些实体主要风险同义词误召回、属性缺失图谱断链、查询范围过大代码入口本体语义检索关系查询这张表不能被理解成“二选一”。真实业务问题往往先需要向量检索找到概念再用图谱推理补关系最后沿关系指向的数据源取数。只用向量检索答案容易变成文档或本体名称的罗列只用图谱推理又要求调用方已经知道准确的实体 ID入口对普通用户不友好。四、混合查询应该如何串联一个跨系统问题可以按下面的顺序处理。先从用户问题中提取业务关键词用本体语义检索或业务模型检索找到候选范围。再通过本体清单查询查看当前模型中的本体清单确认与问题强相关的核心实体。之后调用关系查询获取封闭子图最后根据节点上的数据源坐标执行表格查询或知识库检索。流程日志中定义六阶段映射的方法为这条链路提供了阶段标记业务模型、本体、关系图谱、数据检索、扩展操作和答案。向量检索并不等于第一阶段关系图谱也不等于最终答案。每一步都有自己的失败含义日志中记录的工具 ID、阶段次数和耗时能够帮助工程师把“答案不准”拆成可处理的问题。综合查询实现还把流程拆为加载本体、查询属性和关系、获取数据源、分析查询意图、生成并执行自然语言转 SQL、分析结果六个阶段。这个设计适合需要真实业务数据的问数场景但不适合把本体关系当成所有业务规则的充分条件。规则仍需在模型中维护数据质量也不能由图查询自动修复。在向量空间JBoltAI的实践里混合查询最需要控制的是上下文边界。向量阶段只负责缩小候选范围图谱阶段只带入问题相关的种子和路径数据阶段再按数据源坐标取数。三层都把自己的职责做好比把所有本体、文档和表结构一次性塞进提示词更容易排查。五、四个容易踩坑的地方第一把前 10 个候选、阈值 0.4 当成固定答案。它们是当前实现的默认参数实际阈值还要看名称、描述和业务术语质量。调参前应先看误召回和漏召回而不是只改一个数字。第二只更新本体属性却期待向量结果立刻变化。本体落库方法只在新增或名称、描述发生变化时才触发本体向量化方法重建向量。属性和规则变化应通过结构化查询验证不能用向量召回结果判断是否已经生效。第三把所有本体 ID 传给图查询。这样会让关系范围和数据源范围一起扩大模型难以判断哪条链路与问题有关。更稳妥的做法是从二到五个核心实体开始再让后端完成邻居和最短路径补全。第四把空结果当成“没有关系”。图数据库不可用、路径查询失败、模型 ID 错误和业务上确实没有关系可能产生不同的返回路径。结构化查询方法会把错误信息放进结构化结果调用方应保留这类状态不要直接转成一段肯定式答案。六、按问题类型选择技术路径如果问题是“库存这个词在系统里对应哪个业务对象”先用向量检索。若问题是“库存和哪些商品、仓库、期初记录有关”进入图谱查询。若问题是“为什么某订单延期以及应该查看哪份处理规范”先查客户、订单、生产批次等关系再用知识库补充流程文本。如果业务域只有稳定的实体名称和描述没有跨系统关系单独使用向量检索就足够。向量空间JBoltAI的实现把这条边界落在独立的本体向量集合与关系查询服务上便于按问题拆分责任。若查询需要状态机、上下游对象、跨模型桥接或数据源追溯必须建立本体关系。两种路径的建设顺序也应按业务问题决定而不是按技术名词的流行程度决定。总结先用相似度找入口再用关系完成解释向量检索回答“可能是哪一个本体”知识图谱推理回答“这些本体如何连接”。前者的工程核心是向量内容、集合隔离和阈值后者的核心是种子选择、路径边界、图数据库可用性和降级逻辑。向量空间JBoltAI把本体向量集合与关系图查询分开实现再用 Ontology Agent 和六阶段日志把两者串起来。企业真正需要验收的不是某一种技术的单点指标而是从候选发现、关系解释到数据取证的整条链路是否可追溯。知识只能回答问题认知才能驱动决策而认知的第一步就是把相似和关系分清楚。