共用方式為

在 Windows 上開發負責任的產生 AI 應用程式和功能

  • 發行項

本檔提供建議的負責任開發作法概觀，讓您在 Windows 上使用產生人工智慧來建立應用程式和功能時使用。

在 Windows 上負責任開發產生的 AI 應用程式和功能的指導方針

每個Microsoft小組都會 遵循核心原則和做法 ，以負責任地建置和運送 AI，包括 Windows。 您可以在Microsoft負責任 AI 透明度報告中深入瞭解Microsoft負責任開發的方法。 Windows 遵循 RAI 開發的基礎要素 —治理、對應、測量及管理—，與美國國家標準與技術研究所 （NIST） AI 風險管理架構一致。

控管 - 原則、做法和程式

標準是治理和合規性程序的基礎。 Microsoft已開發自己的負責任 AI 標準，包括六個原則，可讓您作為起點來開發負責任 AI 的指導方針。 建議您在開發生命週期端對端建置 AI 原則，以及流程和工作流程，以符合隱私權、安全性和負責任 AI 的法律法規。 這涵蓋每個 AI 功能的早期評估，使用 AI 公平檢查清單和人類 -AI 互動指導方針等工具 -- Microsoft Research，透過負責任 AI 計分卡等工具來監視和檢閱 AI 基準、測試和程式，以及將文件公開到 AI 功能的功能和限制和使用者洩漏和控件 -- 通知、 同意、數據收集和處理資訊等 -- 符合適用的隱私權法、法規要求和原則。

對應 - 識別風險

識別風險的建議做法包括：

端對端測試

端對端測試會從頭到尾評估整個 AI 系統，以確保其如預期般運作，並遵守已建立的標準。 此完整方法可能包括：

紅隊演練

紅隊 一詞歷來描述系統對抗攻擊以測試安全性弱點。 最近，此詞彙已延伸到傳統網路安全性之外，並在常見用法中演進，以描述許多種類的探查、測試和攻擊 AI 系統。

由於大型語言模型（LLM）和小型語言模型（SLM），良性和對立的使用可能會產生潛在的有害輸出，這些輸出可能會採取許多形式，包括仇恨言論、煽動或讚美暴力或性內容。 徹底進行紅隊行動可讓您對系統進行壓力測試，並完善您的內容策略，以降低系統造成危害的可能性。

所有 AI 系統都應該接受紅隊測試，視功能與用途而定，適用於採用產生 AI 的高風險系統，以及使用非產生 AI 的低風險系統：

  • 正式紅隊演練：對於使用大型語言模型（LLM）生成 AI 的所有高風險系統，應該完成獨立的紅隊演練。 正式的紅色小組包括招募組織外部的專業人員，以參與紅隊活動。

  • 內部滲透測試：至少應為所有低風險、非生成型 AI 系統規劃內部滲透測試。 這可以由組織內部的人員完成。

深入了解紅色小組，以及如何評估您系統的紅色小組需求：Microsoft AI Red Team

模型評估

作為端到端測試的一部分，重要的是評估模型本身。

  • 模型卡片：針對公開可用的模型，例如 HuggingFace 上的模型，您可以檢查每個模型的模型卡片作為方便的參考，以瞭解模型是否為適合使用案例的模型。 深入瞭解模型卡片。

  • 手動測試：人類執行不含腳本的逐步測試是支援...之模型評估的重要元件。

    • 測量一組優先順序問題的進度。 減輕特定傷害時，在移至自動化測量之前，要持續手動檢查小型資料集的進度，直到不再觀察到傷害為止，通常最具生產力。

    • 定義和報告計量，直到自動化測量足夠可靠，才能單獨使用。

    • 定期抽查以測量自動測量的品質。

  • 自動化測試：自動執行的測試也是支援...

    • 大規模測量並增加涵蓋範圍，以提供更全面的結果。

    • 持續測量，以監視系統、使用方式和風險降低演進時的任何回歸。

  • 模型選擇： 選取適合您用途的模型，並教育自己瞭解其功能、限制和潛在安全性挑戰。 測試模型時，請確定它會產生適合您使用的結果。 若要開始使用，Microsoft（和非Microsoft/開放原始碼）模型來源的目的地包括：

量值 - 評估風險和風險降低

建議的做法包括：

  • 指派 Content Moderator：Content Moderator 會檢查文字、影像和視訊內容，以了解內容中可能具有冒犯性、風險或其他不想要的內容。 深入瞭解：Content Moderator 簡介（Microsoft學習訓練）。

    • 使用內容安全篩選器：這種多類別分類模型的合奏分別在四個嚴重性層級（安全、低、中、高）偵測到四種有害內容（暴力、仇恨、性及自我傷害）。 深入瞭解： 如何使用 Azure OpenAI 服務設定內容篩選。

    • 套用中繼提示： 中繼提示是提示開頭所包含的系統訊息，可用來為模型加上內容、指示或其他與您使用案例相關的資訊。 這些指示可用來引導模型的行為。 深入瞭解： 使用中繼程式/系統訊息工程建立有效的安全性防護。

    • 利用封鎖清單： 這會封鎖提示中使用特定字詞或模式。 深入瞭解： 在 Azure OpenAI 中使用封鎖清單。

    • 熟悉模型的源頭：證明是模型擁有權的歷程記錄，或模型在何者位置，而且對於瞭解非常重要。 誰收集了模型中的數據？ 數據與誰有關？ 使用何種數據？ 收集數據的位置？ 收集數據的時機？ 瞭解模型數據的來源可協助您評估其品質、可靠性，並避免任何不道德、不公平、偏差或不正確的數據使用。

    • 使用標準管線：使用一個 con 帳篷模式 ration 管線，而不是提取元件分工。 深入瞭解： 了解機器學習管線。

  • 套用UI風險降低：這些可讓您的使用者清楚瞭解 AI 功能的功能和限制。 若要協助使用者並提供功能透明度，您可以：

    • 鼓勵使用者在接受輸出之前編輯輸出

    • 醒目提示 AI 輸出中的潛在不透明度

    • 揭露 AI 在互動中的角色

    • 引用參考和來源

    • 適當時限制輸入和輸出的長度

    • 提供結構輸出或輸出 – 提示必須遵循標準格式

    • 為有爭議的提示準備預先決定的回應。

  • 實作客戶意見反應迴圈： 鼓勵用戶主動參與意見反應迴圈：

    • 直接在應用程式/產品中使用與用戶體驗相結合的簡單意見反饋機制來尋求意見反饋。

    • 運用社交聆聽技術於客戶用來進行功能問題、顧慮及可能影響的初期對話的渠道。

管理 - 減輕 AI 風險

減輕 AI 風險的建議包括：

  • 濫用監視： 此方法會偵測並減輕週期性內容和/或行為實例，這些實例建議服務已以可能違反《行為規範》或其他適用的產品條款的方式使用。 深入瞭解： 濫用監視。

  • 階段式傳遞：慢慢推出您的 AI 解決方案，以處理傳入的報表和疑慮。

  • 事件回應計劃：針對每個高優先順序的風險，評估將發生的情況，以及回應程序的外觀，以及回應程式需要多久的時間。

  • 關閉功能或系統的能力：如果事件即將發生或已發生需要暫停功能以避免進一步傷害，請提供功能來關閉功能的功能。

  • 用戶訪問控制/封鎖：開發方法來封鎖濫用系統的使用者。

  • 用戶意見反應：利用機制偵測用戶端的問題。

    • 在您的產品中直接要求意見回饋，並提供一種在典型工作流程中可使用的簡單回饋機制。

    • 運用社交聆聽技術於客戶用來進行功能問題、顧慮及可能影響的初期對話的渠道。

  • 負責部署遙測數據：識別、收集及監視指出用戶滿意度的訊號或其如預期使用系統的能力，確保您遵循適用的隱私權法、原則和承諾。 使用遙測數據來識別間距並改善系統。

工具和資源