閱讀英文

共用方式為


在 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 解決方案,以處理傳入的報表和疑慮。

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

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

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

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

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

    • 運用社交聆聽技術於客戶用來進行關於功能問題、疑慮以及可能傷害的早期討論的管道。

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

工具和資源