4、特征命名规范：命名规则制定、层级命名法、版本管理策略
特征命名这件事，说实话，很多团队一开始都不太当回事。我见过不少项目，特征表里什么名字都有——有拼音缩写、有中文、有随机字符串，甚至还有"feature_1"、"test_123"这种。等到特征数量上了几百个，你就知道什么叫痛苦了。
命名规范不是形式主义。它是特征目录的"门牌号"。门牌号乱了，你找谁都找不到。今天我们就聊聊怎么把这套门牌号体系搭起来。
4.1 命名规则制定的核心原则
我个人习惯，命名规则先定三条底线：
- 可读性——看到名字就知道这个特征是什么
- 唯一性——同一个特征只有一个名字
- 可扩展性——新特征能自然融入，不用改规则
这三条看起来简单，实际落地时坑不少。我举个例子：
一个真实案例
某金融团队早期用"user_age"、"user_income"这种命名，看起来没问题。后来加了"user_credit_score_v1"、"user_credit_score_v2"，再后来加了"user_credit_score_v2_fix"。你猜怎么着？三个月后没人分得清v2和v2_fix的区别。这就是可扩展性没考虑好。
所以，我建议命名规则要包含这几个要素：
| 要素 | 说明 | 示例 |
|---|---|---|
| 实体域 | 特征所属的业务主体 | user, order, product |
| 业务域 | 特征所属的业务领域 | credit, risk, marketing |
| 特征名 | 描述特征含义的英文短语 | age, income, score |
| 聚合方式 | 如果是聚合特征，标明聚合函数 | avg, max, count |
| 时间窗口 | 如果是时间窗口特征，标明窗口 | 7d, 30d, 90d |
| 版本号 | 特征版本标识 | v1, v2 |
把这些要素拼起来，一个完整的特征名大概长这样：
user_credit_avg_score_30d_v1
实体域_业务域_特征名_聚合方式_时间窗口_版本号嗯，这里要注意：不是所有特征都需要所有要素。比如一个简单的用户年龄特征，可能就是"user_age_v1"。但聚合特征、时间窗口特征，这些要素必须带上，否则后面根本没法追溯。
4.2 层级命名法：让特征目录有结构
特征多了以后，平铺命名就不够用了。你需要一个层级结构。我推荐三层命名法：
- 第一层：实体层——特征属于谁（user/order/product）
- 第二层：领域层——特征属于哪个业务领域（credit/risk/marketing）
- 第三层：特征层——特征的具体含义和计算方式
这三层在命名中用下划线分隔，在目录中用文件夹组织。说白了，就是让特征名自带"路径信息"。
我的经验
层级命名法最大的好处是：你可以用通配符批量管理特征。比如"user_credit_*"就能匹配所有用户信用类特征。这在权限管理、数据脱敏、质量监控时特别有用。
来看一个完整的层级命名示例：
# 用户实体 - 信用领域
user_credit_score_v1
user_credit_avg_score_30d_v1
user_credit_max_score_90d_v1
# 用户实体 - 风险领域
user_risk_overdue_flag_v1
user_risk_loan_count_7d_v1
# 订单实体 - 交易领域
order_transaction_amount_v1
order_transaction_count_30d_v1你想想看，如果有一天你需要把所有"用户信用类特征"迁移到新集群，一个正则表达式就搞定了。这就是层级命名的威力。
4.3 版本管理策略：特征也会"升级"
特征不是一成不变的。业务变了、数据源变了、计算逻辑变了，特征就得跟着变。怎么管理这些变化？版本号。
我见过最糟糕的做法是：直接在原特征上改。改完以后，线上模型用的还是旧逻辑，结果模型输出全乱了。那次事故让我养成了一个习惯——特征必须版本化管理。
版本管理我建议用"语义化版本"的思路：
| 版本号 | 变更类型 | 示例 |
|---|---|---|
| v1 → v2 | 计算逻辑变更 | 评分公式调整 |
| v1 → v1.1 | 数据源切换，逻辑不变 | 从MySQL切到Hive |
| v1 → v1.0.1 | Bug修复，逻辑不变 | 修复空值处理 |
避坑指南
我曾经犯过一个错：特征版本号只加不减。结果v1、v2、v3、v4……到了v10，没人记得每个版本的区别。后来我强制要求：每次版本变更必须附带变更日志，记录变更原因、变更时间、变更人。没有日志的版本变更，一律驳回。
版本管理的另一个关键点是：旧版本不能删除。为什么？因为线上模型可能还在用旧版本。你删了v1，模型就崩了。正确的做法是：
- 新版本上线后，旧版本标记为"已废弃"
- 设置一个过渡期（比如30天）
- 过渡期后，确认没有模型使用旧版本，再归档
下面这张图展示了特征版本的生命周期管理流程：
4.4 命名规范落地的三个关键动作
光有规范不行，得落地。我总结了三件事：
- 写进开发规范——命名规则必须写入团队的开发手册，新成员入职第一课就讲这个
- 自动化校验——在特征注册环节加一个命名校验脚本，不符合规则的直接拒绝注册
- 定期审计——每个月跑一次特征目录审计，找出不合规的命名，推动整改
一个小技巧
我习惯在特征注册平台加一个"命名预览"功能。开发人员输入特征名，系统自动解析出实体域、业务域、特征名、聚合方式、时间窗口、版本号，并显示在界面上。这样开发人员能直观看到自己的命名是否规范。这个小功能帮我们减少了80%的命名错误。
最后说一句：命名规范不是一成不变的。随着业务发展，你可能需要调整规则。但每次调整都要有充分的理由，并且要通知到所有相关人员。改规则容易，让所有人跟上节奏难。