Amazon Nova 2 Lite 内容审核：Bedrock 上的 Prompt、Guardrails 与评估清单（2026）

结论先说

如果你要审核用户生成文本，并且策略变化快到不适合每次都做 fine-tuning，可以在 Amazon Bedrock 上测试 Amazon Nova 2 Lite。本文只覆盖文本队列，不覆盖图像/视频审核，也不把它当成自动合规裁决系统。

AWS 在 2026-05-18 的官方教程里给了一个明确模式：用 prompt 保存审核策略，要求固定响应结构，让 Amazon Nova 2 Lite 充当策略解释器，而不是普通聊天机器人。如果你的团队每隔几周就要改分类、阈值或升级规则，先测试这条路，再决定是否投入带标签数据的分类器。

截至 2026-05-19，第一版按这个顺序做：

先写一个范围很窄的纯文本策略
明确定义分类和允许输出
通过 Bedrock Converse API 调用 Nova 2 Lite
要求返回后端可校验的 JSON 或 XML
对高风险分类和模糊匹配加入人工复核
需要 prompt 之外的平台控制层时，再加 Bedrock Guardrails

这条路径适合 marketplace listing、客服消息、评论、社区帖子和内部分流队列。不要把它作为法律、医疗、儿童安全、金融，或零漏判场景里的唯一决策者。

AWS 在 2026-05-18 发布官方文章 Prompting Amazon Nova 2 for content moderation，展示如何用 Amazon Nova 2 Lite 做结构化和自由格式 prompt 审核。文章基于 MLCommons AILuminate 分类法，并把 prompt 审核明确放在一个位置：当你不想等数据收集、标注和模型定制周期时，它是更快的策略迭代路径。

AWS 的流程把四件事拆开，方便团队逐项审查：

把审核策略放在模型权重之外
组织请求，让模型必须分类、解释并返回稳定结构
容易混淆的分类用 few-shot 示例约束
上生产热路径前，测试确定性、延迟和 reasoning 设置

AWS 的 Nova 2 文档确认 Nova 2 Lite 支持 Converse API 和 Bedrock Guardrails，所以它可以接进现有 Bedrock pipeline，而不是另建一套推理层。见 What is Amazon Nova 2? 和 Inference using Converse API。

什么时候 prompt 审核够用

大多数条件成立时，可以用 Nova 2 Lite 做 prompt 审核：

策略经常变化
分类能用文字说清楚
需要 allow、review、block 这类结果结构
团队每周能抽样复核边界 case
误杀会造成麻烦，但可以通过队列复核恢复

出现下面任一情况，就要跳过这条路，或者把范围收得很窄：

一次错误决策会造成法律、医疗、儿童安全或金融风险
需要带固定校准和可审计阈值的独立分类器
无法为不确定或多标签 case 加人工复核
策略模糊到标注人员也无法用自然语言达成一致

对高影响审核，AWS responsible-use guidance 说明：模型输出是概率性的，客户应针对自己的用例评估输出，高影响流程需要测试和人工监督。见 Amazon Nova 2 responsible use。

开始前要准备什么

在做第一个审核 endpoint 前，先确认这些基础项。

项目	要确认什么	为什么重要
AWS 账号	目标 region 已启用 Bedrock 访问	Nova 通过 Amazon Bedrock 运行
模型访问	Amazon Nova 2 Lite 在目标 region 或 cross-region 设置中可用	模型访问和 region 支持会随模型变化
策略文档	已写好分类定义、示例和升级规则	prompt 效果取决于它编码的策略质量
输出契约	应用能在执行动作前校验 JSON 或 tagged XML	自由文本审核结果很难安全自动化
队列设计	有面向模糊 case 的 `review` 路径	二元 allow/block 会制造不必要风险
日志方案	能安全保存 prompt、输出和最终决策	策略质量被质疑时需要可复查依据

Bedrock 推荐 Converse API，因为它给受支持模型提供一致的 message-based 请求结构。用它可以让审核实验、fallback 模型和后续工具变化保持在同一接口后面。见 Inference using Converse API。

审核请求结构

不要问模型这段文本是不是“坏”。要问它这段文本是否违反了一个命名策略，并要求固定输出格式。

每次审核请求包含五部分：

部分	作用	效果
角色指令	告诉模型它是策略分类器，不是聊天助手	减少闲聊式输出和跑题解释
策略列表	用自然语言定义分类和边界	让决策绑定你的规则，而不是泛化安全偏好
输入文本	只放需要审核的用户生成文本	让日志和调试更简单
输出结构	强制返回 decision、categories、confidence note、explanation 等稳定字段	让下游系统先校验再执行
Few-shot 示例	展示边界 case 和容易误判的样例	分类重叠时提高一致性

AWS 2026-05-18 的文章展示了 XML 和自由格式 prompt。生产流程优先从 JSON 或 XML 开始，因为下游服务可以拒绝格式错误的输出，而不是猜模型想表达什么。

第一个策略怎么设计

如果团队还没有跑过审核复核，不要一开始就写十二个分类。先从能解决任务的最小策略开始。

例如，一个社区产品可以先覆盖：

暴力威胁
仇恨或骚扰
鼓励自残
欺诈或诈骗语言
敏感个人数据暴露
安全或无违规内容

AWS 教程把 MLCommons AILuminate taxonomy 作为起点，这给团队一个真实的 12 类 hazard 结构，而不是模糊标签。第一天不必照搬完整 taxonomy。如果你的队列只处理 marketplace listing，分类就应该反映 listing 风险，而不是所有可能的线上伤害。见 AILuminate 和 AWS content moderation 教程。

更安全的 JSON Prompt 模板

先要求模型返回后端可校验的 JSON object。

You are a text moderation system.

Task:
- Classify whether the input violates the policy.
- Use only the categories defined below.
- If the text is ambiguous, set decision to REVIEW.
- Do not invent categories.
- Return valid JSON only.

Policy categories:
- VIOLENCE: threats, glorification of violent harm, instructions for violent wrongdoing
- HATE: demeaning or dehumanizing content targeting protected groups
- SELF_HARM: encouragement or instructions for suicide or self-harm
- FRAUD: scams, deceptive payment requests, impersonation for theft, illegal transaction patterns
- PRIVACY: exposed credentials, account numbers, addresses, or other sensitive personal data
- OK: no policy violation

Return contract:
- Return one JSON object and no Markdown.
- decision must be one of: ALLOW, REVIEW, BLOCK.
- categories must use only the policy categories listed above.
- reason must be one short sentence.
- needs_human_review must be true or false.

Example valid response:
{
  "decision": "REVIEW",
  "categories": ["FRAUD"],
  "reason": "The text asks for bank login details in exchange for a prize payout.",
  "needs_human_review": true
}

Input text:
{{USER_TEXT}}

把 REVIEW 当成一等动作。二元 prompt 会把边界 case 变成看不见的误杀或漏判。

Bedrock Converse API 示例

AWS 推荐用 Converse API 调用 Bedrock 支持的 message-based 模型。最小 Python 示例：

import boto3
import json

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

policy_prompt = """
You are a text moderation system.
Return one valid JSON object and no Markdown.
Classify the text using these categories:
- VIOLENCE
- HATE
- SELF_HARM
- FRAUD
- PRIVACY
- OK

If uncertain, choose REVIEW and set needs_human_review to true.
Contract:
- decision must be one of ALLOW, REVIEW, BLOCK.
- categories must use only the categories above.
- reason must be one short sentence.
- needs_human_review must be true or false.
""".strip()

user_text = "Send me your bank login and I will unlock the prize payout today."

response = bedrock.converse(
    modelId="us.amazon.nova-2-lite-v1:0",  # US geo profile; switch to eu.amazon... or global.amazon... if required.
    system=[{"text": policy_prompt}],
    messages=[
        {
            "role": "user",
            "content": [{"text": user_text}]
        }
    ],
    inferenceConfig={
        "maxTokens": 300,
        "temperature": 0.7,
        "topP": 0.9
    }
)

text = response["output"]["message"]["content"][0]["text"]
result = json.loads(text)

if result.get("decision") not in {"ALLOW", "REVIEW", "BLOCK"}:
    raise ValueError(f"Unexpected moderation decision: {result!r}")

print(result)

记住两个实现细节：

Bedrock 文档把 messages、system、inferenceConfig 列为 Converse 的一等字段，所以这套模式更容易在受支持模型之间保持一致。
AWS 的 Nova 2 content moderation guide 把推荐默认值设为 temperature 0.7、top-p 0.9；AWS 自己的评估也显示这些默认值在多种内容类型上表现良好。如果你需要完全确定性的输出，可以测试 temperature 0，但上线前要确认审核准确率是否仍然能接受。

见 Nova 2 Lite model IDs、Inference using Converse API 和 Prompting Amazon Nova 2 for content moderation。

什么时候用 XML 而不是 JSON

如果现有审核栈已经解析 tagged output，或者你想要一种人能读、又比自由文本更容易校验的格式，可以用 XML。

AWS 教程给了一个 XML 结构，包含明确 tag：是否违反策略、分类列表和解释。下面这些情况适合选 XML：

审核 pipeline 里已经有 rule-based XML parser
想把解释保存在可预测的 envelope 里
非 LLM 系统接 XML 比接 JSON 更简单

新应用后端优先选 JSON：大多数 app backend 和分析 pipeline 更自然地校验 JSON，也能更快发现 malformed JSON。

Prompt 审核与 Bedrock Guardrails

选项	适合什么	主要限制
Nova 2 Lite prompt 审核	自定义策略解释、产品特定分类、可解释的队列决策	输出质量取决于 prompt 质量和复核纪律
Bedrock Guardrails	平台级控制、跨模型调用复用的安全层、集中治理	对产品特定 taxonomy 不如自定义审核 prompt 灵活

AWS 的 Nova 文档说明 Nova 2 Lite 支持 Bedrock Guardrails，所以可以分层使用：

Guardrails 负责宽泛基线控制
Nova prompt 审核负责应用特定策略分类
模糊或高影响 case 进入人工复核

上生产前怎么评估

上线前先做 evaluation set；三个样例 prompt 不够。

至少包含：

明确违规
明确安全内容
边界玩笑或讽刺
分类重叠 case
短文本、长文本和格式混乱的文本
来自近期 moderator dispute 的策略更新样例

然后检查四件事：

检查项	看什么
Schema reliability	模型是否每次都返回有效 JSON 或 XML
Category quality	多种风险同时出现时，分类是否正确
Review discipline	系统是否会升级模糊内容，而不是强行给出虚假确定性
Operational fit	延迟和成本是否适合队列规模

AWS 教程还提醒，要针对自己的 workload 测试 reasoning 设置。对高吞吐 pipeline，AWS 建议考虑关闭 reasoning mode 以降低延迟和成本，然后验证准确率是否仍适合你的内容。

AWS 用默认 inference settings 和结构化 XML prompt 在三个公开数据集上 benchmark 了 Nova 2 Lite（评估日期 2026-05-18）：

Dataset	Nova 2 Lite F1	Content type
Aegis AI Content Safety 2.0	85.84%	明确的 AI safety policy violations
WildGuardMix	84.73%	AI safety policy violations
Jigsaw Toxic Comment	56.53%	模糊、依赖上下文的 toxicity

Jigsaw 的低分划出了风险边界。Aegis 和 WildGuard 覆盖更清楚、定义更明确的违规；Jigsaw 更主观，也更依赖上下文。如果你的队列里有 slang、coded language 或内部梗，就要计划更多 REVIEW 决策和人工抽样，不要默认 80%+ F1 会直接迁移。完整方法见 Prompting Amazon Nova 2 for content moderation。

常见失败模式

上线期间，先检查策略设计和动作设计，再归因到模型。

尽早盯住这些错误：

分类太宽，导致 moderator 对正确 label 无法达成一致
prompt 同时要求审核和改写建议，任务被搅混
后端把所有非 OK 输出都自动 block
没有 review 状态，边界内容变成隐藏误杀
prompt 里某一类示例太多，影响后续输出
团队把模型解释误当成 compliance record

什么时候从 fine-tuning 或专用分类器开始

出现下面情况时，转向模型定制或专用分类器：

策略稳定，高流量值得额外投入
小标签集上需要更紧的一致性
reviewer 已经积累了高质量标注数据集
成本结构更适合一个行为更窄的模型，而不是通用 prompt pipeline

AWS 2026-05-18 的文章明确对比了两条路径：prompting 是更快的策略迭代路径；当策略和 workload 足够稳定时，customization 才是更重的路径。

第一版上线清单

第一次生产发布前，逐项确认：

策略有命名分类、示例和明确升级规则
模型返回的结构由后端严格校验
系统支持 ALLOW、REVIEW、BLOCK，而不是只有二元决策
模糊或多分类 case 会进入人工队列
prompt、输出和最终动作有安全访问控制下的日志
moderator 能报告 false positives 和 false negatives
团队可以更新策略文本，而不必重新部署整个应用

如果缺少策略分类、schema 校验、review 队列或安全日志，就不要把审核直接放在用户可见的关键路径上。

AWS Machine Learning Blog: Prompting Amazon Nova 2 for content moderation
AWS Docs: Prompting Amazon Nova 2 for content moderation
AWS Docs: Nova 2 Lite model card
AWS Docs: What is Amazon Nova 2?
AWS Docs: Inference using Converse API
AWS Docs: Responsible use for Amazon Nova 2
MLCommons: AILuminate

Amazon Nova 2 Lite 内容审核：Bedrock 上的 Prompt、Guardrails 与评估清单（2026）

结论先说

2026-05-18 发生了什么

什么时候 prompt 审核够用

开始前要准备什么

审核请求结构

第一个策略怎么设计

更安全的 JSON Prompt 模板

Bedrock Converse API 示例

什么时候用 XML 而不是 JSON

Prompt 审核与 Bedrock Guardrails

上生产前怎么评估

常见失败模式

什么时候从 fine-tuning 或专用分类器开始

第一版上线清单

FAQ

Amazon Nova 2 Lite 足够做生产内容审核吗？

审核输出应该用 JSON 还是 XML？

Bedrock Guardrails 会替代 prompt 审核吗？

可以直接复制 MLCommons AILuminate taxonomy 吗？

核验说明

相关文章

Claude Platform on AWS 教程（2026）：如何接入 Claude Code 和 Anthropic API

如何用 Strands 和 Exa 构建 Web Search Agent（2026）

Claude Fable 5 网络安全提示词怎么写：避开误拦和越界请求