DeepTeam 單回合紅隊測試：LLM 弱點與防護指南

想知道語言模型會不會洩漏提示、產生偏見或被不當指令帶偏，不能只問幾個「看起來正常」的問題。DeepTeam 是一套開源的 LLM 紅隊測試框架，能把漏洞類型、攻擊方法、模型回應與評估結果整理成可重跑的測試。本文把原本「用十多種攻擊找弱點」的主題，更新成安全、可實作的單回合測試指南：不公開可濫用的攻擊字串，而是說明如何在獲得授權的測試環境中找問題、修補並回歸驗證。

先釐清：漏洞、攻擊方法與測試案例不是同一件事

紅隊測試最容易混淆的地方，是把「漏洞名稱」當成「攻擊指令」。在 DeepTeam 的模型中，漏洞代表要檢查的失效行為；攻擊方法是用來改變測試輸入的策略；測試案例則是一次實際執行的輸入、輸出、評分與上下文。把三者分開，結果才有辦法比較，也不會為了湊數而測一堆與產品無關的案例。

項目	它回答的問題	例子（僅描述目的）
漏洞（vulnerability）	模型或應用程式哪一種行為不安全？	提示洩漏、PII 洩漏、偏見、錯誤資訊
攻擊方法（attack）	如何在不改變測試目標的前提下變化輸入？	角色扮演、編碼、語言轉換、權威升級
測試案例（test case）	這一次輸入造成什麼輸出，是否通過判定？	輸入、模型回應、漏洞、評估理由與分數

這種分層也能避免「攻擊方法越多就越安全」的誤解。攻擊變形只是增加覆蓋率；真正重要的是測到與產品風險相符的漏洞，並且能在修補後重跑同一組測試。

單回合測試能回答什麼，不能回答什麼？

單回合測試通常是一個輸入配一個輸出，適合先隔離模型本身的行為。它可以協助回答：模型是否透露系統提示的內容、是否對特定族群產生不公平回應、是否在要求個資時缺乏拒答、是否捏造沒有根據的資訊。這也是原文章所說的「OpenAI 單回合攻擊」較準確的解讀：測的是一個模型回呼，不是整個產品。

但單回合不是完整安全證明。只要產品包含對話記憶、RAG 檢索、外部工具、使用者權限或多步代理流程，就必須另外做多回合與應用層測試。單回合結果應該被視為基線，不能宣稱「模型已經安全」。

測試範圍	單回合可觀察的部分	需要另外測的部分
純模型回呼	輸入到輸出的偏見、毒性、提示洩漏、錯誤資訊	長期漂移、版本升級後的差異
RAG 問答	模型對單一情境的回答與引用習慣	檢索邊界、文件注入、權限隔離、資料外洩
工具型代理	單次指令下的拒答與輸出格式	工具授權、越權、連續步驟、失敗復原

DeepTeam 的安全測試流程

1. 先限定目標與授權範圍

只在自己擁有或明確獲得授權的模型與測試端點上執行。建立獨立的測試專案、測試金鑰與資料集，避免把紅隊輸入送到正式服務；也不要把真實客戶個資放進測試。先寫下停止條件，例如偵測到真實個資、服務成本超過上限或模型回應涉及高風險內容時立即停止。

2. 用產品風險挑選漏洞

DeepTeam 支援多種漏洞類型與框架對照，但不代表每個專案都要全部開啟。聊天機器人可以先檢查偏見、毒性、提示洩漏與錯誤資訊；處理客服資料則加上 PII 洩漏；有工具或權限時，再檢查越權與不當工具使用。把選擇理由寫進測試設定，日後才能解釋為什麼某類風險沒有測。

3. 產生基線探針，再套用攻擊變形

框架會先依漏洞產生基線測試，再用攻擊方法改變表達方式。這些變形可以是角色扮演、不同語言、編碼、情緒操弄或把請求放入較長的上下文；文章只描述測試類別，不提供可直接濫用的提示字串。每一類先跑小批量，確認評估器與模型回呼正常，再逐步提高數量。

4. 讓評估結果可解釋、可重跑

DeepTeam 的 RiskAssessment 會按漏洞與攻擊方法整理通過、失敗與錯誤。對需要模型評審的項目，應保留評估理由與原始回應的雜湊或受控存檔，而不是只記一個總分。若評估器與人工判定不同，先標記為待審，不要為了讓通過率好看而刪掉案例。

5. 修補後重新執行同一組案例

紅隊發現問題後，修補可能位於系統提示、輸入驗證、工具授權、輸出過濾或 RAG 邊界。修補完成要重跑原本失敗的案例，並確認沒有讓其他能力退化；這一步才把一次性的攻擊示範變成可持續的回歸測試。

用最小設定開始，而不是一次開滿所有攻擊

DeepTeam 可以接收自訂的模型回呼，因此不只限於 OpenAI。下面是概念性的 Python 片段，展示如何選擇漏洞與攻擊類別；測試輸入由框架在隔離環境中產生，本文不放置可直接套用的攻擊內容。

from deepteam import red_team
from deepteam.vulnerabilities import Bias, PromptLeakage
from deepteam.attacks.single_turn import PromptInjection

risk = red_team(
    model_callback=your_callback,
    vulnerabilities=[Bias(), PromptLeakage()],
    attacks=[PromptInjection()],
    attacks_per_vulnerability_type=5,
)

實際使用前，請依目前 DeepTeam 版本的文件確認匯入路徑與回呼介面。第一次執行建議把每個漏洞的案例數設小，先確認成本、延遲、評估器與輸出保存策略，再擴大覆蓋。

「10+ 攻擊方法」應該怎麼理解？

數量不是目標。較好的做法是把方法視為測試維度，搭配與產品相關的漏洞，而不是對同一個模型無限重複。下表是防禦性分類，刻意不列出可操作的 payload：

方法類別	要觀察的風險	對應防護方向
直接指令與提示注入	模型是否忽略既定規則	指令分層、輸入分隔、輸出政策檢查
角色扮演與權威升級	是否因「管理員／研究者」語境而放寬限制	權限不可由文字自稱決定，改由後端授權
編碼與語言轉換	過濾器是否只支援單一語言或格式	正規化、跨語言測試與多層判定
長上下文與合成情境	規則在較長內容後是否失效	上下文長度限制、來源標記、重點規則重申
情緒、急迫與社交操弄	模型是否因壓力語氣而跳過安全檢查	固定政策、人工升級與風險分級
格式、數學或工具包裝	危險意圖被藏在另一種輸出格式	先判斷意圖，再處理格式與工具呼叫

依系統類型安排測試覆蓋

測試清單應該反映系統真正能做的事。對沒有工具的文字模型，優先確認輸出安全與資訊可靠性；對 RAG 或代理，則要把資料來源和權限邊界納入測試，而不能只看模型答得像不像。

系統	第一批單回合檢查	下一階段
公開聊天機器人	偏見、毒性、提示洩漏、錯誤資訊	多語言、速率限制、人工升級
企業 RAG	資料引用、提示洩漏、PII	文件注入、租戶隔離、權限回歸
工具型代理	單次輸入的拒答與工具意圖	越權、工具參數、連續步驟與復原
模型 API	不同輸入格式下的政策一致性	版本漂移、流量尖峰、成本與濫用監控