模型開發好後，能不能在真實生産環境中使用，是需要通過模型評審會議來決定的。
模型評審會議一般由業務方（政策方）和模型團隊組織，通過模型評審文檔内容的講解，來确定後續的工作事項（調整/review/上線）。
是以模型開發文檔的整理顯得尤為重要，它是對整個模組化過程及結果的描述，主要包含：
①背景說明、
②樣本描述、
③模組化方案簡介、
④模型效果分析、
⑤特征描述這5個部分内容。
編輯切換為居中
添加圖檔注釋，不超過 140 字（可選）
在開發文檔完成後，最重要的工作也有三步，分别是：
①模型部署
②模型驗證
③模型監控指
一.模型部署
模型部署流程
模型同學的真實工作中絕非隻是按流程開發一個模型而已，我們需要和上下遊的同學溝通對接。首先需要明确各協同部門同學的職責，這裡簡單說明，各個公司具體情況不一樣，但大多大同小異。
模型同學：根據業務需求，基于離線資料建構風控模型，并負責模型部署、監控等。
政策同學：根據離線預測的模型分數，制訂相應的風控政策方案，配置政策包等。
開發同學：支援底層資料源接入、問題排查、上線部署、平台搭建等工作。
通常情況下，風控模型一旦正式上線運作後，将會保持運作至少半年以上。這就要求我們把模型的穩定性、可控性放在第一位。
模型在通過模型評審和政策評估後，模型人員一般需要聯合開發同學牽頭進行模型的部署。
其主要流程包括：配置模型檔案、确定離線任務還是實時任務、部署驗證（包括曆史分區的回刷和每日的例行生産驗證）、最後由政策同學根據政策正式調用。
編輯切換為居中
添加圖檔注釋，不超過 140 字（可選）
一般python開發的模型，會轉成PKL檔案或PMML檔案供下遊使用。
需要以下幾點：
①原始特征在入模前的資料預處理（如缺失值填充）
②入模變量的順序需要固定（入模順序不一緻，可能會造成預測結果誤差）
③本地自行加載模型檔案打分驗證
編輯切換為居中
添加圖檔注釋，不超過 140 字（可選）
二. 模型驗證
在模型正式調用階段，需要經過兩個層面的驗證。
（1）回溯打分驗證：是指模型檔案部署好後，回溯曆史樣本進行本地和伺服器模型打分對比。
因為模型檔案在本地跑，還是給開發同學在伺服器上跑，其變量調用以及模型運作 環境都不一樣，是以這一步回溯驗證是為了部署的模型是否與本地模型打分邏輯一緻。
（2）線上線下打分驗證：是指部署好的模型線上空跑一批後，對應的樣本在本地進行打分，與線上的樣本進行一緻性驗證；并且這部分樣本與前期線下的樣本進行變量分布的穩定性檢驗。
因為線上跑分其資料并不是回溯而來，而是通過各種接口進行調用，由于資料的傳輸性能等等，排除可能對模型打分造成的誤差，并且同時可以監測新樣本與模組化樣本的分布差異。
三. 模型監控
風控模型上線部署後，将運作較長一段時間才會更新換代。此時監控就是非常需要完成的工作。
3.1.穩定性是模型需要考慮的重要因素。
模型之是以出現不穩定，主要因為以下兩個方面造成的：
①樣本（客群）的變化：而導緻客群發生變化的原有主要有：政策市場變化、經濟環境變化等各種内外部因素。一旦客群發生明顯變化，那麼原理的分數或者根據分數而指定的政策，将不再有效。（比如根據評分制定的攔截分數線，客群下沉後，通過率将大幅降低）
②評分系統出問題：資料源擷取、系統bug等均會造成模型打分出現誤差。（某個資料源出現誤差，或者停止更新，會造成入模的某個變量出現問題進而造成打分失效）
為了能在第一時間發現上述問題，我們需要對模型進行動态監控。監控是構成閉環控制非常重要的一環，相當于控制系統的眼睛。
3.2.模型監控的名額
模型監控的内容主要包含穩定性監控和效果監控兩個方面
①穩定性監控：
1. 評分分布：模型分數在各分段的分布（PSI+明細）
2. 特征分布：入模特征在各分段的分布（PSI+明細）
編輯切換為居中
添加圖檔注釋，不超過 140 字（可選）
②模型效果監控：
1.模型排序性評估：PR-表格。
2.模型區分度評估：包括KS、AUC、Gini等名額。
3. 模型監控
編輯切換為居中
添加圖檔注釋，不超過 140 字（可選）
【模型評分分布】統計周期可以按日/周/月 拆分成在各個周期内要統計的内容，以報表的形式
【模型效果】統計周期可以按周/月 一般統計ks和auc，逐周或者逐月以報表的形式展示
編輯切換為居中
添加圖檔注釋，不超過 140 字（可選）
以上關于風控模型相關的内容，可關注：
編輯切換為居中
添加圖檔注釋，不超過 140 字（可選）
...
~原創文章