為什麼一個技術系列要花一天講怎麼寫數字

因為護欄是安全產品，而安全產品的數字會被拿去做決策：要不要買、要不要上線、出事時誰負責。一個寫成「99.9% 攔截率」的簡報，會讓採購方以為剩下 0.1% 是可以接受的殘餘風險——但那個數字可能來自 50 筆樣本、只測英文、閾值調到誤判 30%。

這一天是本系列所有數字的寫作規範，也是我看別人簡報時的提問清單。

五條紅線

一、不寫 100%，不寫「全部」「幾乎所有」

任何有限測試集上的 100% 都只代表「這個集合裡的沒漏」。寫法：

✗ 攔截所有已知 prompt injection 攻擊 ✓ 在 eval 集（六類、n=＿）上攔截率 ＿%，B-benign 誤判率 ＿%

二、每個數字帶三樣東西：測試集、n、條件

• 測試集名稱與分割（eval / PINT 公開子集 / XSTest 中譯）。
• 樣本數 n。
• 條件：閾值、filter 版本、模型版本、統一的誤判率目標。

沒有這三樣的數字，本系列不寫。

三、攔截率與誤判率永遠成對

Day 25 陷阱二。單獨的攔截率是可以用「全擋」達成的。

四、safety 與 security 的數字分開報

Day 2 分界、Day 25 陷阱三。JailbreakBench 的成績不放在「injection 防護」的段落。

五、對抗性改寫後的數字要報

Day 25 的改寫表。eval 集上的數字是已知攻擊的攔截率；改寫後的數字更接近真實攻擊者會做的事。只報前者是誤導。

n 多少才夠

用二項分布的信賴區間粗估。攔截率 p、樣本 n，95% 信賴區間寬度約 ±1.96 × √(p(1−p)/n)：

n=20 的 95% 攔截率，真值可能在 85% 到 100% 之間——這個數字說不了任何事。本系列各類語料的 eval 集目標是每類 ≥ 50，合計 ≥ 300，但誠實講：分類別的數字（例如 M-turn 那一列）信賴區間仍然寬，寫的時候要標。

看別人簡報時的提問清單

反過來，當你是採購方：

1. 這個攔截率是在哪個測試集上量的？可以看到樣本嗎？
2. n 是多少？
3. 誤判率是多少？在什麼負例集上量的？
4. 這是 safety 的數字還是 security 的數字？
5. 有沒有測過中文？多輪？間接注入？
6. 攻擊改寫後掉多少？
7. 閾值是誰調的？調到什麼條件？
8. 測試集有沒有在訓練資料裡？

任何一題答不出來，那個數字就當不存在。

為什麼這對地端線特別重要

Model Armor 是 Google 的產品，它的數字由 Google 負責。地端線是你自己組的——微調版是你訓的、閾值是你調的、eval 集是你建的。上線後出事，「我們的護欄有 95% 攔截率」這句話會被拿出來檢視，而檢視的人會問上面八個問題。寫得誠實，是在保護自己。

這條紅線也適用於本系列的結尾

Day 28 的對照表、Day 30 的結論，會照今天的規範寫。如果某一格的 n 不夠、條件不一致、或根本沒測到，那一格會寫「未測」或「n 不足，不列」，不會用相鄰的數字補。

明天預告

Day 28：雲端 vs 地端總對照。覆蓋率、延遲、成本、資料主權、可解釋性、維運負擔——把 27 天的數字與觀察放進一張表，附上每個數字的來源天數。

追蹤 AId3fend

Instagram @aid3fend。

更多 AI 資安筆記：aid3fend.com