引言：当项目被"全量建模"四个字拖垮
企业引入本体语义时，业务负责人的第一反应往往是"把所有业务概念建模完"。这种决心听上去很足，工程上却是给自己挖坑——十几个业务域一次性铺开、半年内类型冲到 200 多个、规则堆到上千条，结果建模团队一半时间在协调冲突、业务部门提不出可执行的修改意见。
行业里上千个项目跟踪下来有个收敛判断：实体类型先控制在 20-50 个，关系规则先控制在 100-200 条，跨域的"超级本体"放到第二版或第三版。本篇文章把这两个数字背后的工程边界讲清楚。
一、实体类型为什么不能无限扩张
实体类型是本体建模的"骨架"。每多一个类型，意味着新的属性、关系、校验规则，类型越多建模工作量呈非线性增长。前期的工作量还在可控范围，但跨团队对齐和跨系统字段映射这两项会快速膨胀——业务专家每多讨论一个概念就要花时间理解跟现有类型的区别，字段映射每多一个类型要和 ERP/MES/CRM 多套一次。
在工程实现中，本体保存接口背后是一条重链路：校验名称唯一性全表查重、落库、增量保存属性、增量保存规则与数据源、触发向量化。100 个类型同时进，意味着每次业务侧字段调整要做 100 次这种全量比对，成本是叠加的，不是线性的。经验上前 20 个类型投入 1 位工程师 4-6 周，20-50 个类型同样配置 8-12 周，50-100 个类型需要 16 周以上且人员翻倍，100 之后再增加会反噬业务价值。
属性枚举爆炸是另一个成本点。一个类型 10 个属性、3-5 个枚举类、维护 5-10 个合法值，50 个类型时枚举值逼近 1000-2000 条。新增一个状态值要在多套系统同步定义，否则本体验证和业务系统脱节。
20-50 这个区间的工程可跑性来自跨项目跟踪的中位经验：超过这个范围的项目在后续几年里转为"维护停滞"的比例明显上升。
二、关系规则为什么不能堆砌
关系规则是本体的"血管"。规则量超过 200 条时，跨类型约束的冲突组合空间成倍增加，人工 review 已不够用，必须引入冲突检测引擎。规则量在 100-200 条以内，冲突能通过人工 review 发现并调整。
推理时的"规则雪崩"是另一个成本点。本体在 AI 推理时触发关系链，每跳可能评估多条规则。一个"客户风险评估"查询跨五个以上关系时，规则总数明显超过 200，本体定义在检索阶段注入后按其在提示词中的占比明显加压，推理延迟与 token 消耗都增长——具体阈值需要业务侧基于运行时压测调参，不是从经验数值直接套用。
规则维护也有视野盲区。100 条以内的规则，业务专家一周完整 review 一遍；超过 200 条，每两周才能 review 一遍且容易漏掉边界条件。100-200 条规则、每月新增或修改 10-20 条是合理工作量。
三、跨域本体的层次结构
实体类型和关系规则各自有上限，企业级"超级本体"靠分层次建模解决。核心层是 8-10 个最稳定的本体（客户、订单、合同、产品、工单、设备、人员等），规模控制在 15-20 个类型、50-80 条规则。扩展层是各业务域特有本体，每域 8-15 个类型、20-50 条规则。行业层是行业模板，每行业 10-25 个类型、30-80 条规则。三层加起来 60-120 个类型、250-400 条规则，但每一层有自己的维护节奏和责任人。
这套分层在工程上按业务域独立建模，三层之间通过显式的"分组"字段隔离，避免属性互相污染。
四、关键经验参数与工程取舍
完成核心层建模，按经验覆盖 15-20 个类型和 50-80 条规则，需要 1 位本体工程师加 1-2 位业务专家、6-8 周；完成一个扩展层规模 10-15 个类型和 30-50 条规则，投入 4-6 周。这就是分三层结构的项目第一版能在 3-4 个月内上线、"全量建模"项目一年还在迭代的原因。
性能上，50 类型、200 条规则的本体在图数据库上单跳查询响应时间毫秒级，4-5 跳的多跳查询响应时间会到几百毫秒到秒级，更深的查询要分步骤拆解。工程实现中进入图关系查询前先检查连接是否可用，不可用时直接抛错——目前通用商业实现只支持 Neo4j 一种图后端，工程师精力聚焦本体结构设计而非图存储选型。
本体内容注入 AI 上下文时，一个 50 类型、200 条规则的本体在检索后体积大概 20-40KB，是合理范围；超过 100KB 会让推理成本和延迟明显上升，具体阈值要按业务场景实测。
五、识别本体过载的早期信号
信号一，规则冲突频繁。每月 3 次以上"这条规则和那条规则矛盾"被业务专家提出来，规则量已接近 200。信号二，业务专家 review 不动规则——每周都有人提修改但 80% 没进 review。信号三，AI 推理结果被业务频繁否决但工程师查不出逻辑错误，多半是查询路径触发了不预期的多跳规则。信号四，月新增规则持续两个月超 20 条。信号五，检索返回的本体清单 JSON 体积明显增长，AI 响应时间从几十毫秒跳到几秒。
运营人员可以基于查询日志表按会话 ID 关联的各阶段耗时与本体清单体积拼出一个"过载趋势看板"——目前通用商业实现还没有整套现成的健康度仪表盘 UI，需要业务团队基于现有数据自行拼装。
六、怎么控制扩张冲动
方法一是设上限文化。实体类型上限 50、关系规则上限 200，超出就拆项目或拆层次。方法二是按价值排序。每个新增类型或规则都要回答"在三个业务场景里被引用过"，这条原则砍掉了 60-70% 的扩张申请。方法三是先单域后跨域，跨域工程难度是单域的 3-10 倍，没有单域的稳定迭代经验做跨域容易崩。方法四是定期瘦身，每个季度把三个月内没被引用的规则标记为"待清理"。
七、本体管理能力的工程取舍
在工程实践中，本体管理接口的设计比较克制：检索类做全局查与单实体属性获取；写操作类按"实体级-属性级"分六组；关联类负责本体与属性之间的有向边。总数控制在两位数，每个方法对应一组固定语义。
更关键的是工程化的"协议单一"——所有写操作走"后端落库 + 推送协议消息给前端画布"的双通路，消息在事务提交后才推送以避免前端读到未提交数据，同步操作码按"添加/更新/删除 × 实体/属性/关系"的笛卡尔积定义，没有"更新关系"这种含糊的合并码。如果接口膨胀到几十个方法、协议消息膨胀到几十种类型，前端画布的渲染分支和后端业务逻辑都会失控。
八、总结：边界在哪，怎么守住
本体的工程边界由四个数字锚定：实体类型 20-50、关系规则 100-200、规则月迭代 10-20 条、人力维护 0.5-1 人。超过任一指标都会反噬价值。跨域用三层结构拆解，总量 60-120 个类型、250-400 条规则，仍可由 2-3 人团队管理。
上限不是束缚，是让有限建模资源聚焦最有价值的规则。剩余业务需求用规则扩展、知识图谱补充、行业模板三种路径分担。把这些经验固化为团队共识，比让每个新项目重新踩一遍坑要划算得多。