安全指南

生成式人工智慧模型是很強大的工具，但同時符合這些模型的限制。其多功能性和適用性有時可能會導致非預期的輸出內容，例如不準確、偏誤或令人反感的輸出內容。進行後續處理和嚴謹的手動評估，是限制這類輸出內容造成傷害的風險。

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

大型語言模型 (LLM) 的實用性之一，就是提供可處理許多不同語言任務的廣告素材工具。遺憾的是，這也表示大型語言模型可能產生非預期的輸出內容，包括令人反感、不敏感或與事實不符的文字。此外，這些模型的靈活性也使您難以準確預測可能產生的不理想輸出內容類型。雖然 Gemini API 是依據 Google 的 AI 開發原則而設計，但開發人員仍須以負責任的方式套用這些模型。為協助開發人員建立安全且負責任的應用程式，Gemini API 內建內容篩選功能，以及可調整安全性設定的 4 個層面。詳情請參閱安全設定指南。

本文件旨在說明使用 LLM 時可能會出現一些安全風險，並提供新興的安全設計和開發建議。(請注意，法律和法規也可能施加限制，但這類考量不在本指南的涵蓋範圍內)。

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

• 瞭解應用程式的安全風險
• 考慮進行調整以降低安全風險
• 針對您的用途執行適當的安全測試
• 向使用者徵求意見回饋並監控使用情況

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

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

在此情況下，「安全性」的定義是 LLM 避免對使用者造成危害的能力，例如：產生鼓吹刻板印象的惡意用語或內容。Gemini API 提供的模型符合 Google 的 AI 開發原則，因此使用時必須遵守《生成式 AI 使用限制政策》。API 提供內建安全性篩選器，可協助解決某些常見的語言模型問題，例如惡意用語和仇恨言論，並致力確保多元包容與避免刻板印象。但是，每個應用程式可能會對使用者造成不同的風險。因此，身為應用程式擁有者，您必須負責瞭解使用者，以及應用程式可能造成的潛在危害，並確保應用程式以安全且負責任的方式使用 LLM。

在評估過程中，您應考量可能造成傷害的可能性，並判斷其嚴重性和緩解步驟。例如，與生成虛構娛樂報導的應用程式相比，根據事實事件產生論文的應用程式必須更小心，才能避免不實資訊。若要開始探索潛在安全風險，一個不錯的方法是研究使用者，以及可能受應用程式結果影響的其他人。這有多種形式，包括研究應用程式網域中的藝術研究狀態、觀察使用者如何使用類似應用程式，或與潛在使用者進行使用者研究、問卷調查或進行非正式訪談。

考慮採取調整來降低安全風險

現在您已瞭解相關風險，接著就能決定如何降低風險。判斷要優先處理哪些風險，以及應採取哪些行動來避免這些風險是一項關鍵決定，類似分類軟體專案中的錯誤。決定優先順序後，就可以開始思考最適合的緩解類型。簡單的改變通常能帶來差異，並降低風險。

舉例來說，設計應用程式時會考量以下因素：

• 調整模型輸出內容，更準確地反映應用程式結構定義可接受的內容。調整模型可讓模型的輸出內容更容易預測且一致，進而有助於降低特定風險。
• 提供的輸入法提供更安全的輸出內容。提供給 LLM 的確切輸入內容可能會影響輸出內容品質。多方嘗試輸入提示，找出對您用途中最安全有效的方法，這麼做絕對值得，因為您才能提供有助於實現這一點的使用者體驗。舉例來說，您可以限制使用者只能從輸入提示的下拉式清單中選擇，或是以彈出式建議形式提供彈出式建議，並依照您在應用程式環境中可安全執行的敘述性詞組。

• 封鎖不安全的輸入內容，並在使用者看到輸出內容前過濾輸出內容。在簡單的情況下，封鎖清單可用來辨識及封鎖提示或回應中不安全的字詞或詞組，或要求人工審查員手動修改或封鎖這類內容。

• 使用訓練過的分類器，為每個提示加上潛在危害或惡意信號加上標籤。然後，您就可以根據偵測到的危害類型，採用不同的策略來處理要求。舉例來說，如果輸入內容過於對抗或濫用性質，可能會遭到封鎖，而改為輸出事前指令碼的回應。

  進階提示

  • 如果信號判定輸出內容是有害的，應用程式可以使用下列選項：
    • 提供錯誤訊息或預先腳本的輸出內容。
    • 如果系統產生替代的安全輸出內容，請再次輸入提示，因為有時相同的提示可能會產生不同的輸出內容。

• 防範刻意濫用的保護措施，例如為每位使用者指派專屬 ID，以及限制特定期間可提交的使用者查詢數量。另一項保護措施則是嘗試防範可能插入的提示與 SQL 插入類似，提示插入是惡意使用者設計會操控模型輸出內容的輸入提示，例如傳送輸入提示來指示模型忽略先前的任何範例。若想詳細瞭解蓄意濫用的情形，請參閱《生成式 AI 使用限制政策》。

• 將功能調整到原本不太可能降低的風險。 至於範圍較狹隘的工作 (例如從文字段落中擷取關鍵字)，或是需要較多人工監管 (例如產生會送交人工審查的簡短內容)，通常風險較低。因此，您可以限制應用程式從大綱擴展，或建議替代語句，而不必建立應用程式來撰寫從頭撰寫電子郵件回覆的內容。

針對您的用途執行適當的安全測試

測試是建構強大且安全應用程式時的重要一環，但測試的範圍、範圍和策略都有所不同。舉例來說，相較於律師事務所製作的應用程式，為法律事務提供摘要及協助草擬合約草稿，專為純粹製播車產生器提出的風險通常較低。但廣大的使用者可能會使用 Haiku 產生器，因此可能較容易被對抗，甚至是意外有害輸入。實作的情境也很重要。例如，如果應用程式在執行任何動作之前已經過專家審查，且輸出內容的輸出內容已經過專家處理，那麼在沒有受到這類監督的情況下，其產生有害輸出內容的可能性可能會降低。

即使應用程式的風險相對較低，您還是要經過多次變更及測試，才有信心地準備好發布應用程式，我們並不常見。以下兩種測試對 AI 應用程式來說特別實用：

• 「安全基準測試」需要設計安全指標，反映應用程式在可能的使用方式上可能不安全，然後使用評估資料集測試應用程式在指標上的表現。建議您在測試前，先思考可接受的最低安全指標等級，以便 1) 您可以根據這些預期評估測試結果，以及 2) 透過評估您最重視指標的測試來收集評估資料集。

  進階提示

  • 過度依賴「現成」的方法，因為您可能需要透過人工評估人員自行建構測試資料集，才能完全滿足應用程式環境的需求。
  • 如果您有多個指標，您必須決定當一項變更導致某項指標降低時，要如何取捨。就像其他效能工程一樣，建議您把重點放在評估集上最壞的成效，而非平均效能。

• 對抗性測試是指主動嘗試破壞應用程式。目標是找出弱點，以便您視情況採取措施加以修正。對手測試可能需要對您應用程式具有專業知識的評估人員花費大量的時間/心力，但越是如此，出現問題的可能性就越高，尤其是發生在極少或重複執行應用程式後才出現的問題。

  • 對抗測試是系統性評估機器學習模型的一種方法，目的是瞭解模型在提供惡意或無意中有害輸入內容時的行為：
    • 如果輸入內容清楚設計出具有不安全或有害的輸出內容，例如要求文字生成模型產生與特定宗教有關的仇恨情緒，就可能是惡意輸入內容。
    • 如果輸入內容本身可能無害，但卻產生有害的輸出內容，例如要求文字生成模型描述某個族裔的描述，並接收種族主義的輸出結果，輸入內容就會無意中傷害。
  • 對抗性測試與標準評估的區別在於用於測試的資料組合。針對對抗測試，請選取最有可能從模型產生問題輸出內容的測試資料。這表示探測模型的行為會探究所有可能的危害類型，包括與安全政策相關的罕見或異常範例，以及邊緣情況。此外，句子的不同維度也應涵蓋多元性，例如結構、意義和長度。如要進一步瞭解建立測試資料集時應考量的事項，請參閱「Google 的負責任 AI 技術做法」。

    進階提示

    • 請採用自動測試，不要採用傳統的招集「紅隊」成員的做法來嘗試運作中斷應用程式。在自動化測試中，「紅隊」是另一種語言模型，可找出輸入文字，從測試用模型中排除有害的輸出內容。

監控問題

無論您的測試和緩解多少，永遠都無法保證不盡完美，因此請事先規劃如何發現並處理可能發生的問題。常見做法包括建立受監控的管道讓使用者分享意見回饋 (例如「喜歡/不喜歡」評分)，以及執行使用者研究，主動徵求不同使用者的意見；如果使用模式與預期不同，這個做法就格外實用。

後續步驟

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