金融機構 LLM 與小型模型選擇：評估框架

金融機構評估生成式 AI 時，最容易問錯的問題是：「大型語言模型（LLM）和小型語言模型（SLM）哪個比較好？」真正應先釐清的，是任務的影響程度、資料邊界、可接受的錯誤型態，以及出了問題時誰能介入。

本文把「小型模型」當作較小、較聚焦或針對有限任務部署的語言模型統稱；各供應商的名稱、參數規模與能力並沒有單一標準。因此，模型大小可以是成本、延遲與部署方式的參考，卻不該單獨決定採用與否。

先看任務，再談模型大小

金融服務的 AI 使用情境差異很大：有些是協助同仁搜尋內部規範、整理長文件或起草客服回覆；有些則會影響信用審核、交易監控、客戶權益或法遵判斷。後者的錯誤代價高，不能只因模型回答流暢就直接自動執行。

美國聯準會 2026 年更新的模型風險管理指引，強調應依機構的模型風險樣貌、規模、複雜度與模型用途採取風險導向的管理方式。這也提供一個實用原則：先界定用途與風險，再選擇技術與控制，而不是讓模型能力反過來決定業務流程。聯準會 SR 26-2 指引

何時較適合用 LLM？

LLM 通常較適合需要理解較多上下文、跨文件整理或自然語言互動的工作。例如：把多份制度文件整理成重點、協助內部人員尋找流程依據、草擬非最終版的客戶溝通內容，或將未結構化文字先轉成待人工確認的摘要。

不過，這些優勢不是「可以不驗證」的理由。若系統會引用內部政策、產品條款或法規資料，應優先讓回答可追溯到核准來源，並限制模型在資料不足時的表述。對於高影響情境，LLM 的產出更適合作為輔助材料，而非唯一的核准、拒絕或定價依據。

何時較適合用小型或任務專用模型？

若任務範圍穩定、輸入輸出明確，較小或專用模型往往更容易測試與控管。例如：

把文件路由到正確的作業隊列；
從固定格式或有限類型的文件擷取欄位；
辨識已定義的客服意圖，交由既有流程處理；
在受限網路或對回應時間敏感的環境中，提供有限範圍的文字協助。

這不代表小型模型天生比較安全，也不表示 LLM 一定不適合受控環境。重點在於：任務是否能清楚定義、測試資料是否具有代表性、錯誤是否能被偵測，以及部署後是否能持續監控。若需求其實包含多輪推理、跨來源理解與例外處理，硬把它壓進一個窄模型，也可能累積新的營運風險。

高影響決策要設清楚的「不能自動化」邊界

涉及授信、保險核保、反詐、交易監控或客戶權益的流程，應先將模型角色切分為「協助蒐集」、「提出風險訊號」、「建議下一步」或「自動執行」。角色越接近最終決策，所需的驗證、可解釋性、覆核與留存證據就越高。

可行的做法不是一開始就追求全自動，而是把 AI 放在能被檢查的節點：模型提出摘要或候選原因、規則與人工覆核負責關鍵判斷、系統保留輸入來源與版本紀錄。BIS 的 Project Noor 也把透明度、公平性與穩健性列為金融監理中檢視 AI 模型的重要面向；這提醒我們，能回答問題不等於已具備可稽核性。BIS Project Noor

一套可落地的評估順序

1. 寫清楚任務與失敗成本

把「導入聊天機器人」改寫成可測試的任務描述，例如「協助客服人員從已核准的產品條款中找到段落並產生草稿」。同時列出不能接受的結果：洩漏個資、捏造條款、跳過人工覆核，或讓客戶誤以為已獲核准。

2. 決定資料能否離開既有邊界

先分類輸入資料與模型輸出，再決定是否能使用外部服務、是否須私有部署、哪些欄位需要遮罩，以及資料會保留多久。若供應商、雲端、模型或檢索資料庫有第三方依賴，也應把責任分界、存取權限與終止／轉移方案寫進採購與風險流程。

3. 用代表性案例比較，而非只看展示結果

建立含正常、邊界與對抗情境的測試集，讓候選模型在相同條件下比較。除了正確性，也應量測是否引述正確來源、是否在不知道時停止作答、是否暴露不應出現的資料，以及人工覆核能否有效攔截錯誤。NIST 的生成式 AI 風險管理資源指出，風險管理應貫穿設計、使用、測試與評估，而不是只在上線前做一次檢查。NIST AI RMF 與生成式 AI Profile

4. 把部署與營運控制一起評估

成本、延遲、吞吐量與多語能力都重要，但還要同時確認模型版本能否固定、變更如何審核、異常時是否能停用或退回既有流程、日誌是否足以追查。若採用模型路由，也要測試路由規則本身：什麼任務可由小模型處理、何時升級到 LLM、何時必須交給人員。

5. 上線後持續監測

模型表現與資料分布會改變，供應商模型也可能更新。應為每個使用案例指定業務負責人、技術負責人與風險／法遵檢視窗口，定期檢查錯誤樣態、人工覆核結果、資料品質與供應商依賴。BIS 對金融穩定的整理也特別點出第三方集中、資料治理、模型驗證與網路風險，這些都不是只靠選對模型就能消失的問題。BIS／FSB：AI 的金融穩定意涵