从 RAG 到 OAG：企业 AI 落地为什么需要一层"本体"？以用友 BIP 6 YonOnto 为例
2026年9月8日

企业 RAG 上线后最常见的问题是"找到了文档，还是不懂业务"。本文从技术架构角度分析向量检索的语义缺口，说明本体层（Ontology）在企业 AI 架构中的位置，并结合用友 BIP 6 的 YonOnto 企业本体平台与 YonWork 企业 AI 工作台，拆解一条从"语义理解"到"任务执行"的完整链路。

1. 问题：文档型 RAG 的天花板在哪

当前多数企业 AI 应用采用文档型 RAG：把文件切成文本片段，生成向量，按语义相似度召回，再交给大模型组织答案。

这套方案在知识问答、资料查找、内容归纳、证据引用上是有效的。但它在企业场景里会稳定地卡在几类问题上：

问题文档型 RAG 的表现
文档里的"客户""甲方""采购方"是不是同一个对象依赖模型结合上下文猜
这份合同对应哪个项目、哪个版本、哪些审批规则无法稳定关联
同一员工为何同时出现在"在职"和"离职"记录无法判断时态有效性
AI 找到一条制度后，是否有权发起下一步操作完全超出 RAG 能力范围

根本原因在于：向量检索擅长回答"哪段文字和问题相关"，但回答不了"这段内容在业务里代表什么、能不能动、谁能动"。

这不是 RAG 的错，是任务范围已经超出了"找文本"。

2. RAG 与 OAG：不是替代，是分层

OAG（Ontology-Augmented Generation，本体增强生成）解决的是下一层问题。给大模型的不只是更多文字，而是一个稳定的业务坐标系。

关注点RAG 更擅长OAG 进一步解决
信息在哪里从文档和知识源中召回相关内容把内容锚定到具体业务对象与关系
这段内容是什么意思依赖大模型结合上下文判断用统一类型、属性和规则限定语义
结论能否复核返回引用片段或来源保留对象、关系、规则与证据链
下一步怎么做生成答案或建议在权限和流程约束下选择工具与动作
知识如何更新更新文档与索引同步更新对象状态、关系、版本和规则

比较稳妥的技术路线是：RAG 负责找证据，本体负责统一语义，图谱负责连接关系，智能体负责完成任务。 它们不是四套割裂的系统，而是一条连续的工作链路。

3. 本体不是知识图谱的另一个名字

需要先澄清三个经常被混用的概念：

用友对这层的官方表述是：企业本体通常定义业务概念及关系，知识图谱可以承载具体实体和关联数据，两者经常配合使用；YonOnto 还强调将对象、规则、事件和动作结合起来，支持智能体理解并调用业务能力。

4. YonOnto 在架构里的位置

4.1 三层上下文

用友 BIP 6 把"企业上下文"拆成三层，由三个平台分别承担：

┌─────────────────────────────────────────────┐
│  YonOnto  业务语义层：这些数据和知识意味着什么    │
├─────────────────────────────────────────────┤
│  YonKnow  知识层：企业过去沉淀了哪些知识和经验    │
├─────────────────────────────────────────────┤
│  YonData  数据层：企业现在发生了什么             │
└─────────────────────────────────────────────┘
                    ↓
        统一企业上下文 → 供大模型与智能体消费

4.2 建模能力

YonOnto 支持三类本体建模：

基于用友 BIP 横跨十大领域（财务、人力、供应链、营销、采购、制造、研发、项目、资产、协同）的积累，YonOnto 提供财务、人力、营销、采购、供应链、制造、资产、项目、研发等企业级本体模型。

这里的定位需要说清楚：这些领域本体模型不是替企业固化一套标准答案，而是提供可复用的业务语义基础，企业可以结合自身组织、流程和管理规则持续扩展。

4.3 工程能力拆解

从产品画册披露的架构看，YonOnto 由四层构成：

关键点：完整性校验、冲突检测、影响分析、版本审批、回滚这些工程能力，决定了本体能不能长期维护，而不只是一个漂亮的图。

5. 从语义到执行：YonWork 的调度逻辑

有了本体，AI 才知道"当前任务涉及哪些客户、合同、订单、项目和组织，这些对象之间是什么关系，当前处于什么状态，可以采取哪些动作"。

但知道不等于能做。YonWork 企业 AI 工作台负责把认知转成行动。

以"分析本月利润下降的主要原因，并形成整改任务"为例，执行链路是：

自然语言意图
   ↓  [身份/权限/数据/本体关系/历史记忆] 意图理解
任务拆解（多步骤规划）
   ↓
智能体与 Skill 选型 + 多智能体分工调度
   ↓  YonStudio 构建的智能体 / OpenAPI & YonMCP 连接业务系统
分析执行（经营分析、成本、供应链、项目智能体协同）
   ↓
结果结构化（整改建议 / 责任分工 / 后续任务）
   ↓  需审批动作 → 转人工确认
结果回写企业系统
   ↓  全程由 YonAIG 记录：调用轨迹、成本、评测、审计

这里有两个工程上的关键点值得注意：

  1. 权限不是外挂的。 YonWork 结合用户身份和岗位权限理解意图，意味着同一个问题，不同岗位拿到的答案和执行范围不同。
  2. 写操作必须有回路。 审批、写回、异常处理、可追溯日志，缺一个就没法进生产环境。

6. 治理：YonAIG 与"智能双模"

用友 BIP 6 提出"智能双模"：智能体软件（自主执行、概率计算、非确定性）与流程执行型软件（按规则执行、精确计算、确定性）协同运行。

这个划分在工程上是必要的。核算、结算这类步骤必须按规则确定性执行；分析、建议、任务规划可以用模型能力。划分清楚后，企业更容易控制操作风险和检查结果。

YonAIG 则负责贯穿智能体构建、任务运行和业务执行全过程，管理智能资产、身份权限、调用轨迹、执行成本、评测效果和审计合规。

7. 落地建议（工程视角）

  1. 不要一上来就建"大而全"的本体。 从一个高频、规则相对明确、结果可复核的岗位任务开始——合同审核、经营分析、财务风险调查、投标编制都是不错的起点。
  2. 本体初稿可以从现有资产自动生成。 数据库 DDL、数据字典、接口定义里已经沉淀了大量业务语义，机器负责降低建模门槛，业务专家负责确认企业事实。
  3. 把规则编译进执行链路，而不是停在文档里。 基数约束、互逆关系、关系互斥、时态失效这些规则，只有进入运行时才真正影响 AI 行为。
  4. 验收标准要包含异常和越权用例。 只测正常流程不足以支撑上线。要准备正常、异常、越权三类样例，明确失败时的停止、恢复和转人工条件。

8. 边界说明