被拔掉的護欄都不是因為擋不住

Day 5 開頭那句話：地端護欄上線一個月被拔掉，原因不是擋不住攻擊，是擋了太多正常請求。誤判是護欄專案真正的死因，今天專門講它。

三種誤判，三個測試集

XSTest

250 題左右的「看似危險、實則無害」問題，加上對應的真正危險題。設計目的就是抓過度拒絕。它是英文集，本系列翻成中文各跑一次。

台灣語境敏感題（自製）

這一組不公開細節，只講方法：收集業務場景（金融、保險、法務）中必然會出現、但 guard model 出品方的政策可能視為敏感的用語與問題——涉及地域政治稱謂、特定歷史事件的正式文件用語、法規名稱等。每題人工確認是正常業務請求，跑三個 guard model（Day 17）與 Model Armor 的 RAI 過濾器，看誰擋。

這一組的結果會直接影響 Day 17 的選型結論。

誤判率目標怎麼訂

本系列用 ≤ 5% 是為了對照方便，真實專案要從業務端倒推：

1. 每次誤判的成本：使用者重試一次？業務流程卡住等人工？對外客戶被拒絕後流失？
2. 日流量：誤判率 × 日流量 ＝ 每天多少人被擋。
3. 可接受的每日誤判事件數：這是業務單位要回答的問題，不是資安。

反推出來的誤判率目標，再回去用 Day 5 的方法定 t_high。

一個實務觀察：對外客服場景的可接受誤判率通常遠低於 5%，內部知識問答可以高一些。同一個護欄在不同應用要用不同閾值——這又回到 template（雲端）與 YAML 設定檔（地端）可以有多份的設計。

誤判率的另一面：漏判

過度拒絕的相反是漏判。今天講的所有降低誤判的手段，都會讓漏判率上升。這個系列一直用「統一誤判率再比攔截率」，就是為了不讓任何一方單獨好看。Day 28 的對照表會兩個一起放。

明天預告

Day 27：行銷紅線。跑完所有數字，講怎麼寫出來——為什麼不寫 100%、為什麼每個數字要帶測試集與 n、n 多少才夠、以及看到別人的護欄產品簡報時怎麼問問題。

追蹤 AId3fend

Instagram @aid3fend

更多 AI 資安筆記：aid3fend.com