安全指南

大型語言模型 (LLM) 的實用性之一，就是能處理多種不同語言工作的創意工具。遺憾的是，這也表示大型語言模型可以產生您不想要的輸出內容，包括令人反感、不敏感或事實有誤的文字。此外，這些模型的靈活性更勝以往，也導致難以準確預測可能產生的不理想的輸出內容類型。雖然 Gemini API 的設計符合 Google 的 AI 原則，但開發人員是以負責任的方式套用這些模型。為協助開發人員建立安全且負責任的應用程式，Gemini API 內建內容篩選功能，並提供 4 種傷害可調整的安全設定。詳情請參閱安全設定指南。

本文件旨在向您介紹使用 LLM 時可能產生的一些安全風險，並建議新興的安全設計與開發建議。(請注意，法律和法規也可能設有限制，但這類考量不在本指南的範圍內)。

使用 LLM 建構應用程式時，建議執行下列步驟：

• 瞭解應用程式的安全性風險
• 考慮調整以降低安全風險
• 根據您的用途執行安全測試
• 向使用者徵求意見回饋及監控使用情形

調整和測試階段應該反覆進行，直到您達到應用程式的效能為止。

瞭解應用程式的安全性風險

在這種情況下，安全性是指 LLM 能避免對使用者造成傷害的能力，例如產生惡意語言或推廣刻板印象的內容。Gemini API 提供的模型皆遵循 Google 的 AI 原則設計，使用時必須遵守《生成式 AI 使用限制政策》。這個 API 提供內建安全性篩選器，可協助解決常見的語言模型問題，例如惡意語言、仇恨言論，以及鎖定多元包容度並避免刻板印象。不過，每個應用程式可能會為其使用者帶來不同的風險。因此，應用程式擁有者有責任瞭解使用者，以及應用程式可能造成的潛在危害，並確保應用程式以安全且負責任的方式使用 LLM。

在評估過程中，您應考量受損的可能性，並確定其嚴重性和緩解步驟。舉例來說，如果應用程式會根據事實事件產生短文，比起產生虛構的娛樂故事的應用程式，需要更謹慎地防範錯誤資訊。如果想開始探索潛在的安全風險，最好的方式是研究使用者，以及可能受到應用程式結果影響的其他使用者。這可能有多種形式，包括研究應用程式領域的藝術研究狀態、觀察使用者如何使用類似應用程式，或是進行使用者研究、調查，或與潛在使用者進行非正式的訪談。

考慮調整以降低安全風險

瞭解風險後，您就可以決定如何降低風險。您必須判斷要優先處理哪些風險，以及應該採取哪些行動來防範這些風險，這一點非常重要，就像在軟體專案中分類錯誤一樣。決定優先順序後，即可開始思考最合適的緩解措施類型。簡單的改變通常能帶來改變並降低風險。

舉例來說，設計應用程式時，請考慮使用：

• 調整模型輸出，更準確地反映應用程式結構定義的可接受內容。調整會使模型輸出更加可預測且一致，因此有助於降低特定風險。
• 提供輸入方式，確保輸出作業更加安全。您提供給 LLM 的確切輸入內容，可能會影響輸出內容的品質。多方嘗試輸入提示，找出在應用實例中最安全的做法，因為您可以藉此提供較有利的使用者體驗。例如，您可以限制使用者只能從輸入提示的下拉式清單中選擇，或是提供彈出式建議，並提供您認為在應用程式使用情境中安全無虞的描述性詞組。

• 在向使用者顯示之前，封鎖不安全的輸入及篩選輸出內容。在簡單的情況下，封鎖清單可用來識別及封鎖提示或回應中不安全的字詞或詞組，或是要求人工審查員手動修改或封鎖這類內容。

• 使用經過訓練的分類器，為每個提示加上潛在危害或惡意信號的標籤。然後，可以依據偵測到的損害類型，採用不同的策略來處理要求。舉例來說，如果輸入內容過於惡意或濫用，可能會遭到封鎖，改為輸出預先撰寫的回應。

  進階提示

  • 如果信號判定輸出內容有害，應用程式可以使用下列選項：
    • 提供錯誤訊息或事前腳本的輸出內容。
    • 請嘗試再次提示，以在產生替代安全輸出的情況下進行，因為有時相同的提示會引入不同的輸出內容。

• 採取保護措施來防止誤用，例如為每位使用者指派專屬 ID，以及限制特定期間內可提交的使用者查詢量。另一個保護措施是嘗試並防範可能的提示插入行為。與 SQL 插入類似，「提示插入」是一種惡意使用者，能夠設計用來操控模型輸出內容的輸入提示，例如傳送輸入提示，指示模型忽略先前的任何範例。如需故意濫用政策，請參閱《生成式 AI 使用限制政策》。

• 將功能調整到原本可以降低風險的項目。如果工作的範圍較窄 (例如從文字段落中擷取關鍵字)，或工作較受監督 (例如產生人工審查的簡短內容)，通常的風險通常較低。例如，您不應建立應用程式來從頭撰寫電子郵件回覆，而應改為限制其以大綱擴展或建議替代的措辭。

根據您的用途執行安全測試

測試是建構強大安全應用程式的重要環節，但測試範圍、測試範圍與策略可能有所不同。例如，相較於律師事務所設計用來提供法律文件和協助草擬合約的應用程式，一般特殊的 haiku 產生器不太可能承擔更嚴重的風險。但有較多的使用者可能會使用 haiku 產生器，這意味著對惡意嘗試或意外有害的輸入可能更大。實作情境也很重要。例如，相較於未經這類監督，如果應用程式具有輸出內容，並在任何動作發生前先行審查，則與相同應用程式產生有害輸出內容的可能性較低。

即使應用程式風險相對較低，再進行幾次變更與測試，即有可能準備好要發布。兩種測試特別適合用於 AI 應用程式：

• 安全基準化包括設計安全性指標，以反映應用程式可能在使用情境下的可能不安全方式，然後使用評估資料集測試應用程式在指標上的表現。建議您在測試前思考可接受的最低安全指標層級，以便 1) 根據這些期望評估測試結果；2) 根據您最重視的指標，評估測試資料集來收集評估資料集。

  進階提示

  • 請避免過度依賴「現成」方法，因為您可能需要使用評估人員建構自己的測試資料集，以符合應用程式情境。
  • 如果您有多個指標，則必須決定當某項變更導致某項指標的成效降低時，要如何取捨。與其他效能工程一樣，建議您關注整個評估集的最壞成效，而非平均效能。

• 對抗性測試包括主動嘗試破壞應用程式。目標是找出弱點，以便您可以採取適當措施加以修復。對抗性測試可能花費大量時間/精力，這需要具備應用程式專業知識的評估人員會花費大量時間/心力，但您的提案越多，找出問題的機會就越大，尤其是在重複執行應用程式之後，或只有在重複執行應用程式之後才會發現問題。

  • 對抗性測試是一種有系統性評估機器學習模型的方法，目的在於學習透過惡意或無意間有害的輸入內容，而預測模型的行為：
    • 如果輸入內容明確設計成會產生不安全或有害的輸出內容，例如要求文字生成模型針對特定宗教的產生仇恨性言論，輸入內容就可能是惡意的。
    • 如果輸入內容本身可能無害，但會產生有害的輸出內容，例如要求文字生成模型描述特定族裔及接收種族主義者的輸出內容，就會對輸入內容造成無意的影響。
  • 對抗性測試和標準評估的不同之處在於用於測試的資料組合。針對對抗性測試，請選取最有可能從模型中擷取有問題輸出的測試資料。這意味著偵測模型的行為是否有任何可能的危害類型，包括罕見或不尋常的示例，以及與安全性政策有關的極端情況。還要包括語句不同維度 (如結構、含意和長度) 的多元性。您可以參閱「Google 的負責任 AI 技術實踐」，進一步瞭解建構測試資料集時應考量的事項。

    進階提示

    • 請嘗試使用自動化測試，而不是用「紅隊演練」人員的傳統方法，嘗試使應用程式故障。在自動化測試中，「紅隊」是另一種語言模型，會在測試範圍內尋找並移除有害輸出內容。

監控問題

無論您的測試量多高，都無法保證完美無缺，因此應預先規劃您將如何發現及處理可能發生的問題。常見的做法包括設定受監控的管道，讓使用者分享意見回饋 (例如表示喜歡/不喜歡)，以及進行使用者研究，主動徵求不同使用者的意見。如果使用模式與預期不同，這就特別重要。

後續步驟

• 請參閱安全性設定指南，瞭解 Gemini API 中可用的可調整安全性設定。
• 如要開始編寫第一個提示，請參閱提示簡介。