4. 特征评审流程：特征从开发到上线的标准评审流程
特征评审是金融风控模型开发中连接“开发”与“上线”的关键质量门禁。一个严谨的评审流程能够有效拦截低质量特征、避免数据泄露、防止过拟合，并确保特征在线上环境中的稳定性和可解释性。本节将详细阐述标准评审流程、评审委员会角色分工以及可落地的评审Checklist模板。
核心原则：特征评审不是“走过场”，而是通过多角色交叉验证，确保每一个上线的特征都经过严格的统计检验、业务逻辑校验和工程稳定性评估。
4.1 标准评审流程：从开发到上线的五阶段门禁
标准评审流程分为五个阶段，每个阶段都设有明确的准入准出标准，形成递进式的质量保障体系。
- 阶段一：特征开发自测（开发者）
- 完成特征计算逻辑编码与单元测试
- 验证特征在离线回放数据上的覆盖率与缺失率
- 初步检查特征分布是否符合业务预期
- 阶段二：技术架构评审（工程架构师）
- 评估特征计算对线上资源的消耗（CPU、内存、IO）
- 检查特征依赖的数据源是否稳定、是否存在循环依赖
- 确认特征计算逻辑可扩展、可运维
- 阶段三：数据质量评审（数据科学家）
- 执行全量数据回放，生成特征统计报告
- 检查特征缺失率、异常值、跨时间稳定性（PSI）
- 验证特征与目标变量的相关性是否符合业务逻辑
- 阶段四：业务逻辑评审（业务风控专家）
- 确认特征含义在业务场景中可解释
- 评估特征是否引入潜在歧视或合规风险
- 审核特征在极端场景下的表现是否符合业务常识
- 阶段五：上线发布评审（评审委员会）
- 汇总前四个阶段的评审结论
- 确认A/B测试方案设计合理
- 签署上线许可或退回整改
4.2 评审委员会角色与职责
评审委员会是特征上线的最终决策机构，通常由以下五个角色组成，每个角色拥有一票否决权。
| 角色 | 所属部门 | 核心职责 | 否决权范围 |
|---|---|---|---|
| 评审委员会主席 | 风控部 / 模型部 | 主持评审会议、协调争议、签署上线许可 | 流程合规性、整体风险 |
| 数据科学家 | 数据科学部 | 审核特征统计指标、回放报告、模型性能影响 | 数据质量、统计有效性 |
| 工程架构师 | 技术架构部 | 评估计算资源、数据依赖、系统稳定性 | 工程可行性、性能瓶颈 |
| 业务风控专家 | 风控策略部 | 审核业务逻辑、合规性、可解释性 | 业务合理性、合规风险 |
| 运维发布经理 | 运维部 | 确认发布计划、灰度策略、回滚方案 | 发布安全性、应急响应 |
最佳实践：建议每周固定时间召开一次特征评审会议，集中处理本周待评审的特征。紧急特征可发起临时评审，但需至少3位委员会成员（含主席）参与方可生效。
4.3 评审Checklist模板
以下Checklist模板可直接用于特征评审会议，确保评审过程无遗漏。每个检查项需标记“通过”、“不通过”或“不适用”。
4.3.1 技术架构检查项
- TC-01：特征计算逻辑是否已编写单元测试并通过？
- TC-02：特征依赖的数据源是否在SLA保障范围内？
- TC-03：特征计算预估QPS是否低于线上资源阈值？
- TC-04：是否存在循环依赖或死锁风险？
- TC-05：特征是否支持灰度发布和快速回滚？
4.3.2 数据质量检查项
- DQ-01：特征在回放数据集上的覆盖率是否 > 95%？
- DQ-02：特征缺失率是否 < 5%？
- DQ-03：特征PSI（群体稳定性指标）是否 < 0.1？
- DQ-04：特征与目标变量的IV值是否在合理区间（0.02 ~ 0.5）？
- DQ-05：特征是否存在明显的异常值或离群点？
4.3.3 业务逻辑检查项
- BL-01：特征含义是否在业务文档中有明确定义？
- BL-02：特征是否引入潜在的歧视性偏见（如地域、性别）？
- BL-03：特征在极端业务场景下的表现是否符合预期？
- BL-04：特征是否与现有策略规则存在冲突？
- BL-05：特征是否满足监管合规要求？
4.3.4 上线发布检查项
- RL-01：A/B测试方案是否已设计并评审通过？
- RL-02：实验组与对照组的分流逻辑是否正确？
- RL-03：监控指标（如KS、AUC、PSI）是否已配置告警？
- RL-04：回滚方案是否已准备就绪？
- RL-05：上线通知是否已发送至相关方？
常见陷阱：评审Checklist不能流于形式。建议在评审会议中逐项宣读检查结果，并记录每个检查项的详细证据。对于“不通过”项，必须明确指定整改责任人和整改截止日期，并在下次评审中重新检查。
4.4 评审流程自动化建议
为提升评审效率，建议将评审流程与CI/CD流水线集成，实现自动化检查与人工评审相结合。
# 特征评审自动化流水线伪代码示例
pipeline:
name: feature_review_pipeline
stages:
- stage: unit_test
tasks:
- run: pytest tests/feature_*.py
- check: coverage > 80%
- stage: data_quality_check
tasks:
- run: python scripts/feature_report.py --feature ${FEATURE_NAME}
- check: missing_rate < 0.05
- check: psi < 0.1
- check: iv > 0.02 and iv < 0.5
- stage: manual_review
tasks:
- notify: ["review_committee@company.com"]
- wait_for: approval
- stage: deploy_approval
tasks:
- run: python scripts/deploy_feature.py --feature ${FEATURE_NAME}
- notify: ["ops@company.com"]通过自动化流水线，可以将技术架构检查和数据质量检查前置，减少人工评审的负担，让评审委员会聚焦于业务逻辑和上线策略的审核。