4、特征版本化策略：语义化版本（SemVer）在特征中的应用
版本号这东西，说白了就是给特征打标签。我见过不少团队，特征一多就开始乱——今天改个计算逻辑，明天调个窗口参数，后天发现线上模型跑出来的结果跟训练时对不上。嗯，问题就出在版本管理上。
我个人习惯用语义化版本（SemVer）来管特征。为什么？因为它清晰。你看到版本号，就知道这个特征经历了什么级别的变更。
4.1 语义化版本的核心结构
标准的 SemVer 是 MAJOR.MINOR.PATCH 三段式。在特征场景里，我把它映射成：
- MAJOR（主版本）：不兼容的变更。比如特征的计算逻辑完全重写，或者输入源换了。
- MINOR（次版本）：向后兼容的新功能。比如新增了一个聚合维度，但旧逻辑还能用。
- PATCH（修订版本）：向后兼容的缺陷修复。比如修了一个边界值 bug，或者优化了缓存策略。
关键原则：特征版本号一旦发布，就不能再修改。只能递增，不能回退。这是版本管理的底线。
4.2 版本号规范：特征场景下的具体规则
我在项目中遇到过这样的问题：两个工程师同时改了同一个特征，一个改了计算逻辑，一个修了数据源格式。结果版本号冲突了。后来我们定了一套规则：
| 变更类型 | 版本号变化 | 示例 | 说明 |
|---|---|---|---|
| 计算逻辑重写 | MAJOR +1 | 1.2.3 → 2.0.0 | 输出值可能完全不同 |
| 新增特征维度 | MINOR +1 | 1.2.3 → 1.3.0 | 旧版本仍可用 |
| 修复空值处理 | PATCH +1 | 1.2.3 → 1.2.4 | 不影响已有结果 |
| 数据源切换 | MAJOR +1 | 1.2.3 → 2.0.0 | 分布可能偏移 |
| 性能优化 | PATCH +1 | 1.2.3 → 1.2.4 | 输出不变 |
我的习惯：每次发布前，先问自己三个问题——这个变更会影响下游模型吗？旧版本还能跑吗？新版本和旧版本的结果能直接对比吗？答案决定了版本号怎么跳。
4.3 向后兼容性：特征版本的生命线
你想想看，一个特征被十几个模型引用，你改了一个小逻辑，结果所有模型都得重新训练。这就是不兼容的代价。
向后兼容性，说白了就是新版本不能破坏旧版本的使用方式。具体来说：
- 接口兼容：特征名称、输入参数、输出格式不能变。变了就是 MAJOR。
- 语义兼容：相同输入下，新版本输出值的变化在可接受范围内。比如归一化后的均值漂移不超过 0.01。
- 行为兼容：新版本不能引入新的异常情况。比如原来返回 null 的地方，现在不能抛异常。
我曾经踩过的坑：有一次我改了一个特征的默认值，从 0 改成了 -1。我觉得只是个小改动，就只升了 PATCH。结果下游模型跑出来的 AUC 掉了 3 个点。后来查了半天，才发现是默认值变了导致样本分布偏移。从那以后，任何默认值的变更我都升 MINOR。
4.4 特征版本的生命周期管理
版本号不是随便写的。我习惯用一张图来管理特征版本的生命周期：
4.5 版本号在特征注册中的实际应用
在特征注册系统里，版本号是特征的唯一标识。我习惯这样组织：
# 特征注册时的版本号示例
feature_registry = {
"user_30d_avg_spend": {
"version": "2.1.3",
"status": "active",
"created_at": "2024-03-15",
"deprecated_at": None,
"compatible_versions": ["2.0.0", "2.1.0", "2.1.1", "2.1.2"]
},
"user_7d_click_rate": {
"version": "1.0.0",
"status": "deprecated",
"created_at": "2023-11-01",
"deprecated_at": "2024-02-28",
"compatible_versions": ["0.9.0"]
}
}一个小技巧：我每次注册特征时，都会在元数据里记录 compatible_versions 列表。这样下游模型在升级时，可以快速知道哪些旧版本还能用。省去了很多排查时间。
4.6 版本冲突与解决策略
多团队协作时，版本冲突是家常便饭。我遇到过最典型的情况：A 团队升了 MAJOR，B 团队不知道，直接引用了新版本，结果模型全崩了。
我的解决思路是：
- 版本锁定：每个模型必须显式声明它依赖的特征版本号。不能写「latest」。
- 兼容性矩阵：维护一张表，记录每个特征版本与模型版本的兼容关系。
- 灰度发布：新版本先在小流量上跑，验证没问题再全量。
| 特征版本 | 模型 A | 模型 B | 模型 C |
|---|---|---|---|
| user_30d_avg_spend v2.1.3 | ✅ 兼容 | ✅ 兼容 | ❌ 不兼容 |
| user_30d_avg_spend v2.0.0 | ✅ 兼容 | ✅ 兼容 | ✅ 兼容 |
| user_7d_click_rate v1.0.0 | ❌ 已废弃 | ✅ 兼容 | ✅ 兼容 |
血的教训：我曾经在灰度发布时只放了 5% 的流量，结果那 5% 的用户特征分布跟全量不一样，导致模型在灰度组表现很好，全量一上就崩。后来我学乖了——灰度不仅要看流量比例，还要看特征分布是否均匀。
4.7 版本号自动化管理
手动维护版本号？不现实。我建议用 CI/CD 来自动化：
- 提交信息解析：根据 commit message 自动判断版本号变化。比如
feat:升 MINOR，fix:升 PATCH，breaking:升 MAJOR。 - 版本号校验：每次注册时自动检查版本号是否合法，是否与已有版本冲突。
- 变更日志生成：自动生成 CHANGELOG，记录每个版本的变化。
# 自动化版本号生成示例
def bump_version(current_version, change_type):
major, minor, patch = map(int, current_version.split('.'))
if change_type == 'breaking':
return f"{major + 1}.0.0"
elif change_type == 'feature':
return f"{major}.{minor + 1}.0"
elif change_type == 'fix':
return f"{major}.{minor}.{patch + 1}"
else:
raise ValueError(f"Unknown change type: {change_type}")嗯，版本号这东西，看着简单，但用好了能省很多事。我见过太多团队因为版本管理混乱，导致线上事故。说白了，版本号就是特征的身份证，你得让它清晰、唯一、可追溯。