本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
什麼是 Amazon Bedrock Guardrails 中的自動推理檢查？
自動化推理檢查的功能
大型語言模型 (LLM) 的關鍵挑戰是確保回應的準確性。如果沒有驗證，LLMs 可能會產生幻覺或不準確的資訊，從而破壞信任。Amazon Bedrock Guardrails 中的自動推理檢查使用數學技術，根據您定義的政策驗證自然語言內容，以協助解決此問題。
與根據模式比對封鎖或篩選內容的傳統護欄元件不同，Automated Reasoning 檢查使用正式邏輯來提供有關回應正確或不正確原因的結構化意見回饋。此意見回饋可用來引導 LLM 產生可能與您的政策一致的內容。具體而言，自動推理檢查可以：
-
以數學方式證明產生的內容與您的政策規則相衝突，以偵測 LLM 回應中的事實上不穩定陳述式。
-
反白未陳述的假設，其中回應與您的政策一致，但未解決所有相關規則，表示回應可能不完整。
-
提供數學上可驗證的說明，說明正確陳述式為何正確，並引用支援結論的特定政策規則和變數指派。
這些功能可讓自動推理檢查與其他 Amazon Bedrock Guardrails 元件不同。內容篩選條件和主題政策做為二進位閘道，它們會封鎖或允許內容。自動化推理檢查可做為驗證層，提供詳細的可行意見回饋，讓您以程式設計方式改善回應。
何時使用自動推理檢查
當您需要示範 LLM 回應的事實基礎時，自動化理由檢查最有價值。當您的應用程式涉及以下項目時，請考慮使用它們：
-
受監管的產業，例如醫療保健、人力資源和金融服務，其中不正確的資訊可能會造成法律或合規後果。
-
複雜的規則集，例如抵押貸款核准、區域法律、保險資格或員工福利，其中多個條件會互動以判斷結果。
-
需要可稽核 AI 回應的合規案例，以及數學上可驗證的回應與您的政策一致。
-
面對客戶的應用程式，如果指引不正確，可能會破壞信任，例如回答有關公司政策、產品資格或服務條款問題的聊天機器人。
自動化推理檢查不會執行的動作
若要設定正確的期望，請注意下列限制：
-
無提示注入保護。自動化理由檢查會驗證您傳送的內容。如果提供惡意或操控的內容做為輸入，則會依原樣對該內容執行驗證。若要偵測和封鎖提示注入攻擊，請使用內容篩選條件搭配自動推理檢查。
-
無離主題偵測。自動化理由只會分析與政策相關的文字。它會忽略不相關的內容，而且無法告訴您回應是否偏離主題。若要偵測主題外回應，請使用主題政策。
-
無串流支援。自動化理由檢查不支援串流 APIs。您必須驗證完整的回應。
-
僅限英文。自動化理由檢查目前僅支援英文 （美國）。
-
範圍僅限於您的政策。
VALID結果保證僅對透過政策變數擷取的輸入部分有效。不在政策變數範圍內的陳述式不會進行驗證。例如，如果政策沒有用來擷取醫生診斷證明是否為仿造的變數，「我可以延遲提交我的家庭作業，因為我有仿造醫生診斷證明」可能會被視為有效。
自動化合理性檢查可補充其他 Amazon Bedrock Guardrails 功能，例如內容篩選條件和主題政策。為了獲得最佳保護，請同時使用它們。如需詳細資訊，請參閱防護機制元件。
End-to-end工作流程概觀
使用自動推理檢查包含四個階段：建立政策、測試政策、在護欄中部署政策，以及將其整合到您的應用程式中。
Source Document ──► Extracted Policy ──► Testing ──► Deployment ──► Integration (rules) (formal logic) (verify) (guardrail) (validate responses and act on feedback)
-
建立政策。上傳包含您要強制執行之規則的來源文件。自動化推理會從文件中擷取正式邏輯規則和變數結構描述。系統會自動產生保真度報告，以測量擷取的政策代表來源文件的準確度，以及涵蓋範圍和準確性分數，以及將每個規則和變數連結回來源內容中特定陳述式的詳細基礎。檢閱擷取的政策和保真度報告，以確保政策正確擷取您的規則。如需詳細資訊，請參閱建立自動推理政策。
-
測試和精簡。測試有助於確保您的政策可以準確地驗證產生的內容，即使您對政策本身進行變更。建立測試來模擬使用者將詢問的問題，以及 LLM 可能產生的回應。自動化推理檢查使用基礎模型將自然語言轉譯為邏輯。使用產生的案例來驗證規則正確性和 QnA 測試，以驗證自然語言到邏輯轉譯準確性。根據測試結果精簡您的政策。如需詳細資訊，請參閱測試自動推理政策。
-
部署。儲存測試政策的不可變版本，並將其連接到護欄。您可以使用 CloudFormation 或 CI/CD 管道自動化部署。如需詳細資訊，請參閱在應用程式中部署自動推理政策。
-
整合。在執行時間，自動化原因調查結果會透過支援 Amazon Bedrock Guardrails 組態APIs 傳回：
Converse、InvokeAgent、InvokeModel和RetrieveAndGenerate，以及獨立ApplyGuardrailAPI。檢查調查結果，以決定是否提供回應、使用意見回饋重寫回應，或要求使用者釐清。自動化原因檢查只會在偵測模式下操作，它們會傳回問題清單和意見回饋，而不是封鎖內容。如需如何在應用程式中整合自動原因檢查的詳細資訊，請參閱 在您的應用程式中整合自動推理檢查。如需啟用自動原因檢查所需許可的詳細資訊，請參閱 使用 ApplyGuardrail 自動推理政策的許可。
可用性和語言支援
Amazon Bedrock Guardrails 中的自動推理檢查通常在以下區域提供：
美國東部 (維吉尼亞北部)
美國西部 (奧勒岡)
美國東部 (俄亥俄)
歐洲 (法蘭克福)
歐洲 (巴黎)
歐洲 (愛爾蘭)
自動化理由檢查目前僅支援英文 （美國）。
限制及考量
在實作自動推理檢查之前，請注意下列技術限制：
-
文件複雜性。來源文件應以明確、不明確的規則妥善建構。具有巢狀條件或矛盾陳述的高度複雜文件可能無法清楚擷取為正式邏輯。輸入文件的大小限制為 5 MB 和 50，000 個字元。您可以分割較大的文件，並將每個區段合併到您的政策中。文件中的影像和資料表也會影響輸入字元的數量。
-
處理時間。自動化原因檢查驗證會為您的應用程式回應新增延遲。規劃額外的處理時間，尤其是具有許多變數的複雜政策。政策中的變數數量直接導致驗證延遲增加。
-
政策範圍。為了建立更容易維護的政策，每個政策都應專注於特定網域 （例如 HR、財務、法務），而不是嘗試在單一政策中涵蓋多個不相關的領域。
-
變數和規則限制。變數數量過多或規則互動過於複雜的政策可能會達到處理限制或傳回 TOO_COMPLEX 結果。請參閱 Amazon Bedrock 限制文件 和 驗證結果參考。
-
自然語言相依性。驗證的準確性取決於將使用者提示和模型回應中的自然語言轉譯為您政策的正式邏輯變數的程度。自動化推理檢查使用基礎模型，將自然語言轉換為邏輯表示法。變數描述會影響此轉譯的品質。
-
非線性算術。如果限制涉及使用非線性算術推理 （例如，不合理數字或指數），則自動推理檢查可能會逾時或傳回 TOO_COMPLEX。
定價
Amazon Bedrock 防護機制中的自動推理檢查會根據處理的驗證請求數收費。如需目前定價的資訊，請參閱 Amazon Bedrock 定價頁面
無論結果為何 (例如 VALID、INVALID、TRANSLATION_AMBIGUOUS)，每個驗證請求都會產生費用。若要最佳化成本：
-
使用適當的可信度閾值來平衡準確性與處理需求。
-
如果適用您的使用案例，請考慮快取相同或類似查詢的驗證結果。
-
監控用量模式並調整政策，以減少不必要的驗證請求。
政策操作的跨區域推論
自動推理利用跨區域推論來最佳化政策建立和測試操作的效能和可用性。特定 API 操作會自動將處理分佈到地理界限內的 AWS 區域，以確保交付可靠的服務。
下列自動推理 API 操作採用跨區域推論：
-
StartAutomatedReasoningPolicyBuildWorkflow— 從來源文件建立和編譯政策期間叫用。 -
StartAutomatedReasoningPolicyTestWorkflow— 在政策驗證和測試程序期間調用。
這些操作會調用大型語言模型，從來源文件中擷取正式邏輯規則，並將自然語言建構模組轉換為結構化邏輯表示法。為了確保最佳效能和可用性，請求處理會根據下列地理位置路由進行分配：
-
美國區域：來自美國東部 (維吉尼亞北部)、美國西部 (奧勒岡) 或美國東部 (俄亥俄) 的 API 請求可以在任何支援的美國區域中進行處理。
-
歐盟區域：來自歐洲 (法蘭克福)、歐洲 (巴黎) 或歐洲 (愛爾蘭) 的 API 請求可以在任何支援的歐洲區域中進行處理。
重要
客戶資料會保留在原始地理界限 (美國或歐盟) 內，並根據 AWS 資料落地承諾進行處理。跨區域推論只會在相同地理區域內路由請求，以最佳化效能和服務可用性。
跨區域推論會以透明的方式運作，不需要客戶組態。無論處理請求的特定區域為何，API 功能都會保持一致。
主題
