平衡各方利益的模型才是最好模型
---Toby！2022 09 03
各位朋友大家好，我是Toby老師。之前有很多風控朋友咨詢如何搭建風控模型。今天我抛磚引玉為大家講述金融風控模型開發SOP(标準操作流程)，供大家參考。
一.SOP标準操作流程
SOP，是 Standard Operating Procedure三個單詞中首字母的大寫 ，即标準作業程式，指将某一事件的标準操作步驟和要求以統一的格式描述出來，用于指導和規範日常的工作。SOP的精髓是将細節進行量化，通俗來講，SOP就是對某一程式中的關鍵控制點進行細化和量化。實際執行過程中sop核心是符合本企業并可執行，不流于形式。
模型開發SOP
模型開發sop即指“模型開發标準操作程式”，将開發過程統一為标準操作步驟和要求，用來指引模型開發日常的工作。
模型開發并非易事，需要平衡業務方，模型開發方，驗證方，上司層等多方面需求。不同部門需求有可能發生沖突，是以模型開發需要照顧各方利益，平衡取舍。模型開發并非完全尊從教科書理論，真實大資料是不幹淨的，無法完美滿足教科書上各條理論。
模型開發盡可能做到模型較高準确性，較高區分能力，分數穩定，合理、次元合适。
模型開發SOP重要性
（1）标準化，流程化重複工作，提高模組化效率和品質
（2）便于模型驗證和維護
二.模型開發立項需求
業務方或政策方（政策部）發起需求，确定模型開發方原因，使用場景，模型性能要求。
比如，A卡貸前審批模型主要是為了評估貸前使用者的違約機率；B卡用于預測使用者貸後違約機率；C卡用于催收。反欺詐模型預測黑産，灰産使用者騙貸、薅羊毛行為；資本計量模型主要适用于 Basel 體系确定最低資本要求和進行壓力測試。
模型立項可以通過郵件和會議形式确立，必要時做好會議紀要。
三.模型開發具體環節
是模組化工作的主要過程，包括SQL取數、資料清洗、資料探索，變量篩選、模型建立、模型選擇，模型驗證，模型部署，線上驗證，模型監控和模型疊代。
1.SQL取數：
SQL取數是根據業務方需求，關聯若幹表單，提取模型需要資料。公司資料量越大，基層表單越混亂，此步驟會越耗時，SQL語句可能從幾十行到幾千行不等，需要熟悉公司資料庫和表單邏輯。新手寫的SQL語句還容易産生跑資料耗時，卡死伺服器等問題。
2.資料清洗：
資料清洗主要是對不能直接入模的資料做清洗處理，比如類型不對資料，不合理異常值，缺失值，怪異字元串等等。入模資料必須是結構化資料，否則訓練模型時會報錯。對于類别變量，可以用one-hot編碼。但one-hot編碼消耗記憶體，産生高次元變量。邏輯回歸模組化時推薦WOE編碼方法。對于新一代內建樹算法catboost，可以直接申明類别變量，然後自動處理。
3.資料探索
EDA探索性資料分析和描述性統計，包括統計總體資料量大小，好壞客戶占比，資料類型有哪些，變量缺失率，變量頻率分析直方圖可視化，箱形圖可視化，變量相關性可視化等。
4.變量篩選：
從原始資料中篩選出重要變量，踢除噪音變量，相關性高變量。
常見的特征選擇方法：
- IV information value（資訊價值），常用于邏輯回歸模型
- Information gain（資訊增益），常用于決策樹模型
- Correlation coefficient scores（相關系數），通用所有模型
- missing value （缺失率），删除缺失率接近1的變量
- unique value（唯一值），删除唯一值占比接近1的變量
- shap value，删除shap值接近0的變量
5.模型建立：
模型建立就是用清洗後資料,通過機器學習算法建立模型。給模型喂養資料，訓練資料，最終讓模型生成預測能力，批量預測客戶違約率。
6.模型選擇：
根據業務方需求，通過多算法比較，擇優選擇綜合性能最佳模型。
一般而言,金融風控領域模型看重AUC，ks，accuracy，psi等名額，混淆矩陣等其他名額也要附帶參考。不同模型名額代表不同意義。
7.模型驗證：
模型開發過程不可或缺的一部分。它有助于發現表達資料的最佳模型和所選模型将來工作的性能如何。
模型驗證分為三個環節,模型開發部門首先内部評估模型品質是否合格，如果沒問題會發生第三方模型驗證團隊。第三方模型驗證團隊必須保證獨立性，驗證過程不受模型開發團隊幹擾，避免既當裁判又當球員的作弊行為。第三方模型驗證團隊可以是外包公司，也可以是公司内部團隊。如果擔心資料洩露，優先推薦公司内部團隊獨立驗證。最後模型驗證報告會送出給各個團隊上司審批。如果上司認為模型品質有問題，會郵件批注或駁回模型。
模型評估的常見的五個⽅法：
- 混淆矩陣
- lift提升圖&洛倫茲圖
- 基尼系數
- ks曲線
- roc曲線
- psi模型穩定性
由于人員編制不穩定，部分項目相關同僚會離職。是以模型驗證完後需要存檔，包括模型資料儲存。存檔中要完整記錄驗證人員，開發人員，業務方人員，開發時間，模型性能，模型缺陷等内容，以便後續人員查閱和維護。
8.模型部署
通過模型驗證後，配置好模型的包，文檔說明，變量表，準備線上部署。
9、線上線下驗證
完成模型線上部署後，進行模型的線上線下部署驗證。主要測試線上模型分和線下模型分是否一緻。如果線上線下模型分不一緻需要找出原因。一般情況下次元高的模型容易發生線上線下分數不一緻，是以保留合适模型次元有利于模型上線後維護。
10、模型監控
完成模型的部署和線上驗證後，對模型進行各次元的監控，确定是否疊代，形成模型工作閉環。
模型監控需要每日生成報表，郵件發送相關同僚查閱。對于資料量大的金融公司，需要整合大量表，模型監控并不是容易的事。
11.模型疊代
如果監控模型ks，AUC，psi等名額變化太大，需要重新疊代模型
備注：上述模型開發sop隻是為大家提供一個參考模闆，由于各條業務方差異，不能滿足所有場景。希望大家因地制宜，建好最适合自己公司的模型開發sop。
歡迎關注 《 python金融風控評分卡模型和資料分析(加強版)》，學習評分卡,內建樹，神經網絡算法等系統化風控模組化内容。
版權聲明：文章來自公衆号(python風控模型),未經許可，不得抄襲。遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。