本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
透過在 Amazon Bedrock Guardrails 中新增自動推理檢查來提高準確性
Amazon Bedrock Guardrails 中的自動推理檢查會根據您定義的政策以數學方式驗證自然語言內容，確保嚴格遵守您的護欄。這些檢查有助於在到達您的使用者之前，系統性地封鎖有害或不合規的內容。與模式比對方法不同，Automation Reasoning 提供更高的準確性，並減少誤報，特別是對於複雜的政策需求。對於優先考慮精確度的客戶，可以自訂政策規則，透過清晰的邏輯陳述式來增強護欄有效性。
大型語言模型 (LLMs的關鍵挑戰是確保回應的準確性。如果沒有驗證，LLMs 有時可能會產生幻覺或不準確的資訊，從而破壞信任。
Amazon Bedrock Guardrails 中的自動推理檢查透過使用數學技術來解決此問題：
-
偵測 LLM 回應中的幻覺
-
反白未陳述的假設
-
說明正確陳述式為何正確
當您需要示範 LLM 回應的事實基礎時，此功能特別有用：
-
醫療保健和人力資源等受管產業
-
具有複雜規則的應用程式 （抵押貸款核准、區域法律）
-
需要稽核 AI 回應的合規案例
Amazon Bedrock Guardrails 中的自動推理檢查無法防範即時注入攻擊。這些檢查會驗證您傳送的內容 - 如果提供惡意或操控的內容做為輸入，則會依原狀對該內容執行驗證 (garbage-in、garbage-out)。若要偵測和封鎖提示注入攻擊，請使用內容篩選條件搭配自動推理檢查。
自動化理由只會分析和偵測與自動化理由政策相關的文字。它會忽略其餘內容，而且無法告知開發人員答案是否偏離主題。如果您需要偵測主題外回應，請使用其他護欄元件，例如主題政策。
注意
Amazon Bedrock Guardrails 中的自動理性檢查通常在美國 （維吉尼亞北部、奧勒岡州和俄亥俄） 和歐洲 （法蘭克福、巴黎、愛爾蘭） 區域提供。
注意
Amazon Bedrock Guardrails 中的自動推理檢查可補充其他 Amazon Bedrock Guardrails 功能，例如內容篩選條件和主題政策。如需詳細資訊，請參閱護欄元件。
目前不支援 CloudFormation。CloudFormation 支援即將推出。
Amazon Bedrock Guardrails 中的自動原因檢查目前僅支援英文 （美國）。
Amazon Bedrock Guardrails 中的自動推理檢查不支援串流 APIs。
限制及考量
實作自動化理由檢查之前，請注意下列重要限制：
-
文件複雜性：來源文件應以明確、不明確的規則妥善建構。具有巢狀條件或矛盾陳述式的高度複雜文件可能無法完全擷取為正式邏輯。
-
處理時間：自動推理驗證會為您的應用程式回應增加延遲。規劃額外的處理時間，尤其是具有許多規則的複雜政策。
-
政策範圍：每個政策都應專注於特定網域 （例如 HR、財務、法務），而不是嘗試在單一政策中涵蓋多個不相關的領域。
-
變數限制：變數數量過多或規則互動過於複雜的政策可能會達到處理限制或傳回 TOO_COMPLEX 結果。
-
自然語言相依性：驗證的準確性很大程度上取決於使用者提示和模型回應中自然語言翻譯到政策的正式邏輯變數的程度。
最佳實務
遵循這些最佳實務，以最大限度地提高自動化理由政策的有效性：
-
開始簡單：從涵蓋核心規則的重點政策開始，然後逐漸增加複雜性。在每個階段徹底測試。
-
撰寫全面的變數描述：包括使用者如何自然地參考概念，而不只是來源文件中的技術定義。
-
測試邊緣案例：建立測試，特別針對使用者可能遇到的界限條件、例外狀況和不尋常案例。
-
監控可信度閾值：從較高的可信度閾值 (0.8-0.9) 開始，並根據您對偽陽性與偽陰性的容忍度進行調整。
-
定期政策維護：在業務規則變更時或當您透過測試和生產使用來識別差距時，檢閱和更新您的政策。
-
記錄您的註釋：追蹤政策修改及其背後的原因，以供日後參考和團隊知識分享。
定價
Amazon Bedrock Guardrails 中的自動原因檢查會根據處理的驗證請求數量收費。如需目前定價資訊，請參閱 Amazon Bedrock 定價頁面
無論結果為何 （例如 VALID、INVALID、TRANSLATION_AMBIGUOUS)，每個驗證請求都會產生費用。若要最佳化成本：
-
使用適當的可信度閾值來平衡準確性與處理需求
-
考慮在適合您使用案例時快取相同或類似查詢的驗證結果
-
監控用量模式並調整政策，以減少不必要的驗證請求
政策操作的跨區域推論
自動化理由利用跨區域推論來最佳化政策建立和測試操作的效能和可用性。特定 API 操作會自動在您的地理界限內跨 AWS 區域分配處理，以確保可靠的服務交付。
下列自動推理 API 操作採用跨區域推論：
-
StartAutomatedReasoningPolicyBuildWorkflow- 從來源文件建立和編譯政策期間叫用 -
StartAutomatedReasoningPolicyTestWorkflow- 在政策驗證和測試程序期間調用
這些操作會叫用大型語言模型，從來源文件中擷取正式邏輯規則，並將自然語言建構轉換為結構化邏輯表示法。為了確保最佳效能和可用性，請求處理會根據下列地理路由進行分配：
-
美國區域：來自美國東部 （維吉尼亞北部）、美國西部 （奧勒岡） 或美國東部 （俄亥俄） 的 API 請求可以在任何支援的美國區域中處理。
-
歐盟區域：來自歐洲 （法蘭克福）、歐洲 （巴黎） 或歐洲 （愛爾蘭） 的 API 請求可以在任何支援的歐洲區域中處理。
重要
客戶資料會保留在原始地理界限 （美國或歐盟） 內，並根據 AWS 資料落地承諾進行處理。跨區域推論只會在相同地理區域內路由請求，以最佳化效能和服務可用性。
跨區域推論以透明的方式運作，而不需要客戶組態。無論處理請求的特定區域為何，API 功能都會保持一致。
若要在 Amazon Bedrock Guardrails 中使用自動推理檢查，請遵循下列步驟：
-
上傳包含您要強制執行之規則的來源文件
-
使用自動識別的概念和規則檢閱解壓縮的政策
-
測試和精簡政策，以確保其正常運作
-
部署政策以驗證基礎模型的回應
工作流程可視覺化為：
Source Document → Extracted Policy → Testing → Deployment → Runtime Validation (rules) (formal logic) (verify) (activate) (check responses)
政策
自動化理由政策是準確性驗證的基礎，其中包含從您的來源文件自動擷取的邏輯規則和變數。這些政策可做為業務規則的數學表示法，讓系統有系統地驗證基礎模型回應是否符合您定義的限制。若要在應用程式中執行自動推理檢查，請將護欄設定為使用符合您特定網域和驗證需求的政策。
規則
規則是自動推理從您的來源文件擷取的邏輯。這些可能會寫入為 if-then 陳述式。以下是規則格式的一些範例：
if <premise>, then <claim>
<premise> is true
注意
重要事項：不是 if-then 格式的規則，可以透過配置有關世界的軸來產生非預期的後果。例如，如果規則只陳述 accountBalance > 5，則無論驗證的內容為何，帳戶餘額都無法達到 5 或更少。此規則使該條件在邏輯上無法存在。這可能會導致意外的驗證結果，其中內容不正確地標記為不合規，因為它與規則建立的軸矛盾。為了避免這種情況，請將規則建構為描述關係而非絕對限制條件的條件式陳述式 (if-then 格式）。
Variables
變數代表自動化推理政策中的概念，在將自然語言轉譯為正式邏輯時，可以為其指派值。您的政策規則會定義這些變數有效或無效值的限制。
變數具有名稱、類型和描述。例如，有關員工利益的政策可能具有名稱為 "employee_age" 的變數、類型為 "integer" 的變數，以及描述為 "以年為單位的員工年齡"。系統會根據應用程式提示中的自然語言，將類似 25 的值指派給此變數。
例如，HR 政策中的 is_full_time變數可能會有描述，指出「每週工作超過 20 小時的員工」，這是來源文件的直接引號。使用聊天機器人時，使用者更可能會說「我是全職員工」，而不是「我每週工作超過 20 小時。」
從自然語言轉譯到正式邏輯的準確性高度取決於變數描述的品質。雖然轉譯完成後推理程序就會響起，但清晰且全面的變數描述可確保正確解譯使用者提示。如果沒有完整的變數描述，Automated Reasoning 可能會傳回，NO_DATA因為它無法將輸入自然語言轉譯為其正式的邏輯表示法。
變數描述必須考慮這類案例。全面的變數描述可能表示「每週工作超過 20 小時的員工是全職的。使用者將說全職將此值設定為 true，或兼職將其設定為 false。」
預先定義的變數類型
下表說明政策可擁有的預先定義變數類型。
| Type | 描述 |
|---|---|
|
bool |
布林值變數可以是 true 或 false。例如，在休假政策中，您可以使用 |
|
int |
數值 |
|
real |
數值 |
|
enum |
列舉變數可以存放從一組固定選項中選取的單一值。例如，在休假政策中，您可以使用列舉變數來存放休假類型：(1) 帶薪休假；(2) 個人時間；(3) 休假 您也可以建立自訂、使用者定義的列舉類型，以提供預先定義變數類型以外的其他內容。這些自訂類型可讓您定義與政策網域相關的特定值集。 |
