AI 安全基準與評估
Advanced4 min readUpdated 2026-03-13
AI 安全評估之概觀：基準框架、安全指標、評估方法論，以及供 AI 紅隊使用之標準化評估工具景觀。
AI 安全評估將主觀判斷（「此模型安全嗎？」）轉化為可量測、可重現之評估。安全基準 提供共享量測基礎設施——啟動跨模型比較、追蹤時間軸之改善、以及向利害關係人溝通風險。
評估景觀
主要安全基準
| 基準 | 焦點 | 攻擊類型 | 指標 | 維護者 |
|---|---|---|---|---|
| HarmBench | 自動化紅隊 | Jailbreak、有害內容 | ASR、拒絕率 | CMU / Center for AI Safety |
| TrustLLM | 全面可信度 | 安全、公平、穩健、隱私 | 多維度分數 | 學術聯盟 |
| SafetyBench | 多語言安全 | 跨語言有害內容 | 各類別準確度 | 多個機構 |
| AdvBench | 對抗穩健性 | 對抗後綴、GCG 攻擊 | 含分類器之 ASR | 學術 |
| JailbreakBench | Jailbreak 評估 | 已知 jailbreak 技術 | 成功率、評審一致度 | 學術 |
| MLCommons AI Safety | 標準化安全 | 與 NIST 分類一致 | 標準化評分 | MLCommons |
覆蓋圖
┌──────────────────────────────────────┐
│ 安全評估 │
│ 景觀 │
├──────────────────────────────────────┤
│ │
│ HarmBench ────── Jailbreak │
│ │ │
│ ├──── 直接注入 │
│ ├──── 對抗後綴 │
│ └──── 自動化攻擊 │
│ │
│ TrustLLM ────── 多維度 │
│ ├──── 安全 │
│ ├──── 公平 │
│ ├──── 穩健 │
│ └──── 隱私 │
│ │
│ 客製 ─────── 部署特定 │
│ ├──── 領域政策 │
│ ├──── 工具／代理安全 │
│ └──── 系統整合 │
└──────────────────────────────────────┘評估方法論
評估管線
定義評估範圍
對此部署而言，哪些安全屬性重要？將部署風險對映至基準類別。並非每個基準皆與每個部署相關。
選擇基準
選擇涵蓋所辨識風險類別之標準化基準。為基準未涵蓋之部署特定風險規劃客製測試套件。
組態評估 harness
設置評估基礎設施：模型 API 存取、評審模型、評分函式與結果儲存。詳見 打造評估 Harness。
執行評估
以一致之參數執行基準。記錄模型版本、溫度、系統提示與所有組態細節以便重現。
分析結果
計算指標、辨識失敗類別，並將結果與部署風險相對脈絡化。無脈絡之原始分數無意義。
報告與追蹤
以標準化格式記錄發現。隨時間追蹤指標以偵測退化。詳見 ASR 之外的紅隊指標。
基準侷限
| 侷限 | 描述 | 影響 |
|---|---|---|
| 靜態測試集 | 固定提示變成已知；模型可被調校以通過 | 基準分數提升卻無真正安全改善 |
| 類別缺口 | 無基準涵蓋所有攻擊類型 | 自已涵蓋類別之高分獲得虛假信心 |
| 評審可靠度 | 以 LLM 為本之評審具其自身偏誤與失敗模式 | 評分不一致，尤其於邊界案例 |
| 脈絡盲點 | 基準測試孤立互動，非系統層行為 | 錯失多輪攻擊、代理風險與整合問題 |
| 文化偏誤 | 多數基準以英文為中心 | 其他語言之安全被低估 |
| 時間退化 | 攻擊技術演進較基準更新快 | 基準測試昨日之攻擊，而非明日的 |
Goodhart 問題
選擇評估做法
目標：評估模型是否足夠安全以供部署。
| 做法 | 覆蓋 | 成本 | 建議 |
|---|---|---|---|
| 標準化基準（HarmBench、TrustLLM） | 廣泛、已知類別 | 低 | 永遠——建立基線 |
| 客製領域特定測試 | 部署特定風險 | 中 | 永遠——涵蓋基準錯失者 |
| 人工專家紅隊 | 新穎、創意攻擊 | 高 | 對高風險部署 |
| 自動化紅隊（PAIR／TAP） | 廣泛、自適應 | 中 | 為全面覆蓋 |
目標：偵測自模型更新與提示變動之安全退化。
| 做法 | 覆蓋 | 成本 | 建議 |
|---|---|---|---|
| 具基準子集之 CART 管線 | 核心退化偵測 | 低 | 永遠——及早捕捉退化 |
| 排程之自動化紅隊 | 持續漏洞發掘 | 中 | 每週或每次部署 |
| 生產流量監控 | 現實攻擊偵測 | 低（邊際） | 永遠——偵測新穎攻擊 |
目標：深入理解特定安全失敗。
| 做法 | 覆蓋 | 成本 | 建議 |
|---|---|---|---|
| 根本原因分析 | 單一失敗模式、深度 | 低—中 | 事件後永遠 |
| 建立迴歸測試 | 防止重現 | 低 | 永遠——加入 CART 套件 |
| 圍繞失敗之對抗探測 | 相關漏洞發掘 | 中 | 對關鍵失敗 |
解讀結果
將基準分數脈絡化
於 HarmBench 得 95% 之模型不代表「95% 安全」。它代表：
- 模型拒絕 HarmBench 特定測試提示之 95%
- 剩餘之 5% 代表已知繞過技術
- 未知攻擊類別未被量測
- 該分數是漏洞之下界，非安全之上界
比較分析
| 指標 | 有用於 | 無用於 |
|---|---|---|
| 絕對分數 | 追蹤同一模型隨時間之改善 | 比較根本不同之模型 |
| 相對排名 | 理解模型定位 | 量測絕對安全 |
| 類別拆解 | 辨識特定弱點 | 整體安全判斷 |
| 失敗分析 | 理解失敗如何與為何發生 | 預測未來失敗 |
Knowledge Check
某模型於 HarmBench 得 98% 且於 TrustLLM 安全類別得 95%。利害關係人問：『此模型可部署嗎？』最準確之回應為何？
參考資料
- Mazeika et al.，〈HarmBench: A Standardized Evaluation Framework for Automated Red Teaming〉（2024）
- Sun et al.，〈TrustLLM: Trustworthiness in Large Language Models〉（2024）
- Chao et al.，〈JailbreakBench: An Open Robustness Benchmark for Jailbreaking Large Language Models〉（2024）
- MLCommons，〈AI Safety Benchmarks v0.5〉（2024）
相關主題
- 打造評估 Harness -- 執行評估之基礎設施
- ASR 之外的紅隊指標 -- 評估之進階指標
- AI 紅隊中的統計嚴謹度 -- 統計方法論
- CART 管線 -- 持續自動化測試