評估、解釋與部署判斷

40 分鐘

Classification 與 Threshold

學習目標：理解機率分數、threshold、confusion matrix、precision、recall、specificity。

分類模型輸出的不是「是」或「否」，而是一個 0 到 1 之間的機率分數。要把它變成一個可以行動的決策，還需要選一個 threshold：分數高於這個門檻就判定為「將超過容量門檻」。改變 threshold 不會改變模型本身，卻會大幅改變 precision 與 recall 之間的取捨。

from sklearn.metrics import precision_score, recall_score

proba = model_clf.predict_proba(valid[feature_cols])[:, 1]
for threshold in [0.3, 0.5, 0.7]:
    pred = (proba >= threshold).astype(int)
    precision = precision_score(valid["target_binary"], pred)
    recall = recall_score(valid["target_binary"], pred)
    print(threshold, round(precision, 3), round(recall, 3))

選擇 threshold 之前，先把兩種錯誤的實際成本寫下來：漏抓一個真的會超過容量的據點，可能代表服務品質下降或緊急調度成本；誤報一個其實還好的據點，則是浪費了提前調度的資源。把這兩個成本量化後，threshold 的選擇就從「感覺」變成可以被檢視的決策。

• 選 threshold 時只看哪個數字「看起來順」，沒有對照實際的業務成本
• 用同一個 threshold 套用到所有據點，卻沒有檢查不同據點的成本結構是否一樣
• 只報告 accuracy，沒有同時報告在選定 threshold 下的 precision 與 recall
• threshold 選定後沒有重新檢查在各 group_attribute 子群上是否公平

重點: 能完成步驟不代表結果可信；本節的能力必須能被驗證、重做並清楚說明。

40 分鐘

Overfitting、Cross-Validation 與 Tuning

學習目標：在 training data 使用 CV，test 保持未接觸，限制過度調參。

同事把模型複雜度不斷調高，訓練集上的表現越來越好，但驗證集上的表現卻開始變差。這是 overfitting 的典型跡象：模型記住了訓練資料的雜訊，而不是學到能推廣到新資料的模式。Cross-validation（CV）能讓你在只使用訓練資料的情況下，更穩健地評估不同參數設定的表現。

from sklearn.model_selection import TimeSeriesSplit, cross_val_score

tscv = TimeSeriesSplit(n_splits=5)
for depth in [2, 4, 8]:
    scores = cross_val_score(make_model(max_depth=depth), train[feature_cols], train["target_numeric"], cv=tscv, scoring="neg_mean_absolute_error")
    print(depth, round(-scores.mean(), 2))
# test set 在整個調參過程中完全沒有被用到

除了調整模型複雜度，常見的因應 overfitting 的方式還包括：增加正則化（regularization）、減少 feature 數量、或是增加訓練資料。Cross-validation 的價值在於它用多組切分方式估計出一個更穩健的表現範圍，而不是只依賴單一一次切分可能出現的運氣成分。

• 只看平均 CV 分數，沒有檢查每一折之間的變異是否過大
• 用非時間感知的 KFold 切分有時間順序的資料，造成切分內仍有 leakage
• 調參次數沒有限制，持續嘗試到驗證分數「剛好」變好為止
• test set 在整個調參過程中被意外用到（例如寫程式時筆誤引用了 test 變數）

重點: 能完成步驟不代表結果可信；本節的能力必須能被驗證、重做並清楚說明。

35 分鐘

Feature Importance、Interpretation 與 Fairness

學習目標：將 importance 視為預測貢獻而非因果，檢查子群錯誤。

模型的 feature importance 顯示 features_staffing_level 是最重要的預測因子，同事立刻下結論：「所以增加人力配置就能降低案件量。」Feature importance 只描述一個變數對模型預測結果的貢獻程度，並不能證明改變這個變數就會改變真實世界的結果: 這和 Module 2 的相關與因果限制是同一個陷阱。

importances = pd.Series(model.feature_importances_, index=feature_cols).sort_values(ascending=False)
print(importances.head())

# 依 group_attribute 檢查各子群的 MAE 是否一致
valid_pred = model.predict(valid[feature_cols])
valid.assign(abs_error=(valid["target_numeric"] - valid_pred).abs()).groupby("group_attribute")["abs_error"].mean()

Feature importance 的計算方式本身也會影響結論：以樹模型內建的 importance、permutation importance 或 SHAP 值計算出來的排序，有時會不一致。報告 importance 時，最好說明用的是哪一種計算方式，並且把它當作「模型目前依賴這個變數的程度」，而不是「這個變數在真實世界有多重要」。

• 把高 importance 的 feature 直接當作因果結論的證據，對外宣稱「改變它就能改變結果」
• 只看整體 importance 排序，沒有檢查這個排序在不同子群上是否一致
• 只用一種 importance 計算方式，沒有交叉確認結果是否穩定
• 檢查子群誤差時，樣本量太小就直接下結論，沒有註明不確定性

重點: 能完成步驟不代表結果可信；本節的能力必須能被驗證、重做並清楚說明。

40 分鐘

Error Analysis、Drift 與 Deployment Decision

學習目標：檢查錯誤分布、成本、drift、監測與人工 fallback。

模型上線三個月後，表現逐漸變差，但沒有人注意到，因為當初只看了一次離線分數就直接部署，之後再也沒有監測。這是「test 表現好就直接自動部署」最常見的後果：真實世界的資料分布會隨時間改變（drift），一個當初表現良好的模型，並不保證能一直維持這個表現。

監測計畫至少要回答三個問題：用什麼指標偵測表現衰退（例如持續追蹤的 MAE 或誤報率）、多久檢查一次（每日、每週），以及誰負責在指標異常時介入。沒有寫清楚這三件事的「監測」，往往只是形式上存在，實際上沒有人會真的去看。

valid_pred = model.predict(valid[feature_cols])
errors = (valid["target_numeric"] - valid_pred).abs()
high_demand = valid["target_numeric"] > valid["target_numeric"].quantile(0.9)
print("高需求案例的平均誤差：", round(errors[high_demand].mean(), 2))
print("其餘案例的平均誤差：", round(errors[~high_demand].mean(), 2))
# 如果高需求案例的誤差明顯更大，代表模型在最需要準確的情境反而最不可靠

• 部署前只檢查了一次整體誤差，沒有檢查誤差是否集中在特定情境
• 沒有寫下漏抓與誤報各自的業務成本，導致 threshold 或決策依據不透明
• 監測指標沒有設定明確的異常門檻，導致「看起來怪怪的」卻沒有人採取行動
• 沒有人工 fallback 機制，模型異常時只能等下一次排程重新訓練

重點: 能完成步驟不代表結果可信；本節的能力必須能被驗證、重做並清楚說明。

55 分鐘

Independent Lab：Predictive Analytics Use Case

學習目標：獨立交付 baseline、模型、評估、錯誤分析、限制與部署判斷依據。

• 前往 DS 201 實作頁面
• 預覽下載實作資料（含挑戰）
• 下載 Independent Lab 起始 Notebook
• 預覽下載資料字典（繁體中文）
• 預覽下載資料字典（英文）

1. 1定義預測問題
   寫下預測單位、target（回歸或分類）、決策與 prediction time 可用的 features。
2. 2建立 baseline
   為你選定的 target 建立至少一個 naive/majority/mean baseline。
3. 3正確切分並訓練
   依時間切分 train/validation/test，訓練模型並在 validation 上調參。
4. 4評估並比較
   用 MAE/RMSE 或 precision/recall 比較模型與 baseline，並檢查 threshold 或模型複雜度的取捨。
5. 5錯誤分析
   依 group_attribute 或案件量區間檢查誤差是否集中，並找出至少一個需要進一步調查的模式。
6. 6做出部署判斷
   根據表現、成本、drift 風險與監測可行性，寫下一個有理由的 go/no-go 判斷，不宣稱普遍成立。

• 一個清楚陳述的預測問題與決策
• 至少一個 baseline 及其表現
• 正確的時間切分方式與 leakage 檢查紀錄
• 模型表現與 baseline 的比較，包含至少兩個評估指標
• 至少一項子群或情境層級的錯誤分析
• 至少一項限制與一個部署判斷（含成本、drift、監測與人工 fallback 的考量）
• AI 協助情形的紀錄（若有使用）與你自己驗證了什麼

• 部署判斷必須寫清楚假設的成本與監測方式，而不是只給一個「go」或「no-go」的結論
• 子群錯誤分析的樣本量過小時，要註明這一點而不是直接下定論
• Model Card 中的限制欄位必須具體，像是「在資料量少於 N 筆的子群上誤差較不穩定」，而不是空泛的「可能有限制」

重點: 能完成步驟不代表結果可信；本節的能力必須能被驗證、重做並清楚說明。