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