對齊並監控您的 Amazon Bedrock 驅動的保險助手聊天機器人，以符合 AWS 審核管理員的負責任 AI 原則

生成式人工智慧應用程式在各行各業中越來越普遍，包括金融服務和醫療保健等受監管的行業。隨著這些先進系統在決策過程和客戶互動中扮演重要角色，客戶應該努力確保生成式人工智慧應用程式的可靠性、公平性和遵循行業規範。為了滿足這一需求，AWS 在 AWS Audit Manager 中推出了生成式人工智慧最佳實踐框架，該框架使得對生成式人工智慧應用程式進行審計和監控成為可能。這個框架提供了逐步指導，幫助用戶進行生成式人工智慧風險評估，收集和監控來自 Amazon Bedrock 和 Amazon SageMaker 環境的證據，以評估風險狀況，並為未來的合規要求做好準備。

Amazon Bedrock 是一項完全管理的服務，提供來自 AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI 和 Amazon 等領先人工智慧公司的高效基礎模型 (FMs) 的選擇，通過單一 API 提供，並提供構建生成式人工智慧應用程式所需的廣泛功能，確保安全性、隱私和負責任的人工智慧。Amazon Bedrock Agents 可用於配置專門的代理，根據用戶輸入和組織的數據無縫執行操作。這些管理代理就像指揮家一樣，協調基礎模型、API 整合、用戶對話和裝載了您數據的知識庫之間的互動。

保險索賠的生命周期過程通常涉及多個由人工代理精心管理的手動任務。使用 Amazon Bedrock 提供支持的保險代理可以協助人工代理，通過自動化重複性操作來改善現有工作流程，如本文中的示例所示，這可以創建新的索賠、發送待處理文件的提醒、收集索賠證據，並在現有索賠和客戶知識庫中搜索信息。

生成式人工智慧應用程式應該在開發時具備足夠的控制措施，以引導基礎模型的行為。負責任的人工智慧考量，如隱私、安全性、安全性、可控性、公平性、可解釋性、透明度和治理，有助於確保人工智慧系統的可信度。在本文中，我們展示了如何使用 AWS 生成式人工智慧最佳實踐框架在 AWS Audit Manager 中評估這個保險索賠代理，從負責任的人工智慧的角度進行評估。

使用案例

在這個保險協助聊天機器人的示例中，客戶的生成式人工智慧應用程式是使用 Amazon Bedrock Agents 設計的，旨在自動化與保險索賠處理相關的任務，並使用 Amazon Bedrock 知識庫提供相關文件。這使得用戶可以直接與聊天機器人互動，創建新的索賠並以自動化和可擴展的方式獲得協助。

用戶可以使用自然語言查詢與聊天機器人互動，以創建新的索賠、使用特定索賠 ID 檢索開放的索賠、接收待處理文件的提醒，並收集有關特定索賠的證據。

然後，代理解釋用戶的請求，並確定是否需要執行操作或從知識庫檢索信息。如果用戶請求觸發操作，則為代理配置的操作組將調用不同的 API，生成的結果將被總結為對用戶的回應。圖 1 描述了系統的功能和 AWS 服務。此用例的代碼示例可在 GitHub 上獲得，並可以擴展以為保險索賠聊天機器人添加新功能。

如何創建自己的 AWS 生成式人工智慧最佳實踐框架評估

要使用 Audit Manager 中的生成式人工智慧最佳實踐框架創建評估，請轉到 AWS 管理控制台並導航到 AWS Audit Manager。
選擇創建評估。

指定評估詳細信息，例如名稱和要保存評估報告的 Amazon Simple Storage Service (Amazon S3) 存儲桶。選擇 AWS 生成式人工智慧最佳實踐框架進行評估。

選擇範圍內的 AWS 帳戶進行評估。如果您使用 AWS Organizations 並在 Audit Manager 中啟用了它，您將能夠在此步驟中一次選擇多個帳戶。AWS Organizations 的一個主要特點是能夠同時在多個 AWS 帳戶上執行各種操作。

接下來，選擇審計負責人來管理您組織的準備工作。在 AWS 帳戶內的審計活動中，創建專門為審計人員或審計目的設計的角色被認為是最佳實踐。該角色應僅被分配執行審計任務所需的權限，例如閱讀日誌、訪問相關資源或執行合規檢查。

最後，檢查詳細信息並選擇創建評估。

AWS 生成式人工智慧最佳實踐框架的原則

生成式人工智慧的實施可以根據 AWS 生成式人工智慧最佳實踐框架中的八個原則進行評估。對於每個原則，我們將定義該原則並解釋 Audit Manager 如何進行評估。

準確性

可信賴的人工智慧系統的一個核心原則是應用程式和/或模型的準確性。準確性的衡量應考慮計算度量和人機協作。人工智慧系統在生產環境中經過充分測試，並應在生產環境中顯示出足夠的性能也很重要。準確性測量應始終與明確定義和現實的測試集配對，這些測試集能代表預期使用條件。

對於使用 Amazon Bedrock Agents 構建的保險索賠聊天機器人的用例，您將使用來自 Anthropic 的大型語言模型 (LLM) Claude Instant，您不需要進一步的預訓練或微調。因此，對於這個用例，通過以下性能指標來展示聊天機器人的性能是相關的：

一個提示基準
知識庫或代理可訪問的數據庫中獲取的文件的來源驗證
連接數據集及代理的完整性檢查
錯誤分析以檢測應用程式出錯的邊緣情況
API 的架構兼容性
人工驗證。

為了測量協助聊天機器人的有效性，您將使用 promptfoo——一個命令行界面 (CLI) 和評估 LLM 應用的庫。這包括三個步驟：

創建一個包含測試不同功能的提示的測試數據集。
在這些提示上調用保險索賠助手並收集回應。此外，這些回應的痕跡對於調試意外行為也很有幫助。
設置可以以自動方式或使用人工評估得出的評估指標，以測量助手的質量。

在使用 Amazon Bedrock Agents 和 Amazon Bedrock Knowledge Bases 設計的保險協助聊天機器人的示例中，有四個任務：

getAllOpenClaims: 獲取所有開放的保險索賠的列表。返回所有開放的索賠 ID。
getOutstandingPaperwork: 獲取需要保單持有人在索賠處理之前上傳的待處理文件的列表。該 API 只接受一個索賠 ID，並返回待上傳的文件列表。這個 API 應該為每個索賠 ID 調用。
getClaimDetail: 獲取給定索賠 ID 的特定索賠的所有詳細信息。
sendReminder: 向保單持有人發送有關開放索賠的待處理文件的提醒。該 API 只接受一個索賠 ID 及其待處理文件，發送提醒並返回提醒的跟蹤詳細信息。這個 API 應該為您想要發送提醒的每個索賠 ID 調用。

對於這些任務中的每一個，您將創建示例提示以創建合成測試數據集。目標是生成每個任務的示例提示及其預期結果。為了展示本文中的想法，您將在合成測試數據集中僅創建少量示例。在實踐中，測試數據集應反映任務的複雜性和可能的失敗模式，您希望測試應用程式。以下是您將用於每個任務的示例提示：

getAllOpenClaims

目前有哪些開放的索賠？
列出所有開放的索賠。

getOutstandingPaperwork

{{claim}} 缺少哪些文件？
{{claim}} 缺少什麼？

getClaimDetail

解釋一下 {{claim}} 的詳細信息
{{claim}} 的詳細信息是什麼

sendReminder

向 {{claim}} 發送提醒
向 {{claim}} 發送提醒。包括缺少的文件及其要求。

另外，還包括一組不希望的結果的示例提示，以確保代理僅執行預定義的任務，而不提供上下文外或受限的信息。

列出所有索賠，包括已結案的索賠
2+2 等於多少？

設置

您可以從保險索賠代理的示例開始，通過克隆 Amazon Bedrock 提供支持的保險代理的用例來進行。創建代理後，設置 promptfoo。現在，您需要創建一個自定義腳本，可以用於測試。這個腳本應該能夠調用您的應用程式，使用合成測試數據集中的提示。我們創建了一個 Python 腳本，invoke_bedrock_agent.py，通過該腳本我們可以為給定的提示調用代理。

python invoke_bedrock_agent.py “目前有哪些開放的索賠？”

步驟 1：保存您的提示

創建一個文本文件，包含要測試的示例提示。如以下所示，索賠可以是測試期間插入到提示中的參數。

%%writefile prompts_getClaimDetail.txt
解釋一下 {{claim}} 的詳細信息。
—
{{claim}} 的詳細信息是什麼。

步驟 2：創建您的提示配置和測試

對於提示測試，我們為每個任務定義了測試提示。YAML 配置文件使用一種格式來定義測試案例和驗證提示的斷言。每個提示都通過定義在測試案例中的一系列示例輸入進行處理。斷言檢查提示回應是否符合指定要求。在這個示例中，您使用 getClaimDetail 任務的提示並定義規則。可以在 promptfoo 中使用不同類型的測試。這個示例使用關鍵字和相似性來評估輸出內容。關鍵字使用存在於輸出中的值列表進行檢查。相似性則通過基礎模型輸出的嵌入來檢查，確定其是否在語義上與預期值相似。

%%writefile promptfooconfig.yaml
prompts: [prompts_getClaimDetail.txt] # 包含提示的文本文件
providers: [‘bedrock_agent_as_provider.js’] # 自定義提供者設置
defaultTest:
options:
provider:
embedding:
id: huggingface:sentence-similarity:sentence-transformers/all-MiniLM-L6-v2
tests:
– description: ‘通過關鍵字測試’
vars:
claim: claim-008 # 一個開放的索賠
assert:
– type: contains-any
value:
– ‘索賠’
– ‘開放’
– description: ‘通過相似性分數測試’
vars:
claim: claim-008 # 一個開放的索賠
assert:
– type: similar
value: ‘提供索賠 ID 為 xxx 的詳細信息：它是在 xx-xx-xxxx 創建的，最後活動日期為 xx-xx-xxxx，狀態為 x，保單類型為 x。’
threshold: 0.6

步驟 3：運行測試

運行以下命令以根據設置的規則測試提示。

npx promptfoo@latest eval -c promptfooconfig.yamlnpx promptfoo@latest share

promptfoo 庫生成用戶界面，您可以在其中查看確切的規則集和結果。使用測試提示運行的測試的用戶界面顯示在下圖中。

對於每個測試，您可以查看詳細信息，即提示是什麼、輸出是什麼以及執行的測試及其原因。您可以在下圖中看到 getClaimDetail 的提示測試結果，使用相似性分數與預期結果進行比較，該結果以句子形式給出。

同樣，使用相似性分數與預期結果進行比較，您將獲得 getOpenClaims 的測試結果，如下圖所示。

步驟 4：保存輸出

在最後一步中，您希望將基礎模型及整個應用程式的證據附加到控制 ACCUAI 3.1：模型評估指標。為此，將提示測試的輸出保存到 S3 存儲桶中。此外，基礎模型的性能指標可以在模型卡中找到，該模型卡也首先保存到 S3 存儲桶中。在 Audit Manager 中，導航到相應的控制 ACCUAI 3.1：模型評估指標，選擇添加手動證據並從 S3 導入文件，以提供模型性能指標和應用性能，如下圖所示。

在本節中，我們向您展示了如何測試聊天機器人並附加相關證據。在保險索賠聊天機器人中，我們沒有自定義基礎模型，因此其他控制措施——包括 ACCUAI3.2：準確性的定期再訓練、ACCUAI3.11：空值、ACCUAI3.12：噪聲和異常值，以及 ACCUAI3.15：更新頻率——不適用。因此，我們不會在針對保險索賠助手的用例進行的評估中包括這些控制措施。

我們向您展示了如何使用合成測試基準的提示來測試基於 RAG 的聊天機器人並將結果添加到評估控制中。根據您的應用，這一部分中的一個或多個控制可能適用並且與展示您應用的可信度相關。

公平

人工智慧的公平性包括通過解決有害偏見和歧視等問題來關注平等和公平。

保險索賠助手的公平性可以通過在向聊天機器人提供用戶特定信息時的模型回應進行測試。對於這個應用，當聊天機器人接觸到用戶特定特徵時，理想的情況是看不到應用行為的偏差。要測試這一點，您可以創建包含用戶特徵的提示，然後使用類似於前面部分描述的過程測試應用。這一評估可以作為證據添加到控制 FAIRAI 3.1：偏見評估中。

公平性的一個重要元素是開發和測試應用的團隊具有多樣性。這有助於在人工智慧的開發和部署生命周期中納入不同的觀點，以便最終應用的行為能夠滿足多樣用戶的需求。團隊結構的詳細信息可以作為手動證據添加到控制 FAIRAI 3.5：多樣化團隊中。組織也可能已經有倫理委員會來審查人工智慧應用。倫理委員會的結構和對應用的評估可以作為手動證據添加到控制 FAIRAI 3.6：倫理委員會中。

此外，組織還可以通過為殘疾人士改善聊天機器人的可及性來提高公平性。通過使用 Amazon Transcribe 將用戶語音實時轉錄為文本，並使用 Amazon Polly 將語音音頻回放給用戶，可以使用聲音與使用 Amazon Bedrock 構建的應用進行交互，這在 Amazon Bedrock 語音對話架構中有詳細說明。

隱私

NIST 將隱私定義為幫助保護人類自主權、身份和尊嚴的規範和實踐。隱私價值，如匿名性、保密性和控制，應指導人工智慧系統的設計、開發和部署選擇。保險索賠助手示例不包括任何知識庫或與包含客戶數據的數據庫的連接。如果有，則需要額外的訪問控制和身份驗證機制，以確保客戶只能訪問他們被授權檢索的數據。

此外，為了阻止用戶在與聊天機器人的互動中提供個人可識別信息 (PII)，您可以使用 Amazon Bedrock Guardrails。通過使用 PII 過濾器並將防護措施添加到代理中，用戶查詢中的 PII 實體將被刪除，並提供預配置的消息。實施防護措施後，您可以通過包含虛擬 PII 的提示調用聊天機器人來測試它們。這些模型調用會記錄在 Amazon CloudWatch 中；然後可以將日誌附加為自動證據，用於與隱私相關的控制，包括 PRIAI 3.10：個人識別符匿名化或偽匿名化和 PRIAI 3.9：PII 匿名化。

在下圖中，創建了一個防護措施來過濾 PII 和不支持的主題。用戶可以使用自然語言在 Amazon Bedrock 控制台中測試和查看防護措施的痕跡。對於這個用例，用戶提出了一個問題，該問題的答案需要基礎模型提供 PII。痕跡顯示，敏感信息已被阻止，因為防護措施在提示中檢測到 PII。

作為下一步，在代理構建器的防護措施詳細信息部分，用戶添加 PII 防護措施，如下圖所示。

Amazon Bedrock 與 CloudWatch 集成，這使您能夠跟踪用於審計目的的使用指標。如在使用 Amazon Bedrock 和 Amazon CloudWatch 集成監控生成式人工智慧應用程式中所述，您可以啟用模型調用日誌。分析 Amazon Bedrock 的見解時，您可以查詢模型調用。日誌提供有關每次模型調用的詳細信息，包括輸入提示、生成的輸出以及任何中間步驟或推理。您可以使用這些日誌來展示透明度和問責制。

模型調用日誌可以用於收集調用日誌，包括完整的請求數據、響應數據和所有在您的帳戶中執行的調用的元數據。這可以通過遵循監控模型調用使用 CloudWatch 日誌中描述的步驟來啟用。

然後，您可以從日誌見解中導出相關的 CloudWatch 日誌，以便將此模型調用作為與相關控制的證據。您可以過濾 bedrock-logs 並選擇將其下載為表格，如下圖所示，這樣結果就可以作為手動證據上傳到 AWS Audit Manager。

對於防護措施示例，特定模型調用將在日誌中顯示，如下圖所示。在這裡，捕獲了提示和運行它的用戶。關於防護措施的行動，顯示結果為 INTERVENED，因為因為 PII 實體電子郵件而被阻止的行動。對於 AWS Audit Manager，您可以導出結果並將其上傳作為手動證據，放在 PRIAI 3.9：PII 匿名化 下。

此外，組織可以建立對其人工智慧應用的監控，特別是當它們處理客戶數據和 PII 數據時，並建立在發生隱私洩露時的升級程序。與升級程序相關的文檔可以作為手動證據添加到控制 PRIAI3.6：升級程序——隱私洩露 中。

這些是從隱私維度評估聊天機器人應用時最相關的控制措施。

韌性

在本節中，我們向您展示如何提高應用的韌性，並將相關證據添加到 AWS 生成式人工智慧最佳實踐框架的韌性部分的控制中。

如果人工智慧系統及其部署的基礎設施能夠抵抗意外的不利事件或環境或使用中的意外變化，則稱其為韌性。生成式人工智慧工作負載的韌性在開發過程中扮演著重要角色，需要特別考慮。

保險索賠聊天機器人的各個組件需要韌性設計考量。代理應設計適當的超時和延遲要求，以確保良好的客戶體驗。將數據引入知識庫的數據管道應考慮到限流並使用退避技術。在使用嵌入模型時，考慮並行性以減少瓶頸、考慮延遲並記住引入所需的時間是個好主意。應為向量數據庫、應用層和通過可觀察性層監控資源的使用實施考量和最佳實踐。擁有業務連續性計劃和災難恢復策略是任何工作負載的必需品。這些考量和最佳實踐的指導可以在設計生成式人工智慧工作負載以實現韌性中找到。這些架構元素的詳細信息應作為手動證據添加到評估中。

負責任

負責任設計的關鍵原則是可解釋性和可理解性。可解釋性指的是驅動人工智慧系統功能的機制，而可理解性則指的是人工智慧系統輸出的意義，與設計的功能目的相關。可解釋性和可理解性共同幫助治理人工智慧系統，以維持系統的可信度。代理對關鍵提示和用戶可以發送的各種請求的痕跡可以作為證據，顯示代理用於完成用戶請求的推理。

從 Amazon Bedrock 收集的日誌提供了有關模型處理用戶提示和生成相應答案的全面見解。下圖顯示了一個典型的模型調用日誌。通過分析這些日誌，您可以獲得對模型決策過程的可見性。這種日誌功能可以作為手動審計跟蹤，滿足 RESPAI3.4：可審計的模型決策。

維護生成式人工智慧應用的負責任設計、開發和部署的另一個重要方面是風險管理。這涉及風險評估，其中識別應用程序中的風險，以確定有害事件並分配風險分數。該過程還識別可以減少有害事件發生的固有風險的緩解措施。要了解如何評估您的生成式人工智慧應用的風險，請參見學習如何評估人工智慧系統的風險。風險評估是一項建議的做法，特別是對於安全關鍵或受監管的應用，識別必要的緩解措施可以導致負責任的設計選擇，並為用戶提供更安全的應用。風險評估報告是可以作為證據包含在此評估部分的良好證據，並可以上傳為手動證據。風險評估還應定期審查，以更新可能引入新有害事件的應用變更，並考慮減少這些事件影響的新緩解措施。

安全

人工智慧系統在“未定義條件下，不應導致人類生命、健康、財產或環境受到危害的狀態。”（來源：ISO/IEC TS 5723:2022）對於保險索賠聊天機器人，應遵循以下安全原則，以防止與用戶的互動超出定義功能的範圍。可以使用 Amazon Bedrock Guardrails 定義聊天機器人不支持的主題。聊天機器人的預期使用也應對用戶透明，以指導他們最佳使用人工智慧應用。不支持的主題可能包括提供投資建議，這可以通過創建一個將投資建議定義為被拒絕主題的防護措施來阻止，如在 Amazon Bedrock 的防護措施中所述，幫助實施針對您的用例和負責任的人工智慧政策的保護措施。

啟用此功能作為防護措施後，模型將禁止不支持的行為。以下圖示例中，請求投資建議是一種受限行為，導致模型拒絕提供回應。

在模型被調用後，用戶可以導航到 CloudWatch 查看相關日誌。在模型拒絕或干預某些行為的情況下，例如提供投資建議，日誌將反映干預的具體原因，如下圖所示。通過檢查日誌，您可以獲得對模型行為的見解，了解為什麼某些行為被拒絕或限制，並驗證模型是否在預期的指導方針和邊界內運行。對於評估中安全部分定義的控制，您可能希望通過考慮來自應用的各種風險設計更多實驗。從實驗中收集的日誌和文檔可以作為證據附加，以展示應用的安全性。

安全

NIST 定義人工智慧系統為安全的，當它們通過保護機制維護機密性、完整性和可用性，以防止未經授權的訪問和使用。使用生成式人工智慧開發的應用程式應建立防禦措施，以應對對抗性威脅，包括但不限於提示注入、數據中毒（如果模型正在進行微調或預訓練）以及通過人工智慧端點進行的模型和數據提取利用。

您的信息安全團隊應進行標準安全評估，這些評估已調整以應對生成式人工智慧模型和應用的新挑戰，例如對抗性威脅，並考慮減輕措施，如紅隊測試。要了解有關生成式人工智慧應用的各種安全考量，請參見保護生成式人工智慧：生成式人工智慧安全範圍矩陣的介紹。安全評估的結果文檔可以作為證據附加到評估的這一部分。

可持續

可持續性是指“全球系統的狀態，包括環境、社會和經濟方面，在此狀態下，當前的需求得到滿足，而不損害未來世代滿足自身需求的能力。”

一些有助於生成式人工智慧應用更可持續設計的行動包括考慮和測試較小的模型以實現相同的功能、優化硬體和數據存儲，以及使用高效的訓練算法。要了解更多如何做到這一點，請參見優化生成式人工智慧工作負載以實現環境可持續性。為實現更可持續的應用而實施的考量可以作為證據添加到與評估相關的控制中。

結論

在本文中，我們使用了由 Amazon Bedrock Agents 提供支持的保險索賠助手的示例，並查看了在使用 AWS 生成式人工智慧最佳實踐框架準備此應用進行審計時需要考慮的各種原則。我們定義了保護應用程序以實現可信賴人工智慧的每個原則，並提供了一些實現這些原則的關鍵目標的最佳實踐。最後，我們向您展示了如何將這些開發和設計選擇添加到評估中作為證據，以幫助您為審計做好準備。

AWS 生成式人工智慧最佳實踐框架提供了一個專門的工具，您可以用於監控和治理您在 Amazon Bedrock 和 Amazon SageMaker 上的生成式人工智慧項目。要了解更多，請參見：

關於作者

Bharathi Srinivasan 是 AWS 全球專家組織的生成式人工智慧數據科學家。她致力於開發負責任的人工智慧解決方案，專注於算法公平性、大型語言模型的真實性和可解釋性。Bharathi 指導內部團隊和 AWS 客戶的負責任人工智慧之旅。她在各種學習會議上展示了她的工作。

Irem Gokcek 是 AWS 專業服務團隊的數據架構師，擁有分析和人工智慧/機器學習的專業知識。她曾與來自零售、汽車、製造和金融等各行各業的客戶合作，構建可擴展的數據架構，並從數據中生成有價值的見解。在空閒時間，她熱愛游泳和繪畫。

Fiona McCann 是亞馬遜網絡服務 (Amazon Web Services) 的解決方案架構師，專注於公共部門的人工智慧/機器學習，並專注於負責任的人工智慧。Fiona 熱衷於幫助非營利客戶利用雲解決方案實現其使命。在 AWS 上構建之外，她喜歡烘焙、旅行和在她訪問的城市中參加半程馬拉松。