安全指南

生成式人工智慧模型功能強大，但仍有其限制。有時可能會產生不準確、有偏見或令人反感的輸出內容。後續處理和嚴格的手動評估是必要程序，可降低這類輸出內容造成危害的風險。

Gemini API 提供的模型可用於各種生成式 AI 和自然語言處理 (NLP) 應用程式。如要使用這些功能，只能透過 Gemini API 或 Google AI Studio 網頁應用程式。使用 Gemini API 時，也必須遵守《生成式 AI 使用限制政策》和《Gemini API 服務條款》。

大型語言模型 (LLM) 之所以如此實用，是因為這類模型是創意工具，可處理許多不同的語言工作。但這也代表大型語言模型可能會生成預期外的內容，包括令人反感、未顧及感受或與事實不符的文字。此外，這些模型功能強大，但也因此難以準確預測可能產生哪些不當輸出內容。雖然 Gemini API 的設計符合 Google 的 AI 原則，但開發人員仍有責任以負責任的方式運用這些模型。為協助開發人員建立安全可靠的應用程式，Gemini API 內建內容篩選功能，並提供可調整的安全設定，涵蓋 4 個危害層面。詳情請參閱安全設定指南。

本文旨在介紹使用大型語言模型時可能出現的一些安全風險，並提供新興的安全設計和開發建議。(請注意，法律和法規也可能設下限制，但這類考量不在本指南的討論範圍內)。

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

• 瞭解應用程式的安全風險
• 考慮調整內容，以降低安全風險
• 根據用途執行適當的安全測試
• 徵求使用者意見回饋及監控使用情況

您應反覆調整及測試，直到達到適合應用程式的效能為止。

瞭解應用程式的安全風險

在此情境中，安全是指 LLM 避免對使用者造成傷害的能力，例如生成惡意語言或宣揚刻板印象的內容。Gemini API 提供的模型是按照 Google 的 AI 開發原則設計，使用時須遵守《生成式 AI 使用限制政策》。這項 API 提供內建安全篩選器，可協助解決一些常見的語言模型問題，例如有害語言和仇恨言論，並盡量避免出現刻板印象，以求包容性。不過，每項應用程式都可能對使用者造成不同的風險。因此，身為應用程式擁有者，您有責任瞭解使用者和應用程式可能造成的潛在危害，並確保應用程式安全且負責任地使用大型語言模型。

評估時，請考量損害發生的可能性，並判斷損害的嚴重程度和減輕損害的步驟。舉例來說，如果應用程式會根據真實事件生成文章，就必須比生成虛構故事的娛樂應用程式更謹慎，避免提供錯誤資訊。如要開始探索潛在安全風險，建議先研究您的使用者，以及可能受到應用程式結果影響的其他對象。這類研究的形式有很多種，包括研究應用程式領域的最新研究、觀察使用者如何使用類似應用程式，或是進行使用者研究、問卷調查，或與潛在使用者進行非正式訪談。

考慮調整內容，降低安全風險

瞭解風險後，您就能決定如何降低風險。決定優先處理哪些風險，以及應採取多少措施來防範這些風險，是至關重要的決策，類似於軟體專案中的錯誤分類。確定優先順序後，即可開始思考最合適的緩解措施類型。通常只要稍做調整，就能降低風險。

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

• 調整模型輸出內容，使其更符合應用程式環境的接受標準。微調可讓模型輸出內容更具可預測性及一致性，因此有助於降低特定風險。
• 提供有助於生成安全輸出內容的輸入方式。您提供給 LLM 的確切輸入內容，可能會影響輸出內容的品質。建議您嘗試使用輸入提示，找出最適合您用途的安全做法，然後提供有助於此做法的使用者體驗。舉例來說，您可以限制使用者只能從輸入提示的下拉式清單中選擇，或是提供彈出式建議，其中包含您在應用程式環境中發現可安全執行的描述性片語。

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

• 使用經過訓練的分類器，標記可能包含有害或對抗信號的提示。然後您就能根據偵測到的危害類型，運用不同策略處理要求。舉例來說，如果輸入內容明顯含有對抗或濫用意圖，系統可能會封鎖該內容，並輸出制式回覆。

  進階提示

  • 如果訊號判斷輸出內容有害，應用程式可以採用下列選項：
    • 提供錯誤訊息或制式輸出內容。
    • 請再次嘗試使用提示，因為有時相同的提示會產生不同的輸出內容，或許會生成其他安全輸出內容。

• 採取防範措施，避免遭到蓄意濫用，例如為每位使用者指派專屬 ID，並限制特定時間內可提交的使用者查詢量。另一項安全措施是盡量防範可能的提示詞注入攻擊。提示植入與 SQL 植入非常相似，惡意使用者可設計輸入提示來操縱模型輸出內容，例如傳送輸入提示，指示模型忽略先前的任何範例。如要進一步瞭解蓄意濫用行為，請參閱「生成式 AI 使用限制政策」。

• 將功能調整為本質上風險較低的項目。 範圍較窄的任務 (例如從文字段落中擷取關鍵字)，或需要大量人工監督的任務 (例如生成短片內容，並由專人審查)，通常風險較低。舉例來說，您可能不會從頭建立應用程式來撰寫電子郵件回覆，而是限制應用程式擴充大綱或建議替代措辭。

根據用途執行適當的安全測試

測試是建構安全可靠應用程式的重要環節，但測試的程度、範圍和策略會有所不同。舉例來說，與專供律師事務所使用的應用程式 (可摘要法律文件及協助草擬合約) 相比，純粹娛樂用的俳句產生器造成的風險可能較小。但俳句生成器可能供更多使用者使用，這表示出現對抗性嘗試或甚至無意間輸入有害內容的可能性更高。實作背景也很重要。舉例來說，如果應用程式的輸出內容會先經過專家審查，再採取任何行動，則相較於沒有這類監督機制的相同應用程式，這類應用程式產生有害輸出內容的可能性較低。

即使是風險相對較低的應用程式，您也可能需要經過多次反覆變更和測試，才能確信已準備好發布。有兩種測試特別適合用於 AI 應用程式：

• 安全基準測試包括設計安全指標，反映應用程式在可能的使用情境中不安全的方式，然後使用評估資料集測試應用程式在指標上的表現。建議您在測試前先考量安全指標的最低可接受程度，這樣一來，您就能根據這些期望評估測試結果，並根據評估最重要指標的測試收集評估資料集。

  進階提示

  • 請勿過度依賴「現成」方法，因為您可能需要使用人工評估人員建立自己的測試資料集，才能完全符合應用程式的環境。
  • 如果有多個指標，您需要決定如何取捨，因為變更可能改善某項指標，但對其他指標不利。與其他成效工程一樣，您可能想著重於評估集中的最差情況成效，而非平均成效。

• 對抗測試是指主動嘗試破壞應用程式，目標是找出弱點，以便採取適當的補救措施。對抗性測試可能需要評估人員投入大量時間/精力，但測試次數越多，就越有機會發現問題，尤其是很少發生或只在重複執行應用程式後才會發生的問題。

  • 對抗測試是一種系統性評估方法，用來瞭解使用者輸入惡意提示，或無意間輸入有害提示時，機器學習模型會有什麼行為：
    • 惡意輸入內容是為了產生不安全或有害結果，而刻意設計的內容。舉例來說，要求文字生成模型針對特定宗教生成仇恨言論。
    • 非故意的有害輸入內容本身可能無害，但會生成有害的輸出內容，例如要求文字生成模型描述特定族裔的人，而模型提供的輸出內容帶有種族歧視。
  • 對抗測試與標準評估的不同之處，在於測試所用的資料組成。如果是對抗測試，請選取最有可能導致模型產生問題輸出的測試資料。也就是說，要探究模型可能造成的各種危害，包括與安全政策相關的罕見或異常範例和極端案例。此外，也應包含句子不同層面的多樣性，例如結構、意義和長度。如要進一步瞭解如何建構測試資料集，請參閱 Google 的 Responsible AI 做法，確保公平性。

    進階提示

    • 使用自動化測試，而非傳統的「紅隊」人員招募方式，嘗試破解應用程式。在自動測試中，「紅隊」是另一個語言模型，負責找出會導致受測模型產生有害輸出的輸入文字。

監控問題

無論測試和減輕多少，您永遠無法保證完美，因此請預先規劃如何發現及處理發生的問題。常見做法包括設定監控管道，供使用者分享意見回饋 (例如按讚/倒讚評分)，以及進行使用者研究，主動向各種使用者徵求意見回饋，如果使用模式與預期不同，這項做法就特別有價值。

後續步驟

• 請參閱安全設定指南，瞭解如何透過 Gemini API 調整安全設定。
• 請參閱提示簡介，開始撰寫第一個提示。