安全指南

生成式人工智慧模型是功能強大的工具 完全不受限制有時工具的靈活性和適用性 導致非預期的輸出內容，例如輸出內容不正確、有偏誤或 令人反感的內容後續處理和嚴謹的人工評估 以降低這類輸出的傷害風險

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。

進行評估時，應考量 並確定其嚴重性和緩解步驟。舉例來說 要根據事實事件產生論文的應用程式必須格外謹慎 與生成虛構的應用程式相比，致力避免不實資訊 可以帶來更有趣的體驗開始探索潛在安全風險的好方法 目的是研究使用者，以及其他可能影響你 結果。這有很多種形式，包括研究 觀察使用者運用類似應用程式的情形 或進行使用者研究、問卷調查或非正式訪談 吸引潛在使用者

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

瞭解風險後，接著就可以決定 具體做法是指示 Kubernetes 建立並維護 一或多個代表這些 Pod 的物件判斷要優先處理哪些風險，以及應採取哪些行動 這就像將軟體錯誤分類 專案。決定好要優先事項後，接下來可以開始思考 最適合採取的緩解措施通常只要稍微調整一下 並降低風險

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

• 調整模型輸出內容，更準確地反映您的 應用程式結構定義。調整模型可以提高模型的輸出內容 可預測且一致，因此有助於減輕某些風險。
• 提供的輸入法提供更安全的輸出內容。確切輸入內容 要求 LLM 回答，結果品質會更好。 嘗試輸入提示，找出效果最佳的 因此非常值得您付出心力，如此一來就能提供 提升整體效率舉例來說，您可以限制使用者只能 新增輸入提示的下拉式清單，或提供 描述性 您可以放心建立這些詞句，並在應用程式結構定義中安全地執行這些詞組。

• 在向使用者顯示安全性前，先封鎖不安全的輸入內容並篩選輸出內容 使用者。這時，封鎖清單就能用來識別 提示或回覆含有不安全的字詞或詞組，或是僅供人工審查 手動變更或封鎖這類內容。

• 使用訓練過的分類器，為每個提示加上潛在危害標籤，或 對抗信號。接著，您就能採用不同的策略 根據所偵測到的傷害類型處理要求。舉例來說，如果 輸入內容太過強烈的對抗或不當內容，因此可能會遭到封鎖 而是會輸出事前腳本的回應

  進階提示

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

• 採取保護措施來防範蓄意濫用，例如指派 每個使用者都有專屬 ID 而且使用者查詢量會受到限制 以及在特定期間提交的內容另一項保護措施是嘗試 防止出現提示插入的情況提示插入，與 SQL 類似 惡意使用者會藉此設計輸入提示 操控模型的輸出內容，例如傳送輸入提示 指示模型忽略之前的任何範例詳情請參閱 生成式 AI 使用限制政策 。

• 將功能調整到原本不太可能降低的風險。 範圍較小的工作 (例如從 文字)，或是內容較為人工監督 (例如：製作短篇影片) 送交人工審查的內容) 通常的風險較低。針對 例如，與其建立應用程式來撰寫電子郵件回覆 除了在大綱上展開 替代語句

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

測試是建構強大且安全應用程式的關鍵要素，但更進一步 範圍和測試策略都不盡相同舉例來說 和 提供法律文件摘要及協助草擬合約但 更多使用者都能使用 Haiku 產生器 可能會產生惡意企圖 甚至是非預期的有害輸入 。實作的情境也很重要。例如應用程式 相關輸出內容均已通過專家審查，才會在執行任何行動前 可能較不可能產生有害輸出內容 且不會對應用程式造成這類監督

反覆進行變更及測試有時並不常見 再對應用程式做好萬全準備， 則風險相對較低對 AI 技術來說，兩種測試特別實用 應用程式：

• 安全基準化包括設計安全指標，以反映 可能的隱密性 ，然後測試應用程式在指標上的成效 分析資料集建議您考量 可接受的安全指標，以便 1) 對照這些期望評估測試結果，以及 2) 您可以收集 評估用資料集 大致上來說

  進階提示

  • 留意過度依賴「現成」的做法，因為這麼做很有可能 您將需要自行建構測試資料集 完全配合應用程式的情境
  • 如果您有多個指標，就必須決定您希望 如果變更導致單一指標的成效提升 而負責任的 AI 技術如同其他效能工程 評估時，可能會希望將重點放在最壞情況的成效 而非平均成效

• 對抗性測試是指積極嘗試 應用程式。目的是找出弱點，有效提升執行效能 相關修正步驟。對抗測試 評估人員需要投入大量時間/心力，才能發揮您的專業。 但活動越多，發現問題的可能性就越大 尤其是很少出現，或是只會在重複執行 應用程式。

  • 對抗測試是一種系統性評估機器學習的方式 意圖學習 惡意或無意中有害的輸入內容：
    • 如果輸入內容清楚設計為惡意輸入來源， 產生不安全或有害的輸出內容，例如詢問使用者要求 生成模型產生「仇恨」 宗教
    • 輸入內容本身 無害，但產生有害輸出內容，例如 模型描述特定族裔的 卻收到不起種族的偏見
  • 對抗性測試與標準評估的區別在於 測試用的資料組合若要進行對抗測試，請選取 最有可能產生問題輸出內容的 模型這代表模型針對所有 可能造成的傷害，包括罕見或不尋常的例子 或遇到與安全政策相關的邊緣案例這應包含 語句不同維度的多樣性，例如結構 意義和長度您可以參閱「Google 負責任的 AI 技術 做法 公平性 。

    進階提示

    • 使用 自動化測試 而不是使用傳統方式 將「紅隊」成員 來嘗試修復應用程式在自動測試中 「紅隊」是另一種語言模型，可找出 從測試模型中取得有害輸出內容
  ，瞭解如何調查及移除這項存取權。

監控問題

無論您的測試與緩解程度如何，永遠都有完美之處，因此 事先計劃如何找出並處理突發問題。一般 做法包括建立受監控的管道，方便使用者分享意見回饋 (例如「喜歡/不喜歡」評分) 及進行使用者研究，主動徵求意見 不同使用者組合的意見 — 尤其是當使用模式太 或預期不同

後續步驟

• 詳情請參閱 安全設定指南，瞭解可調整項目 可透過 Gemini API 存取安全性設定
• 請參閱提示簡介，瞭解如何 您會開始撰寫第一則提示