3. 版本管理核心概念：版本号规范、基线版本与分支版本、版本发布流程
在风控策略的持续迭代中，版本管理是保障策略可追溯、可回滚、可协作的基石。缺乏规范的版本管理，将导致策略混乱、线上事故频发、模型迭代无法对齐。本节围绕版本管理的三大核心要素展开：版本号规范、基线版本与分支版本、版本发布流程。
3.1 版本号规范：语义化与风控扩展
风控策略版本号推荐采用 语义化版本控制（Semantic Versioning）并扩展风控领域标识，格式为：
主版本号.次版本号.修订号-预发布标识+构建元数据
示例：2.1.3-rc.1+build20240515
| 组成部分 | 风控语义 | 变更示例 |
|---|---|---|
| 主版本号 | 策略框架或核心模型架构发生不兼容变更 | 评分卡从A卡切换为B卡；决策流从规则集升级为模型+规则混合架构 |
| 次版本号 | 新增策略模块、规则或模型版本升级（向下兼容） | 新增多头借贷规则组；模型从v2.0升级到v2.1 |
| 修订号 | 参数调优、阈值调整、bug修复（不改变策略逻辑） | 将“近30天查询次数”阈值从5次调整为3次 |
| 预发布标识 | 标识版本处于开发、测试或灰度阶段 | alpha（内部开发）、beta（内部测试）、rc（候选发布） |
| 构建元数据 | 记录版本构建时间、流水线ID或责任人 | build20240515、jenkins-1234 |
实践建议：风控策略版本号应纳入CI/CD流水线自动生成，避免人工手动编号导致遗漏或冲突。建议在版本号中嵌入策略生效的样本分层标识（如：2.1.3-rc.1+sampleA），便于快速定位版本适用的客群。
3.2 基线版本与分支版本
风控策略版本管理借鉴Git分支模型，形成基线版本与分支版本的双轨机制。基线版本是稳定、经过充分验证的策略主干；分支版本则用于特定场景的并行开发与测试。
核心原则：基线版本只允许合并，不允许直接修改。所有策略变更必须从基线拉出分支，在分支上完成开发、测试、评审后，再合并回基线。
3.2.1 基线版本（Master/Trunk）
- 定义：当前生产环境正在运行或即将发布的稳定策略版本。
- 特性：只读、受保护、必须通过Code Review和自动化测试才能合并。
- 生命周期：从首次发布开始，持续维护，直到被新的基线版本取代。
3.2.2 分支版本（Branch）
- 特性分支：用于开发新规则、新模型或新策略模块，开发完成后合并回基线。
- 修复分支：用于紧急修复线上bug或阈值调整，修复后合并回基线并打上修订号标签。
- 实验分支：用于A/B测试、样本分层对比实验，实验结束后可选择合并或废弃。
- 发布分支：从基线拉出，用于灰度发布、小流量验证，验证通过后合并回基线并打上正式版本号。
3.3 版本发布流程
风控策略的版本发布必须遵循严格的分级审批与灰度放量流程，以最小化线上风险。标准发布流程包含以下六个阶段：
- 开发阶段：从基线拉出分支，在分支上进行策略开发、参数调优、规则编写。
- 自测阶段：开发人员在分支上完成单元测试、离线回测（Backtesting），确保策略在历史样本上表现符合预期。
- 评审阶段：提交Code Review，由风控策略负责人、模型团队、业务方共同评审策略逻辑与预期效果。
- 测试阶段：在预发环境或沙箱环境进行集成测试、压力测试、样本分层验证。
- 灰度发布：将策略以分支版本形式部署到生产环境，控制流量比例（如1%→5%→20%→50%），监控核心指标（通过率、逾期率、响应时间）。
- 全量发布：灰度验证通过后，将分支合并回基线，打上正式版本号，全量上线。
常见陷阱：
- 跳过灰度：直接全量发布未经灰度验证的策略，可能导致大规模通过率异常或逾期飙升。
- 版本号冲突：多人同时开发时未及时拉取最新基线，导致合并冲突或版本号重复。
- 分支长期不合并：实验分支长期游离于基线之外，导致策略碎片化，后续维护成本剧增。
3.4 版本发布检查清单
| 阶段 | 检查项 | 责任人 |
|---|---|---|
| 开发 | 版本号是否符合规范；分支是否从最新基线拉出 | 策略开发工程师 |
| 自测 | 离线回测通过率偏差 < 5%；KS/Gini指标未显著下降 | 策略开发工程师 |
| 评审 | 策略逻辑文档完整；评审意见已闭环 | 风控策略负责人 |
| 测试 | 集成测试通过；样本分层验证各客群指标一致 | 测试工程师 |
| 灰度 | 灰度流量比例符合计划；监控指标无异常告警 | 运维/风控值班 |
| 全量 | 分支已合并回基线；版本标签已打；发布公告已发送 | 发布经理 |