构建高效的奖励函数可以帮助你根据自身需求定制 Amazon Nova 模型，而 AWS Lambda 提供了可扩展且具成本效益的基础。Lambda 的无服务器架构让你能够专注于定义质量标准，而将计算基础设施交给它处理。
Amazon Nova 提供了多种定制方式，其中强化微调（RFT）因能够通过迭代反馈教会模型所需行为而尤为突出。不同于需要数千个带有推理路径标注样本的监督微调（SFT），RFT 是从最终输出的评估信号中学习的。RFT 的核心是奖励函数，它是一种引导模型生成更优回答的评分机制。
本文展示了 Lambda 如何为 Amazon Nova 定制提供可扩展、低成本的奖励函数。你将了解如何在适用于客观可验证任务的可验证奖励强化学习（RLVR）与适用于主观评估的 AI 反馈强化学习（RLAIF）之间做选择，如何设计有助于防止奖励黑客的多维奖励系统，如何针对训练规模优化 Lambda 函数，以及如何使用 Amazon CloudWatch 监控奖励分布。文中还包含可运行的代码示例和部署指导，帮助你开始实验。
使用 AWS Lambda 构建基于代码的奖励
你可以通过多种路径定制基础模型，每种方式都适用于不同场景。当你拥有清晰的输入输出示例，并希望教授特定响应模式时，SFT 表现出色。它尤其适合分类、命名实体识别，或让模型适应特定领域术语和格式规范等任务。当期望行为可以通过示例展示时，SFT 很有效，因此很适合教授一致的风格、结构或事实知识迁移。不过，有些定制挑战需要不同的方法。当应用需要模型同时平衡多个质量维度，例如客服回复既要准确、富有同理心、简洁，又要符合品牌风格，或者为成千上万条数据标注推理路径并不现实，那么基于强化的方法就是更好的选择。RFT 通过从评估信号中学习来应对这些场景，而不要求用穷尽式标注来演示正确推理过程。
基于 AWS Lambda 的奖励函数通过反馈式学习简化了这一过程。你不必向模型展示数千个高质量示例，而是提供提示词并定义为回答打分的评估逻辑，然后模型通过迭代反馈学习改进。这种方式需要更少的标注样本，同时能让你精确控制期望行为。多维评分能够捕捉细致的质量标准，防止模型利用捷径，而 Lambda 的无服务器架构则无需基础设施管理即可处理变化的训练负载。最终，Nova 定制既让没有深厚机器学习背景的开发者也能上手，又足够灵活，可满足复杂的生产场景需求。
基于 AWS Lambda 的奖励如何工作
RFT 架构将 AWS Lambda 用作无服务器奖励评估器，并与 Amazon Nova 训练流水线集成，形成一个引导模型学习的反馈回路。流程开始于训练任务针对每个训练提示生成 Nova 模型的候选回答。这些回答会流入你的 Lambda 函数，由它从正确性、安全性、格式和简洁性等维度评估质量。函数随后返回标量数值分数，最佳实践通常是控制在 -1 到 1 的范围内。更高的分数会引导模型强化产生这些分数的行为，而更低的分数则会让模型远离导致低质量回答的模式。这个循环会在整个训练过程中重复数千次，逐步将模型塑造成能够持续获得更高奖励的响应方式。
这一架构将多项 AWS 服务整合为一套连贯的定制方案。Lambda 执行你的奖励评估逻辑，并通过自动扩展处理变化的训练需求，无需你预置或管理基础设施。Amazon Bedrock 提供了完全集成 Lambda 支持的托管式 RFT 体验，并通过简单的应用程序编程接口（API）为 RLAIF 实现提供 AI 裁判模型。对于需要更高级训练控制的团队，Amazon SageMaker AI 可通过 Amazon SageMaker AI Training Jobs 和 Amazon SageMaker AI HyperPod 提供选项，两者都支持相同的基于 Lambda 的奖励函数。Amazon CloudWatch 实时监控 Lambda 性能，记录有关奖励分布和训练进展的详细调试信息，并在出现问题时触发警报。底层则是 Amazon Nova 本身，其模型定制方案针对各种用例进行了优化，能够有效响应奖励函数提供的反馈信号。
这种无服务器方法使 Nova 定制具有成本效益。Lambda 无需进行基础设施调优或容量规划，就能从初始实验阶段每秒处理 10 次并发评估，自动扩展到生产训练阶段 400+ 次评估。单个 Lambda 函数可以同时评估多个质量标准，从而提供细致的多维反馈，防止模型利用过于简单的评分捷径。该架构既支持通过 RLVR 进行客观验证，例如针对测试用例运行代码或验证结构化输出，也支持通过 RLAIF 进行主观判断，即由 AI 模型评估语气、帮助性等特征。你只需按实际评估计算时间付费，且计费粒度精确到毫秒，因此实验成本更可控，生产成本也能与训练强度保持匹配。对迭代开发而言，最有价值的一点或许是 Lambda 函数可以作为可复用的“Evaluator”资产保存到 Amazon SageMaker AI Studio 中，让你在多次训练迭代中持续保持一致的质量衡量方式。
选择合适的奖励机制
成功实施 RFT 的基础是选择正确的反馈机制。两种互补的方法适用于不同用例：RLVR 和 RLAIF 都是在大语言模型（LLM）完成初始训练后用于微调的技术。它们最大的区别在于向模型提供反馈的方式不同。
RLVR（Reinforcement Learning via Verifiable Rewards）
RLVR 使用确定性代码来验证客观正确性。它适用于答案可以通过数学或逻辑方式验证的领域，例如求解数学题。RLVR 使用确定性函数对输出进行评分，而不是使用学习得到的奖励模型。对于创意写作或品牌语调这类不存在绝对真实标准的任务，RLVR 并不适用。
RLVR 函数会以编程方式将输出与真实答案进行比对验证。在这里，示例任务是情感分析。
为了实现有效训练，你的 RLVR 函数应包含三个关键设计要素。第一，构建平滑的奖励地形，给予部分分数，例如即使最终答案错误，也可因响应结构正确而给予 format_score 分值。这样可以避免二元评分悬崖，使学习更容易。第二，实现良好的提取逻辑，通过多种解析策略优雅处理不同的响应格式。第三，在每个步骤都验证输入，并采用防御式编码实践，防止因输入格式错误而导致崩溃。
RLAIF（Reinforcement Learning via AI Feedback）
RLAIF 使用 AI 模型作为裁判来进行主观评估。RLAIF 可达到与 RLHF（基于人类反馈的强化学习）相近的性能，同时速度更快、成本更低。这里给出一个用于情感分类的 RLVR Lambda 函数代码示例。
RLAIF 函数会像下面的示例代码所示那样，将判断工作交给能力足够的 AI 模型。
在实现 RLAIF 函数时，应考虑用全局变量初始化客户端，以降低整体调用延迟。要妥善处理限流异常，避免训练中断。将 temperature 设置为 0.0，以获得确定性的裁判分数，这有助于模型一致性。同时提供清晰的评分标准，以帮助裁判给出校准后的分数。
编写优质奖励函数时的注意事项
要为 RFT 编写好的奖励函数，应从简单开始，构建平滑的奖励地形，而不是二元悬崖；确保奖励与真实目标一致，避免被“黑”掉；针对复杂任务使用密集型或塑形奖励；提供清晰信号；并让奖励具备可验证性和一致性。
奖励信号应为“走在正确轨道上”的情况提供部分分数。这种细粒度反馈可以让模型从渐进式改进中学习，而不是一直等到出现完美回答。对于复杂的多步骤任务，应对中间进展给予奖励（塑形），而不是只奖励最终结果（稀疏奖励）。
奖励应从多个维度评估模型表现，例如正确性、对输入的忠实度、安全性或策略一致性、格式和简洁性等。
要避免模型利用漏洞，例如靠运气猜中或进行重复性动作；要让任务尽量无法通过猜测取巧。
可以使用执行代码或解析特定答案标签（例如 <answer>）的评分器，在没有人工参与的情况下验证正确性。
对于无法直接程序化验证答案的任务，例如摘要，可使用一个独立且能力足够的模型作为“LLM Judge”。但你必须先评估这个裁判，确保其评分稳定且与人类偏好一致。
在训练循环中优化奖励函数执行
当奖励函数能够正确工作后，优化可以帮助你在控制成本的同时更快完成训练。本节介绍了适用于不同工作负载的一些技术。多项优化技术的效果会叠加。一个配置良好的 Lambda 函数，如果具备合适的批处理大小、并发设置、冷启动缓解和错误处理能力，评估响应的速度可能比朴素实现快 10 倍，同时成本显著更低，训练可靠性也更好。在定制流程早期投入优化，能在整个训练阶段持续带来回报，包括缩短迭代时间、降低计算成本，并在问题演变成需要高成本重训之前发现它们。
对多个函数共享的依赖项使用 layers，对函数专用逻辑使用部署包。对于 RLAIF 实现，应将 AWS Identity and Access Management（IAM）权限附加到 Lambda 执行角色。遵循最小权限原则，应将 Resource ARN 限定到你作为裁判使用的特定基础模型，而不是使用通配符。
优化基于 Lambda 的奖励函数，需要理解不同训练环境如何与无服务器评估交互，以及架构选择如何影响吞吐、延迟和成本。同步与异步处理模型的优化空间差异很大，因此针对具体环境进行调优，对于生产规模的定制至关重要。
Amazon SageMaker AI Training Jobs 采用同步处理方式，先生成 rollout，再以并行批次进行评估。这种架构在批处理大小和并发管理方面带来了独特的优化机会。lambda_batch_size 参数默认值为 64，用于确定 Lambda 单次调用评估多少样本。对于能在毫秒级完成的快速奖励函数，可以调高这个值；但对于接近超时阈值的复杂评估，则应适当调低。lambda_concurrency 参数控制并行执行，默认 12 个并发调用，对于生产工作负载往往偏保守。快速奖励函数通常能从更高的并发中受益，有时可达到 50 次或更多同时执行，但你必须监控账户级 Lambda 并发限制，因为它会限制某一区域内函数的总并发执行数。
Amazon SageMaker AI HyperPod 则采用根本不同的方法，通过异步处理逐个生成和评估样本，而不是使用大批量处理。这种逐样本架构天然支持更高吞吐，默认配置下无需特别调优，就能通过 Lambda 实现每秒 400 笔事务。若要在此基础上进一步扩展，则需要协调调整 HyperPod 配方参数，尤其是控制工作器并行度的 proc_num 和 rollout_worker_replicas。在大幅增加工作器规模时，应考虑按比例提升 generation_replicas，避免生成成为瓶颈而评估能力处于闲置状态。
Lambda 配置会直接影响训练速度和可靠性：
冷启动缓解能够防止延迟峰值，避免训练变慢并增加成本。应将部署包控制在 50MB 以下，以尽量减少初始化时间。这通常意味着排除不必要的依赖，并为大型共享库使用 Lambda layers。要在多次调用之间复用连接，可将 Amazon Bedrock runtime client 等客户端初始化放在全局作用域，而不是放在 handler 函数内部，让 Lambda 执行环境在调用之间维持这些连接。使用 Lambda Insights 对函数进行性能分析，以识别瓶颈。将评估规则、验证规则或配置参数等高频访问数据缓存到全局作用域中，这样 Lambda 每个容器只需加载一次，而不是每次调用都加载。对于在训练期间处理数千次评估的 Lambda 函数，这种“全局初始化、handler 层执行”的模式尤其有效。
对于使用 Amazon Bedrock 模型作为裁判的 RLAIF 实现，还需要考虑一个重要权衡。更大的模型判断更可靠，但吞吐更低；更小的模型吞吐更高，但能力可能较弱。应选择足以胜任任务的最小裁判模型，以最大化吞吐。在扩展到完整训练之前，应先评估裁判的一致性。
真实系统中会遇到各种故障，例如网络抖动、服务临时不可用，或偶发的 Lambda 超时。我们没有让单次失败拖垮整个训练任务，而是构建了健壮的重试机制，能够自动处理超时、Lambda 失败和瞬时错误。系统会通过指数退避智能重试失败的奖励计算，为临时问题留出恢复时间。如果一次调用在三次重试后仍然失败，你会收到清晰、可执行的错误消息，明确指出具体问题是超时、权限问题，还是奖励逻辑中的漏洞。这种透明性让你无需在晦涩日志中翻找，就能快速定位并修复问题。
无论是监控训练进度，还是排查问题，可观测性都至关重要。我们会自动将训练流水线各阶段的全面信息记录到 CloudWatch，包括每个训练步骤的指标，例如逐步训练奖励分数，以及各流水线组件的详细执行轨迹。这种细粒度日志让你能够轻松实时跟踪训练进度，验证奖励函数是否按预期对回答打分，并在出现问题时快速诊断。例如，如果你发现训练没有改进，就可以在 CloudWatch 中检查奖励分布，看看函数是否大多返回 0，或是否缺乏足够信号。
CloudWatch 为奖励函数性能提供了全面可见性。下面是该方案中一些有用的 Amazon CloudWatch Insights 查询。
结论
基于 Lambda 的奖励函数，为那些希望在无需海量标注数据的情况下实现精确行为控制并提升推理能力的组织，打开了 Amazon Nova 定制的大门。这种方法通过灵活性、可扩展性和成本效益带来了显著优势，从而简化模型定制过程。该架构让 RLVR 处理客观验证任务，同时让 RLAIF 用于细致质量评估中的主观判断。组织既可以单独使用两者，也可以将它们结合起来，构建同时覆盖事实准确性和风格偏好的综合评估体系。得益于无服务器基础，扩展能力自然形成，能够自动处理从早期实验到生产级定制过程中不断变化的训练负载。成本效益也直接来自这种设计，即组织仅为实际评估计算付费，同时通过优化后的 Lambda 并发和高效奖励计算，使训练任务更快完成。Amazon Nova 基础模型、Lambda 的无服务器扩展能力，以及 Amazon Bedrock 的托管式定制基础设施三者结合，使强化微调无论对何种规模的组织都更易于采用。你可以从本文中的示例代码开始实验，着手定制出恰好符合应用需求行为的 Amazon Nova 模型。
致谢
特别感谢 Eric Grudzien 和 Anupam Dewan 对本文的审阅和贡献。
Bharathan Balaji
Bharathan Balaji 是 Amazon Web Services 的高级应用科学家，致力于强化学习和基础模型服务。他的工作重点是构建帮助客户推动业务转型的 AI 能力。
Manoj Gupta
Manoj Gupta 是 AWS 的高级解决方案架构师，常驻旧金山。他在 AWS 拥有超过 4 年经验，长期与客户密切合作，构建经过优化的 AI/ML 解决方案和云基础设施。他的主要关注领域是数据、AI/ML 和安全，帮助组织实现技术栈现代化。工作之外，他喜欢户外活动并与家人旅行。
Brian Hu
Brian Hu 是 AWS 的高级应用科学家，专注于监督微调、强化微调及其在多个领域的应用。他与客户密切合作，为大语言模型（LLM）进行定制，以获得更强性能和特定领域优化。
Sarthak Khanna
Sarthak Khanna 是 Amazon AGI 的软件开发工程师，专注于强化微调和智能体式 AI 系统。他的工作重点是构建可扩展的大语言模型训练流水线，利用强化学习实现多轮推理、工具使用和自主决策。
