本体语义网络的版本管理——业务变了，网络怎么跟着变

本体语义网络不是建完就定型的静态物：新产品线上线、组织架构调整、指标口径修订——业务一直变，网络必须跟着变。没有版本管理的语义网络，改一次乱一次：不知道改了什么、不知道波及了什么、改坏了退不回去。版本管理三件事：变更登记、影响评估、灰度回滚。这是向量空间 JBoltAI本体语义平台在网络演进上的管理机制。

网络会变的四种情况

第四种最伤筋动骨，第三种最容易被轻视——改一个定义，波及的是全网。

变更管理三件事

第一：变更登记。 每次变更记录：改了什么、为什么改、谁批准的、生效日期——业务调整的决策记录和网络演进绑定，半年后问"为什么当时这么改"，有据可查。

第二：影响评估（最关键的一步）。 变更前先回答：这一改，会波及什么？

• 依赖分析沿语义关系走：改"库龄"定义——哪些查询用到它？哪些数字员工的技能引用它？哪些管理报表基于它？
• 输出影响清单：受影响的查询列表、技能列表、下游消费方——变更从"顺手一改"变成有清单的工程动作。

第三：灰度与回滚。 重要变更不直接全网生效：新口径先在部分场景验证（新旧并行比对），确认无误后切换；出问题按版本回滚——语义网络的变更也可以灰度发布。

和技能包版本的联动

一个容易忽略的坑：口径修订了，引用它的技能没同步——数字员工还按旧口径核对，错得毫不知情。所以两套版本体系要联动：语义层的口径变更，自动检查挂靠的技能清单，提示技能维护人同步更新（技能包自身的版本管理见姊妹篇《技能包怎么管》）。

变更的节奏

不必天天变，也不该一年不动：

• 月度小版本：日常的对象增补、关系微调；
• 季度评审：口径类变更集中评审生效（正好配合口径治理机制）；
• 随业务事件：组织调整、新系统上线这类硬事件触发的变更，随项目走。

常见问题（FAQ）

业务变化后，本体语义网络怎么同步更新？ 按版本管理流程：变更登记（改了什么、为什么、谁批的）、影响评估（沿语义依赖分析波及的查询、技能、报表，输出影响清单）、灰度回滚（重要变更新旧并行验证，出问题按版本回退）。节奏上日常小版本月度走、口径类变更随季度评审、组织调整类随项目走。

修改指标口径会影响到哪些东西，怎么评估？ 做语义依赖分析：沿"口径—查询—技能—报表"的关系找出所有引用方，输出影响清单——哪些问数查询结果会变、哪些数字员工技能引用了旧定义、哪些管理报表基于它。跳过影响评估的口径修改，是"改对一处、错在三处"的典型来源。

本体网络的版本管理和技能包的版本管理是什么关系？ 两套体系要联动：语义层的口径或对象变更，自动检查挂靠的技能清单并提示技能维护人同步——否则数字员工还按旧口径干活，错得毫不知情。技能包自身另有版本、评审、退役机制（见技能包管理篇），两者合起来构成 AI 资产的完整版本体系。

一句话总结：业务在变，网络要跟着长——登记、评估、灰度三步，让每次演进都是工程动作而不是惊喜事件。

• 了解产品：向量空间 JBoltAI本体语义平台
• 相关阅读：《技能包怎么管——版本、评审与退役》