第七章 模型治理與可解釋性

# 第七章 模型治理與可解釋性 在金融風險管理領域，**模型治理** 不僅是確保算法正確運行的技術措施，更是符合 Basel、MiFID、IFRS 9 等國際規範的法規遵循基石。從資料蒐集到模型投產，整個過程必須在可追溯、可監控、可審計的環境下進行，才能在面對市場變化與監管審查時保持彈性與透明度。 ## 7.1 模型治理框架 | 主要流程 | 內容說明 | 相關工具/技術 | 監管關聯 | |---|---|---|---| | **1. 需求與範圍定義** | 明確模型目的、預期指標、風險類別 | 需求文檔、RACI 表 | Basel III 模型風險治理指引 | | **2. 資料治理** | 資料品質、來源可追溯、靜態/動態校驗 | DVC、Great Expectations | IFRS 9 資料質量要求 | | **3. 模型開發** | 特徵工程、算法選擇、版本控制 | Git、MLflow | MiFID II 透明度 | | **4. 內部驗證** | 效能評估、穩健性、偏差測試 | scikit‑learn、PyTest | Basel III 模型驗證 | | **5. 投產與部署** | 監控、容器化、回滾策略 | Docker、Kubernetes、ArgoCD | MiFID II 監控 | | **6. 持續監測** | 漂移檢測、再訓練觸發、風險指標 | Evidently、Seldon Core | Basel III 持續監控 | | **7. 模型審計** | 可追溯性、重現性、審計報告 | Databricks Runtime、Airflow | IFRS 9 審計 | | **8. 模型退役** | 退役流程、知識轉移 | Knowledge Graph | Basel III 風險管理 | > **筆者建議**：在設計治理流程時，將 **「模型治理」視為一個完整的產品生命週期，確保每一步都有相應的 SOP、指標與審計痕跡。 ## 7.2 可解釋性工具：SHAP、LIME 與自定義解釋 ### 7.2.1 SHAP（SHapley Additive exPlanations） SHAP 借鑒遊戲理論中的 Shapley value，能將模型輸出拆解為各特徵對預測的貢獻。對於金融模型而言，特徵重要性往往直接關係到風險評估與合規審查。 #### 例子：使用 SHAP 解釋 XGBoost 信用風險模型 python import xgboost as xgb import shap import pandas as pd # 讀取已訓練模型 model = xgb.Booster() model.load_model('credit_xgb.model') # 讀取測試資料 X_test = pd.read_csv('credit_test.csv') # 建立 SHAP KernelExplainer（或 TreeExplainer） explainer = shap.TreeExplainer(model) shap_values = explainer.shap_values(X_test) # 可視化 shap.summary_plot(shap_values, X_test) > **要點**：對於大規模資料，使用 `TreeExplainer` 可大幅降低計算時間；若模型為非樹狀結構，則需採用 `KernelExplainer` 或 `LinearExplainer`。 ### 7.2.2 LIME（Local Interpretable Model‑agnostic Explanations） LIME 透過局部線性近似，快速解釋單筆預測。適合需要快速、直觀解釋的情境，例如內部風控報告。 python from lime.lime_tabular import LimeTabularExplainer explainer = LimeTabularExplainer( training_data = X_train.values, feature_names = X_train.columns, class_names = ['non_default', 'default'], mode='classification' ) exp = explainer.explain_instance(X_test.iloc[0].values, model.predict) exp.show_in_notebook(show_table=True) > **差異**：SHAP 兼具全局與局部解釋，且在數學上保證一致性；LIME 更輕量、易於自訂。 ### 7.2.3 自定義解釋規則 金融機構往往需要將模型輸出轉化為業務可操作的指標，例如「逾期風險閾值 0.7 → 建議加碼風險敞口」或「特定特徵（如失業率）> X% → 觸發手動審核」。可利用 **業務規則引擎**（Drools、EasyRules）將解釋結果映射至業務決策。 ## 7.3 模型監測與漂移檢測 | 監測指標 | 觸發條件 | 措施 | 典型工具 | |---|---|---|---| | **輸入漂移** | 分佈距離 > 0.1 | 重新收集樣本，更新特徵工程 | Evidently、River | | **概念漂移** | 模型預測分佈變化 | 進行回測、重訓 | Evidently、Seldon Core | | **效能衰退** | MAE / RMSE > 10% | 進行模型再評估、再訓練 | MLflow, Airflow | | **合規風險** | 重要特徵變化 | 觸發合規審核 | Custom Dashboards | > **實務提醒**：在投產前，必須將監測指標納入 SLA，並設計自動化警報（Slack、PagerDuty）以確保及時回應。 ## 7.4 模型審計與透明度 1. **可追溯性**：每一次模型更新都應記錄版本、參數、資料來源與驗證結果。可透過 **Git + DVC** 完成。 2. **重現性**：利用 Docker 或 Conda 環境固定依賴，並存檔模型壓縮包（如 `pickle`、`pmml`）。 3. **審計報告**：包含模型假設、驗證結果、風險評估、可解釋性摘要。可使用 **ReportLab** 或 **WeasyPrint** 產生 PDF。 4. **外部審計**：定期邀請第三方評估模型性能與治理流程，符合 Basel III 第11章。 ### 7.4.1 審計流程示例 markdown 1. **模型提交**：開發人員提交 PR，包含程式碼、測試、模型文件。 2. **CI Pipeline**：自動執行單元測試、性能測試、SHAP/LIME 報告。 3. **審計人員評審**：審查模型設計、數據治理、解釋性報告。 4. **審批或退回**：若合格，合併至主分支；若不合格，退回並提供改進建議。 5. **部署**：透過 ArgoCD 或 Jenkins 將模型推送至生產環境。 6. **持續監測**：利用 Evidently Dashboard 監控輸入/輸出漂移。 7. **季度審計**：生成年度模型表，報告給合規團隊。 ## 7.5 合規要求對模型治理的影響 | 監管機構 | 主要要求 | 具體落實 | |---|---|---| | **Basel III** | 模型風險管理、內部模型驗證 | 建立內部模型審核委員會、制定驗證報告 | | **MiFID II** | 透明度、投資者保護 | 提供模型解釋、風險披露 | | **IFRS 9** | 資產評價、損失計提 | 使用可解釋模型支持損失估算 | | **SFTR** | 交易報告 | 需要能追溯模型對交易決策的影響 | > **關鍵點**：合規不僅關注模型準確度，更重視**可解釋性**與**可審計性**。金融機構應在模型生命周期早期納入合規需求，避免後期改造成本。 ## 7.6 實作範例：全流程模型治理演練 > **場景**：一家投信基金公司使用 XGBoost 進行負債抵押債券（CDS）風險評估。 1. **需求定義**： - 目標：預測未來 12 個月內違約概率。 - KPI：AUC > 0.78，Brier Score < 0.12。 2. **資料治理**： - 數據來源：Bloomberg、FactSet。 - 使用 Great Expectations 定義 Schema、Completeness、Null Count。 3. **開發環境**： - Git + DVC 追蹤 `credit_data.csv`, `model.pkl`。 - 使用 `docker-compose` 搭建開發環境。 4. **模型訓練**： - 參數搜尋：Optuna，目標 `val_auc`。 - 版本號：`v1.0.3`。 5. **內部驗證**： - 交叉驗證、Bootstrap、Bootstrap‑Brier。 - 生成 SHAP 重要性報告並輸出 PDF。 6. **審計報告**： - 生成 `audit_report_v1.0.3.pdf`，包含模型結構、驗證結果、可解釋性摘要。 7. **部署**： - 打包至 Docker，推送至 ECR。 - 透過 ArgoCD 將服務部署至 Kubernetes cluster。 8. **持續監測**： - Evidently Dashboard：每日輸入/輸出漂移報告。 - 若 `SHAP_avg | feature: unemployment_rate` 變化 > 0.2 → 觸發審計。 9. **再訓練**： - 每季回測 3 年歷史資料，若 AUC 下降 > 5% → Auto‑ML pipeline 重新訓練。 10. **退役流程**： - 模型 `v1.0.3` 退役後，生成退役報告並上傳至 SharePoint。 > **結語**：本範例將 **資料治理 → 模型開發 → 內部驗證 → 部署 → 監測 → 再訓練 → 退役** 的完整流程體現於一個可追溯、可審計的工作流，符合 Basel III、MiFID II 等監管標準。 ## 7.7 小結 - **治理流程** 是模型風險管理的核心，涵蓋從需求到退役的每一步。 - **可解釋性工具**（SHAP、LIME）提供數學保證與業務可操作性，為合規披露與內部決策加分。 - **監測機制** 需在投產前就設計好，確保模型漂移或效能衰退能即時被偵測與處理。 - **審計報告** 需要具備可重現性、可追溯性，並以符合 Basel III、MiFID II 的格式呈現。 - **自動化**（CI/CD、MLflow、Evidently）是實現高效治理與快速迭代的關鍵。 > **筆者寄語**：在金融數據科學的實務道路上，治理與可解釋性不只是技術選型，而是 **企業合規、風險可視化、決策透明度** 的三大支柱。只有將這三者同時落地，才能真正讓模型為金融機構帶來可持續的價值。