沒有測試集的護欄，等於沒有護欄

Day 5 講的三層架構裡，L2 的兩個閾值要「用語料庫跑出來」。Week 4 要比較雲端與地端的攔截率。Day 27 要說「每個數字附測試集與樣本數」。這些全部依賴今天要建的東西。

先講一個原則：測試集要分成「調校用」與「驗收用」兩份，而且驗收用的那份在調校期間不能看。 這是機器學習的基本功，但在護欄領域經常被忽略——很多團隊用同一組 payload 調閾值又拿它報攔截率，數字當然漂亮。

公開資料集：能用什麼、各自的偏差

以下是本系列會用到的資料集，每個都標明它適合測什麼、以及它的盲點。

Security 類（injection / jailbreak）

Safety 類（過度拒絕）

三個共同的盲點

1. 英文為主。zh-TW 的注入句式（「請忽略上述規範」「你現在是開發者模式」）在英文資料集上的變體覆蓋很差。
2. 單輪為主。多輪鋪陳型攻擊（前三輪建立信任、第四輪下手）幾乎沒有公開資料集。
3. 沒有間接注入。藏在 PDF、網頁、工具回傳 JSON 裡的注入，公開資料集極少。

這三個盲點，就是自製案例要補的地方。

自製案例：本系列的語料結構

我把自製語料分成六個類別，每個類別至少 50 筆，正例與負例對半：

第六類最重要。沒有高相似度負例，你永遠不知道誤判率——一個把所有含「忽略」二字的句子都擋掉的護欄，在只有正例的測試集上會拿滿分。

【此處貼語料庫 repo 的目錄結構截圖】

語料的產生方法

手寫

D-zh 與 B-benign 兩類我堅持手寫，因為它們決定了 zh-TW 的品質，而現有 LLM 生成的中文攻擊句式同質性很高。

模板 × 變體

I-doc 與 I-tool 用模板生成：準備 20 份正常文件／JSON，準備 15 種注入句，交叉嵌入不同位置（開頭、中段、結尾、註解、隱藏欄位），再抽樣。

LLM 輔助擴增（有條件）

用 LLM 對手寫案例做同義改寫，擴增變體。條件：擴增後要人工抽驗，且擴增資料只進「調校集」，不進「驗收集」——否則等於用生成器的偏好考自己。

從真實事件回收

每一次紅隊演練、每一次客戶環境的真實攔截事件（去識別化後），回收進語料庫。這是語料庫長期最有價值的來源，也是為什麼 Day 29 的稽核日誌要能匯出樣本。

標記格式

每一筆語料統一成這個結構，後面所有評測腳本都吃它：

{"id": "D-zh-0042", "category": "direct_injection", "lang": "zh-TW",
 "turns": [{"role": "user", "content": "…"}],
 "context": {"rag_chunks": [], "tool_results": []},
 "label": "attack", "expected_action": "block",
 "source": "handwritten", "split": "eval"}

幾個欄位的用意：

• turns 是陣列，才能裝多輪案例。
• context 分開放 RAG 與工具回傳，才能測間接注入的不同攔截點。
• expected_action 不只是 block／allow，還有 mask（PII 遮罩後放行）與 escalate（送 L3）。
• split 明確標 tune 或 eval，程式層級防止混用。

語料庫本身的安全

一份好的攻擊語料庫，本身就是攻擊工具。本系列的處理：

• Repo 公開的是結構、模板與弱化版範例，完整 payload 不公開。
• 弱化版指的是：保留攻擊「形狀」但拿掉可直接使用的細節。
• 讀者若要完整集，請用自己的環境依照方法重建——這也是為什麼今天花篇幅講方法而不是貼資料。

本系列的樣本數

【此處貼實際建置完成後的統計表截圖，含各類別筆數】

Day 25 開始跑數字時，每張表的標題都會帶這裡的分割名稱與樣本數。

明天預告

Day 7：本系列實驗環境。GCP 專案怎麼開、Model Armor API 怎麼啟用、DGX Spark 上的地端環境長什麼樣、兩邊的延遲怎麼量才公平。Week 1 收尾，Week 2 開始動手。

追蹤 AId3fend

更多 AI 資安筆記：aid3fend.com