上一篇先把 Guardrails 的六個驗收情境改寫成合成資料需求，並且分清楚三類條件：哪些一定要固定、哪些可以變化、哪些不能交給模型自行發明。
接下來很容易直接打開 LLM，開始寫提示詞（Prompt）。例如：「請幫我生成一百筆包含地址的客服對話，格式多樣、語氣自然。」這個要求確實可能生出一百筆文字，卻沒有回答更基本的問題：這一百筆各自在測哪條規則？哪些條件不能變？正常案例、誤擋案例與邊界案例各有多少？
如果這些事情沒有先決定，Prompt 寫得越自由，資料偏離測試目的的可能也越大。
其實 Data Seeding 並不是生成式 AI 出現後才有的概念。在傳統軟體開發中，我們就會先準備一批初始資料（Seed Data），讓資料庫、測試環境或應用程式有一個可以開始運作的狀態。
到了合成資料（Synthetic Data）的情境，概念其實很類似：在開始大量生成資料以前，先準備一批種子資料，告訴生成系統「要從哪些案例與條件開始生成」。
例如我們想產生一批用來測試 PII Guardrail 的客服資料，與其直接告訴 LLM：
「請生成 1,000 筆包含個資的客服對話。」
更好的做法是先準備 Seed，定義我們真正想測的情境：
scenario: change_address
pii_type: ADDRESS
destination: external_llm
raw_pii_allowed: false
expected_action: BLOCK
接下來，生成模型可以根據這筆 Seed 改變地址內容、使用者語氣、句型、格式或個資出現的位置，產生許多不同的 Synthetic Data。
因此，可以先把整個關係簡化成：
Seed
↓
定義要生成的案例與條件
↓
Synthetic Data Generation
↓
產生不同的資料變化
不過這裡有一個很容易忽略的問題：
從一筆 Seed 生成 100 筆資料，不代表我們就測到了 100 種風險情境。
如果這 100 筆資料都只是同一個「地址送往外部 LLM，因此應該 BLOCK」的案例換了不同說法，那本質上仍然只覆蓋一種風險邊界。
所以在 AI Guardrails 的測試裡，Seed 真正重要的地方不只是「提供資料給模型參考」，而是要先回答：
我們到底希望這批合成資料覆蓋哪些 Guardrail 風險情境？
放到 Guardrails 測試裡，Seed 更像一份列級的資料契約。它至少要回答三個問題：
以前幾天一直使用的 PII-01 為例，真正固定的不是「台北市信義區測試路 100 號」這句文字，而是這筆案例的任務與信任邊界：使用者要修改地址，原始地址準備送往未核准接收個資的外部 LLM，因此預期處置是 BLOCK，而且外部 LLM 的實際呼叫次數必須是 0。
地址本身可以換，句型、換行、語氣與出現位置也可以變；但目的端是否核准、是否允許原始個資，以及預期處置，不能讓模型自行決定。
這筆 Seed 可以先整理成下面的契約：
| 欄位 | PII-01 Seed 的內容 | 為什麼要放在 Seed |
|---|---|---|
case_id |
PII-01 |
讓生成結果能回到原始驗收情境 |
scenario |
客戶修改配送地址 | 固定任務，避免對話中途變成退款或查訂單 |
destination |
未核准接收原始 PII 的外部 LLM | 這是決定 Policy 的關鍵條件 |
raw_pii_allowed |
false |
不讓模型猜測資料使用權限 |
entity_type |
ADDRESS |
指定這一輪要覆蓋的敏感資訊類型 |
must_use |
虛構的新地址與訂單識別資訊 | 生成內容必須真的使用，否則沒有測到目標 |
may_vary |
語氣、格式、換行、地址位置、是否混合英文 | 用來增加表達與格式的變化 |
must_not_invent |
核准狀態、身分驗證結果、Policy 例外 | 這些值會改變預期處置，不能由 LLM 補寫 |
expected_action |
BLOCK |
連回 Day 5 的驗收標準 |
evidence_requirement |
外部 LLM 實際呼叫次數 = 0 | 避免只檢查 Guardrail 回傳的標籤 |
這張表還不是最終的資料集結構（Dataset Schema），更不是已經執行過的測試。它目前只負責一件事：把「這筆資料為何存在」與「哪些條件不能漂移」寫清楚。
Day 7 的規劃也提到 Persona。Persona 當然有用：第一次使用線上客服的人，可能會把資訊拆成多個回合；熟悉流程的使用者可能直接提供訂單編號；情緒急躁的使用者可能一次貼上大量內容。這些差異會影響句型、長度、錯字與資訊出現順序，正好可以增加測試覆蓋。
但 Persona 不應決定資料能不能送出去。
如果同一筆 PII-01 只是把 Persona 從「熟悉流程的使用者」換成「急著改地址的使用者」，destination、raw_pii_allowed 與 expected_action 不應跟著變。否則 Persona 就不再只是生成條件，而是在偷偷改寫企業 Policy。
我會把這兩類欄位分開：
欄位分開後，發現結果不符預期時，才有辦法先判斷是文字變化造成偵測問題，還是案例的政策條件在生成過程中被改掉了。
假設目前只準備「包含地址、預期 BLOCK」的 Seed，模型可以生成很多不同地址，也可以換很多種說法。表面上資料很豐富，實際上仍只覆蓋同一側的邊界。
一組要拿來測 PII Guardrails 的 Seed，至少要分清三種角色：
| 類型 | 這次要測什麼 | 地址案例示意 |
|---|---|---|
| 正樣本（Positive） | 該偵測、該依 Policy 處置的內容能否被處理 | 原始地址準備送往未核准的外部 LLM，預期 BLOCK |
| 一般負樣本（Negative） | 沒有目標 PII 的正常內容會不會被誤擋 | 使用者只詢問配送進度，沒有提供姓名、電話或地址 |
| 易誤判負樣本（Hard Negative） | 外觀很像 PII、但可信資料契約確認不是 PII 的值會不會被誤判 | 結構化欄位已定義為訂單代碼，但數字格式碰巧像電話號碼 |
易誤判負樣本的前提是「可信資料契約已經確認它不是 PII」。如果自由文字裡只寫一句「這不是電話，是訂單編號」，還不能把它當成可靠標籤；否則只是讓生成模型替自己的答案背書。
這三種案例也不能只靠最後的 expected_action 區分。正樣本與易誤判負樣本可能使用非常接近的字串，但欄位來源、任務與語境不同。Seed 必須把差異寫出來，後續生成與標註才不會把「長得像」誤當成「就是」。
Seed 的另一個責任，是決定案例分布。
這裡很容易掉進一個直覺：正式環境最常出現什麼，測試集就照相同比例準備。這種分布適合回答「目前流量下整體表現如何」，卻不一定適合回答「換了一個 Guardrail 之後，風險邊界有沒有退步」。
正式環境裡，Hard Negative 可能很少；Agent Tool 參數裡出現敏感資料也可能尚未發生。但只要這些案例一旦失敗會造成高風險，回歸測試就有理由刻意提高它們的比例。這是風險導向的測試設計，不是在宣稱正式環境真的有相同分布。
因此我會先列出想控制的軸，再談每一軸要放多少案例：
BLOCK、MASK、ALLOW、DENY_TOOL_CALL。每個軸都放進去，不代表要做完整的排列組合。那會很快造成測試數量爆炸。比較實際的做法，是從目前最重要的 Policy 與已知失敗模式開始，明確記錄這一版 Seed 選了哪些組合、哪些沒有選，以及原因。
例如這一輪如果專門驗證電話格式的誤擋問題，就可以提高電話類 Hard Negative 的比例；如果下一輪要驗證長文本漏判，則把 PII 出現位置與文件長度拉成主要變因。兩輪資料的比例不同沒有問題，前提是測試目的與分布版本有留下來。
NVIDIA 的官方文件提醒，生成筆數大於 Seed 筆數時，同一列 Seed 會被重複使用。這點對 Guardrails 測試尤其重要：把十筆 Seed 各改寫十次，可以得到一百筆資料，但風險邊界仍然只有十個。資料筆數增加，不等於涵蓋範圍跟著增加。
開始寫 Prompt 以前，應該先審查 Seed Contract：
must_use、may_vary 與 must_not_invent 是否分得開？這些問題沒有答案時，先增加 Prompt 細節只會把未決條件藏進自然語言裡。等到資料生成完，再回頭追查某筆案例為什麼是 BLOCK 或 ALLOW，成本會更高。
下一步是把同一筆 Seed 拆成含 PII 原文、去識別化版本與標註資料等不同生成階段（Stage）。今天先確定管線最前面的資料契約沒有寫錯。
iThome鐵人賽
看影片追技術