規劃大型語言模型及其應用程式的紅色小組
本指南提供一些潛在策略，以規劃如何在整個大型語言模型 （LLM） 產品生命週期中設定及管理負責任 AI（RAI） 風險的紅色小組。
什麼是紅色小組？
Red Teaming 一詞過去用於描述測試安全性弱點的系統化對抗性攻擊。 隨著 LLM 的使用情形增加，此詞彙不再侷限於傳統網路安全性領域，演變為描述 AI 系統多種探查、測試和攻擊的常見用法。 使用 LLM 時，無論是良性或對抗性使用方式都可能產生潛在的有害輸出，包括許多不同輸出形式，例如仇恨言論、煽動或美化暴力或性內容等有害內容。
為什麼 RAI 紅隊是一個重要的做法？
紅色小組是使用 LLM 負責開發系統和功能的最佳作法。 儘管不能取代系統化測量和風險降低工作，但 Red Team 人員可以協助找出及識別危害，從而啟用測量策略來驗證風險降低的有效性。
雖然 Microsoft 已針對其 Azure OpenAI 服務模型執行紅色小組練習並實作安全系統（包括內容篩選和其他風險降低策略），但每個 LLM 應用程式的內容將是唯一的，您也應該進行紅色小組處理：
根據應用程式的內容，測試 LLM 基底模型，並判斷現有安全系統中是否有間距。
識別並緩解現有預設篩選或風險降低策略中的缺點。
提供失敗的意見反應，以便進行改進。
請注意，紅色小組不是系統測量的替代專案。 最佳做法是先完成一輪手動紅色小組，再進行系統測量並實作緩和措施。 如上所述，RAI 紅隊的目標是識別傷害、了解風險表面，以及開發可通知需要測量和減輕哪些傷害的清單。
以下說明如何開始和規劃您的紅色小組 LLM 程式。 想讓 Red Teaming 練習更具生產力，事前規劃便是關鍵所在。
測試之前
計劃：神秘 會執行測試
組合一群不同的紅隊員
針對產品領域，決定紅色小組成員在人員經驗、人口統計和專業知識方面的理想組合（例如 AI 專家、社會科學、安全性）。 例如，如果您正在設計一款能幫助醫療保健提供者的聊天機器人，醫療專家可以協助識別該領域的風險。
以良性和對抗思維招募紅色小組員
招募具有對抗性心態和安全性測試經驗的 Red Team 成員對於了解安全性風險而言至關重要，而身為應用程式系統的一般使用者且尚未參與相關開發的 Red Team 成員，則可針對一般使用者可能遇到的危害帶來寶貴觀點。
將紅色小組人員指派給傷害和/或產品功能
指派具有特定專業知識的 RAI 紅色小組人員來探查特定類型的傷害（例如，安全性主題專家可以調查越獄、中繼提示擷取，以及與網路攻擊相關的內容）。
針對多輪測試，決定是否要在每一輪切換紅色小組工作分派，以針對每個傷害取得不同的觀點，並維持創造力。 如果切換指派，請讓紅隊員在新指派的傷害指示上加快速度。
在稍後階段，當應用程式及其UI開發時，您可能會想要將紅色小組指派給應用程式的特定部分（亦即功能），以確保整個應用程式的涵蓋範圍。
請考慮每個紅隊員應該投入多少時間和精力（例如，針對良性案例的測試可能需要比對立案例測試更少的時間）。
為紅色小組提供下列專案很有説明：
- 清除可能包含下列指示：
- 描述指定一輪紅隊用途和目標的簡介：將測試的產品和功能，以及如何存取它們;要測試的問題種類;紅色小組的焦點區域，如果測試更針對性;每個紅隊員在測試上應該花費多少時間和精力：如何記錄結果;和誰聯繫問題。
- 用來記錄其範例和結果的檔案或位置，包括下列資訊：
- 顯示範例的日期;如果可用，則為輸入/輸出組的唯一標識符，以供重現之用;輸入提示;輸出的描述或螢幕快照。
計劃：要測試的專案
由於應用程式是使用基底模型開發，您可能需要在數個不同的層級進行測試：
LLM 基底模型及其安全性系統已就緒，可識別應用程式系統內容中可能需要解決的任何缺口。 （測試通常是透過 API 端點完成。
您的應用程式。 （測試最好透過UI完成。
LLM 基底模型和您的應用程式，在風險降低之前和之後都已就緒。
下列建議可協助您在紅色小組期間選擇要在各種點測試的專案：
您可以從測試基底模型開始了解風險表面、識別危害，以及引導開發產品的 RAI 風險降低措施。
使用和不使用 RAI 風險降低來反覆測試產品版本，以評估 RAI 風險降低的有效性。 （請注意，手動紅隊可能還不夠評估—也使用系統測量，但只有在完成初始一輪手動紅隊處理之後。
盡可能在生產 UI 上對應用程式進行測試，因為這最類似於真實世界的用法。
報告結果時，請清楚說明哪些端點用於測試。 在產品以外的端點中完成測試時，請考慮在未來回合中再次在生產端點或 UI 上進行測試。
計劃：如何測試
進行開放式測試，以發現各種傷害。
RAI 紅隊員探索和記錄任何有問題的內容的好處（而不是要求他們找到特定傷害的範例），讓他們能夠創造性地探索各種問題，在了解風險表面時發現盲點。
從開放式測試建立傷害清單。
- 請考慮建立傷害清單，其中包含傷害的定義和範例。
- 在稍後的幾輪測試中，將此清單作為紅色小組的指導方針。
進行引導式紅隊和反覆運算：繼續調查清單中的傷害：識別表面的新危害。
如果有的話，請使用危害清單，並繼續測試已知危害及其風險降低的有效性。 在這個過程中，您可能會識別出新的危害。 將這些專案整合到清單中，並開放以轉移測量和緩和優先順序，以解決新識別的危害。
規劃要優先進行反覆測試的危害。 有幾個因素可以通知您的優先順序，包括但不限於傷害的嚴重性，以及它們更有可能浮出水面的內容。
規劃：如何記錄數據
決定您需要收集的數據，以及哪些數據是選擇性的。
決定紅隊員需要記錄哪些數據（例如，所使用的輸入;系統的輸出;如果有的話，唯一標識符，在未來重現範例;以及其他附注。
請策略性地瞭解您收集哪些數據，以避免大量紅隊員，同時不會遺漏重要資訊。
建立數據收集的結構
共用 Excel 電子錶格通常是收集紅色小組數據的最簡單方法。 此共用檔案的優點是，紅色小組人員可以檢閱彼此的範例，以取得自己的測試創意，並避免重複數據。
測試期間
規劃在紅隊進行時處於作用中待命狀態
- 準備好協助紅隊員處理指示和存取問題。
- 監視電子錶格上的進度，並將及時提醒傳送給紅色小組。
每一輪測試之後
報表數據
定期與重要項目關係人分享簡短報告，讓項目關係人：
列出最上層的已識別問題。
提供原始數據的連結。
預覽即將進行的回合測試計劃。
認可紅色小組。
提供任何其他相關信息。
區分識別和測量
在報告中，請務必澄清 RAI 紅隊的作用是公開和提高對風險表面的認識，而不是系統測量和嚴格的緩和工作。 重要的是，人們不會將特定範例解譯為這種傷害普遍的計量。
此外，如果報表包含有問題的內容和範例，請考慮包含內容警告。
本檔中的指導方針不應被解釋為提供法律建議。 您正在運作的司法管轄區可能會有適用於 AI 系統的各種法規或法律需求。 請注意，並非所有建議都適用於每個案例，相反地，這些建議可能不足以用於某些案例。