在 Amazon SageMaker AI 中训练多轮智能体以解决工单或内容审核

训练一个多轮智能体（multi-turn agent）来处理支持工单或内容审核，意味着要处理一系列相互依赖的步骤，而非单次响应。这些智能体读取指令、调用工具、读取结果、决定下一步行动，并在提交答案前从错误中恢复。这种灵活性也正是智能体强化学习（agentic RL）具有挑战性的原因。更多的行动方式意味着有更多方法在不完成任务的情况下获得奖励，而智能体训练所处的环境也可能悄然破坏训练信号。在本文中，我们分享可靠的多轮 RL 训练的最佳实践。我们将介绍如何构建一个可信的训练环境、设置外部评估、设计与最终任务对齐的奖励、管理智能体运行多轮时发生的变化，以及监控那些告诉你何时需要迭代的指标。我们的示例来自 SOP-Bench 数据集，这是一个 Amazon Science 基准测试，用于评估智能体在 12 个业务领域中基于复杂标准操作流程（SOP）解决任务的能力。

SageMaker AI 多轮强化学习

Amazon SageMaker AI 多轮 RL（SageMaker AI MTRL）为智能体任务提供了训练循环。你的智能体可以运行在 Amazon Bedrock AgentCore、Amazon Elastic Kubernetes Service（Amazon EKS）、Amazon Elastic Compute Cloud（Amazon EC2）、AWS Fargate 或你选择的基础设施上。你通过一个小型适配器将其连接，该适配器将你的工具接口暴露给 rollout 服务器，SageMaker AI MTRL 处理其余部分：一个模块化的智能体-环境接口，保持低代码集成，同时让你拥有完全的算法控制权。自定义奖励、自定义工具循环和多轮对话形态都由你定义。无服务器执行简化了基础设施问题，因此你可以按每 token 定价获得生产规模的智能体 RL，而无需配置或管理 GPU 集群。异步 rollout 和轨迹收集，具有有界的 off-policy 陈旧性。生成和梯度更新并行运行，不会偏离当前策略太远，从而加速训练。原生算法库涵盖 Proximal Policy Optimization（PPO）、Clipped Importance Sampling Policy Optimization（CISPO）和 importance-sampling（IS）损失，并配有多组基于组的优势估计器（GRPO、GRPO pass@k、RLOO 等）。这些涵盖了与多轮智能体 RL 最相关的选择。序列扩展训练（Sequence-extension training）可减少长多轮轨迹的挂钟时间。由 Amazon SageMaker AI 管理的 MLflow 中的轨迹和奖励可观测性，让你可以逐轮查看智能体的行为，以及跨训练步骤查看。评估作业在部署到 SageMaker AI 端点或 Amazon Bedrock 之前报告奖励、pass@k、轨迹指标等。该服务提供训练循环、硬件和编排。决定你是否能获得可靠智能体的选择权在你手中。你构建智能体训练的环境，在奖励之外衡量成功，设计奖励本身，并决定在曲线停滞时如何迭代。

图 1：SageMaker AI 多轮 RL 服务概览

构建一个廉价、可复现且具有代表性的训练环境

单轮 RL 需要一个 prompt 和一个奖励函数。多轮 RL 增加了一个环境，供智能体在轮次中行动：它调用的工具以及这些工具背后的系统。该环境是你训练设置的一部分，你构建它的方式既决定了模型可以学到什么，也决定了你是否能信任你的指标。

训练智能体时，构建一个沙盒化或模拟的环境，该环境类似于生产环境但与实时流量隔离。工具调用和响应保持相同的 schema 和业务逻辑。它们由记录的响应或隔离状态驱动，而不是实时调用。模拟环境是推荐的起点，因为一次典型的运行会产生数千次 rollout，每次 rollout 都会进行多次工具调用。例如，batch size 为 128，group size 为 8，则每步有 1,024 次 rollout。将这些流量指向实时系统可能会导致客户影响。没有模拟环境，探索可能会产生真实的副作用。例如，通过试错学习的智能体会发出退款、删除记录或触发你未预期的工作流。此外，实时数据会发生变化，因此同一轨迹在不同运行中得分不同。你必须知道正确的结果才能计算奖励，这意味着需要一个固定的、带标签的任务集（或一个可信的判断模型），无论工具调用指向何处。

如何构建模拟环境取决于你的工具做什么。三种模式涵盖了你会遇到的大多数用例：

• 只读工具：根据输入重放记录的响应。这些工具有助于智能体检索与任务相关的信息。例如，在 SOP-Bench 中，客户服务任务提供了十个模拟工具（validateAccount、getAuthenticationDetails、createSessionAndOpenTicket 等），每个工具都从 fixture 返回确定性响应，例如基于工具调用参数的 CSV 文件中的特定行。
• 有状态工具：在 episode 持续时间内保持状态的种子沙盒。当智能体写入某些内容并读回时，环境需要记忆。模式：在 rollout 开始时分配每个 episode 的资源，并注册智能体创建的所有内容。当 episode 结束时，在 try/finally 块中拆除所有内容，无论是通过达到终止动作、达到 max_turns 还是崩溃。没有状态泄漏到下一次 rollout 中。
• 可验证结果：在隔离的模拟环境中真正执行。当智能体的输出是代码、SQL 或数学时，你可以在隔离环境中运行它。对代码使用 Docker exec，对 SQL 使用每个 rollout 的内存 SQLite，对数学使用纯 Python eval。真正的执行，每个实例是确定性的，相同的输入加上相同的沙盒状态等于相同的结果。例如，AgentCore Code Interpreter 为代码执行提供了托管的隔离环境。

无论哪种模式适合，都要保持两个属性固定：

• 可复现性：使用相同参数调用的相同工具返回相同结果，因此相同轨迹的奖励是稳定的，并且你的评估在不同运行之间是可比较的。
• 代表性：从你的真实 schema 和数据分布构建环境，以便模型学习到的行为可以迁移到生产环境。

在开始训练之前，确认你的环境配置正确：

• 使用相同参数的工具调用给出相同结果，通过运行同一实例两次并对 rollout 消息进行 diff 来验证。
• 每个 rollout 的状态是隔离的（单独的临时目录、单独的 ID、单独的 DB 连接）。
• 可用工具与你的生产环境匹配，以及工具请求/响应 schema。

在训练前设置外部评估

在你的环境就位并验证后，在编写奖励函数之前，构建一种衡量成功的方法。该衡量标准应直接捕捉你的最终目标。RL 字面意义上优化奖励信号，因此如果奖励是你唯一关注的数字，你就无法将任务上的进展与满足奖励标准上的进展区分开来。你需要一个你可以信任的外部评估，以便在迭代奖励、环境种子和超参数时指导你的决策。

模式：建立一个保留的评估，对你在部署时关心的结果进行评分，该评分独立于奖励计算。在实践中，这是一小段代码，它接收一个模型，在固定的测试集上通过 rollout 服务器运行它，并返回一个单一的任务成功率。它可以很简单，只要它是诚实的。对于 SOP-Bench，评估是对最终 JSON 对象内的精确匹配：智能体输出中的每个字段都必须与 ground-truth 字段匹配，否则 rollout 得分为零。奖励函数可以计算部分分数和加权组件。评估则不会。

在任何训练之前，建立一个基线。通过相同的评估运行基础模型和一个参考模型（托管在 Amazon Bedrock 上的前沿模型是一个不错的选择）。这告诉你两件事：基础模型还有多远，以及在这个任务上好的表现是什么样的。

反模式：将训练奖励或从中派生的指标视为你的成功衡量标准。这看起来可能很直观，但为了捕捉奖励黑客行为（reward hacking），你需要外部评估。多轮智能体需要特别考虑：一个为工具调用支付奖励的奖励会教会智能体尽可能多地调用工具。一个惩罚轮次数的奖励会教会智能体在获得所需信息之前就提交答案。无论哪种方式，训练奖励上升，但智能体在任务上的真正成功却下降了。

在开始训练之前，确认你的评估是可信的：

• 评估是一个函数 score(rollout) -> float，精确地对你发布的内容进行评分。
• 基线评估在你计划微调的基础模型上非零（如果为零，请参阅下一节中的“确保基础模型首先有一个立足点”）。
• 针对一个前沿模型运行你的评估，以便你有一个高级基线进行比较。

设计一个好的多轮 RL 奖励函数

奖励设计是 RL 中更具挑战性的开放问题之一。让智能体解决真实任务的相同灵活性，也让它可以找到在不完成任务的情况下满足奖励的方法。你添加的每个组件，你调整的每个奖励权重，你叠加的每个格式奖励，都是智能体可以在不解决问题的情况下攀爬的另一个表面。模型优化的是你写下的内容，而不是你的意图。

默认情况下，对训练和评估使用相同的评分规则，并且只有在有具体理由时才偏离。以 SOP-Bench 为例。该基准测试期望答案以 JSON 对象的形式放在 <final_answer> 标签内：

{
  "aircraft_ready": "true",
  "mechanical_inspection_result": "success",
  "electrical_inspection_result": "success",
  "component_incident_response": "success",
  "component_mismatch_response": "success",
  "cross_check_reporting_response": "success"
}

如果每个字段都匹配，基准测试得分为 1，否则为 0。训练和评估通常共享此评分规则，仅在你围绕它观察的内容上有所不同。训练器每次 rollout 消耗一个奖励（标量或标量列表）。评估以较低频率在固定分割上运行，因此你可以监控更多指标：每个字段的准确率、完成率（智能体是否发出了 </final_answer>）、工具调用分布、轮次预算耗尽、格式合规性。

有两个真正的理由偏离默认的基准测试评分规则，两者都需要更密集的奖励。第一个是算法上的。RL 使用基于组的优势方法（advantage_method）从每个 prompt 的 group_size 次 rollout 组的方差中计算学习信号。服务默认的 group_based 是 GRPO。许多其他方法如 rloo 和 grpo_passk 也可用。有关完整列表，请参阅文档。二元分数可能会使该方差崩溃：当组中的每次 rollout 得分相同时，相对信号为零，该组不贡献梯度。当 rollout/reward/valid_mean（非零优势组的均值）低于 rollout/reward/mean 并且模型停滞时，这种差距就是症状。第二个是收敛速度。即使组方差良好，密集奖励也会为模型提供每次 rollout 的部分进展梯度，而不仅仅是那些完全成功的。一个正确了六个字段中五个的 rollout 教会模型更接近的样子。二元分数则对此一无所知。

SOP-Bench 任务的密集奖励独立地对每个字段进行评分，并返回一个奖励标量或标量列表（每轮奖励）加上一个指标字典。

class SOPBenchReward:
    """Dense per-field reward for the SOP-Bench aircraft-inspection task.
    Returns a scalar in [0, 1] plus a metrics dict surfaced in MLflow."""
    ground_truth: dict[str, str]
    format_coef: float = 0.1  # format is a small shaping term, not the objective

    async def __call__(self, history: list[Message]) -> tuple[float, dict[str, float]]:
        fields = parse_final_output(last_assistant(history))  # JSON inside <final_answer>
        emitted = float(fields is not None)
        if fields is None:  # no parseable answer
            return self.format_coef * (emitted - 1), {"completion": 0.0, "field_acc": 0.0}
        matched = sum(1 for k, v in self.ground_truth.items()
                      if str(fields.get(k)).strip().lower() == str(v).strip().lower())
        field_acc = matched / len(self.ground_truth)
        # partial credit: 5/6 > 0
        reward = field_acc + self.format_coef * (emitted - 1)  # correctness dominates
        return reward, {"completion": emitted, "field_acc": field_acc}

你的智能体通过 update_reward 报告奖励，指标字典（completion、field_acc）出现在 MLflow 中。为了奖励单个轮次而不是整个轨迹，update_reward 也接受一个每轮列表，与 group_based_per_turn 优势方法配对，因此你的奖励函数也可以每轮返回一个奖励值。

在训练之前，在实际输出上验证奖励。一个比你的评估更宽容的奖励解析器本身就是一种奖励黑客行为。在我们的一次 SOP-Bench 运行中，奖励接受了一种比基准测试评分更宽松的输出格式：一个裸的 </final_answer> 包装器获得了分数，即使基准测试只读取 <final_answer>。训练完全按照我们的要求进行：模型学会了丢弃基准测试需要的标签，奖励上升了，但外部评估下降了。

确保基础模型首先有一个立足点。 RL 改进了基础模型已经能在部分时间做到的事情。它不会凭空创造能力。如果基础模型在你的任务上产生了零个成功的轨迹，奖励信号就没有什么可以放大的，训练就会停滞。SageMaker AI MTRL 可以将这样的基线作为托管评估作业运行。MultiTurnRLEvaluator 在保留的 prompt 集上重放你的智能体，并报告 eval/reward 和 pass@k。如果你已经训练了一个模型，使用 evaluate_base_model=True 的单次调用会并排对基础模型和微调模型进行评分。因为 pass@k 在 success_threshold 处对奖励进行阈值处理，设置 success_threshold=1 会给你一个严格的成功率：获得完美奖励的 rollout 比例以及均值。

from sagemaker.train.evaluate import MultiTurnRLEvaluator

# With Bedrock AgentCore
evaluator_base = MultiTurnRLEvaluator(
    model="openai-reasoning-gpt-oss-20b",
    dataset="s3://my-bucket/eval-prompts.parquet",
    agent_config="arn:aws:bedrock-agentcore:us-west-2:123456789012:runtime/my-agent",
    s3_output_path="s3://my-bucket/eval-output/base/",
    mlflow_resource_arn="arn:aws:sagemaker:us-west-2:123456789012:mlflow-tracking-server/my-mlflow",
    role="arn:aws:iam::123456789012:role/SageMakerRole",
    accept_eula=True,
)
execution = evaluator_base.evaluate()
execution.wait()

在指定的 s3_output_path 中，你将找到评估的报告指标，你也可以在 MLflow 中以及评估轨迹中查看它们。有关微调和基础模型的基于奖励的评估，请参阅关于模型评估的文档。记住一个区别：评估作业使用你自己的奖励函数对 rollout 进行评分，因此它衡量的是保留集上的泛化能力，而不是对奖励的独立性。一个宽松的奖励解析器在这里看起来是健康的，因为指标就是奖励本身。捕获奖励解析器错误的独立检查保持分离：使用更严格的独立解析器（对于 SOP-Bench，是基准测试的精确匹配评分器）对相同的 rollout 进行评分并比较。你甚至可以通过将 MultiTurnRLEvaluator 指向一个其奖励是独立指标的智能体，将该严格评分器作为其自己的评估作业运行。

有关奖励设计、稀疏与密集奖励、判断模型、多目标塑造及其之间权衡的更深入处理，请参阅 SageMaker AI 奖励设计最佳实践。

在信任你的奖励之前，确认：

• 训练奖励和评估共享相同的底层评分规则，除非你有经过衡量的理由偏离（并且该理由已记录在案）。
• 奖励返回一个 [0, 1] 范围内的浮点数（如果你允许负回归项，则为 [-1, 1]）。
• 超过 100 次基线 rollout 的奖励具有方差（不全为 0，不全为 1）。如果没有，这就是那种需要塑造或设计专门数据课程的衡量信号。
• 没有基线 rollout 在训练奖励上的得分高于评估。如果有，则奖励过度奖励了外部评估不认可的东西。
• 如果奖励有多个组件，请验证你在 MLflow 中分别记录每个组件，以便你可以读取每个项的差异。

管理智能体运行多轮时发生的变化

多轮智能体必须处理单轮看不到的问题。在开始训练之前，值得明确设计这些。

上下文每轮都在增长，轮次预算是奖励设计的一部分。 每次工具调用都会扩展对话：调用本身、其参数、结果以及模型在它们之间产生的推理。长轨迹会快速累积上下文，MTRL 使用序列扩展训练来在它们增长时保持挂钟时间可控。一个需要顺序进行八次调用的任务可能在完成之前就用完了空间。两个预算限制了这一点：max_turns，由你的智能体循环控制；以及每轮 token 预算，由服务通过 sampling_max_tokens（rollout）和 val_sampling_params.sampling_max_tokens（评估）设置。选择两者以匹配你的任务需求以及你在部署时能够提供的服务。对于 SOP-Bench，八轮和每轮 2,048 token 的预算足以覆盖标准流程并有裕量（sampling_max_tokens 允许高达 8,192）。经验法则：如果任务的人工演练需要 N 轮，则在你的智能体循环中设置 max_turns = ceil(N * 1.5)。正确的轮次预算是允许智能体以少量安全裕量完成的最小预算。

观察 rollout/tokens/response_max 是否有响应聚集在限制处。如果超过 5% 的 rollout 达到限制，请提高 sampling_max_tokens。否则，该信号是静默损失。模型从截断的轨迹中学习，但看不到它通过完成本应获得的奖励。

将完成与正确性分开。 一个以错误答案结束的轨迹和一个从未结束的轨迹是不同的失败，将它们混为一谈会掩盖模型在哪里出问题。MLflow 中的 rollout 和 val 指标系列分别给你这两个信号：

指标	它告诉你什么
1 rollout/reward/mean	平均轨迹奖励，你的训练侧信号
2 rollout/reward/zero_frac	得分恰好为 0 的轨迹比例
3 rollout/turns/mean	每个轨迹的平均轮数
4 analysis/zero_adv_groups	每次 rollout 得分相同的组，浪费了 rollout
5 val/reward/mean	平均验证奖励，你的保留数据信号
6 val/reward/pass_k_1、pass_k_8	保留集上的 pass@1 和 pass@k

在低完成率（rollout 在发出 </final_answer> 之前达到 max_turns）上的高 val/reward/pass_k_1 意味着模型正确解决了简单路径，但在困难路径上停滞，表明需要调整轮次预算。在低 val/reward/pass_k_1 上的高完成率意味着它流畅地回答但错误，表明需要重新设计奖励。这两种失败模式需要不同的修复方法，因此值得区分它们。

在提交轮次预算之前，确认：

• 智能体循环中的 max_turns 已根据任务校准，而不是保留在任意默认值。
• 在任何单轮中，少于 5% 的训练 rollout 达到 sampling_max_tokens。
• 少于 10% 的训练 rollout 在未产生最终答案的情况下达到 max_turns。
• 完成（发出最终答案）和正确性（最终答案正确）在 MLflow 中作为单独的指标进行跟踪。

监控训练指标

在设置并验证了你的评估、环境和奖励之后，是时候开始训练了。SageMaker AI MTRL 提供了高级别的 MultiTurnRLTrainer 和 MultiTurnRLEvaluator 构造来训练和评分你的智能体：

from sagemaker.train import MultiTurnRLTrainer
from sagemaker.train.evaluate import MultiTurnRLEvaluator

trainer = MultiTurnRLTrainer(
    recipe="<your-recipe>",
    role=...,
    dataset=...
)
trainer.train()  # step 6: watch rollout/reward and completion in MLflow

evaluator = MultiTurnRLEvaluator(
    model=trainer,
    dataset="<eval-dataset>",
    evaluate_base_model=True
)  # step 7: val/reward + pass@k, base vs fine-tuned
evaluator.evaluate().wait()

print(trainer.get_mlflow_url())  # read the trajectories where reward and evaluation disagree

训练时，将 rollout/reward/mean 与完成率一起观察，并在 MLflow 中打开一些轨迹（在 Traces 选项卡下），这样在完成率持平的情况下奖励上升就不会被忽略。评估时重要的信号是不一致：当 rollout/reward/mean 上升但 val/reward/mean 持平，则奖励被黑客攻击了。打开这些轨迹，比较奖励认可的内容与评估评分的内容。这种比较驱动你的奖励设计迭代：收紧奖励解析器，重塑一个组件，或整理数据，然后再次运行。每次迭代都比上一次快，因为环境和评估保持不变。只有奖励和数据发生变化，MTRL 的每个模型入门配方为你提供了一个调整好的起点。

例如，在我们最早的一次尝试中，我们试图同时在所有 SOP-Bench 任务上训练一个智能体，这导致了任务竞争和奖励波动：

图 2：尝试同时训练所有 SOP-Bench 任务时奖励波动

在将数据限制为专注于单个任务（aircraft_inspection）后，我们注意到验证奖励下降，而 rollout 奖励已经饱和。在我们的奖励公式中，最大奖励是 5.0，但奖励停滞在 3.7 左右：

图 3：奖励停滞且验证奖励下降

模型在 aircraft_inspection 上没有获得全部奖励，并且与基础模型相比，微调模型在外部基准测试上的任务成功率下降了。我们需要审查 rollout 轨迹以找出原因。SOP 的一次性示例与任务的 ground-truth 数据在两个方面不匹配。它省略了数据所需的 cross_check_response 字段，因此模型无法生成完整的答案，并且它将输出包装在与评估期望不同的标签中。我们将示例与数据对齐，并删除了无法回答的字段，这使得奖励和评估衡量的是同一件事。

图 4：SOP-Bench 的 aircraft_inspection 任务健康奖励信号

在衡量微调后的 GPT-OSS 20B 模型相对于外部基准测试的任务成功率（TSR）时，我们看到 aircraft_inspection 任务的 TSR 增加了 13%，每个字段的准确率增长了约 16%，证实了我们的奖励函数与外部评估一致。

整合在一起：一个迭代循环

前面描述的各个部分加起来就是一个单一的训练循环，按照它们被引入的顺序运行。你首先构建环境和评估，因为它们是每个后续步骤所依赖的固定框架。然后你针对该评估设计奖励，只有在那之后你才训练并读取指标。保持早期部分固定是使每次迭代快速的原因，因此你的大部分精力都投入到奖励和数据上。

一个对我们来说效果很好的版本：

1. 收集有代表性的任务数据，并分割为训练集、验证集和保留测试集。
2. 从生产 schema 构建训练环境：封闭、有种子、可复现。
3. 针对测试集建立外部评估，独立于奖励计算。
4. 通过评估运行基础模型和前沿参考模型来建立基线。如果基础模型得分为零，在继续之前停止并简化。
5. 设计奖励，然后在任何训练发生之前，在来自基线的真实模型输出上验证它。
6. 训练，监控 rollout/reward、完成率以及轨迹样本，以了解你的模型在训练期间产生什么。
7. 使用外部评估评估训练好的模型。
8. 读取轨迹，特别是奖励和评估不一致的那些。
9. 调整奖励、环境或数据，然后再次运行。

当曲线停滞或崩溃时，在调整其他任何东西之前，按顺序检查这些：

症状	首先要改变的东西	确认诊断
1 奖励从第 0 步开始持平	验证模型输出格式与奖励对齐	对不同奖励进行独立评估，以将格式奖励与模型的输出结构对齐
2 训练奖励持平，所有组得分相同	将 group_size 从 8 降到 4 并增加 batch_size	观察 analysis/zero_adv_groups，应该下降
3 训练奖励上升但 val/reward/mean 持平	奖励被黑客攻击。重新读取轨迹，收紧奖励解析器	针对新的基线 rollout 重新运行离线奖励审查
4 奖励在第 40-80 步后崩溃（降至 ~0.0）	设置 async_config.max_steps_off_policy = 0。如果使用 CISPO，切换到 PPO 并设置 (0.8, 1.2)	奖励应该稳定，即使更低
5 奖励停滞，改进有限，所有旋钮健康	加倍 LoRA 容量（lora_rank=64、lora_alpha=128）	如果有增长空间，在 50 步内达到更高上限

一次只做一个更改，每个决策观察 25-50 个训练步骤（梯度更新）的指标。在我们的运行中，当这些参数被有意调整时，大多数失败在大约 30 步内变得可识别。

结论

你的奖励质量和你的评估决定了训练是否能产生一个有用的智能体，这比算法或超参数重要得多。奖励是模型优化的唯一信号，而与之保持分离的评估告诉你智能体是在学习任务还是在学习奖励。一个精心设计的奖励和一个与最终任务匹配的评估可以产生一个有用的智能体；没有它们，即使是一个强大的算法也会产生一个在训练中看起来不错但在生产中失败的模型。

SageMaker AI 多轮 RL 处理了运行分布式智能体 RL 训练的大部分操作工作和复杂性，抽象掉了硬件、编排和训练引擎。借助 SageMaker AI 多轮 RL，你可以专注于创建一个准确的环境，其中 Strands Agents 和 AgentCore 可以帮助你将生产环境过渡到智能体设置，并专注于奖励设计、评估和参数调优。

要开始使用智能体 RL，你可以浏览 MTRL 设置的示例 notebook。有关服务级别的指导，请参阅 SageMaker AI 多轮 RL 文档；有关奖励主题的更深入处理，请参阅奖励设计最佳实践；或参阅这篇关于 GRPO 与可验证奖励的 AWS 博客文章。最后，SOP-Bench 论文和数据集是此处使用的运行示例的来源。

关于作者

Sapana Chaudhary Sapana 是 Amazon Web Services（AWS）的一名应用科学家 II，她致力于大型语言模型的强化学习后训练。她的研究位于强化学习、鲁棒性和语言模型的交叉点——目标是通过约束优化、风险感知微调或可验证推理，使 AI 系统对下游任务更可靠和可信赖。Sapana 拥有德克萨斯 A&M 大学（TAMU）的博士学位。在工作之外，她喜欢远足、烹饪、绘画和摄影。

Theodore Vasiloudis Theodore 是 AWS 的一名高级应用科学家，他致力于大型语言模型后训练，重点关注规模和效率。他在系统和算法的交叉点工作，为希望大规模微调模型的 AWS 客户开发训练框架和服务。Theodore 拥有斯德哥尔摩 KTH 皇家理工学院的博士学位。