可解釋性與決策透明度

大多數企業級 AI 可解釋性，不過是一個 SHAP notebook 加上一個被宣稱為「可解釋」的儀表板。我們的做法是建構能經得起監管審查的生產級解釋管線——因為我們從正確的架構問題出發：這個決策系統需要的是 本質可解釋性，還是事後解釋確實已足夠？

SHAP 儀表板與監管現實之間的解釋落差

大多數企業級 AI 可解釋性看起來都一樣：資料科學團隊訓練一個梯度提升模型，在 Jupyter notebook 中計算 SHAP 值，建立一個 Streamlit 儀表板，然後宣稱系統「可解釋」。這種做法有三個問題。

• 不穩定性。 KernelSHAP 的抽樣變異意味著同一個預測在連續執行時可能產生不同的特徵歸因——而大多數團隊從未測試過解釋的穩定性。
• 錯誤的輸出。 顯示全域特徵重要性的儀表板，並不能滿足 CFPB 對「具體且準確」的不利行動理由代碼的要求，即 ECOA Regulation B （我們關於公平放貸問責危機的研究）。
• 可操縱性。 發表於 2025 年 5 月 的研究證明，簡單的特徵表示變更即可改變 SHAP 判定的特徵重要性，這意味著有心人士可以設計出遮蔽歧視性輸入、卻維持預測不變的解釋。

對於放貸、核保與招聘中的表格式決策系統，本質可解釋性往往毫無成本。可解釋提升機在表格資料上可媲美 XGBoost 的準確度，同時提供完整的玻璃箱透明度：每個特徵的貢獻都可直接讀取，無需近似。沒有 SHAP 不穩定性、沒有忠實度疑慮、沒有對抗式操縱風險。當模型本身即為透明時，你便可跳過整個事後解釋堆疊。

何時需要事後解釋，以及如何讓它保持誠實

並非每個系統都能做到本質可解釋。用於醫學影像的深度學習模型、NLP 分類器與多模態系統都需要事後方法。問題在於該信任哪些方法，以及如何驗證它們。我們的方法結合了：

• 具備收斂保證的 SHAP ——執行足夠的排列以達成穩定的歸因，並在收斂失敗時標記該預測，而非默默提供不可靠的解釋。
• 使用 DiCE-Extended 的反事實生成器，它解決了原始 DiCE 框架中的效能退化問題，能在生產延遲預算內產生可付諸行動的「需要改變什麼」解釋。
• 調和層 ——當 SHAP 與 LIME 對同一預測的特徵重要性意見不一時，這種分歧即表示該輸入區域的解釋不可靠。我們會揭露這種不確定性，而非加以隱藏。

解釋基於 LLM 的決策

對於由 LLM 驅動的決策系統，挑戰更為艱鉅。Anthropic 於 2025 年 5 月的研究發現，思維鏈推理在大多數情況下並不忠實： Claude 3.7 Sonnet 僅提及實際推理提示的比例為 25% ， DeepSeek R1 則僅有 39%。思維鏈文字看起來像是推理，但往往是為了顯得合乎邏輯而建構的敘事。

我們的做法不倚賴模型自行解釋： 基於接地（grounding）的可追溯性 ——將 LLM 輸出與可檢索的來源文件透過可驗證的歸因鏈相繫——以及 結構化決策分解 ，使每個推理步驟都能獨立於模型自我報告的邏輯之外接受稽核。

多受眾解釋架構

一個駁回房貸申請的放貸模型，必須從同一個決策產生三種不同的解釋——不是同一段文字的三個版本，而是從共享歸因層計算得出、在結構上截然不同的三種輸出：

• 資料科學家 在除錯模型行為時，需要特徵歸因分數、決策邊界脈絡，以及與訓練分布的比較。
• 合規官 在為系統建立文件時，需要第 13 條的部署者文件，或含有具體、準確且對應到模型實際加權因素之理由代碼的 ECOA 不利行動紀錄（我們關於企業 AI 問責架構的研究）。
• 被駁回的申請人 需要一段淺白的說明：「您的申請主要因您的債務收入比超過此貸款產品的門檻，且您的在職年資低於最低標準而被拒絕。」

我們將解釋管線設計為推論路徑元件，而非離線分析工具，其範圍是為每次預測以次秒級延遲產生全部三種輸出。

特定監管規範的解釋格式

AI 可解釋性的監管格局正快速分化，而每一套制度所要求的都不相同：

• 歐盟 AI 法案第 13 條 （於下述日期起強制執行 2026 年 8 月 2 日）要求高風險系統提供者向部署者提供關於系統運作、準確度水準、已知限制與人為監督措施的明確指引。罰則可達 3,500 萬歐元或全球營業額的 7%。
• 歐盟法院案件 C-203/22 （2025 年 2 月）確立了「僅傳達一個複雜的數學公式」並不能滿足 GDPR 第 22 條就自動化決策所賦予的解釋權。
• CFPB／ECOA 要求不利行動通知須載明拒絕的「主要理由」，且須針對個別申請人具體說明，而非套用制式範本。
• FDA （2026 年 1 月臨床決策支援指引）要求 AI 驅動的臨床決策支援須讓臨床醫師能「理解並驗證其背後的邏輯與資料輸入」。
• NAIC 示範公告 ——已獲 24 個州採用——要求保險業者將可解釋性納入其 AI 治理。

每一項都造成一種截然不同的工程義務，詳見 我們關於演算法完整性與企業責任的研究。我們的做法是建構合規對應的解釋範本：這些結構化輸出旨在滿足特定的監管要求，由解釋管線自動生成，而非事後手工撰寫。ECOA 不利行動通知的範本，與歐盟 AI 法案部署者文件的範本毫無相似之處，即使兩者描述的是同一個模型。

解釋忠實度測試

一個無法反映模型實際計算內容的解釋，比完全沒有解釋更糟。它製造虛假的信心、誤導稽核人員，並可能構成監管違規。我們將解釋忠實度視為一項可測試的屬性，而非一種假設（見 我們關於超越表面 AI 之信任架構的研究）。我們的驗證框架圍繞以下面向設計：

• 穩定性測試 ——在相同輸入上重複執行 SHAP／LIME，以量化歸因變異。
• 對抗式探測 ——運用 Slack 等人的鷹架技術，以驗證解釋無法被操縱以隱藏受保護類別特徵。
• 完整性檢查 ——確保解釋能解釋模型輸出變異中足夠的比例，而不僅是前三個特徵。
• 合成真值基準 ——我們建構具有已知因果結構的測試情境，並衡量解釋方法是否能正確辨識真正的因果因素。

對於基於概念的方法，例如 TCAV 與 概念瓶頸模型（Concept Bottleneck Models），驗證的挑戰有所不同。2025 年一份綜述指出，標準 CBM 並未施加真正的資訊瓶頸，這意味著模型可能在概念表示中編碼非概念資訊。在推薦基於概念的做法之前，我們會評估概念層是否確實約束了模型的資訊流——而在大多數缺乏精選概念資料集的企業環境中，我們建議不採用它們，改用具備更強忠實度保證的方法。

平台可解釋性的止步之處，以及客製工程的起點

Fiddler、Arthur 與 Truera 提供了有價值的模型監控：漂移偵測、效能追蹤與歸因儀表板。它們能在模型行為改變時予以揭示。它們不做的，是建構解釋管線本身、在本質可解釋性與事後方法之間做出架構抉擇、建構多受眾解釋渲染器、設計符合合規要求的輸出格式，或驗證解釋是否忠實。

Gartner 於 2026 年 3 月預測，XAI 將驅動 到 2028 年 50% 的 LLM 可觀測性投資 （高於目前的 15%），這反映出僅有監控並不足夠。監控層觀察模型；解釋層則向利害關係人說明某個特定決策為何發生。我們專注於第二層，並將其設計為能與客戶既有的任何監控平台整合。