本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
在您的應用程式中整合自動推理檢查
在護欄中部署自動推理政策後 （請參閱在應用程式中部署自動推理政策)，您可以在執行時間使用該政策來驗證 LLM 回應並對意見回饋採取行動。此頁面說明如何呼叫驗證 API、以程式設計方式解譯問題清單，以及實作常見的整合模式，例如重寫無效回應和詢問釐清問題。
自動化原因檢查只會在偵測模式下運作，它們會傳回問題清單和意見回饋，而不是封鎖內容。您的應用程式負責決定如何處理問題清單：提供回應、重寫回應、要求釐清，或回復為預設行為。
整合概觀
在執行時間，整合會遵循此流程：
User question ──► LLM generates response ──► ApplyGuardrail validates response │ ┌─────────┴─────────┐ │ │ VALID Not VALID │ │ ▼ ▼ Serve response Inspect findings to user │ ┌────────┴────────┐ │ │ OTHER FINDING TRANSLATION_ TYPES AMBIGUOUS / SATISFIABLE │ │ ▼ ▼ Rewrite using Ask user for AR feedback clarification │ │ ▼ ▼ Validate again Validate with clarified input
自動化理由調查結果會透過支援 Amazon Bedrock Guardrails 組態的任何 API 傳回：
-
ApplyGuardrail— 獨立驗證 API。當您想要獨立驗證 LLM 調用的內容時，請使用此選項。這是自動推理檢查的建議方法，因為它可讓您完全控制驗證的內容和時間。 -
Converse和InvokeModel— 具有護欄組態APIs。自動原因調查結果會在回應的trace欄位中傳回。 -
InvokeAgent和RetrieveAndGenerate— 具有護欄組態APIs。
此頁面著重於 ApplyGuardrail API，因為它為實作如下所述的重寫和澄清模式提供了最大的靈活性。如需搭配其他 APIs 使用護欄的資訊，請參閱使用護欄。
開放原始碼重寫聊天機器人範例
如需此頁面所述模式的完整生產樣式實作，請參閱 GitHub 上的自動原因檢查重寫聊天機器人
-
反覆重寫迴圈，其中無效的回應會根據 AR 意見回饋自動更正。
-
當 LLM 需要使用者的其他內容才能正確重寫時的後續問題。
-
當使用者未回應釐清問題時，會自動繼續處理的逾時機制。
-
政策內容插入 LLM 提示，因此 LLM 可以在重寫期間參考完整的政策規則。
-
每個驗證反覆運算的 JSON 稽核記錄，以進行合規和偵錯。
此範例使用 Python/Flask 後端搭配 React 前端，並與 Amazon Bedrock 通訊以進行 LLM 推論，以及透過 ApplyGuardrail API 進行驗證的 Amazon Bedrock Guardrail。
注意
範例應用程式直接在 LLM 產生提示中包含政策內容，以支援任何自動化理由政策，而不需要上傳文件。在生產部署中，您通常會使用 RAG 內容或向 LLM 提供原始自然語言文件，而不是自動推理政策原始程式碼。
使用自動理性檢查呼叫 ApplyGuardrail
使用 ApplyGuardrail API 根據護欄驗證內容。API 接受一或多個內容區塊，並傳回包含自動推理問題清單的評估。
請求結構
guardrailIdentifier(必要)-
護欄 ID 或 ARN。使用已連接自動化理由政策的護欄。
guardrailVersion(必要)-
護欄版本編號 （例如
1)。針對生產工作負載使用編號版本，而非DRAFT。 source(必要)-
驗證 LLM 回應
OUTPUT時，將 設定為 。驗證使用者提示INPUT時，將 設定為 。對於自動推理檢查，您通常會驗證 LLM 輸出。 content(必要)-
要驗證的內容區塊陣列。每個區塊都包含一個
text欄位，其中包含要檢查的內容。您可以傳遞使用者問題和 LLM 回應做為個別的內容區塊，或將其合併為單一區塊。
範例：使用 驗證 LLM 回應 AWS CLI
aws bedrock-runtime apply-guardrail \ --guardrail-identifier "your-guardrail-id" \ --guardrail-version "1" \ --source OUTPUT \ --content '[ { "text": { "text": "User: Am I eligible for parental leave if I have been working here for 2 years full-time?\nAssistant: Yes, you are eligible for parental leave." } } ]'
範例：使用 Python (boto3) 驗證 LLM 回應
import boto3 import json bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") response = bedrock_runtime.apply_guardrail( guardrailIdentifier="your-guardrail-id", guardrailVersion="1", source="OUTPUT", content=[ { "text": { "text": ( "User: Am I eligible for parental leave if I have been " "working here for 2 years full-time?\n" "Assistant: Yes, you are eligible for parental leave." ) } } ], ) # The AR findings are in the assessments for assessment in response.get("assessments", []): ar_assessment = assessment.get("automatedReasoningPolicy", {}) findings = ar_assessment.get("findings", []) for finding in findings: # Each finding is a union — exactly one key is present # Possible keys: valid, invalid, satisfiable, impossible, # translationAmbiguous, tooComplex, noTranslations print(json.dumps(finding, indent=2, default=str))
回應結構
ApplyGuardrail 回應包含 assessments陣列。每個評估都包含具有findings陣列的automatedReasoningPolicy物件。每個問題清單都是聯集類型，僅存在下列其中一個索引鍵：
validinvalidsatisfiableimpossibletranslationAmbiguoustooComplexnoTranslations
如需每個調查結果類型及其欄位的詳細說明，請參閱 調查結果和驗證結果。
在執行時間解譯 AR 調查結果
若要以程式設計方式處理自動推理問題清單，您的應用程式需要擷取問題清單類型、翻譯詳細資訊，以及支援或矛盾的規則。下列各節說明如何剖析問題清單的每個部分。
判斷問題清單類型
每個問題清單都是一個聯集，只有一個索引鍵存在。檢查存在的索引鍵，以判斷問題清單類型：
def get_finding_type(finding): """Return the finding type and its data from an AR finding union.""" for finding_type in [ "valid", "invalid", "satisfiable", "impossible", "translationAmbiguous", "tooComplex", "noTranslations" ]: if finding_type in finding: return finding_type, finding[finding_type] return None, None
閱讀翻譯
大多數問題清單類型都包含一個 translation 物件，顯示自動推理檢查如何將自然語言輸入轉譯為正式邏輯。翻譯包含：
-
premises— 從輸入擷取的條件 （例如，isFullTime = true、tenureMonths = 24)。 -
claims— 要驗證的聲明 （例如，eligibleForParentalLeave = true)。 -
untranslatedPremises— 無法映射至政策變數的輸入部分。這些部分未經驗證。 -
untranslatedClaims— 無法映射至政策變數的宣告。
檢查 untranslatedPremises和 untranslatedClaims以了解驗證的範圍。VALID 結果僅涵蓋翻譯的宣告 – 未翻譯的內容未驗證。
閱讀支援或矛盾的規則
根據調查結果類型，調查結果包含解釋結果的規則：
-
valid調查結果包括supportingRules：證明宣告正確的政策規則。 -
invalid調查結果包括contradictingRules：宣告違反的政策規則。 -
satisfiable調查結果包括claimsTrueScenario和claimsFalseScenario- 顯示宣告為 true 和 false 的條件。
這些規則和案例是 中所述重寫模式的關鍵輸入使用 AR 意見回饋重寫無效的回應。
判斷彙總結果
單一驗證請求可以傳回多個問題清單。若要判斷整體結果，請依嚴重性排序問題清單，然後選取最差結果。從最差到最佳的嚴重性順序為：TRANSLATION_AMBIGUOUS、IMPOSSIBLE、INVALID、SATISFIABLE、VALID。
SEVERITY_ORDER = { "tooComplex": 0, "translationAmbiguous": 0, "impossible": 1, "invalid": 2, "satisfiable": 3, "valid": 4, "noTranslations": 5, } def get_aggregate_result(findings): """Return the worst finding type from a list of findings.""" worst = None worst_severity = float("inf") for finding in findings: finding_type, _ = get_finding_type(finding) severity = SEVERITY_ORDER.get(finding_type, 0) if severity < worst_severity: worst_severity = severity worst = finding_type return worst
在應用程式中處理驗證結果
使用彙總結果來決定您的應用程式接下來要做什麼。下表摘要說明每個結果類型的建議動作。
| 結果 | 代表什麼意思 | 建議的動作 |
|---|---|---|
valid |
根據內部部署和您的政策規則，此回應在數學上經過驗證是正確的。 | 將回應提供給使用者。記錄調查結果以供稽核之用 （請參閱 建置稽核線索)。 |
invalid |
回應與您的政策規則相衝突。contradictingRules 欄位識別違反了哪些規則。 |
使用 AR 意見回饋重寫回應 （請參閱 使用 AR 意見回饋重寫無效的回應)。如果多次嘗試後重新寫入失敗，請封鎖回應並傳回後援訊息。 |
satisfiable |
在某些情況下，回應是正確的，但不是全部。這並非錯誤，但不完整 — 它並未提及所有要求。 | 重寫回應以包含缺少的條件。使用 claimsFalseScenario來識別遺漏的項目。或者，您可以讓 LLM 詢問使用者釐清問題。 |
impossible |
內部部署是矛盾的，或政策包含衝突的規則。 | 要求使用者釐清其輸入 （請參閱 詢問釐清問題)。如果問題仍然存在，可能表示政策問題 — 檢閱品質報告。 |
translationAmbiguous |
輸入具有多個有效的解釋。翻譯模型對於如何將自然語言映射到政策變數有不同意見。 | 要求使用者釐清以解決模棱兩可的問題。使用 options和 differenceScenarios 欄位來產生目標釐清問題。 |
tooComplex |
輸入超過邏輯分析的處理限制。 | 透過將輸入分成較小的部分來簡化輸入，或傳回後援訊息，說明無法驗證回應。 |
noTranslations |
輸入與您政策的網域無關。無法映射任何政策變數。 | 此政策的內容為離主題。在沒有 AR 驗證的情況下提供回應，或使用其他護欄元件 （例如主題政策） 來處理離主題內容。 |
使用 AR 意見回饋重寫無效的回應
自動化理由檢查最強大的整合模式是重寫迴圈：當回應為 invalid或 時satisfiable，您的應用程式會建構包含原始回應、特定調查結果和政策規則的提示，然後要求 LLM 重寫回應以符合政策。重寫的回應會再次驗證，迴圈會繼續執行，直到回應達到valid或達到反覆次數上限為止。
重寫迴圈流程
LLM generates initial response │ ▼ Validate with ApplyGuardrail ◄──────────────────┐ │ │ ▼ │ ┌─────┴─────┐ │ │ │ │ VALID Not VALID │ │ │ │ ▼ ▼ │ Done Construct rewriting prompt │ with findings + rules │ │ │ ▼ │ LLM rewrites response │ │ │ ▼ │ Max iterations? ──── No ────────────────┘ │ Yes │ ▼ Return best response with warning
建構重寫提示
重寫提示應包含來自 AR 調查結果的三個資訊：
-
驗證失敗的原始回應。
-
特定調查結果 – 包括翻譯的現場部署、宣告，以及矛盾或支援規則。
-
重寫回應使其與政策規則一致的指示。
重寫提示範本範例：
The following response was checked against our policy and found to be {finding_type}. Original response: {original_response} The validation found the following issue: - Premises (what was understood from the input): {premises} - Claims (what was asserted): {claims} - Contradicting rules: {contradicting_rules} Please rewrite the response so that it is consistent with the policy document. Keep the same helpful tone and answer the user's question accurately based on the rules. If you cannot provide an accurate answer without more information, explain what additional information is needed.
提示
在重寫請求或政策規則中一律包含擷取增強生成 (RAG) 內容，以便 LLM 擁有重寫時所需的所有內容。重寫提示範本提供特定的調查結果詳細資訊，而系統提示則提供更廣泛的政策內容。此雙內容方法在開放原始碼重寫聊天機器人範例中
重寫最佳實務
-
設定反覆運算計數上限。重寫迴圈應具有硬性限制 （通常為 2-5 次反覆運算），以防止無限迴圈。如果回應仍然不在重複次數上限
valid之後，請傳回具有警告的最佳回應，或回到預設訊息。 -
依優先順序處理問題清單。傳回多個問題清單時，請先處理最嚴重的問題清單。嚴重性順序為：
translationAmbiguous、impossible、invalid、satisfiable、valid。 -
在系統提示中包含政策內容。LLM 需要存取來源文件或完整政策規則，才能準確重寫。您可以使用知識庫在產生請求中包含文件，或使用
ExportAutomatedReasoningPolicyVersionAPI 擷取政策定義並格式化 LLM 的政策定義。 -
記錄每個反覆運算。記錄原始回應、調查結果、重寫提示，以及每次反覆運算的重寫回應。此稽核線索對於偵錯和合規非常有用 （請參閱 建置稽核線索)。
詢問釐清問題
當自動原因檢查傳回 translationAmbiguous、 satisfiable或 impossible結果時，LLM 可能沒有足夠的資訊來準確重寫回應。在這些情況下，您的應用程式可以要求使用者釐清，然後將答案納入下一次驗證嘗試。
何時要求釐清
-
translationAmbiguous— 輸入有多個有效的解釋。options欄位顯示競爭的解釋，而differenceScenarios欄位顯示它們在實務上有何不同。使用這些來產生有關特定模棱兩可性的目標問題。 -
satisfiable— 在某些情況下，回應是正確的，但不是全部。claimsFalseScenario顯示回應不正確的條件。向使用者詢問這些特定條件。 -
impossible— 輸入包含矛盾的陳述式。要求使用者釐清矛盾之處。 -
重寫失敗 — 如果 LLM 無法重寫多次嘗試
valid後的回應，則可能需要使用者提供其他內容。要求 LLM 根據調查結果產生釐清性問題。
釐清模式
釐清流程的運作方式如下：
-
從 AR 調查結果中解壓縮模棱兩可的變數或缺少的條件。
-
產生釐清問題 - 以程式設計方式從問題清單欄位產生，或要求 LLM 根據問題清單制定問題。
-
向使用者提出問題並收集答案。
-
將答案納入內容中，並產生新的回應。
-
使用 驗證新的回應
ApplyGuardrail。
範例：從satisfiable問題清單產生釐清問題
def generate_clarifying_questions(finding_data, user_question): """Ask the LLM to generate clarifying questions from a SATISFIABLE finding.""" claims_true = json.dumps( finding_data.get("claimsTrueScenario", {}), indent=2, default=str ) claims_false = json.dumps( finding_data.get("claimsFalseScenario", {}), indent=2, default=str ) prompt = ( f"A user asked: {user_question}\n\n" f"The answer is correct when these conditions hold:\n{claims_true}\n\n" f"But incorrect when these conditions hold:\n{claims_false}\n\n" f"Generate 1-3 short, specific questions to ask the user to determine " f"which conditions apply to their situation. Format each question on " f"its own line." ) return generate_response(prompt, "You are a helpful assistant.")
建置稽核線索
自動化推理調查結果提供數學上可驗證的有效性證明。對於受監管的產業和合規案例，此證明是關鍵差異因素 — 您可以證明 AI 回應已根據具有特定變數指派的特定政策規則進行驗證，而不只是模式比對或概率評估。
若要建立有效的稽核線索，請記錄每個驗證請求的下列資訊：
-
時間戳記和請求 ID。驗證發生時，以及請求的唯一識別符。
-
輸入內容。已驗證的使用者問題和 LLM 回應。
-
問題清單類型和詳細資訊。驗證結果 (
valid、 等）invalid、翻譯的現場部署和宣告，以及支援或矛盾的規則。 -
採取的動作。您的應用程式對調查結果所做的工作 — 提供回應、重寫回應、要求釐清或封鎖回應。
-
重寫歷史記錄。如果重寫回應，請記錄每個反覆運算：原始回應、重寫提示、重寫回應，以及每個反覆運算的驗證結果。
-
政策版本。用於驗證的護欄版本和政策版本。這可確保您稍後可以重現驗證結果。
範例：稽核日誌項目結構
{ "timestamp": "2025-07-21T14:30:00Z", "request_id": "req-abc123", "guardrail_id": "your-guardrail-id", "guardrail_version": "1", "user_question": "Am I eligible for parental leave?", "llm_response": "Yes, you are eligible for parental leave.", "validation_result": "valid", "findings": [ { "type": "valid", "premises": "isFullTime = true, tenureMonths = 24", "claims": "eligibleForParentalLeave = true", "supporting_rules": ["A1B2C3D4E5F6"] } ], "action_taken": "served_response", "rewrite_iterations": 0 }
提示
將稽核日誌存放在持久且防竄改的存放區，例如 Amazon CloudWatch Logs 或啟用物件鎖定的 Amazon S3。對於合規案例，請考慮使用 Lake 來查詢整個組織的稽核日誌。
