本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
概念:訊息、內容區塊類型和檢查
下列概念說明對 InvokeGuardrailChecks API 的請求結構。
訊息
訊息是您提交進行評估的基本內容單位。每個訊息有兩個欄位:識別產生內容者的角色,以及將實際文字保留為一或多個輸入內容區塊的內容陣列。
{ "role": "user", "content": [{ "text": "Hello world" }] }
這反映了 Amazon Bedrock 中其他位置使用role-plus-content-blocks結構,因此您為模型所建立的對話可以傳遞到 InvokeGuardrailChecks,而幾乎沒有調整形狀。請求messages的欄位是陣列,因此您可以提交單一訊息或代表多迴轉交換的序列 (例如,系統指令,後面接著使用者迴轉)。訊息會依您提供的順序進行評估,而其位置很重要:有些結果會以零為基礎的 傳回訊息messageIndex,並以其傳回該訊息內的區塊 contentIndex(請參閱敏感資訊結果)。
角色會標記內容的原始伺服器。支援下列角色:
-
system– 設定模型行為的說明。 -
user– 來自最終使用者的輸入。 -
assistant– 模型產生的輸出。
內容區塊類型
content 欄位是類型區塊的陣列,而不是純字串。類型區塊是金鑰命名其類型的小型物件。此設計可讓訊息格式在未來攜帶其他類型的內容 (例如影像或文件),而不會變更整體訊息形狀。目前,唯一支援的區塊類型為 text,其值為裸字串:
{ "text": "Hello world" }
訊息最多可包含十個內容區塊。內容區塊最多可包含一個text區塊。由於 text是目前唯一支援的類型,因此這實際上表示每個內容區塊有一個文字區塊。若要評估一個角色中的數個不同文字片段,請以content陣列中的個別內容區塊傳送它們。若要跨多個角色評估數個不同的文字片段,請以messages陣列中的個別訊息傳送它們。
檢查
檢查一詞可與 Amazon Bedrock Guardrails 提供的保護措施一詞互換。checks 物件是組態物件,每個檢查類型有一個選用欄位,而且您只包含要執行的檢查。您不會設定個別的啟用/停用旗標:只有在 和 存在其欄位時,才會執行檢查,而省略的檢查不會產生任何結果,也不會產生任何用量。您必須設定至少一個檢查欄位。
"checks": { "contentFilter": { ... }, "promptAttack": { ... }, "sensitiveInformation": { ... } }
由於組態是依請求內嵌的,因此您可以在呼叫 時改變安全狀態,而無需管理預存的護欄資源。代理程式迴圈中的不同步驟可以針對相同或不同訊息請求不同的檢查組合。
每個檢查都有自己的組態形狀。欄位名稱會選取檢查;其中的物件會列出檢查所尋找的內容:
-
contentFilter– 取得categories清單 (HATE、INSULTS、SEXUAL、VIOLENCE、MISCONDUCT)。 -
promptAttack– 取得categories清單 (JAILBREAK、PROMPT_INJECTION、PROMPT_LEAKAGE)。 -
sensitiveInformation– 取得entities清單 (31 個支援的 PII 實體)。
請求和回應是對稱的 – 您在 下設定的金鑰checks與在 results和 下傳回的金鑰相同usage。如果您請求 contentFilter和 sensitiveInformation,則只有這兩者會出現在回應中;因為從未執行而promptAttack不存在。這可讓您輕鬆地將問題清單映射回產生問題清單的檢查。
每次檢查僅偵測 – 沒有檢查區塊、遮罩或重寫內容。每個 都會傳回分數 (內容篩選和提示攻擊severityScore的 ,敏感資訊的confidenceScore加號位置位移),而且您可以根據特定需求決定應用程式對其採取的動作。