模型可解釋性：
上線前要能說出「為什麼」

模型評審會上，AUC 0.9684 投影在牆上。業務主管問：「它憑什麼說這位客戶會流失？ 我要打電話過去，總得說個理由。」法遵同事問：「有沒有用到不該用的欄位？」—— AUC 一個都答不出來，它是一個總分，總分不會告訴你分數是怎麼來的。 SHAP 給的是明細：把預測跟平均之間的差距，一分不剩地分給每個特徵。挑一位客戶，看它怎麼分——

貢獻值、機率、排名全部來自 notebook 的實測輸出（shap 0.52.0，RandomForest 100 棵樹 depth 8， 測試集 500 位客戶）；特徵的中文名字是為了好讀而貼上去的，資料本身是模擬的 f0–f11。

「為什麼」有兩種問法，別答錯題

可解釋性不是一個問題，是兩個。搞混了，你會拿全域的答案去回答局部的問題——而那正是最常見的錯。

SHAP 用一句白話講完就是：把「這一筆的預測」跟「平均」之間的差距，公平地分給每一個特徵。 「公平」不是形容詞，是有數學定義的（合作賽局理論的 Shapley value）。實務上你只要記住一個檢查：

一分不多、一分不少。這條等式讓 SHAP 跟「感覺型」的解釋徹底分開：它不是「大概是這幾個原因」， 而是把 0.9860 減 0.4882 的那 0.4978 分完。第 3 節會拿真實的一位客戶驗算到小數點後 15 位。

同一個模型，三種答案，而三種都對

三行程式，三個不同的問題。所以答案不一樣是正常的，不是誰算錯了：

前三名 f2 → f3 → f9 三種完全一致——這是好消息：三個問法不同的方法都指向同一組主角， 你可以放心跟業務說「模型主要靠這三件事在判斷」。第 4 名開始就分家了，而每一處分歧都有原因： f4 被模型用得多（內建與 SHAP 都排第 4），但打亂它 AUC 只掉 0.0090——用得多不等於有用。 尾巴那幾欄 permutation 是負的，那不代表「有害」，只代表「打亂它反而剛好好一點點」，也就是雜訊。

①「加起來一定等於 1」是它最大的限制：它只講得出相對佔比，講不出「重要多少」。 而且它偏愛切得動的特徵——連續值與高基數類別可以切出很多刀，每刀貢獻一點，加起來就不低了。 在資料裡加一欄純亂數的客戶編號重訓，三種算法對它的評價是：

一句話記住三者的分工：內建說「建樹時切了幾刀」、permutation 說「有沒有用」、SHAP 說「模型實際上怎麼用」。 看到「客戶編號很重要」這種結果，先別急著寫進報告——換一種算法問一次。

SHAP 值可以驗算——這是它跟「感覺」的分界線

拿測試集第 1 位客戶（編號 #405，預測機率 0.7460）實際走一遍。從基準出發，把 12 個貢獻依序加上去：

這條等式有兩個立即可用的價值。第一，它是你「有沒有把 SHAP 用錯」最快的自我檢查： 算完加總一次，對不上就是哪裡錯了（多半是忘了選類別、或欄序跟訓練時不同——第 11 節的測驗有實例）。 第二，它讓「最不可能流失的客戶」有唯一解：因為預測 ＝ 基準 ＋ 總和，而基準對每一筆都一樣， 所以「SHAP 總和最小」必然等於「預測最小」。

另外兩個一定要知道的細節。形狀：shap_values(Xte) 回的是 (500, 12, 2)——(列數, 特徵數, 類別數)。二元分類的兩面完全對稱， 要「往流失推」那一面就得寫 [:, :, 1]。忘了這一刀是新手最常見的錯，而且它多半不會噴錯。 單位：sklearn 樹模型的 TreeExplainer 預設解釋 predict_proba，所以 SHAP 值的單位是機率；XGBoost／LightGBM 預設是 log-odds， 加總會等於 margin 而不是機率。看到「加起來不等於機率」，先確認單位。

三張圖，各回答一個問題

兩位客戶，兩個世界。高風險的 #1340（0.986）從 0.488 出發， f2 = +1.45 推了 +0.235、f3 再推 +0.103， 一路加到 0.986——他身上幾乎沒有任何一項在往下拉（最大的負貢獻只有 −0.001）， 所以他不是「某一項特別糟」，而是全面偏向流失。 低風險的 #775（0.004）則是十二項全部為負： f2 拉了 −0.215、f9 拉了 −0.097。

注意 f9：它在全域重要度只排第 3，但在這一位身上是第 2 大原因。 全域重要度不能拿來解釋個案——這是可解釋性最常被誤用的地方，也是第 1 節那張表最後一列講的事。

蜂群圖用來看方向：每個點是一位客戶，橫軸是 SHAP 值，顏色是那位客戶的特徵值（紅＝高、藍＝低）。 把方向量化成「特徵值與它的 SHAP 值的相關係數」：

這張圖是上線前審核最好用的一張：拿給業務看，問一句「照你們的經驗，這個方向對嗎？」 ——方向跟常識相反的特徵，十次有九次是資料處理出了問題（符號寫反、欄位對錯位、缺值被填成 0）。

依賴圖則揭露兩件事。形狀：f2 對 SHAP 的曲線是 S 形，兩端都會飽和—— 分箱平均是 −0.311 / −0.133 / +0.054 / +0.176 / +0.247，中段變化最劇烈、兩端趨平。 樹模型學到的是「切點」不是直線，所以線性模型的係數講不出這件事。 交互作用：f2 落在 1.0 附近的那 26 位客戶，f2 幾乎一樣，SHAP 值卻從 0.111 散到 0.256、相差超過兩倍。 所以：SHAP 值不是「f2 的效果」，是「f2 在這位客戶身上的效果」。

解釋要跟模型一起版本化，不然它只是一張漂亮的圖

要變成 MLOps 資產，解釋必須滿足三個條件：跟模型版本綁在一起、之後查得到、跟當時的數字一模一樣。 log_figure 讓圖不用先存檔就進 artifact；log_dict 存的是 可以被程式讀回來比對的數字——第 6 節的監控就靠它。重點在掛到哪一個 run： 解釋是訓練完之後才算的，用 start_run(run_id=...) 續掛回訓練那個 run， 否則半年後你會有一堆孤兒報告，對不回是哪一版模型。

有了報告，模型評審就有東西可以問。三個問題按殺傷力排序：① 有沒有一枝獨秀的特徵？ ② 方向合不合常識？③ 有沒有用到不該用的欄位？第 ① 個值得當場做一次—— 假設有人在特徵表加了一欄 days_since_cancel（距離上次取消服務幾天）， 聽起來很合理，但它是客戶流失之後才算得出來的：

AUC 0.9996——只看指標，這是一個該開香檳的模型；而它上線之後會是一場災難，因為預測的那一刻根本拿不到這一欄。 重要度分佈是抓洩漏最便宜的雷達：看到一欄吃掉大半重要度、而且 AUC 好得不像話， 先問一句「這一欄在預測的那一刻真的存在嗎？」。這不是判決（真的有主導特徵的問題確實存在）， 它是一個要求你解釋的訊號。

重要度什麼時候會變？答案可能跟你想的相反

第 7 課（模型監控）看的是「哪個特徵的分佈變了」，這一課看的是「哪個特徵在決定」。 很容易混為一談，做兩個實驗就分得清楚。

實驗 A：同一個模型 ＋ 漂移的資料。把生產資料的 f0 整體平移 +1.5 （跟第 7 課同一種漂移），丟給同一個模型重算 SHAP：

第一次看到會意外，但很合理：模型是同一個模型、樹是同一批樹，它的「想法」當然沒變，變的是資料。 所以 SHAP 重要度不是資料漂移偵測器——想知道「輸入變了沒」用 PSI／KS， 想知道「模型的想法變了沒」才看重要度排名。混用會讓你在最需要警報的時候什麼都收不到。

實驗 B：重訓之後，才是重要度該警報的時候。假設上游改版， f2 被灌成常數 0（欄位改名、join 失敗、預設值填 0，這種事每季發生一次）。 管線照常跑完、模型照常重訓、照常註冊成新版本，沒有任何一個步驟報錯：

品質閘門若設在 0.85，這個模型會被放過去。而重要度講的是完全不同的故事： 原本一個人扛起 44% 決策權的 f2，貢獻變成 0。警報寫起來只有三行：

把它寫成 Dagster 的 @asset_check（第 3 課）或 pytest（第 13 課），每次重訓都跟上一版比。 這就是第 5 節那份 artifact 的真正用途：它不是給人看的圖，是給下一次重訓當比較基準的資料。 門檻用「前三名有沒有換人」比「數值差多少」穩，因為數值本來就會浮動； 而警報的動作是要求人來看一眼，不是自動擋——重要度變了，也可能只是模型真的變好了。

禁用欄位檢查：寫得出來，也會被繞過去

法遵給你一張清單：「這幾欄是敏感資訊，可以用來統計，不得作為個案決策的依據。」 「沒有放進訓練資料」是最乾淨的做法，但真實專案的特徵表是共用的、是別的團隊維護的、上週還多了三欄—— 所以你需要一個每次上線都跑一次的檢查。注意它回傳的是報告不是 True/False： 出事的時候你需要知道差多少。

f6 沒過。這時候該做的不是把門檻調到 0.02（雖然那樣報告會變綠色）， 而是三步：① 從訓練資料把它拿掉重訓，看代價有多大——實測拿掉 f6 之後 AUC 是 0.9699，比原本的 0.9684 還高一點點（合規常常沒有你以為的那麼貴，做過才知道）； ② 確認沒有代理特徵頂上來；③ 把檢查寫進管線，不是上線前才想起來。

第 ② 步比第 ① 步重要得多。把 f2 當成禁用欄位、照規定移除， 但特徵表裡另外有一欄 region_score（與 f2 的相關係數 0.97）：

模型照樣在用那個資訊，只是換了個名字。這叫代理特徵（proxy），是所有「禁用欄位」制度共同的漏洞， 而且不需要有人故意——只要特徵表裡有任何跟禁用欄位相關的東西就會自然發生。 SHAP 幫得上忙的地方是讓它現形：一個新欄位突然衝上第一名，你至少會問一句「這欄是怎麼算出來的？」。 真正的解法在資料治理那一層（查代理欄位的相關係數、要求特徵有來源說明）， 但這一節至少告訴你：只查名字的合規檢查，是會被繞過去的。

把 waterfall 變成三句話

瀑布圖是給你看的，不是給客戶看的。客服打電話出去需要的是三句話，而這完全可以自動生成 ——SHAP 值本來就是排好序的數字：

這段模板有三個刻意的設計，每一個都是被投訴教出來的：

⚠️ 最後一件事，也是最重要的一件：這三句話講的是模型怎麼算的，不是為什麼會發生。下一節就講這件事。

誠實比方便重要：SHAP 做不到的三件事

① SHAP 不是因果。f2 的 SHAP 是 +0.26，正確的說法是「這個模型因為 f2 的值而把機率調高了 0.26」； 錯誤的說法是「f2 高導致客戶流失」，更錯的是「把 f2 降下來就能留住客戶」。 模型只學到相關；相關可能來自因果，也可能來自共同原因或反向因果—— 「客服接觸次數多」不是流失的原因，是已經想走的症狀。 實務分界線：SHAP 可以拿來排優先順序（先打給誰）與做審核（模型有沒有亂來）， 不能拿來制定干預（改哪個欄位就會怎樣）。

② 相關的特徵會分攤貢獻。把 f2 原封不動複製一欄叫 f2_copy 再訓練：

f2 沒有變得比較不重要，只是有人跟它平分功勞。真實特徵表裡這太常見了 （「近 30 天訂單數」和「近 30 天訂單金額」高度相關），後果是你會低估一整組相關特徵裡每一個成員， 甚至誤以為某個關鍵資訊「模型沒在用」。對策不是換工具，是先看特徵之間的相關係數、把高度相關的欄位當一組看。

③ TreeExplainer 只吃樹模型。餵它一個 LogisticRegression 會直接拒絕（InvalidModelError）。兩條退路，代價差很多：

KernelExplainer 靠反覆遮蔽特徵、重新預測來估計，所以要給它一份背景資料 （被遮掉的特徵用什麼值代替），成本大約正比於背景筆數——用 shap.sample(X, 100) 壓縮，別把整個訓練集丟進去。 實務規則：能用專用 explainer 就用專用的，Kernel 是最後手段（抽樣看全域、個案來申訴時才現算那一筆）。

LinearExplainer 快到不用計時（500 列 0.3 毫秒），而且給了理解 SHAP 最好的入口 ——它的結果不是估計，是封閉解：

線性模型的 SHAP 就是「係數 × 這一筆偏離平均多少」，樹模型只是把同一個概念推廣到非線性。 順帶戳破一個統計課上的簡化：mean|SHAP| 的排名跟「|係數| × 標準差」的排名完全一致， 但跟「只看係數大小」從第 6 名起就不同——一個係數再大，如果那一欄在資料裡幾乎不變動，它對實際預測就沒有影響力。

換你動手

卡住了？每一題在 notebook 末節都有折疊解答——先自己做，再打開對照。

情境測驗

離開前試試看：下面的情境都真的會遇到。每題選一個你認為的最佳做法，選了馬上看得到解釋。