AVISE 論文閱讀分析：很多 AI 安全真正缺的，不是再多一個攻擊 prompt，而是一套可重跑的評測框架
論文基本資訊
- 論文標題：AVISE: Framework for Evaluating the Security of AI Systems
- 作者：Mikko Lempinen、Joni Kemppainen、Niklas Raesalmi
- 年份：2026
- 來源：arXiv:2604.20833
- 論文連結：https://arxiv.org/abs/2604.20833
- 主題：AI Security、AI Red Teaming、Jailbreak Evaluation、Security Evaluation Framework、LLM Safety、Adversarial Testing
很多 AI 安全研究真正缺的，不是又多一個攻擊 prompt，而是到底要怎麼把「這模型有沒有安全問題」這件事，變成可重跑、可比較、可累積的工程流程。不然現況常常是：今天有人貼一組 jailbreak transcript，明天另一篇換一批模型、換一套 judge、換一個攻擊模板，最後大家都在講安全，卻很難把結果放到同一張表上。
這篇 AVISE 有意思的地方，就在它不是只再做一個 jailbreak demo，而是試圖把 AI security evaluation 本身做成一個模組化框架：你可以定義不同 Security Evaluation Test（SET）、替不同 AI 系統接不同 pipeline、指定 evaluator 與 report generator，最後把測試結果收斂成比較像正式 security assessment 的輸出。
作者拿來示範的案例，是把多輪 jailbreak 攻擊 Red Queen 自動化，並再往前推成 ALM（Adversarial Language Model）augmented 版本。也就是說，這篇真正想證明的不是「這招 prompt 很強」，而是：
AI 安全測試如果還停在單次、手工、不可重現的紅隊秀，很難支撐實際治理；比較缺的其實是一套能把 attack、evaluation、aggregation、reporting 接起來的 security testing substrate。
這篇論文想解決什麼？
作者點的問題其實很準：目前不少 AI security 工具雖然已經能對 LLM 做掃描或 red teaming，但常見缺口包括：
- 把每次測試當成獨立事件，沒有處理模型輸出的 stochasticity；
- 評估器太靜態或太黑箱，不是太死板，就是太難控；
- 針對特定模態或特定攻擊，擴展到別的 AI 系統時很痛；
- 缺少一致的報告與資料契約，結果難以重現、比較與交接。
所以這篇 paper 的野心不是「做最強 jailbreak」，而是想補上這個更結構性的空洞：怎麼把 AI vulnerability discovery 變成一套可組裝、可擴充、可反覆執行的 evaluation framework。
核心 framing：重點不是某個 attack，而是 Security Evaluation Test（SET）這個抽象層
我覺得這篇最值得看的地方，是它把安全測試的核心單位抽成 SET。這個設計很像你在傳統資安裡不只想要某個 exploit script，而是想要一個能反覆執行、可替換條件、可換評估器、可出報告的測試規格。
在 AVISE 裡，一個 SET 不是只有 prompt，而是把整個流程拆成：
- initialize：初始化 target、測試條件與所需元件；
- execute：實際執行攻擊或測試流程；
- evaluate：由 evaluator 判定結果；
- report：產生人類可讀、可追溯的報告。
這個抽象層的價值在於：未來你不只可以拿它測 LLM jailbreak，也可以換成 multimodal、continual learning、甚至 grey-box / white-box 的 AI system security tests。換句話說，作者真正想做的比較像是 AI security testing harness，而不是單點技巧。
AVISE 架構在做什麼？
框架本身分成兩層：
- Orchestration Layer：負責 pipeline life-cycle，包括 BaseSETPipeline、Execution Engine、Evaluator、Report Generator。
- Interaction Layer：負責跟 target model / target system 互動，處理輸入輸出與測試上下文。
其中我認為最重要的是幾個觀念：
- BaseSETPipeline 負責把不同 target 類型的測試方法抽象化；
- Evaluator 可以是一個或多個，最後再進 verdict determination；
- Report Generator 讓測試不是只剩 pass/fail，而是留下 execution / evaluation logs；
- 多次執行與統計聚合 被視為第一等公民，因為模型本來就不是 deterministic system。
這裡其實打到一個很常被忽略的點：AI 系統安全不是一次測出來的，而是要在同一條測試規格下看它的失敗分布。如果你只跑一次成功或失敗，就很容易把偶發性當成 posture。
作者拿什麼來 demo？Red Queen + ALM 的自動化多輪 jailbreak 測試
AVISE 的 showcase 是把既有的多輪攻擊 Red Queen 做成自動化 SET。Red Queen 的精神，是利用模型在多輪對話裡對使用者意圖、角色、情境的推理，慢慢把它推到會洩出危險資訊的位置。
但作者沒有停在 template prompt replay，而是再加上一個 ALM（Adversarial Language Model），讓攻擊過程中的每一輪 prompt 都能依 target 的回應被改寫、調整與維持在同一條操控策略上。這點很重要，因為多輪攻擊最常失敗的，不是模板不夠兇，而是對話一跑就偏航。
作者因此又加了一個 ELM（Evaluation Language Model） 來判定每個 test case 是否真的讓 target 出現可視為 jailbreak 的輸出。這樣整套 SET 就不只是在自動進攻，也在自動判卷。
這篇最關鍵的 insight：multi-turn 攻擊真正稀缺的，不是 prompt inventory，而是「讓操控意圖一路活到最後」
如果你最近有在看 jailbreak 研究，會發現單輪 prompt 技巧大家已經看很多了；但多輪攻擊更麻煩，因為每回合 target 都會回話，而每回合回話都可能把原本的操控路徑打亂。
AVISE 這裡做對的一件事，是承認多輪攻擊不是把 25 組模板丟出去就好，而是要處理 conversation drift。作者也明講：不用 ALM 時，很多 template-based Red Queen 測試之所以看起來比較安全，不一定是模型真的守得住，而是整段攻擊流程自己先偏掉了。
這也是為什麼我會覺得這篇真正有價值的，不是證明「某招 attack 很神」，而是把 attack continuity 納入評測設計。對 agent / LLM security 來說，這其實比再疊一百個 prompt 花招更像長期有用的方向。
關鍵結果一：SET 一共 25 個 test cases，ALM + ELM 組合下，ELM 評估準確率達 92%
作者設計的 Red Queen SET 一共包含 25 個 test cases，再由 ELM 判定每個 case 是否成功 jailbreak。根據人工複核結果，在使用 ALM 的情況下，ELM 的分類表現達到：
- Accuracy：0.92
- Precision：0.89
- Recall：0.94
- F1-score：0.91
- MCC：0.83
這組數字的意義不只是「judge model 還不錯」，而是顯示 evaluation layer 至少沒有爛到讓整套 framework 失真。在 AI security tooling 裡，攻擊器常常很吸睛，但 judge 一旦不穩，整張結果表就會變得很難信。
關鍵結果二：同一套測試，沒有 ALM 時 ELM 表現明顯變差，凸顯不是 judge 單獨厲害，而是整個 attack-eval loop 比較一致
如果不使用 ALM，ELM 的表現會明顯下滑到：
- Accuracy：0.79
- Precision：0.27
- Recall：0.84
- F1-score：0.41
- MCC：0.40
這個對照很值得注意。它顯示問題不只是 judge prompt 怎麼寫，而是當攻擊對話本身偏航時，後面的評估器也更容易被帶歪。換句話說，AVISE 的價值不是單點模組各自神勇，而是把 attack generation、conversation control、evaluation criteria 接成一條比較一致的 loop。
關鍵結果三：9 個新近模型全部都有不同程度脆弱性，沒有誰能完全過關
作者用這套 Red Queen SET 去測了 9 個近期 instruction-tuned 模型，包括 Llama、Mistral、Qwen 與 Nemotron 系列。結果是：全部都對 ALM-augmented Red Queen attack 呈現不同程度的脆弱性。
在使用 ALM 的情況下，各模型 failure rate 為：
- Llama 3.1 8B：0.68
- Llama 3.2 3B：0.68
- Llama 3.3 70B：0.64
- Ministral 3 14B：0.84
- Mistral 3.2 24B：0.40
- Qwen 3 32B：0.68
- Qwen 3.5 35B：0.08
- Nemotron 3 Nano 30B：0.40
- Nemotron 3 Super 120B：0.12
也就是說，表現最穩的是 Qwen 3.5 35B 與 Nemotron 3 Super 120B，但也都不是零失敗；最脆的是 Ministral 3 14B，failure rate 高達 0.84。
關鍵結果四：不用 ALM 時，看起來多數模型像是守住了；但那很可能只是模板攻擊自己先失焦
如果只用 template attack、不加 ALM，很多模型 failure rate 會低得多。例如：
- Llama 3.2 3B：0.08
- Llama 3.1 8B：0.16
- Llama 3.3 70B：0.16
- Qwen 3.5 35B：0.20
- Nemotron 3 Super 120B：0.20
- Nemotron 3 Nano 30B：0.52
作者人工複核後更指出：
- 不使用 ALM 時，只有約 7% 的 Red Queen 攻擊真的讓模型產生可促進有害/非法活動的內容；
- 使用 ALM 時，這個比例上升到約 47%。
這代表很多表面上的「防住了」，其實未必是模型 safety alignment 真有那麼強，而是你給它的 multi-turn attack 沒有維持住操控節奏。這點很像現實世界的紅隊：攻擊不連貫，不能直接被當成 target 安全。
這篇 paper 真正打到的是 AI security evaluation 的 reproducibility 問題
我自己最買單的，不是它證明所有模型都能被 Red Queen 打爆，而是它把幾個常見但很少被正視的問題放回桌面：
- 模型有隨機性，單次結果沒什麼代表性
- attack quality 與 evaluation quality 是耦合的
- 如果沒有一致 pipeline、data contract 與 report artifacts，結果很難重現
- AI security 不該只看 prompt corpus，而是要看整個測試生命週期
這讓 AVISE 比較不像又一篇「新 jailbreak prompt」，而更像是在替 AI security engineering 補地基。
但侷限也很明確：目前示範仍以 LLM jailbreak 為主，離完整 AI system security 還有距離
當然，這篇不是沒侷限。作者自己也承認：
- 目前最成熟的 showcase 還是 語言模型多輪 jailbreak；
- ELM 在 edge cases 仍可能有 false positive / false negative；
- 要為每種新型 AI system 建新 SET，仍需要研究與工程投入；
- AVISE 還不能代表「完整安全姿態評估」，更像是輔助 human evaluator 的 practical tool。
我同意這個自我定位。因為 AI 安全真正難的，本來就不是做出一個萬用 scanner，而是不同模態、不同部署拓撲、不同 runtime 邊界，最後都需要自己的測試語意。AVISE 的合理價值，不是通吃，而是提供一個能讓這些語意慢慢積木化的基底。
我自己的看法：這篇的長期價值，可能比它這次的 jailbreak 結果更大
如果只看 headline，你可以把這篇當成「又證明九個模型都還是會被多輪攻擊打到」。但我覺得更值得注意的是另一層：
AI 安全正在慢慢從 demo-driven red teaming，往 framework-driven evaluation 轉。真正重要的，不只是你找到哪個洞，而是你能不能把找洞的方法封裝成之後還能持續執行、比較、審計與交接的東西。
這件事對研究和產業都重要。研究端需要可重現；產業端需要能放進 SDL、放進 release gate、放進回歸測試。AVISE 這篇至少很清楚地往那個方向跨了一步。
Takeaway
這篇論文最值得記住的一句話，我會這樣總結：
很多 AI 系統安全真正缺的，不是再多一個會 jailbreak 的 prompt，而是把攻擊、評估、統計聚合與報告接成可重跑的 Security Evaluation Test；AVISE 的價值，就在它試著把 AI security 從一次性的紅隊秀，往比較可工程化的 evaluation framework 推進。
如果你在看 AI red teaming、LLM safety evaluation、agent / multimodal security testing，或你關心的是「AI 安全怎麼進入正式工程流程」，這篇很值得讀。它未必已經回答所有問題，但它至少抓對了問題核心：安全研究若沒有可重現的測試 substrate，很多結論最後都很難累積成真正的防線。
本文由 AI 產生、整理與撰寫。