本体语义和 RAG 怎么分工 —— 一份给企业 AI 选型的实操指南

2026/7/21 14:14:59

引言：企业 AI 落地的三类典型语义问题

企业里跑了一段时间的 AI 助手，常遇到三件怪事：业务人员问"那个客户怎么一直没回款"，AI 给出一长串"客户管理"文档清单但不讲为什么没回款；业务部门上线了"订单知识库"，AI 检索到 SOP 写"已关闭订单不允许修改"，但"已关闭"在不同部门有三种含义，AI 照搬 SOP 给出错误答案；AI 调用订单接口时把"已关闭"当成"已完成"，生成的提醒邮件每个字都对、客户看了懵圈。

这三类问题的根源不同。第一类靠"找更准的文档"不能完全解决，第二类靠"语义理解更强的大模型"也解决不了，第三类靠"提示词写细一点"还是出错。问题在于把 RAG 当成万能解。本体语义处理的是一类完全不同的问题，硬塞给 RAG 是工程偷懒。RAG 和本体语义不是"二选一"，而是要看场景做分工。

一、先分清两类知识

企业里需要 AI 处理的知识分两类。一类是文档知识——人写的文字、业务经验的沉淀，比如 SOP、操作手册、合同模板、培训资料，特点是"有出处、能引用、有版本"，RAG 处理这一类，通过向量相似度找到与提问相关的文档片段作为模型回答依据。

另一类是系统知识——数据结构和业务规则，比如"订单状态有哪几种"、“合同从生效到终止有几个状态机”、“客户在不同系统里用什么字段关联”，特点是"结构化、跨字段、有规则"，本体语义处理这一类，把实体、属性、关系建模到图谱里让 AI 沿关系推理出答案。

举一个具体例子。用户问"上周延期订单的主要原因"。先用本体查到"延期"的定义，再沿关系链"订单-产品-批次-缺陷记录"找到涉及批次缺陷的订单；用 RAG 查"批次缺陷的处理流程"补充背景。模型拿到这两路结果组合出回答，背景和原因都覆盖。

二、为什么 RAG 解决不了所有问题

RAG 在企业场景有三个根本限制，不是工程上"再调一调"能突破的。

第一层限制是匹配机制本身。向量检索找的是"语义相近的文档片段"，不保证"业务逻辑一致"。"已关闭订单不允许修改"和"已关闭订单可以补充备注"看起来主题相近，业务上是规则覆盖关系。AI 不加区分地引用就会给业务人员做出互相矛盾的承诺。

第二层限制是文档静态、规则在变。RAG 召回的 SOP 在文档库里，但业务规则可能上周刚改——文档还没更新或没同步到检索库。AI 拿到的"权威文档"可能是三个版本之前的旧规则。这是 RAG 系统最容易踩的坑：检索命中率不低，但准确率长期上不去。

第三层限制是业务概念的关系是结构化的。"客户关联合同、合同关联订单、订单关联产品、产品关联工序"是结构化关系，文档分散在五份文档的不同段落，向量检索很难拼起来。本体能，因为关系在建模时就建好了。经验上给每个核心实体准备一段结构化的"概念卡片"作为 RAG 的优先召回锚点，能让模型在边界问题上少走不少弯路——但是个折中方案，不是替代分流的根本办法。

三、为什么本体也不能替代 RAG

本体处理的是结构化关系。"订单是什么"这种定义性问题，SOP 写得很清楚、本体反而要重新建模一次。“产品的特殊规格说明"是大段技术参数，本体为每个参数建模工程量巨大。维护成本上，本体按月迭代、文档按周更新，强行把文档内容塞进本体成本会急剧上升，半年进入"放任自流”。推理路径上，本体走图查询、RAG 走相似度匹配，工作方式不同不能互换。

用户问的问题常常是混合的。"为什么这个客户的订单一直没发货"既需要本体的"客户-订单-生产排产-库存"关系推理，也需要 RAG 召回"特殊订单处理流程"的说明，单走任何一路都不完整。多个项目跟踪的中位经验：单路 RAG 准确率偏低、单路本体覆盖宽度有限，两路并行交给模型组合准确率能稳到较高区间。具体数字按业务复杂度差异较大，应以压测为准。

四、两条腿走路的具体经验

入口分流先做轻量分类。模型拿到用户问题后做一次意图识别——“这是什么”"怎么操作"走 RAG 路线，“为什么这样”"背后是什么逻辑"走本体路线。分类可用关键词+业务规则的轻量引擎，粗一点没关系，后面用工具调用兜底。

上下文拼接而非结果拼接。RAG 召回的文档片段用引用标注，本体查询的关系链结果用结构化摘要。模型拿到拼接好的上下文自己决定怎么组合，不在工程层做强组合。经验上拼接顺序对回答质量影响很大，通常本体结果在前、RAG 召回在后，模型倾向于"先给业务结论、再补文档证据"，更符合业务人员阅读习惯。

两路并行调用比单一路径更稳。即便意图识别很准，也保留两条路都跑的可能性。意图识别出错时两条路都给结果会让 AI 看到"分歧"，引导它更谨慎地回答。

RAG 与本体不要放在同一个索引。RAG 的向量索引按文档段管理、文档更新就重建，本体的图存储按实体和关系管理。两套存储迭代逻辑不同，强行塞在一起反而增加耦合。一个常见做法是本体服务有自己的"概念卡片"——给核心实体准备一段结构化文本供 RAG 引用作为"概念定义"。

五、什么场景必须建本体

业务规则频繁变化——核心规则按月调整（订单状态加新分支、合同类型加新品种），这类场景本体更新虽慢但版本可追溯，比文档散落不同版本安全。

跨系统关系复杂——查询常常跨三个以上系统（CRM/MES/ERP），必须建本体，否则 RAG 召回的文档片段拼不出完整关系链。

状态机多分支——“订单有 8 个状态、每个状态 3-5 个迁移条件”，文档讲不清楚、AI 检索会自相矛盾，本体能约束状态机的合法迁移。

业务专家对术语理解不一致——同一词在不同部门有不同含义（"已关闭"在三套系统指三件事），必须建本体统一理解。

如果不满足以上任何一条，单纯文档多但语义统一，RAG 足够。盲目上本体是浪费——半年后业务部门会问"这东西到底给我带来什么价值"。不少制造企业项目里高频失败模式是听一次汇报就要全企业本体建模、第一版 8 个月还在迭代、业务部门从配合到放弃、最终无人维护。这条经验比"先做高频域"更值钱——知道什么时候不该建本体，比知道怎么建本体更难。