微調 LLM 的模型風險管理：SR 11-7 合規指南

來自 OCC 和美聯儲的 SR 11-7 管理每家美國銀行的模型風險管理。2011 年為信用評分模型和 VaR 計算而寫，現在也適用於微調 LLM。如果你的銀行使用 AI 模型做出或影響任何業務決策，SR 11-7 就適用。對「它只是 AI」沒有例外。

好消息是：SR 11-7 是基於原則的，而不是規定性的。它告訴你記錄和驗證什麼，而不是如何做。本指南將每個 SR 11-7 要求映射到你的微調 LLM 需要的具體工件和流程。

SR 11-7 要求什麼

SR 11-7 將模型風險定義為「基於不正確或誤用的模型輸出做出決策所帶來的潛在不良後果」。它要求三個支柱：

模型開發和實施 — 有記錄，方法論合理
模型驗證 — 獨立、持續，具有明確的發現
模型治理 — 董事會監督、模型清單、使用控制

對於傳統定量模型，這些要求是眾所周知的。對於微調 LLM，它們需要重新解釋。以下是映射。

將 SR 11-7 映射到微調 LLM

支柱一：開發文件

SR 11-7 要求記錄「模型的目的、設計和方法論，包括數學規範和假設」。

對於微調 LLM，這意味著：

SR 11-7 要求	LLM 等效	需要記錄的內容
模型目的	用例定義	特定業務任務、輸入/輸出格式、決策影響
數學規範	架構 + 訓練配置	基礎模型（例如 Llama 3.1 8B）、量化級別、LoRA 秩、alpha、dropout
資料	訓練資料來源	源系統、日期範圍、數量、預處理步驟、PII 處理
假設	效能邊界	模型能做和不能做什麼，已知的故障模式
限制	範圍限制	Token 限制、語言支援、領域邊界、置信度閾值
實施	部署架構	基礎設施、服務堆疊、API 合約、整合點

關鍵細節： 記錄基礎模型選擇的理由。為什麼是 Llama 3.1 8B 而不是 Mistral 7B？為什麼是 Q4 量化而不是 Q8？審計員會問。「這是默認值」不是可接受的答案。在你的特定任務上使用你的特定資料的基準測試結果才是可接受的答案。

訓練資料來源

對於每個微調資料集，記錄：

源系統： 哪些內部資料庫、文件庫或應用程式生成了訓練範例
日期範圍： 源資料創建的時間（不是你提取的時間）
數量： 訓練範例數量、平均長度、總 token 數
預處理： 應用的每個轉換——去重複、PII 遮蔽、格式轉換、品質過濾
標記： 誰創建了基準事實標籤，他們遵循了什麼指令，如果適用的話標記者間一致性
代表性： 跨類別、部門、時間段的分佈。記錄任何已知的缺口或偏差

LoRA 配置文件

參數	值（範例）	理由
基礎模型	Llama 3.1 8B Instruct	在內部基準上最佳準確率/延遲權衡（見附錄 B）
量化	Q4_K_M	與 FP16 相比在評估集上準確率損失低於 1%；記憶體降低 4 倍
LoRA 秩	16	通過掃描（秩 8/16/32）驗證；秩 16 在評估指標上最優
LoRA alpha	32	標準 2x 秩比；在掃描中驗證
LoRA dropout	0.05	相比 0.0 減少了驗證集上的過度擬合
目標模塊	q_proj, v_proj, k_proj, o_proj	完整的注意力目標；MLP 目標未顯示改善
訓練輪次	3	在驗證損失上提前停止；第 3 輪最優
學習率	2e-4	掃描 1e-4 至 5e-4；2e-4 最小化驗證損失
批次大小	8	GPU 記憶體的最大值，帶梯度累積
訓練範例	2,847	過濾後的完整合格資料集

這個詳細程度是審計員所期望的。每個超參數都應該有由實驗結果支持的記錄理由。

支柱二：驗證框架

SR 11-7 要求通過獨立驗證進行「有效挑戰」。對於微調 LLM，驗證意味著結構化的 5 步過程。

第一步：基準評估

在從未在訓練或超參數選擇中使用過的保留測試集上運行微調模型。

指標	目標	實際	狀態
任務準確率	超過 92%	94.1%	通過
精確率（正類）	超過 90%	91.7%	通過
召回率（正類）	超過 88%	89.3%	通過
F1 分數	超過 89%	90.5%	通過
幻覺率	低於 3%	1.8%	通過
拒絕率（範圍內查詢）	低於 2%	0.9%	通過

第二步：回測

將模型應用於已知正確結果的歷史案例。比較模型輸出與實際決策。

選擇橫跨至少 12 個月的 200-500 個歷史案例
在無任何人工審閱的情況下執行推理
與實際結果或專家審閱的基準事實比較
記錄一致率、不一致模式和故障模式

第三步：對抗測試

故意嘗試破壞模型：

提示注入： 嘗試通過精心設計的輸入覆蓋指令
邊界測試： 在模型記錄範圍邊緣的輸入
亂碼/噪音： 驗證模型拒絕或標記無意義的輸入
跨域洩漏： 驗證模型不回答其領域之外的問題
PII 提取： 嘗試從模型中提取訓練資料

記錄每個測試案例、預期行為、實際行為和通過/失敗狀態。

第四步：偏差審計

對於任何影響客戶或員工決策的模型：

在人口統計細分上測試（年齡、性別、地理位置、帳戶類型）
測量細分之間的準確率差異
記錄任何統計顯著差異和緩解計劃
參考銀行現有的公平借貸/公平對待框架

第五步：獨立審查

驗證必須由未參與模型開發的人執行。在大多數銀行，這是模型風險管理（MRM）團隊或合格的第三方。

獨立審查員應收到：

來自支柱一的所有文件
用於測試的模型存取
基準測試、回測、對抗測試和偏差審計結果
在發現需要時阻止部署的授權

模型卡模板

以下是商業銀行文件分析模型的填寫範例。

模型卡：商業貸款文件分析器 v2.1
===================================================

目的：         從商業貸款文件中提取關鍵條款
               （契約、利率、到期日、抵押品描述）

基礎模型：     Llama 3.1 8B Instruct (Q4_K_M)
適配器：       LoRA 秩 16，在 2,847 份內部文件上訓練
訓練日期：     2026-01-15
部署：         2026-02-01

輸入：         PDF 文字（提取的），最多 4,096 個 token
輸出：         帶有提取字段 + 置信度分數的結構化 JSON

效能：
  - 字段提取準確率：94.1%（測試集，n=412）
  - 幻覺率：1.8%（未在源中的偽造條款）
  - 延遲：1.2 秒中位數（T4 GPU）

限制：
  - 不處理掃描/基於圖像的 PDF（上游需要 OCR）
  - 超過 3,500 個 token 的文件準確率低於 85%
  - 未針對非英語文件進行驗證
  - 不是法律審查的替代品——輸出需要人工驗證

偏差評估：貸款類型（定期、循環、建設）或地區之間沒有
           統計顯著的準確率差異

擁有者：       商業銀行技術部門
驗證者：       模型風險管理（MRM-2026-0142）
下次審查：     2026-08-01（6 個月週期）

10 個常見審計員問題（及答案）

來自 OCC、美聯儲或內部審計的審計員會提出尖銳的問題。以下是 10 個最常見的問題及如何回答。

1. 「你怎麼知道這個模型是準確的？」 指向使用保留測試集結果的基準評估。顯示精確率、召回率和 F1 指標。顯示針對歷史案例的回測結果。

2. 「誰驗證了這個模型？」 命名獨立驗證者（MRM 團隊或外部方）。顯示帶有發現和簽核的驗證報告。

3. 「當模型出錯時會發生什麼？」 描述人機協作工作流程。每個模型輸出在任何業務決策之前都由合格的人工進行審閱。顯示錯誤升級過程。

4. 「你如何監控持續的效能？」 顯示監控儀表板：每週追蹤的準確率指標、漂移偵測警報、流量和延遲趨勢。顯示觸發重新驗證的閾值。

5. 「你能重現 6 個月前的特定輸出嗎？」 可以。顯示帶有模型版本、適配器版本、輸入哈希和輸出哈希的稽核日誌。演示用相同的模型版本和相同的輸入產生相同的輸出（使用 temperature=0 的確定性推理）。

6. 「使用了什麼訓練資料？」 提供資料來源文件。源系統、日期範圍、數量、預處理步驟、標記方法論。

7. 「你如何防止模型不當使用客戶資料？」 描述訓練資料中的 PII 處理（遮蔽或合成替換）。顯示模型在無外部資料傳輸的情況下在本地端運行。顯示存取控制和 API 金鑰管理。

8. 「你的變更管理流程是什麼？」 演練工作流程：提議變更、重新訓練、在基準上驗證、獨立審查、分階段推出、監控。顯示審批鏈。

9. 「這個模型在你的模型清單中嗎？」 是的。顯示帶有以下內容的模型清單條目：模型名稱、版本、擁有者、用例、風險層級、驗證日期、下次審查日期。每個微調模型和每個適配器版本都是單獨的清單條目。

10. 「如果模型擁有者離職，你的繼任計劃是什麼？」 文件是繼任計劃。所有開發工件、驗證結果和運營程序都存儲在模型登錄中。任何合格的工程師都可以使用現有文件操作模型。

文件清單

對於每個微調模型，維護以下工件：

開發工件

用例規範（業務問題、成功標準、利益相關者）
帶基準比較的基礎模型選擇理由
訓練資料來源文件
帶掃描結果的超參數配置
訓練日誌（損失曲線、每輪次的驗證指標）
最終模型卡

驗證工件

基準評估報告（測試集指標）
回測報告（歷史案例比較）
對抗測試報告（攻擊情境和結果）
偏差審計報告（人口統計細分分析）
帶簽核的獨立驗證報告
發現和修復追蹤

運營工件

部署架構圖
API 規範和整合文件
監控儀表板配置
警報閾值和升級程序
變更管理工作流程
事件回應手冊
稽核日誌保留政策

治理工件

模型清單條目
風險層級分類
董事會/委員會批准（針對第 1 層模型）
審查時間表（通常為 6 個月或年度）
使用政策（誰可以使用模型、用於什麼、使用什麼保障措施）

為什麼本地端部署簡化 SR 11-7 合規

當模型在你自己的基礎設施上運行時，每個 SR 11-7 要求都變得更容易。

合規維度	本地端	雲端 API
資料來源	完全控制——訓練資料永遠不離開你的系統	必須記錄到第三方提供商的資料流
可重現性	固定模型版本、適配器版本和推理參數	提供商可能在未通知的情況下更新模型
稽核日誌	在你的 SIEM 中的完整日誌	依賴提供商的日誌和保留
存取控制	與現有 IAM 整合	單獨的 API 金鑰管理，可見性較低
變更管理	你控制每次更新	提供商按自己的時間表控制模型更新
模型清單	你擁有模型工件	你有一個你不控制的模型的 API 金鑰
獨立驗證	隨時根據你的測試集進行驗證	無法對託管模型運行自訂驗證套件
事件回應	完整的取證能力	僅限於提供商的事件報告

根本問題：使用雲端 API，你在記錄別人的模型。使用本地端微調模型，你在記錄你自己的。後者正是 SR 11-7 的設計目的。

在本地端部署微調模型的銀行一致報告，與那些依賴雲端 API 並在頂部疊加供應商風險評估的銀行相比，驗證週期更快、審計發現更清晰、合規開銷更低。