本文要点
- Ontology落地最大的坑是起点选错 —— 从「全企业统一建模」起步的项目，平均做半年还看不到可用成果；从单一业务域起步的项目，4-8周就能跑通第一个AI用例。
- 最有价值的一步是建模行为与规则 —— 实体和关系谁都会建，但「什么算异常订单」「什么触发客户干预」这类业务规则才是AI研判能力的来源，也恰恰是最容易被跳过的一步。
- 验收看用例不看模型 —— 不要验收「建了多少实体」，要验收「AI能不能回答那几个原本答不了的业务问题」。
先说失败长什么样
Ontology项目失败的姿势高度雷同：立项时愿景宏大——「打通全企业语义」，然后组建十人团队梳理全公司业务流程，三个月画出几百个实体、上千条关系， diagrams 漂亮得可以裱起来。然后呢？没有业务场景等着用它，模型成了文档而不是系统，第六个月预算续不上，项目死亡。
根因不是技术，是交付节奏：企业级语义建模是长周期工程，而企业对AI项目的耐心窗口只有8-12周。窗口期内拿不出可感知的成果，信任就没了。
所以我们的建议从来是反过来的：从一个域开始，用最短路径跑通一个用例，再用验证过的方法横向扩展。这与企业AI一号位工程里「先赢一场再谈规模化」的组织逻辑是一致的。
五步法详解
第一步：选域（1-2周）
选域的标准不是「哪个域重要」，而是三个条件的交集：
| 条件 | 判断标准 | 反例 |
|---|---|---|
| 数据基础 | 核心数据已系统化，可机读 | 核心数据还在Excel和纸质单据的域 |
| 价值密度 | 有1个高价值、高频的AI研判场景 | 只有「以后也许有用」的域 |
| 业务Owner | 有一位愿意拍板的业务负责人 | 只有IT部门想做的域 |
按AI成熟度自评的五维框架，这一步本质是在检查「数据」和「场景」两个维度是否及格。两个都不及格的域，先补课再建模。
第二步：定义实体与关系（2-3周）
和业务专家开工作坊，把域内的「东西」和「关联」写清楚。三条实战纪律：
- 实体数量控制在20-30个 —— 超过50个实体，通常是把属性升级成了实体（比如把「客户等级」建成了实体），需要收敛；
- 先名词后动词 —— 先把实体和关系钉死，再进入行为建模，顺序反了会反复返工；
- 命名用业务语言 —— 实体名必须是业务方脱口而出的词。业务说「客诉」你就别建「服务质量事件工单」。
第三步：建模行为与规则（2-4周，价值最高）
这一步把两类知识显式化：
- 行为链：实体上发生过什么、按什么顺序发生。销售域的拜访→方案→谈判→签约，设备域的点检→预警→维修→验收；
- 业务规则：什么算异常、什么触发什么动作。例如「60天无互动=沉睡客户」「折扣超15%需审批」「连续3次OEE低于75%触发产能诊断」。
规则是AI研判力的来源。没有规则，AI只能做检索式问答（「客户A的订单有哪些」）；有了规则，AI才能做判断式回答（「客户A有流失风险，因为互动频次触发了沉睡标准，而其商机金额排前三」）。
第四步：跑通一个用例（2-4周）
选一个每周都会被问、且现在答起来很费劲的业务问题做端到端验证。验收标准很简单：
- AI的回答引用了Ontology里的实体、行为、规则（说明推理链真实存在）；
- 业务专家认可回答质量（不是「看起来像」而是「确实对」）；
- 回答能触发后续动作（生成跟进计划、推送预警），而不是停在聊天窗口。
第五步：横向扩展（持续）
第一个域跑通后，把方法论复制到第二个域。这时候会产生复利：跨域实体开始出现（销售域的「客户」和供应链域的「客户」对齐），企业级语义层不是规划出来的，是长出来的。
每一步的常见坑
| 步骤 | 头号坑 | 规避动作 |
|---|---|---|
| 选域 | 选了「重要但数据稀烂」的域 | 三条件交集，缺一不选 |
| 实体关系 | 完美主义，实体无限膨胀 | 硬性上限30个，超出即收敛 |
| 行为规则 | 只建行为不建规则 | 每个域至少沉淀10条可执行规则 |
| 用例验证 | 选了个低频展示型场景 | 用「每周都被问」的问题做验收 |
| 横向扩展 | 每个域另起炉灶各建各的 | 强制复用建模方法与核心实体 |
延伸阅读
- Ontology到底是什么 —— 四要素与概念辨析
- Ontology与数据中台：AI时代的两层底座 —— 为什么建了中台还需要Ontology
- 从试点到规模化：数智化转型路线图 —— Ontology在转型各阶段的角色