本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

将自动推理检查集成到您的应用程序中

在护栏中部署自动推理策略后（请参阅在应用程序中部署自动推理策略），您可以在运行时使用它来验证 LLM 响应并根据反馈采取行动。本页介绍如何调用验证 API，如何以编程方式解释发现结果，以及如何实现常见的集成模式，例如重写无效的响应和提出澄清问题。

自动推理检查仅在检测模式下运行——它们返回结果和反馈，而不是屏蔽内容。您的应用程序负责决定如何处理调查结果：提供响应、重写响应、要求澄清或回退到默认行为。

自动推理检查如何评估内容

Automated Reasoning 检查会将你提交的内容转化为逻辑含义（if/then“” 关系），然后根据你的政策规则检查这种含义。翻译会生成两种逻辑语句：

自动推理检查在翻译内容时决定哪些陈述是前提，哪些是主张，分割不是直接从输入字段中提取的。您可以通过 API 控制每段内容是作为用户端输入（问题或陈述的条件）还是代理端输入（验证的响应）输入。query限定符将内容标记为用户端；guardContent（或未加标签的文本）将其标记为代理端；groundingSource自动推理检查会忽略。然后，翻译从合并的输入中得出前提和主张。

是否必须标记内容以及如何标记内容取决于您使用的 API。

API 之间的主要区别

集成概述

在运行时，集成遵循以下流程：

User question ──► LLM generates response ──► Validate 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 使用自动推理检查致电

ApplyGuardrail评估您通过的所有内容。标记是可选的：默认情况下，每个内容块都被视为代理端（声明）内容，并根据您的策略规则进行验证，这是最简单的集成路径。为了给自动推理检查提供额外的上下文，你可以在内容块qualifiers上设置以将其标记为用户端 (query) 输入。与Converse和不同InvokeModel，ApplyGuardrail它不会为您附加模型回复，因此您提交的内容必须至少包含一个索赔块；否则请求将返回。ValidationException

请求结构

示例：使用验证 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对象。每个发现都是一种联合类型，恰好存在以下键之一：

有关每种查找结果类型及其字段的详细说明，请参见调查结果和验证结果。

使用自动推理检查致电 Converse

只有当Converse请求至少包含一个guardContent区块时，才会对请求进行自动推理检查。仅发送普通请求text不会运行自动推理检查。

仅限纯文本（已跳过自动推理检查）

如果您的Converse请求仅使用普通text方块（不使用方guardContent块），则不会标记文本以进行护栏评估，因此 Automated Reasoning 检查无需评估，因此会被跳过：

{
  "messages": [{"role": "user", "content": [{"text": "Apply a 20% discount to my order"}]}]
}

此请求返回automatedReasoningPolicyUnits: 0。其他防护政策（内容、主题、文字和敏感信息）仍会对内容进行评估；仅跳过自动推理检查。要运行自动推理检查，请使用下一节所示的guardContent方块。

使用 GuardContent 块

要运行自动推理检查Converse，请将要评估的内容封装在一个guardContent区块中并设置其限定符。这就是你如何标记哪些内容是用户端的，哪些是代理端的。

下表显示了每个限定词如何为自动推理检查标记内容。

限定符仅设定内容是用户端还是代理端；Automated Reasoning 检查在翻译组合输入时会得出实际前提和主张。未指定限定符的区块默认为guard_content（代理端）。你可以在一个区块上指定多个限定符。优先顺序是guard_content > query > grounding_source。

示例：使用自动推理限定符调用 Converse AWS CLI

aws bedrock-runtime converse \
  --model-id "model-id" \
  --guardrail-config '{
    "guardrailIdentifier": "your-guardrail-id",
    "guardrailVersion": "1",
    "trace": "enabled"
  }' \
  --messages '[
    {
      "role": "user",
      "content": [
        {
          "guardContent": {
            "text": {
              "text": "Apply a 20% discount to my order and confirm it is done.",
              "qualifiers": ["query"]
            }
          }
        }
      ]
    }
  ]'

自动推理检查运行时

下表汇总了是否针对每个Converse请求形状运行自动推理检查。在它们运行的每种情况下，模型的响应都会附加为代理端（声明）块。

InvokeModel 使用自动推理检查致电

工作原理

InvokeModel自动推理检查需要两样东西：

XML 标签格式如下所示：

<amazon-bedrock-guardrails-QUALIFIER_SUFFIX>text</amazon-bedrock-guardrails-QUALIFIER_SUFFIX>

其中：

自动推理检查的标签角色

限定符仅设置标记的文本是用户端还是代理端输入；自动推理检查在翻译组合输入时会得出前提和声明。使用标记用户提示query以提供检查上下文。模型的输出会自动附加为代理端（声明）块，因此query仅用标记提示符就足以运行检查。

Multi-tag 优先级和嵌套规则

单个文本段可以用多种嵌套标签类型包装。当多个标签应用于同一内容时，优先级决定自动推理角色：guardContent > query > groundingSource。如果内容同时使用guardContent和标记query，则将其视为版权主张。

以下嵌套规则适用：

示例：使用 “自动推理” 标签进行呼叫 InvokeModel AWS CLI

aws bedrock-runtime invoke-model \
  --model-id "model-id" \
  --guardrail-identifier "your-guardrail-id" \
  --guardrail-version "1" \
  --trace "ENABLED" \
  --cli-binary-format raw-in-base64-out \
  --body '{
    "anthropic_version": "bedrock-2023-05-31",
    "max_tokens": 256,
    "amazon-bedrock-guardrailConfig": {
      "tagSuffix": "arp"
    },
    "messages": [
      {
        "role": "user",
        "content": [
          {
            "type": "text",
            "text": "<amazon-bedrock-guardrails-query_arp>Apply a 20% discount to my order and confirm it is done.</amazon-bedrock-guardrails-query_arp>"
          }
        ]
      }
    ]
  }' \
  output.json

此请求返回automatedReasoningPolicyUnits: 1，自动推理结果正在追踪中。

默认行为（不带标签）

没有 XML 标签的同一个请求使用纯文本：

"text": "Apply a 20% discount to my order and confirm it is done."

此请求返回 automatedReasoningPolicyUnits: 0 — 自动推理检查未运行，也未引发任何错误。护栏仍会评估其他策略（内容、主题、单词和敏感信息），但完全跳过了自动推理检查。

在运行时解释自动推理结果

要以编程方式对自动推理结果采取行动，您的应用程序需要提取结果类型、翻译详细信息以及支持或相互矛盾的规则。以下各节说明了如何解析结果的每个部分。

确定查找类型

每个发现都是一个结合——只有一个钥匙存在。检查存在哪个密钥以确定查找类型：

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对象，该对象显示自动推理检查如何将自然语言输入转换为形式逻辑。翻译包含：

检查untranslatedPremisesuntranslatedClaims并了解验证的范围。VALID结果仅涵盖已翻译的声明，未翻译的内容未经过验证。

阅读支持或相互矛盾的规则

根据查找结果的类型，查找结果包括解释结果的规则：

这些规则和场景是中描述的重写模式的关键输入。使用 AR 反馈重写无效的回复

确定聚合结果

单个验证请求可以返回多个结果。要确定总体结果，请按严重程度对结果进行排序，然后选择最差的结果。从最差到最佳的严重性顺序为：translationAmbiguousimpossible、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

在应用程序中处理验证结果

使用汇总结果来决定您的应用程序接下来要做什么。下表汇总了每种结果类型的建议操作。

使用 AR 反馈重写无效的回复

Automated Reasoning 检查最强大的集成模式是重写循环：当响应为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.

重写最佳实践

提出澄清问题

当自动推理检查返回translationAmbiguoussatisfiable、或impossible结果时，法学硕士可能没有足够的信息来准确地重写响应。在这些情况下，您的应用程序可以要求用户进行澄清，然后将答案纳入下一次验证尝试中。

何时要求澄清

澄清模式

澄清流程的工作原理如下：

示例：根据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.")

Open-source 重写聊天机器人示例

有关本页所述模式的完整生产风格实现，请参阅自动推理检查重写聊天机器人。 GitHub此示例应用程序演示：

该示例使用带有 React 前 Python/Flask 端的后端，并通过 API 与 Amazon Bedrock 通信进行法学硕士推断，与 Amazon Bedrock Guardrails 通信进行验证。ApplyGuardrail

建立审计记录

自动推理结果提供了数学上可验证的有效性证据。对于受监管的行业和合规场景，这种证明是一个关键的差异化因素——你可以证明，人工智能响应是根据具有特定变量分配的特定政策规则进行验证的，而不仅仅是模式匹配或概率评估。

要建立有效的审计跟踪，请记录每个验证请求的以下信息：

示例：审计日志条目结构

{
  "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
}