一.SOP标准操作流程

SOP，是 Standard Operating Procedure三个单词中首字母的大写 ，即标准作业程序，指将某一事件的标准操作步骤和要求以统一的格式描述出来，用于指导和规范日常的工作。SOP的精髓是将细节进行量化，通俗来讲，SOP就是对某一程序中的关键控制点进行细化和量化。实际执行过程中sop核心是符合本企业并可执行，不流于形式。

模型开发SOP

模型开发sop即指“模型开发标准操作程序”，将开发过程统一为标准操作步骤和要求，用来指引模型开发日常的工作。

模型开发并非易事，需要平衡业务方，模型开发方，验证方，领导层等多方面需求。不同部门需求有可能发生冲突，因此模型开发需要照顾各方利益，平衡取舍。模型开发并非完全尊从教科书理论，真实大数据是不干净的，无法完美满足教科书上各条理论。
模型开发尽可能做到模型较高准确性，较高区分能力，分数稳定，合理、维度合适。

模型开发SOP重要性

（1）标准化，流程化重复工作，提高建模效率和质量

（2）便于模型验证和维护

二.模型开发立项需求

业务方或策略方（政策部）发起需求，确定模型开发方原因，使用场景，模型性能要求。

比如，A卡贷前审批模型主要是为了评估贷前用户的违约概率；B卡用于预测用户贷后违约概率；C卡用于催收。反欺诈模型预测黑产，灰产用户骗贷、薅羊毛行为；资本计量模型主要适用于 Basel 体系确定最低资本要求和进行压力测试。

模型立项可以通过邮件和会议形式确立，必要时做好会议纪要。

三.模型开发具体环节

是建模工作的主要过程，包括SQL取数、数据清洗、数据探索，变量筛选、模型建立、模型选择，模型验证，模型部署，线上验证，模型监控和模型迭代。

1. 需求分析
   建模前我们要确定业务目标和风险管理需求。定义模型的预期用途和评估标准。
   其中与用户沟通特别重要，对相关利益相关者进行模型使用和理解的培训。与业务团队沟通模型的限制和预期效果。沟通方式包括会议，邮件，微信等等。
   很多初级风控建模人员连target目标变量没搞清楚就开始建模，与用户需求有真实差异。

   
   

2. 

2.SQL取数：

SQL取数是根据业务方需求，关联若干表单，提取模型需要数据。公司数据量越大，基层表单越混乱，此步骤会越耗时，SQL语句可能从几十行到几千行不等，需要熟悉公司数据库和表单逻辑。新手写的SQL语句还容易产生跑数据耗时，卡死服务器等问题。

3.数据清洗：

数据清洗主要是对不能直接入模的数据做清洗处理，比如类型不对数据，不合理异常值，缺失值，怪异字符串等等。入模数据必须是结构化数据，否则训练模型时会报错。对于类别变量，可以用one-hot编码。但one-hot编码消耗内存，产生高维度变量。逻辑回归建模时推荐WOE编码方法。对于新一代集成树算法catboost，可以直接申明类别变量，然后自动处理。

4.数据探索

EDA探索性数据分析和描述性统计，包括统计总体数据量大小，好坏客户占比，数据类型有哪些，变量缺失率，变量频率分析直方图可视化，箱形图可视化，变量相关性可视化等。

数据探索是新手容易忽略环节。经验丰富建模工程师往往通过数据探索发现高价值变量和数据泄露可疑变量。

5.变量筛选：

从原始数据中筛选出重要变量，踢除噪音变量，相关性高变量。如果为了更好业务解释性，逻辑回归算法对变量筛选严格一些。集成树算法对变量筛选要求不高，但从模型验证，商业成本，后期维护成本考虑，尽可能剔除不必要变量。

常见的特征选择方法：

• IV  information value（信息价值），常用于逻辑回归模型

• Information gain（信息增益），常用于决策树模型

• Correlation coefficient scores（相关系数），通用所有模型

• missing value （缺失率），删除缺失率接近1的变量

• unique value（唯一值），删除唯一值占比接近1的变量

• shap value，删除shap值接近0的变量

• 其它还有很多变量筛选方法，包括工业级和商业街算法，有高端定制需求用户可与Toby老师联系。

6.模型建立：

模型建立就是用清洗后数据,通过机器学习算法建立模型。给模型喂养数据，训练数据，最终让模型生成预测能力，批量预测客户违约率。

7.模型选择：

根据业务方需求，通过多算法比较，择优选择综合性能最佳模型。

一般而言,金融风控领域模型看重AUC，ks，accuracy，psi等指标，混淆矩阵等其他指标也要附带参考。不同模型指标代表不同意义。

8.模型验证：

模型开发过程不可或缺的一部分。它有助于发现表达数据的最佳模型和所选模型将来工作的性能如何。

模型验证分为三个环节,模型开发部门首先内部评估模型质量是否合格，如果没问题会发生第三方模型验证团队。第三方模型验证团队必须保证独立性，验证过程不受模型开发团队干扰，避免既当裁判又当球员的作弊行为。第三方模型验证团队可以是外包公司，也可以是公司内部团队。如果担心数据泄露，优先推荐公司内部团队独立验证。最后模型验证报告会提交给各个团队领导审批。如果领导认为模型质量有问题，会邮件批注或驳回模型。

模型评估的常见的五个⽅法：

• 混淆矩阵

• lift提升图&洛伦兹图

• 基尼系数

• ks曲线

• roc曲线

• psi模型稳定性

由于人员编制不稳定，部分项目相关同事会离职。因此模型验证完后需要存档，包括模型资料保存。存档中要完整记录验证人员，开发人员，业务方人员，开发时间，模型性能，模型缺陷等内容，以便后续人员查阅和维护。

9. 模型优化

• 根据评估结果优化模型。

• 可能包括特征重新选择、模型参数调整或尝试不同的算法。

10.模型部署

通过模型验证后，配置好模型的包，文档说明，变量表，准备线上部署。

11、线上线下验证

完成模型线上部署后，进行模型的线上线下部署验证。主要测试线上模型分和线下模型分是否一致。如果线上线下模型分不一致需要找出原因。一般情况下维度高的模型容易发生线上线下分数不一致，因此保留合适模型维度有利于模型上线后维护。

12、模型监控

完成模型的部署和线上验证后，对模型进行各维度的监控，确定是否迭代，形成模型工作闭环。

模型监控需要每日生成报表，邮件发送相关同事查阅。对于数据量大的金融公司，需要整合大量表，模型监控并不是容易的事。

13.模型迭代

如果监控模型ks，AUC，psi等指标变化太大，需要重新迭代模型

14. 反馈循环
机器学习领域技术是不断发展更新的，我们不能闭门造车。我们要建立用户或内部员工反馈机制，收集模型在实际使用中的反馈。根据反馈进行模型迭代和改进。

15.文档记录
记录模型开发过程中的所有步骤、决策和结果。编写技术文档和用户手册。上述措施是中大型公司必备环节，小公司容易忽略地方。IT技术人员或模型开发人员，数据分析师离职后，留下文档记录方便后续接替岗位人员快速熟悉工作内容，否则容易出现交接问题。公司开发所有模型需要存档，备份。

16.审计与审查
持牌照公司根据巴塞尔协议或银行监管需求要定期进行内部和外部审计，确保模型开发和部署流程的透明度和合规性。
金融风控模型开发的SOP需要不断地根据新的数据、市场变化和监管要求进行更新和优化。此外，整个流程应该遵循行业最佳实践和监管指导原则，以确保模型的可靠性和公正性。

备注：上述模型开发sop只是为大家提供一个参考模板，由于各条业务方差异，不能满足所有场景。希望大家因地制宜，建好最适合自己公司的模型开发sop。

风控建模精英团队组建

实现上述风控开发流程离不开风控团队实施。最后Toby老师根据多年经验谈谈风控模型团队组建。风控建模是个复杂系统工程，涉及金融（信贷，宏观经济），风控，数学，统计学，编程领域知识。如果没有一个精英团队，很难构建风控模型。其中最难环节是数学，统计学，招聘时候需要多储备数学，统计学专业人才。编程主流派别有Python，R，SAS。SAS是付费的，需求相对较少，大中型银行会有SAS编程人员需求。民营公司为了节约成本，更愿意用开源的Python和R。R代码量最小，但Python在AI领域社区更成熟。团队leader，例如模型经理或总监最好同时具备统计学，金融信贷业务，编程知识，这样好协调各个组员交流和沟通。模型开发人员需要尊重业务方意见，不能只从统计学，数学思维考虑问题，有些数学问题在业务方是行不通的，只是一种理想境界。业务方也需要尊重模型开发人员意见，让模型质量更有信服力。

在模型竞赛中，我们也认识到了很多朋友，他们虽然没有海龟，博士等文凭，但是天生的猎手。leader在招人时候也需要开阔心胸，不能因各种条件束缚了双手。当然从其它成熟团队挖人是最快方法，开的筹码也相对较高。