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