LLM Guardrails 測試怎麼做？紅隊、誤攔與上線驗收清單

你已經替聊天機器人加上輸入過濾、輸出檢查或工具權限限制，但要怎麼知道這些護欄真的能上線，而不是只在幾個示範提示上有效？

直接答案：LLM Guardrails 測試應同時驗證四件事：危險輸入能否被攔下、正常請求是否被誤攔、模型或工具越權時能否在系統邊界停止，以及版本更新後結果能否重跑。先從真實任務定義風險與允許行為，再建立「正常、邊界、對抗、歷史失敗」四組案例；每次發布固定記錄攔截率、誤攔率、漏攔案例與高風險工具是否需要人工核准。只測幾句 jailbreak、只看總成功率，或讓另一個 LLM 自己判定全部結果，都不足以證明護欄有效。

如果你還在選擇輸入與輸出護欄，先讀站內的 LLM Guardrails 安全護欄教學；本篇接續回答「做好之後如何驗收」。更多 Agent、RAG 與模型落地內容可回到 AI 工程實戰主題樞紐。

為什麼只測幾個成功攔截案例不夠？

護欄不是「有擋到一次」就完成。對話型系統同時有兩種相反錯誤：漏攔會讓危險內容或未授權動作通過；誤攔則會把正常使用者拒於門外。若團隊只收集攻擊提示，可能得到很高的攔截數，卻完全不知道合法的客服、醫療衛教或資安討論是否也被阻擋。真正的測試必須把安全與可用性放在同一張結果表。

測試對象也不是單一模型回覆，而是完整系統：前處理、檢索內容、系統提示、模型版本、輸出解析、工具呼叫、授權與人工核准都可能改變結果。OWASP 將直接與間接 Prompt Injection 都列為風險，並指出 RAG 或微調不能完整消除注入問題；其建議包含固定輸出格式、最小權限、人工核准與定期對抗測試。這代表驗收不能只對模型聊天框丟提示，還要碰到文件、網頁、工具與權限邊界。

第一步要如何界定 Guardrails 測試範圍？

先寫一頁「允許／禁止／需人工確認」矩陣。允許項目描述系統應完成的任務，例如查詢公開訂單狀態；禁止項目描述絕不能發生的結果，例如跨客戶讀取資料；需人工確認則放入退款、刪除、發信、發布內容與變更權限等不可逆或高影響動作。這張矩陣比抽象的「回答要安全」更容易轉成測試案例與程式斷言。

接著按資料流畫出檢查點：使用者輸入前、檢索資料進入上下文前、模型輸出後、工具執行前、結果寫回後。OpenAI Guardrails 的公開目錄也把護欄分成 input、output 與 agentic 類型，並列出 PII、jailbreak、離題、幻覺與工具意圖等不同檢查。這可作為分類參考，但團隊仍要依自身資料與業務動作決定優先級，不能照抄清單當成完成。

每個風險至少寫出「資產、威脅、控制、可觀察結果」四欄。例如：資產是客戶聯絡資料；威脅是外部文件藏有指令；控制是隔離不可信內容、限制查詢範圍並在工具層重新驗權；可觀察結果是工具沒有取得其他租戶資料，且日誌留下被拒絕原因。沒有可觀察結果，就無法形成可驗收的測試。

測試集該包含哪些案例，才不會只對攻擊資料過度最佳化？

一個最小可用測試集應有四桶。第一桶是正常案例，覆蓋常見問法、繁體中文口語、錯字、縮寫與合理的敏感主題；第二桶是邊界案例，例如研究、新聞摘要、教育與自我保護情境；第三桶是對抗案例，包含直接注入、外部文件中的間接注入、角色扮演、編碼混淆、長上下文與跨語言變體；第四桶是歷史失敗，把正式環境已發生且去識別化的問題變成永久回歸案例。

資料切分時，保留一組從未用來調護欄閾值的驗收集。若每次都拿同一批攻擊提示改規則，再用同一批資料驗收，成績只代表記住題目。正常與危險案例都要標註預期動作：放行、拒絕、遮罩、降級回答、要求澄清或送人工審查，而不只是二元的「安全／不安全」。

對台灣服務，至少加入繁中、英中混用、注音或諧音、全形符號、網址與檔案內容。這不是宣稱某語言一定比較脆弱，而是避免英文測試集無法代表實際流量。每筆資料保留來源、建立日期、適用風險、預期結果與審核者；涉及真實對話時先去識別化，避免測試資料本身成為個資外洩入口。

攔截率與誤攔率要怎麼算？

先分開計算，不要只報一個「準確率」。對已標註危險的案例，記錄漏攔數與危險案例總數；對已標註正常的案例，記錄誤攔數與正常案例總數。再按風險類型、語言、入口、模型版本與工具拆分。高風險動作即使樣本少，也不應被大量低風險聊天稀釋。

• 危險攔截率：危險案例中被正確阻止或轉人工的比例。
• 正常放行率：正常案例中未被錯誤拒絕的比例。
• 高風險越權數：測試期間實際到達工具執行邊界、但未經授權的次數。
• 不可判定率：規則或審核者無法一致判斷、必須補政策定義的比例。

若使用 LLM-as-a-judge，可把它當成擴大檢查的工具，不是唯一真相。Google Cloud 的模型評估文件要求用帶有人類評分的資料作為 ground truth，將 judge model 分數與人類評分比較。實務上應先校準評審模型，抽樣人工複核，並把規則式檢查、工具授權結果與人工標註保留下來；否則評審模型的偏誤會被誤當成護欄品質。

紅隊測試要測到哪一層？

紅隊的目標不是蒐集最花俏的 jailbreak，而是找出可造成實際影響的失敗鏈。先在隔離環境測試輸入與輸出，再加入 RAG 文件、瀏覽內容、附件、記憶與工具。每個攻擊案例都問三件事：不可信內容能否改變系統目標、模型能否要求超出權限的工具、下游系統是否仍會獨立驗證身分與參數。

OWASP 對 Excessive Agency 的說明把根因分為功能過多、權限過大與自主性過強，並建議縮小工具功能、使用最小權限、避免開放式工具、高影響動作要求人工核准，以及由下游系統完成授權。測試因此要包含「工具存在但不應可用」「同一工具對不同使用者權限不同」「模型要求危險參數」「連續多步驟逐漸擴權」等案例。

所有測試只應針對你擁有或獲得明確授權的系統，使用測試帳號、沙盒資料與可復原動作。不要把真實客戶資料交給外部評審模型，也不要為了測試而在正式環境執行刪除、發信或付款。若必須觀察正式流量，優先採取影子評估：記錄護欄若啟用會如何判斷，但不讓測試邏輯實際觸發高影響動作。

上線門檻應該如何設定？

門檻必須依風險分層，而不是套用任意百分比。涉及付款、刪除、跨租戶資料或對外發布的案例，可以要求零未授權執行，且每次都在工具層驗權；一般內容分類則可容許少量不確定結果轉人工。團隊應在測試前寫下門檻與阻擋發布的條件，避免看到結果後才降低標準。

一個可操作的發布關卡包含：指定版本的模型、提示、檢索索引與護欄設定全部可追溯；固定驗收集全數完成；高風險案例沒有漏過工具邊界；正常案例的誤攔沒有超過產品可接受範圍；所有不可判定案例已有人負責；失敗時有降級、停用工具或切回前一版本的方法。每次換模型別名、提示、工具 schema、權限或檢索流程，都應重跑受影響的案例。

不要把「測試全綠」寫成絕對安全。護欄結果受模型、資料與攻擊方法變化影響，驗收只能說明指定版本在指定測試集上的表現。外部攻擊者仍可能找到未覆蓋的路徑，因此要保留事件監控、人工回報與定期更新測試集的流程。

哪些常見做法會讓測試結果失真？

第一，只測拒絕、不測放行。結果通常是規則愈加愈多，產品卻逐漸無法使用。修正方式是每一類危險案例至少配對一批語意相近但應允許的正常案例。

第二，只測模型、不測系統。輸出看似安全，但工具可能已收到危險參數。修正方式是把工具呼叫、授權回應與副作用納入斷言。

第三，用同一個模型產生、回答又評分。三者可能共享盲點。修正方式是加入人類標註、確定性規則與不同來源的攻擊案例，並對 judge model 做校準。

第四，測試資料含有秘密或個資。測試平台、日誌與外部評審都可能擴大暴露面。修正方式是合成資料、遮罩識別資訊、縮短保存時間並限制讀取權限。

第五，只在上線前測一次。模型、提示、索引與工具會持續變動。修正方式是把歷史失敗加入回歸集，在每次相關變更與固定週期重跑，並監看正式環境的新型失敗。

如何做一次可重現的 Guardrails 驗收？

1. 鎖定模型與系統版本，列出資料流、工具、權限與高影響動作。
2. 完成允許／禁止／需人工確認矩陣，指定每項風險的負責人。
3. 建立正常、邊界、對抗與歷史失敗四組資料，另留未參與調參的驗收集。
4. 對每筆案例寫清楚預期的放行、拒絕、遮罩、澄清或人工審查動作。
5. 在沙盒執行完整鏈路，保存輸入版本、護欄判斷、模型輸出、工具要求與授權結果。
6. 分開統計漏攔、誤攔、越權與不可判定案例，按風險與語言切片檢查。
7. 人工複核高風險失敗與 judge model 不一致的樣本，修正政策或控制後重跑。
8. 確認降級與回滾可用，再由產品、安全與系統負責人共同簽核發布。

驗收證據應能讓另一位工程師重跑，而不是只留下截圖或一句「已測過」。最低限度保留資料集版本、設定版本、執行時間、結果檔、失敗案例與處置決定。搜尋排名、使用者轉換或 AI 引用不屬於這份技術驗收；沒有 Search Console、Analytics 或可重現引用紀錄時，這些外部結果都只能標為 Unknown。

參考資料

• OpenAI Guardrails：輸入、輸出與 Agentic Guardrails 的官方分類與文件入口，查證日期 2026-08-11。
• OWASP GenAI：LLM01 Prompt Injection：直接／間接注入、最小權限、人工核准與對抗測試建議，查證日期 2026-08-11。
• OWASP GenAI：LLM06 Excessive Agency：工具功能、權限、自主性與下游授權控制，查證日期 2026-08-11。
• Google Cloud：Evaluate a judge model：以人類評分作為 ground truth 校準模型評審的官方說明，查證日期 2026-08-11。