SOFTWARE × AI × BUSINESS研究交互版 · 2026.09

Ontology.

让数据拥有
业务含义。

从“系统里有什么”,走向“它们意味着什么”。
理解企业如何为人和 AI 建立共同的业务语言。

开始探索 滚动观看 · 可交互实验
BUSINESS WORLD / MODEL 001
从分散记录到有明确含义的业务关系 供应商SUPPLIER 零部件PART / P-17 订单ORDER 工厂PLANT 供应需要库存归属履约 ERP / part_id: P-17inventory: 20
概念 · 关系 · 约束 不是更多数据,而是更明确的含义
THE ESSENTIAL IDEA

“供应商”“客户”“风险”——
人们熟悉这些词,系统却需要明确的定义。

这里的 Ontology(本体)指软件与 AI 中,对领域概念、关系及约束的显式表达。它可以帮助系统共享业务含义;它本身并不保证数据正确,也不天然拥有执行能力。

01 / A WORLD, IN FOUR MOVES

同一张图,
逐步接近真实业务。

向下滚动,观察图如何变化。
这是一段合成供应链情境,不是真实客户案例。

01

定义:什么是一个
业务世界?

先约定对象类型、属性与关系:什么叫供应商,什么叫零部件,“供应”与“需要”分别连接什么。

类 / 类型不是具体的某家公司

形式本体可表达更严密的逻辑公理。OWL 是相关标准之一,并非唯一实现路线。

02

绑定:这个对象,
到底是谁?

将 ERP、供应商管理和生产系统中的记录,映射到稳定的对象身份。名字相似不代表同一实体;同一实体也可能有多个系统编号。

概念 → 实例供应商 → S-01

映射、实体消歧、来源、更新时间和责任人仍需要工程与治理;本体不会自动清洗数据。

03

推演:一次中断,
会影响什么?

供应商 A 中断。沿“供应—需要—履约”追踪,可以定位受影响的订单与工厂,再结合库存和需求计算物料缺口。

需求 80−库存 20=缺口 60 件

这是显式关系与确定性计算的演示,不是 AI 的预测,也不代表实际损失。

04

行动:能做什么,
由谁决定?

找到替代供应商只是建议。要创建采购申请,还要检查认证、产能、时点和授权,再取得人工批准,保存执行记录。

业务绑定实体 → 规则 → 执行

这三层是本研究的分析框架。Palantir 的 Actions 是产品实现之一;学术本体不天然包含写回。

在实验台亲手验证 ↓
01 / DEFINE合成情境

先定义共同语言

点击节点,可查看对象说明

类型是约定,实例是具体事实。先看关系,再看数据。

02 / DISTINGUISH THE LAYERS

相互配合,
不互为同义词。

知识图谱不是本体的另一种写法。
RAG 与本体也不是非此即彼。

工程边界

“能表达约束”不等于“执行时必然阻止错误”。OWL 推理、SHACL 校验、服务端权限和工作流各有分工;不能用提示词替代授权。

03 / THE DECISION LAB

让边界,
变得可以验证。

如果 AI 建议向供应商 B 补采 60 件,
什么情况下,系统应该说“不”?

受控采购实验本地确定性模拟 · 无模型调用 · 无真实写回
输入条件
20120 件

本例规则:已认证、数据 ≤ 24 小时、数量 ≥ 60 且不超过可供量、采购员权限、人工批准。

执行前校验0 / 6 通过
↳
当前方案还不能执行

先尝试提交,观察系统如何解释拒绝原因。

本次会话 · 审计轨迹0 条记录
  1. 等待第一次尝试。
重要区别

创建的是采购申请,不是到货承诺。真实系统需要在服务端强制校验、认证审批人、防重复提交和处理外部副作用;本页只演示机制。

04 / KNOW WHAT THE EVIDENCE SAYS

有力的证据,
也有适用范围。

我们保留研究中的数字,
也保留数字不能回答的问题。

单项实验 / 2026.05

工具参数被业务语义约束后,
标识符错误可以减少。

Qwen3-32B · 6 类工业配置 · 每条件 72 次调用

未约束参数
43%
本体约束参数
0%
050100%

0 次观测 ≠ 0 风险
这是特定模型、任务与工具架构的预印本结果,本项目未独立复现;不是“本体消除所有幻觉”的证明。

厂商公开案例 / 供应链

从跨系统查询,
到围绕业务对象分析。

ERP₁ERP₂ERP₃…ERP₇₊
工厂 · SKU · 客户 · 成本

Palantir 描述一家未具名的财富 100 强消费品企业,将至少 7 套 ERP 数据连接到业务对象模型,用于物料采购与生产分析。

应用可行性 ≠ 普遍 ROI
该案例的节省金额是厂商估计,本页不将它当作已兑现收益;公开流程未描述 Action 写回。

阅读原则

标准说明语义;产品文档说明机制;实验说明特定条件下的结果;厂商案例提供线索。它们不能互相代替。

05 / FROM THESIS TO TEST

研究院的机会:
让“值得做”可被检验。

面向德勤人工智能研究院的讨论建议。
以下是研究假设,不是已发布的方法论。

德勤全球网络已有本体与知识增强 Agent 研究资产。下一步可以先盘点、连接,再检验跨平台的增量价值,而非假定这里是一片空白。

01

语义就绪度诊断

检查实体身份、映射、数据时效、权限、变更责任。把“我们懂业务”变成可观察的证据。

候选产物 / 诊断问卷 + 证据清单
02

跨平台任务基准

固定数据、模型和任务,比较 SQL + 语义层、RAG、GraphRAG 与受控本体方案。

候选产物 / 黄金任务集 + 失败分类
03

行业语义最小包

聚焦一个窄场景,沉淀可复用词汇、映射与约束,并定义谁维护、如何版本化。

候选产物 / 领域模型 + 治理规程
A 90-DAY HYPOTHESIS

从一个可停止的试点开始。

一个场景 · 3–5 类实体 · 一个需人工批准的 Action

01—30 天定义任务与基线

谁负责定义?如何判对错?

31—60 天构建最小闭环

映射、工具校验与失败测试。

61—90 天比较并决策

任务成功率、越权率、时延、成本与治理工时。

停止条件:若主要指标没有可重复增益,或治理成本超过收益,不扩大;保留已验证的词汇、映射与评测资产。

DISCUSSION NOTES

讨论前,先厘清这几件事。

是不是所有 AI 项目都需要 Ontology?+

不是。单文档问答、简单查询可能用较轻方案就足够。跨系统对象身份、复杂关系、严格约束或高影响操作越重要,显式语义模型越值得评估;仍须与较简单的基线比较。

本体和数据库 schema 有什么不同?+

Schema 也能表达结构和约束。本体更强调跨应用可共享的领域含义与关系,有时包含形式化公理与推理。二者有重叠,不应靠改名判断价值,应看语义复用、治理和任务效果。

用了本体,AI 就不会犯错了吗?+

不会。本体与工具校验能帮助减少某些错误,但模型、映射、规则、数据时效和权限实现仍可能出错。拒绝执行有时是正确结果,未知编号不能被解释为“没有风险”。

一定要用 Palantir 或图数据库吗?+

不一定。概念模型、RDF/OWL、属性图、关系数据库与业务服务可以按任务组合。Palantir 是较完整的产品化路线之一。选型还要验证集成、权限、模型变更、导出可移植性和持续成本。

今天这份网页证明了什么?+

证明这组概念可以被清晰展示,且所列合成规则在本地模拟中可执行;没有证明任何平台优于另一平台,也没有证明真实企业 ROI。真实有效性须通过客户数据上的受控试点检验。

SOURCES & BOUNDARIES

资料索引与证据边界

正文仅保留可追溯的关键主张。机构资料来自既有研究核验;本页不宣称完成市场全量更新。

纳入的本地研究

Codex:领导沟通稿、15 分钟提纲、主张—证据台账、供应风险示例与 90 天试点画布。

Claude:核心框架、交叉核验、应用案例与业务绑定、arXiv 全文核验。

编辑处理:不复用两边含义不同的证据等级数字;以“标准 / 产品文档 / 单项研究 / 厂商案例 / 研究建议”区分。删除无法支持的普遍 ROI 与“本体消除幻觉”表述。