随着 Palantir 的走红，叠加 Al 的热度，最近国内企业讨论本体论的热情一直高涨，不少明星企业也找我们交流语义层，新老客户通常都会问一个问题：Aloudata CAN 指标平台跟本体论是什么关系？语义层未来也会走向本体论吗？
我分享我的 3 个观点。
一、概念对齐的靶点应该是技术原理，而不是解释概念本身
对于本体论（Ontology）这一概念，网络上朋友图里有很多的介绍、讨论和争辩，我理解本体论跟语义层一样，都是对现实世界的数据建模，只是建模目标不同。
Ontology 是 Palantir 的数据语义层，是对现实业务运营的数字孪生，解决的是业务决策逻辑如何定义和映射到业务 IT 系统的问题。
Aloudata CAN 是 Aloudata Agent 的数据语义层，是对现实经营决策的数字孪生，解决的是数据分析逻辑如何定义和映射到数据 IT 系统的问题。
两者本质上都是通过语义建模实现智能决策，只是一个偏业务运行，一个偏经营分析。Aloudata CAN 对外称呼“指标平台”，纯粹是因为“指标”这一概念贴近客户日常用语，减少沟通成本。
由于建模场景的不一样，本体论主要通过四个核心组件对象（Objects）、关系（Links）、属性（Properties）、操作（Actions），完成对现实世界运营决策的数字化映射。
语义层则主要通过实体建模和维度建模的方法定义实体，属性和关联关系，并在此基础之上形成指标和维度等统计分析对象，完成对现实世界经营决策的数字化映射。
从技术结构上看，两者并不是完全不同的物种，而是同一类技术范式在不同业务目标下的不同实现路径。
相比本体论，现有的 Aloudata 语义层模型一样可以完成“客户”、“商品”、“订单”这类对象以及他们之间关系与属性的定义，不仅支持 Data Agent 的“问数”功能，还天然支持“归因、解释和建议”这类需求。目前的语义层模型主要缺少了操作（Actions），导致无法承载和执行具体的业务动作。
但反过来看，本体论也并不是天然完整的。
相比语义层，本体论一样也需要增加指标这类对象（可以了解一下 Pipeline Builder、Contour、Quiver 和 Notepad 这几个 Palantir 中的常用工具），Palantir Ontology 的 Action 本身只是一个执行体，它回答的是“能做什么”，但“该什么时候做”，恰恰是指标要回答的问题。基于不同的业务阀值产生差异化的决策，这在 Palantir 的案例中比比皆是，而人们在讨论本体论的时候，似乎刻意忽视了这一点。
所以，本体论和语义层这两者的设计目标最终都是致力于实现决策自动化，因此哪怕起点不同，但技术拼图也会大致趋同。
为此，我想重点补充一点：Aloudata 语义层模型目前缺失的操作（Actions），在 Al Agent 的时代，在业务系统都在开始提供 CLI 接口和 Agent 化的当下，会不会存在不同的解法，还需不需要和能不能将操作（Actions）封闭在一个类似 Palantir 的体系内，相信 Aloudata 会有自己的判断，也会有自己的行动层技术方案。
二、从概念到业务，中间隔着"地球到火星的距离"，看不见的地方才危险
无论是本体论，还是语义层，本质都是一种通过语义建模实现智能决策的方法，都需要完成从概念到技术，从技术到产品，从产品到系统的进化。概念成立，并不代表产品和系统成立，这中间隔着“地球到火星的距离”。
首先，面临语义建模的成本挑战。
要将现实场景数字孪生到模型系统中，需要经历业务建模、逻辑建模和技术建模的过程，这个过程涉及企业不同部门多个岗位的协同，前期的业务调开、逻辑确认的过程往往比技术实现更复杂，需要考虑的因素更多，“能不能建”、“谁建”、“怎么建”、......，每一个问题都需要业务与 IT 之间的联动配合。
从技术角度看，语义建模解决的是系统如何理解业务；但从组织角度看，它更深层解决的是：企业是否愿意把决策权部分让渡给系统。
比如本体论的落地需要涉及多个业务系统之间的业务流打通，这种跨部门、跨厂商的协同，往往是企业一号位才能真正推动执行，这也是 Palantir 商务上选择 CXO 人群从上往下找"流血场景"打的原因。
相比之下，语义层因为依托企业数据仓库或数据中台已有的数据建设和治理方法，语义建模的成本相对可控，起步更稳，见效更快。这也是为什么今天天企业更容易先接受语义层，而不是一步进入本体论的原因。
其次，面临语义执行的成本挑战。
本体论和语义层存在明显的核心场景差异，前者要要对每一个业务事件进行自动化决策，要尽量避免人员介入，对数据实时性和系统自动化的要求非常高高，属于 Event-Driven。后者大部分的时候都是由人类直接或经由 Agent 发起，对数据时效性和数据查询性能的要求比较高，属于 Demand-Driven。
Event-Driven 和 Demand-Driven 在响应时长上存在数量级的差距，前者通常要求毫秒或亚秒级的响应性能，而后者通常是秒级的响应性能，部分场景甚至允许分钟级的响应性能。
Event-Driven 和 Demand-Driven 在计算量级上更是存在不止一个数量级的差距，前者一天累积的执行需求通常亿级起步，而后者一天累积的执行需求通常最多不超过数百万次。
两相比较，对企业而言，投资本体论在计算和存储资源上的投入，通常会比语义层至少高出一个数量级。
而对厂商而言，哪怕是语义层，如果没有 30~50 人起步的有经验的产研团队，也很难解决企业大规模应用过程中遇到的各类技术挑战，比如如何复用企企业现有的计算存储资源、如何裁剪语义逻辑和动态分配计算资源、如何识别物化机会和规划调度物化任务、如何提升大规模查询请求下的系统可用性、......。
最后，面临语义演进的成本挑战。
相比建模和执行成本，更容易被忽视的是语义演进过程中的成本问题。
无论是本体论还是语义层，本质上都是对现实业务世界的一种抽象映射。但现实世界不是静态的，业务流程会变，组织结构会变，系统边界会变，决策规则也会持续变化。
这意味着，系统上线，才是真正挑战的开始。
尤其是本体论，由于它直接作用于业务运行系统，对现实业务流程的映射要求高度准确，一旦业务流程发生变化，对象定义、关系结构、属性规则和作逻辑都可能需要同步调整。一旦产生偏差，可能直接导致错误决策和错误执行，带来严重业务后果。
从这个角度看，不管本体论，还是语义层都不是一个项目，而是一项持续进化的组织能力。
客观地说，现实中没有一步到位的完美建模，语义建模只有能够支持逐步进化，才能边用边治，越用越好。
但由于本体论和语义层这两者的灰度空间天然不同，本体论天生具有灰度空间小的特性，对建模准确性，执行稳定性和持续维护能力都提出了更高要求。
综上，无论对厂商还是客户而言，本体论在建模本，运行成本和演进成本上，都会面临更大的综合挑战。
三、选型决策的依据应该是业务目标，而不是对比概念大小，应量力而行、逐步升级
今天我们在看本体论和语义层时，内心往往有一个真实顾虑：如果未来企业 Al Agent 基建的终局形态是本体论，那今天先建设语义层，会不会只是一个过渡方案？既然两者的建设成本都不低，要不要干脆一步到位，直接建设一个上限更高的系统？
如果只对比概念大小，本体论的抽象程度更高，界范围更大，但概念大小不代表起步路径，更关键的是：今天能不能用起来，以及用了之后，能不能持续演进。
无论是本体论还是语义层，最终都不是为了建模而建模，也不是为了自动化而自动化，而是为了创造业务价值。
但相比语义层，本体论的价值闭环更长，也更难验证。
语义层的价值通常是显性的：一个分析需求是否是效，一个指标口径是否统一，一个经营问题是否更快得到答案，价值往往在短周期内就能被验证。
而本体论的价值更多体现在业务运行效率的优化上，比如订单履约效率提升、供应链协同效率提升等。这类价值往往是系统性结果，不仅验证周期更长，而且影响因素更多。
这意味着企业很难简单回答一个问题：到底是本本论创造了价值，还是业务流程优化创造了价值？
相比之下，不像本体论只是抽象了方法，没有明角业务场景，语义层本身就定义了要解决的业务问题，聚焦数据分析决策场景，价值链路更短，验证路径更清晰。
因此，企业通常更愿意先投资那些“短链路、快反馈、可量化、低风险”的能力，再逐步向“长链路、强耦合、系统性、高价值”的能力延伸。
这也是为什么今天语义层更容易成为企业迈向 AI Agent 的第一站，而本体论更像是企业完成智能决策深水区建设后的下一站。
总结一下，本体论不是语义层的终点，语义层也不是本体论的低配版。它们只是企业智能决策在不同阶段、不同场景下的不同技术形态。
本体论（Ontology）作为哲学概念，被商业包装成一个技术概念，出胎于 Palantir，其技术原型来源于 Paypal 的风控团队。
10 年前，我在支付宝做数据相关的架构工作时，数据团队曾归属风控 VP 兼管，大部门的兄弟团队就以本体论这一概念做过相关的产品。那个时期也是 AI 1.0 的热度期，市场上号称做中国版 Palantir 的公司比比皆是。
10 年后，同样的情形再次出现，盛况更比当年，套用本体论的现象层出不穷，比如出现了本体论与语义层合体的概念——“本体语义层”。
走过前 10 年，再看后 10 年，行胜于言，与客户一起，量力而行、逐步升级，提供管用的自动化决策产品，服务好每一个客户的每一次决策需求，才是企业经营致胜的关键。
