amazon-bedrock

關於amazon-bedrock

針對在 Amazon Bedrock 上建置生成式 AI 應用程式的領域專業知識。內容涵蓋透過 Converse API 和 InvokeModel 呼叫模型、運用知識庫進行檢索增強生成、Bedrock 代理程式、透過 Guardrails 確保內容安全，以及使用 AgentCore 部署和擴展代理程式。 適用於呼叫模型、設定知識庫、建立代理程式、套用 Guardrails、部署至 AgentCore、排除 Bedrock 錯誤（例如 ThrottlingException 和 AccessDeniedException），或從 Claude、Llama、Nova 和 Titan 等模型中進行選擇。 此外，本指南亦涵蓋提示詞快取、配額健康檢查、成本追蹤、模型遷移、分塊策略以及 AgentCore Payments 等內容，但明確不適用於自訂模型訓練、Rekognition 或 Comprehend。 由於 Bedrock API、模型 ID 及配置參數經常變更，此技能堅持在回應前，必須先讀取其內建的參考檔案作為主要可信來源。

其中一個主要主題是 Bedrock API 架構，該架構公開了五個獨立的端點，而這些端點的誤用是常見的錯誤來源：用於列出模型和管理存取權限的 bedrock 控制平面；用於透過 Converse 或 InvokeModel 呼叫模型的 bedrock-runtime； bedrock-mantle 用於 OpenAI 相容的 API（推薦給新使用者）；以及 bedrock-agent 和 bedrock-agent-runtime 用於代理程式配置與呼叫。AgentCore 是一項獨立服務，擁有專屬的控制平面與資料平面端點。 此技能建議使用 AWS MCP 伺服器進行沙箱執行與稽核記錄，但亦可與任何具備 AWS CLI 存取權限的代理程式配合使用。

本技能特別強調關鍵警告與安全實務：必須始終明確設定 `maxTokens`，因為若未設定，系統將預留遠超過實際需求的配額，並導致意外的流量限制；Guardrails 的 PII 遮罩功能僅適用於回應內容，未經遮罩的內容仍會記錄至 CloudWatch；且必須使用最新版本的 boto3 和 AWS CLI v2。 安全性指引建議優先使用 IAM 角色而非使用者、範圍限定權限、Secrets Manager、混淆代理防護機制，並將代理程式產生的參數視為不可信輸入。相較於 InvokeModel，建議優先使用 Converse API 以獲得統一的請求/回應格式，其中能力與模型選取表會指向更詳細的參考檔案。

常見問題

我應該使用哪種 Bedrock API 來呼叫模型？

在 bedrock-runtime 端點上，該技能建議優先使用 Converse API 而非 InvokeModel，因為它為所有模型提供統一的請求/回應格式。InvokeModel 僅保留給罕見的供應商特定功能，而對於新的 OpenAI 相容工作，建議使用 bedrock-mantle。

為何特別強調每次呼叫都必須設定 maxTokens？

若未設定 maxTokens，系統將預設採用模型的最大值（例如 Claude Sonnet 的 64K），並在後台預留遠超實際需求的配額，這正是導致意外發生 ThrottlingException 的常見原因。

Bedrock API 共有多少個端點，各自用於什麼用途？

共有五個：bedrock（控制平面）、bedrock-runtime（呼叫模型）、bedrock-mantle（OpenAI 相容 API）、bedrock-agent（配置代理與知識庫）以及 bedrock-agent-runtime（呼叫代理與查詢知識庫）。 AgentCore 是一項獨立服務，擁有專屬的端點。

此技能針對 Guardrails 和 PII 發出哪些警告？

Guardrails 的 PII 遮蔽功能僅適用於 API 回應；原始未遮蔽的內容（包括 PII）仍會以明文形式記錄至 CloudWatch Logs。為符合 HIPAA/GDPR 規範，建議使用 KMS 對這些日誌進行加密，並限制存取權限。

此技能是否適用於訓練自訂模型或使用 Rekognition？

不適合。該技能明確聲明不適用於自訂模型訓練、Rekognition 或 Comprehend。其重點在於模型呼叫、RAG、代理、Guardrails 以及 AgentCore。

所有檔案