2. 特征生命周期管理：特征从采集到退役的全流程
信用评分特征并非静态资产，而是经历从需求提出、开发、上线、监控到最终退役的完整生命周期。缺乏生命周期管理的特征库会迅速积累大量“僵尸特征”——无人使用、无文档、无血缘记录，最终导致评分模型维护成本激增。本节将定义特征生命周期的标准阶段、版本控制机制及各阶段的血缘记录要求。
2.1 特征生命周期全流程阶段
一个信用评分特征通常经历以下六个核心阶段，每个阶段都有明确的准入/准出标准和血缘记录节点：
| 阶段 | 阶段名称 | 核心活动 | 产出物 | 血缘记录要求 |
|---|---|---|---|---|
| 1 | 需求与设计 | 业务方提出特征需求；数据科学家完成特征定义、计算逻辑设计 | 特征需求文档、特征设计说明书 | 记录需求来源、业务口径、设计人、设计日期 |
| 2 | 开发与测试 | 数据工程师编写ETL脚本；在测试环境验证特征逻辑与数据质量 | 特征开发代码、测试报告 | 记录代码仓库地址、提交版本、测试数据集、测试通过标准 |
| 3 | 评审与上线 | 代码评审、数据质量评审、业务验收；部署至生产调度 | 上线审批单、生产调度配置 | 记录评审人、审批时间、上线版本号、生产调度ID |
| 4 | 监控与运维 | 每日/每周监控特征分布、缺失率、稳定性（PSI）、延迟 | 监控看板、告警日志 | 记录监控指标基线、告警阈值、异常事件及处理记录 |
| 5 | 变更与迭代 | 因业务调整或数据源变更，修改特征逻辑或参数 | 变更申请单、新版本特征代码 | 记录变更原因、变更前后对比、版本升级记录 |
| 6 | 退役与归档 | 特征不再使用；下线生产调度，归档代码与血缘记录 | 退役审批单、归档记录 | 记录退役原因、下线时间、替代特征（如有）、归档位置 |
关键原则：每个阶段的血缘记录必须包含“谁、什么时间、做了什么、为什么做、产出物在哪”五个要素。缺失任一要素的血缘记录在回溯时将产生信息断层。
2.2 特征版本控制
特征版本控制是生命周期管理的核心基础设施。与软件版本控制不同，特征版本不仅管理代码，还需管理特征元数据、依赖数据源版本和模型关联版本。
2.2.1 版本号规范
推荐采用语义化版本号（Semantic Versioning）扩展格式：
主版本号.次版本号.修订号-构建元数据
示例：v2.1.3-20250315
版本号递增规则：
- 主版本号：特征计算逻辑发生不兼容变更（如聚合口径从“近6个月”改为“近12个月”）
- 次版本号：向下兼容的功能性变更（如新增一个过滤条件但默认行为不变）
- 修订号：向下兼容的问题修正（如修复空值处理bug）
- 构建元数据：可选，记录构建日期或CI流水线编号2.2.2 版本控制内容清单
| 管理对象 | 版本控制方式 | 存储位置 | 血缘关联字段 |
|---|---|---|---|
| 特征计算代码 | Git仓库（分支+Tag） | 特征代码库 | commit_id, tag_name |
| 特征元数据 | 元数据管理平台（版本快照） | 特征注册中心 | feature_version, effective_date |
| 依赖数据源版本 | 数据资产目录（版本标记） | 数据血缘系统 | source_version, table_snapshot |
| 模型关联版本 | 模型管理平台（版本映射表） | 模型注册中心 | model_version, feature_version_map |
| 监控配置版本 | 配置中心（版本化配置） | 监控系统 | monitor_config_version |
最佳实践：在特征注册中心中，每个特征版本应保存一份完整的“版本快照”，包含该版本下的全部元数据、代码指针、依赖数据源版本和关联模型列表。这样在回溯时，可以一键还原该特征在任意历史时间点的完整上下文。
2.3 特征生命周期各阶段的血缘记录要求
血缘记录不是事后补录，而是伴随特征生命周期各阶段同步产生的元数据。以下按阶段详细说明记录要求：
2.3.1 需求与设计阶段
- 需求来源：记录提出需求的业务方、需求单号、需求日期
- 业务口径：用自然语言描述特征的业务含义，例如“近3个月信用卡账单最低还款次数”
- 计算逻辑：伪代码或SQL逻辑描述，包含聚合窗口、过滤条件、空值处理规则
- 设计人：数据科学家或特征设计者
- 设计日期：特征设计说明书定稿日期
2.3.2 开发与测试阶段
- 代码仓库：Git仓库URL、分支名、提交commit_id
- 测试数据集：测试数据的时间范围、数据量、数据源表名
- 测试结果：测试通过/失败、测试报告链接、测试执行人
- 数据质量检查：缺失率、异常值比例、分布一致性检验结果
2.3.3 评审与上线阶段
- 评审记录：评审人、评审日期、评审意见、审批状态
- 上线版本：特征版本号、上线时间、上线环境（生产/预发）
- 调度配置：调度任务ID、调度频率、依赖上游任务列表
- 上线审批单：审批系统链接或审批单号
2.3.4 监控与运维阶段
- 监控基线：特征均值、标准差、PSI基线、缺失率基线
- 告警记录：告警时间、告警类型、告警阈值、触发值
- 异常处理：异常原因分析、处理措施、处理人、处理时间
- 监控看板：看板URL或截图存储路径
2.3.5 变更与迭代阶段
- 变更原因：业务变更、数据源变更、bug修复、性能优化等
- 变更前后对比：旧版本号 vs 新版本号、逻辑差异说明
- 变更审批：变更申请单号、审批人、审批日期
- 版本升级记录：升级时间、升级方式（灰度/全量）、回滚方案
2.3.6 退役与归档阶段
- 退役原因：特征不再使用、被替代、模型下线、数据源不可用等
- 退役时间：实际下线生产调度的日期时间
- 替代特征：替代特征的特征ID和版本号（如有）
- 归档位置：代码归档路径、元数据归档路径、血缘记录归档路径
- 归档确认人：执行归档操作的数据管理员
常见陷阱：许多团队只在特征上线时记录一次血缘，后续变更和退役阶段完全不更新血缘记录。这会导致回溯时出现“特征已变更但血缘仍指向旧版本”的断链问题。建议将血缘记录更新作为每个阶段准入/准出检查的强制步骤。
2.4 特征生命周期血缘全景图
下图展示了特征从需求到退役的全生命周期中，各阶段的血缘记录节点与数据流向：
2.5 特征生命周期管理检查清单
为确保特征生命周期管理落地，建议在每个阶段设置以下检查点：
| 阶段 | 检查项 | 责任人 | 检查频率 |
|---|---|---|---|
| 需求与设计 | 特征设计说明书是否包含业务口径、计算逻辑、空值处理规则 | 数据科学家 | 每个新特征 |
| 开发与测试 | 代码是否提交至Git仓库并打Tag；测试报告是否包含数据质量指标 | 数据工程师 | 每个新版本 |
| 评审与上线 | 评审审批记录是否完整；上线版本号是否与代码Tag一致 | 数据架构师 | 每次上线 |
| 监控与运维 | 监控基线是否已配置；告警阈值是否合理 | 数据运维 | 上线后一周内 |
| 变更与迭代 | 变更申请是否经过审批；变更前后版本对比是否记录 | 数据科学家 | 每次变更 |
| 退役与归档 | 退役审批是否完成；血缘记录是否归档至指定位置 | 数据管理员 | 每次退役 |
落地建议：将上述检查清单嵌入数据治理平台的“特征注册”流程中，每个阶段设置强制填写字段和审批节点。只有通过当前阶段检查，特征才能进入下一阶段。这种“门禁式”管理可以有效防止血缘记录缺失。