Bedrock自动Prompt优化工具发布

问题：大规模提示词工程仍然困难重重

在 Amazon Bedrock 上将提示词迁移到新模型，或针对您当前的模型优化提示词，仍然是构建生成式 AI 应用程序中最费力的工作之一。假设您已经构建并部署了一个生成式 AI 应用程序。它正常运行。您的提示词已调优，输出结果一致，用户很满意。然后 Amazon Bedrock 上推出了一个新模型，速度更快、成本更低、能力更强，您必须决定是否迁移。

这个决定应该很直接，但实际上很少这样。

客户在迁移到新模型时花费数天到数周的时间来优化提示词并重新评估响应。当他们尝试改进当前模型的性能时，投入同样的精力。这个周期每次都是一样的。重写提示词，针对测试用例运行，比较结果，调整，然后重复。现在将这个工作乘以生产中的每个提示词模板和每个值得评估的模型候选。结果是一个随着您的野心而扩展的问题。

今天，Amazon Bedrock 推出了 Advanced Prompt Optimization，这是一个可以针对 Bedrock 上最多 5 个模型优化提示词并比较原始和优化性能的工具。在本文中，我们向您展示如何使用 Amazon Bedrock Advanced Prompt Optimization 在单个作业中跨多个模型迁移和优化提示词。这种方法用有指导性的、指标驱动的工作流程取代了数天的手动迭代。

挑战：这如何破坏生成式 AI 软件开发生命周期

提示词迁移和优化是生成式 AI 开发生命周期中的一个关键瓶颈。当这个步骤缓慢或需要手动操作时，您会在 4 个方面感受到影响：

模型锁定。团队避免迁移，因为重新调优的时间和精力太高，即使更新的模型可以降低延迟和推理成本。

性能不足。当您为一个模型编写提示词时，您不会使用另一个模型的完整能力。

回归盲目。没有针对基准真实情况的系统化评估，您无法区分"不同"和"更差"。团队在不知情的情况下发布降级的输出。

迭代周期缓慢。每次提示词更改都需要手动 A/B 测试，这使工程师陷入评估循环中，而不是构建功能。

您需要一个具有内置评估功能的提示词优化器，可以同时测试多个模型。它还应该让您引导提示词和响应如何变化，使优化基于实际用例和数据。

架构：指标驱动的反馈循环

Amazon Bedrock Advanced Prompt Optimization 从您的评估指标向后工作。系统不是启发式地重写提示词，而是以强化学习风格的反馈循环运行，而不改变模型权重：

您提供一个提示词模板、示例用户输入（文本或多模态）、可选的基准真实答案和一个评估指标。

优化器将您的模板和输入发送到您选择的推理模型。它根据您的指标评估响应，然后重写提示词。

循环重复（评估、重写、评估），针对您的评估指标迭代地优化您的提示词。

输出是原始和优化的提示词。对于每一个，您都能获得评估分数、每个样本的首 token 时间 (TTFT)，以及按按需定价的推理成本估计。

这个架构是模型无关的。您可以在 Amazon Bedrock 上使用您选择的模型。单个作业最多可以同时针对 5 个模型。您为每个候选模型获得一个优化的提示词，以及质量、延迟和成本的直接比较，全部来自一次提交。

下图显示了这些部分如何组合在一起。

什么是 TTFT？ TTFT（首 token 时间）衡量模型开始响应的速度：从发送请求到接收第一个 token 的时间。这是感知延迟的有用代理，比如聊天机器人开始输入。

TTFT 捕捉响应开始的时刻，因此将其与输出 token 计数配对以获得完整的延迟图景。由于它也反映了实时基础设施条件，将单次运行值解读为方向信号。

Advanced Prompt Optimization 针对您的质量指标（分数）进行优化，并报告每个结果旁边的 TTFT 和成本。这为您提供了质量、延迟和成本的完整视图，以便有信心地选择正确的提示词。

解决方案：Amazon Bedrock Advanced Prompt Optimization

Amazon Bedrock 推出了 Advanced Prompt Optimization，这是一个可以针对 Bedrock 上最多 5 个模型优化提示词并比较原始和优化性能的工具。您可以以两种方式使用它：

模型迁移。选择您的当前模型作为基线，再加上最多 4 个候选模型。您为每个模型获得优化的提示词和并排比较。

同模型改进。仅选择您的当前模型。您无需更改其他任何内容就能获得更好的提示词。

三种评估模式

您为每个提示词模板选择一种评估方法，每种方法服务于不同的用例。下表总结了何时使用每一种。

如果您省略所有评估字段，系统会使用结合准确性、答案完整性和写作风格评分的内置默认值。我们建议您定义自己的评估指标以获得最佳结果。如果您有多个优化目标，可以在评分算法中为每个标准创建带有权重的复合指标。您的指标输出必须是一个数字。

Advanced Prompt Optimization 支持多模态输入：PNG、JPG、JPEG、GIF、WebP 和 PDF 文件，通过 Amazon Simple Storage Service (Amazon S3) URI 引用。您可以针对文档分析、图像分类、视觉问题回答和其他结合文本和视觉输入的任务优化提示词。

开始使用：控制台

本节逐步演示控制台工作流程：您创建作业、选择模型、上传输入数据集、提交优化并读取结果。Advanced Prompt Optimization 登陆页面列出您的作业及其状态，并提供一个按钮来开始新作业，如以下屏幕截图所示。

Advanced Prompt Optimization 登陆页面

步骤 1：创建提示词优化作业

在 Amazon Bedrock 控制台的左导航窗格中，选择 Advanced Prompt Optimization。在登陆页面上，选择 Create prompt optimization。下一个屏幕截图显示创建页面。

步骤 1：创建提示词优化作业

步骤 2：选择推理模型

在"Model selection（模型选择）"部分，选择 Add model。将您的当前模型选择为基线。要添加候选模型，再次选择 Add model 并选择最多 4 个额外的模型。如果您不是迁移，仅选择您的当前模型。

步骤 2 选择推理模型

步骤 3：准备输入数据集 (JSONL)

您的输入文件使用 JSONL 格式，每行一个 JSON 对象，每一行是一个要优化的提示词模板。有关完整详情，请参阅技术文档。以下代码段显示了核心架构。

{
    "version": "bedrock-2026-05-14",
    "templateId": "unique-id-for-this-template",
    "promptTemplate": "Your prompt with {{variableName}} placeholders",
    "evaluationSamples": [
        {
            "inputVariables": [
                {"variableName": "value"}
            ],
            "referenceResponse": "Expected output (optional but recommended)"
        }
    ]
}

然后添加其中一个评估方法字段。有关更多详情和总体指导，请参阅技术文档。以下代码段显示了 AWS Lambda 指标选项。

{
    "evaluationMetricLambdaArn": "arn:aws:lambda:us-west-2:111122223333:function:my-metric",
    "customEvaluationMetricLabel": "my_score_name"
}

以下代码段显示了 LLM-as-a-Judge 选项。

{
    "customLLMJConfig": {
        "customLLMJPrompt": "Your rubric. Use {{prompt}}, {{response}}, {{referenceResponse}} as placeholders.",
        "customLLMJModelId": "us.anthropic.claude-opus-4-6-v1"
    },
    "customEvaluationMetricLabel": "my_judge_metric"
}

编写您的评审标准。在您的 customLLMJPrompt 中，使用双花括号引用 3 个占位符：{{prompt}}（完全呈现的提示词，即提示词模板与评估样本的组合）、{{response}}（模型输出）和 {{referenceResponse}}（基准真实情况）。Advanced Prompt Optimization 为每个候选模型和样本替换这些值，然后将标准发送给评审模型。有关详情，请参阅 Use an LLM as a judge。

以下代码段显示了引导标准选项。

{
    "steeringCriteria": [
        "be concise",
        "use professional tone",
        "avoid speculation"
    ]
}

步骤 4：上传并提交

步骤 5：解释结果

结果页面显示 4 个要素：优化前后的评估分数（按模型）、准备就绪可复制部署的优化提示、各模型间的首个令牌到达时间（TTFT），以及基于按需推理定价的成本估计。

以下截图展示了本文所运行示例的实际结果：NESTFUL 和 XSum。我们通过 API 和 SDK（见下一部分）使用教程 GitHub 仓库中的数据集提交了它们。每个作业使用 5 个评估样本。无论作业从控制台还是 API 创建，控制台都会呈现相同的结果。你可以使用该仓库作为参考，了解预期的输出格式，并在自己的账户中重现这些视图。你的结果将因数据集、提示复杂度和模型选择而异。摘要视图给出优化前后的首要分数。以下截图显示 NESTFUL 运行（函数调用，Amazon Nova 2 Lite），其中精度从 0.267 提升至 0.647。

NESTFUL：摘要表优化结果

详情视图并排显示原始和优化后的提示，以及每个样本的指标和完整的令牌及延迟明细，如以下截图所示。

NESTFUL：详细结果视图

以下截图显示 XSum 运行的摘要视图（摘要任务，Claude Haiku 4.5）。质量分数从 0.550 提升至 0.743，同时输出令牌从 51 降低至 28。

XSum：摘要表优化结果

以下截图显示 XSum 的相应详情视图。

XSum：详细结果视图

开始使用：API / SDK（boto3）

你也可以用 boto3 驱动整个工作流。以下代码创建一个针对两个候选模型的作业。

import boto3

bedrock = boto3.client("bedrock", region_name="us-west-2")

response = bedrock.create_advanced_prompt_optimization_job(
    jobName="my-migration-job",
    modelConfigurations=[
        {"modelId": "us.amazon.nova-2-lite-v1:0"},              # candidate 1
        {"modelId": "us.anthropic.claude-haiku-4-5-20251001-v1:0"}, # candidate 2
    ],
    inputConfig={
        "s3Uri": "s3://amzn-s3-demo-bucket/inputs/prompts.jsonl"
    },
    outputConfig={
        "s3Uri": "s3://amzn-s3-demo-bucket/outputs/migration-job/"
    },
)

job_arn = response["jobArn"]
print(f"Job submitted: {job_arn}")

作业异步运行，所以轮询其状态直到达到终止状态。以下代码每 60 秒检查一次。

import time

while True:
    info = bedrock.get_advanced_prompt_optimization_job(jobIdentifier=job_arn)
    status = info["jobStatus"]
    print(f"Status: {status}")

if status in ("Completed", "Failed", "Stopped"):
        break
    time.sleep(60)

作业完成后，它会自动将 JSONL 结果文件写入到启动作业时选择的 Amazon S3 输出位置。以下代码使用 boto3 下载该文件。

# Results land at: s3://output-uri/job-id/advanced_prompt_optimization_results.jsonl
s3 = boto3.client("s3")
job_id = job_arn.rsplit("/", 1)[-1]
result_key = f"outputs/migration-job/{job_id}/advanced_prompt_optimization_results.jsonl"
s3.download_file("amzn-s3-demo-bucket", result_key, "results.jsonl")

完整示例：多模态输入的指向条件

以下示例构建一个指向条件数据集，将问题与 PDF 文档配对，将其写入 JSONL，并上传到 Amazon S3。

import json

# Build your input dataset
record = {
    "version": "bedrock-2026-05-14",
    "templateId": "document-qa-v1",
    "promptTemplate": "Answer the question based on the document.\n\nQuestion: {{question}}",
    "steeringCriteria": [
        "State the answer first, then provide supporting evidence from the document.",
        "Use exact figures from the document. Do not round or approximate.",
        "Keep the response under 100 words."
    ],
    "evaluationSamples": [
        {
            "inputVariables": [
                {"question": "What was the total revenue in Q4?"}
            ],
            "inputVariablesMultimodal": [
                {
                    "financial_doc": {
                        "type": "PDF",
                        "s3Uri": "s3://amzn-s3-demo-bucket/assets/q4_report.pdf"
                    }
                }
            ],
            "referenceResponse": "Total Q4 revenue was $4.2 billion, a 12% increase year-over-year."
        }
    ]
}

# Write JSONL (one record per line)
with open("input.jsonl", "w") as f:
    f.write(json.dumps(record) + "\n")

# Upload to Amazon S3 and submit
s3.upload_file("input.jsonl", "amzn-s3-demo-bucket", "inputs/prompts.jsonl")

在运行作业之前，了解服务限制和一些能保证优化顺利进行的最佳实践会有所帮助。下表列出了每个作业的限制。

有几个最佳实践比限制更重要。每个模板选择单个评估方法，因为不支持将 steeringCriteria 与 customLLMJConfig 或 evaluationMetricLambdaArn 组合使用。在编写模板时，使用双花括号（{{variable}}）而不是单花括号。给 inputVariables 中的每个键它自己的对象，所以应为 [{"var1": "val"}, {"var2": "val"}] 而不是 [{"var1": "val", "var2": "val"}]。最后，在数据集中混合简单和困难的示例。全部简单的数据集不会推动优化器，而全部困难的数据集让它无法学习。

如果你使用 LLM-as-a-Judge，当前有 3 个裁判模型可用：anthropic.claude-opus-4-6-v1、anthropic.claude-sonnet-4-5-20250929-v1:0 和 anthropic.claude-sonnet-4-6。有关按区域的模型可用性，请参阅"支持的区域、模型和配额"。

以下数据来自本文为此运行的 4 个真实高级提示优化作业，这些作业在 AWS US East（N. Virginia）区域进行，每个作业优化 5 个评估样本。这些运行使用小样本集来说明工作流，而不是建立正式基准。请将这些数字视为优化器出现的收益类型的说明，而不是已发布的基准结果。你可以使用教程 GitHub 仓库中的数据集重现它们。

关于命名的说明。XSum、NESTFUL、MM-VQA 和 IFBench 是教程仓库中的示例数据集。它们不是你选择的模式。你实际选择的是评估方法（Lambda 指标、LLM-as-a-Judge 或指向条件），如"三种评估模式"所述。你根据用例为每个提示模板选择一个。这 4 个数据集只是演练了所有 3 种方法，这样你就可以看到每种方法的实际应用。

下表总结了 4 次运行中的质量收益。

下一个表格显示了质量收益旁边的延迟和令牌计数变化。

理解成本和延迟权衡

优化后的提示不仅改变质量，还改变你的支付金额和等待时间。下面是如何读取这些数字的方式。

当你优化提示时，令牌计数会发生变化，这就是驱动成本的因素。Bedrock 按输入和输出令牌计费，输出令牌的价格高于输入令牌。读取这些结果的最清晰方式是比较优化前后的输入和输出令牌计数。4 次运行落在不同的位置，你可以控制落在哪里。

优化器最大化你的质量指标（分数）并报告令牌、TTFT 和成本，让你对每个结果有全面的了解。你也可以直接塑造输出：在评估条件中添加一个目标以奖励更短的响应，优化器就会倾向于生成这样的提示。

XSum 交付了 35% 的质量收益。指向条件（"正好一句话，25 个词或更少"）产生了更紧凑的答案，将输出令牌从 51 降低至 28。优化后的提示承载了这一指导，所以输入令牌从 720 增长至 1,601。你在输入上花费更多以获得更高质量、更简洁的答案，当短的准确响应是目标时这是一个强有力的权衡。

NESTFUL 为精度投入了令牌。函数调用提示从约 1.3K 增长至约 3.8K 输入令牌，因为它添加了显式分解规则和工作示例，精度翻了一倍多（+143%）。你为每次调用花费更多以获得实质性的质量改进。

MM-VQA 以最小的成本变化产生了最大的质量收益。文档 VQA 上的 ROUGE-L 从 0.339 上升至 0.777（+129%），同时输入令牌仅增长约 7%（从 30,998 到 33,057），输出令牌从 142 略降至 136。在这里优化器锐化了提示而不是延长它，所以大质量收益只伴随着很小的成本变化。

IFBench 的质量提升了一倍以上。在这项由 LLM 充当评判者的任务中，约束遵循度从 0.413 上升到 0.890（提升 115%）。优化后的提示词使用了更多 token，因为它明确列出了模型必须满足的约束。这使它成为 4 个任务中 token 使用量最高的一个，也是通过投入更多 token 换取质量提升的最典型案例。

4 次运行呈现出的规律一致：优化带来了显著的质量提升，而且每个优化后的提示词使用的总 token 数都更多。增幅从大约 7%（MM-VQA）到数倍（IFBench）不等。当输出缩短时（如 XSum 和 MM-VQA），总 token 数的增幅会有所缓和。优化器会提供准确的 token 数量和评分，因此你可以根据自己的流量计算成本，并选择适合工作负载的权衡方案。与手动调优提示词相比，这种量化决策能力才是真正的优势。

解读成本列。Bedrock 按输入和输出 token 计费，且输出 token 通常比输入 token 更昂贵。对于低流量、高风险的任务，通过增加输入 token 获得更高的评分可能是非常划算的权衡；而高流量端点则需要控制 token 数量的增长。由于输出 token 的价格更高，你可以在评估标准中加入减少输出 token 的目标，从而在优化质量的同时降低推理成本。

结果揭示了什么

与手动调优提示词相比，Advanced Prompt Optimization 带来的不仅仅是更高的评分。每次运行都会在单个作业中生成一组可量化、可比较的结果，涵盖质量、延迟和成本。这会将一个“感觉更好”的提示词转变为一项能够在设计评审中得到充分论证的变更。

在解读自己的结果时，需要注意以下几个陷阱：

进行真实的成本计算。即使更高的评分会增加输入 token，这仍然可能是正确的选择。由于输出 token 比输入 token 更昂贵，优化后更简短的响应可以抵消一部分新增的输入成本。请根据你的请求量计算实际的输入加输出成本，从而将质量提升与真实的单次调用成本进行权衡。

将 TTFT 视为方向性指标。Bedrock 上的 TTFT 会受到实时网络状况、容量和时段的影响，而更长的输入提示词往往会提高 TTFT。应将报告的 TTFT 作为粗略参考信号，并通过自己多次重复测量来确认工作负载的延迟。

谨慎选择指标。优化器会严格最大化你所衡量的内容，因此需要定义能够反映实际成功与否的指标。通过混合简单和困难的样本，为优化器提供足够的提升空间。评估数据集应尽可能覆盖预期的生产数据分布，从而让优化后的提示词具备良好的泛化能力。

在由 LLM 充当评判者的评分标准中使用正确的占位符。使用双花括号引用 {{prompt}}、{{response}} 和 {{referenceResponse}}，以便优化器替换正确的值，并让评判模型准确地为每个样本评分。

使评估方法与目标相匹配。引导标准会指导重写器，并用于生成综合评分，因此适合语气和格式等定性目标。当你需要明确的阈值（例如准确率达到或超过 0.9）时，应选择 Lambda 指标，以获得精确且确定性的评分。

注意：本文所展示的是教程数据集（每个数据集包含 5 个样本）的单次运行结果。实际结果会因数据分布、提示词复杂度和模型选择而异。

借助 Amazon Bedrock Advanced Prompt Optimization，你可以消除提示词迁移和优化过程中的人工瓶颈。无需再花费数天反复试错，只需提交作业、定义成功标准，即可一次性获得适用于多个模型的优化提示词，以及经过量化的改进结果。

不同用例的工作流保持一致。你可能会为了节省成本而迁移到更新的模型，评估多模态模型在文档理解方面的能力，或者从当前配置中挖掘更多性能。无论哪种情况，你都只需提供模板、数据和指标，然后让优化器弥合差距。

如需了解更多信息，请参阅以下资源：

Advanced Prompt Optimization 的工作原理。

API 参考：CreateAdvancedPromptOptimizationJob。

GitHub：三种评估模式的教程 notebook。

文档：准备输入数据集。