How We Benchmark ARIA—and Why It Runs on Weave

我们如何对ARIA进行基准测试——以及为什么它在Weave上运行

发布于

2026年8月24日

11

分钟阅读

W&B如何将生产环境中的ARIA故障转化为与生产对齐的Weave评估——以及为什么一次成功的重试是不够的。

作者

Anish Shah

已复制

最初发布于CoreWeave博客的Weights & Biases文章，发布日期为2026年8月24日。

当ARIA给出错误答案时，我们的第一步通常是修改提示或工具指导并重新运行任务。有时第二次尝试会成功。我们很容易认为问题已经解决。

但一次成功的重跑只能说明ARIA完成过该任务一次。修改可能确实有帮助，工具可能恢复了，项目数据可能发生了变化，或者修复可能解决了这个示例却破坏了另一个。原始故障告诉我们需要调查什么，但无法说明ARIA实际上需要如何改进。

为了解答这个更广泛的问题，我们会在经过审查的任务集合中，将当前ARIA配置与提议版本进行对比。我们使用Weave，因为它将生产可观测性和评估保持在相同的证据模型中。原始故障、离线尝试、它们的评分以及底层模型和工具操作保持关联，使我们能够更好地捕捉候选ARIA退化的时机。

生产故障必须经受住传输过程

ARIA在W&B内部运行，其中一个问题已经拥有项目、选定的运行记录、指标、工件和页面状态。复制到基准文件中的提示本身无法单独重现该任务。

生产环境中的ARIA通过ARIA服务运行。该服务将每个用户请求及其后续代理工作存储为持久化的Turn：提示、可重建的历史、配置的代理和环境，以及继续所需的状态。生产评估和离线评估使用相同的驱动程序运行Turn。这使我们测试的行为与实际可部署的行为保持一致。

W&B代理工厂（WBAF）导入与生产对齐的ARIA配置，并运行特定于ARIA的任务、环境和评分器。完整路径很简单：ARIA服务记录Turn，Weave保存证据，WBAF比较当前和提议的配置，被接受的更改在部署前返回生产审查。WBAF不会单独部署ARIA。

这条所有权规则解决了实际问题。ARIA发展迅速，基准副本可能在无意中变得过时。我们现在将比较绑定到我们想要测试的生产配置或确切ARIA更改上。否则，我们可能会花费金钱证明候选方案优于昨天的ARIA，却对用户实际使用的版本一无所知。

ARIA服务可以保存Turn和沙箱状态，但不会将整个W&B项目冻结在那个历史时刻。新的运行记录会到达，工件会发生变化，服务之后可能给出不同答案。精确重放需要不可变的引用或为关键外部数据准备固定装置。

图1. WBAF分别为当前和提议的ARIA独立运行相同的已解析套件。Weave保持两个证据记录可见，任务和试验行仍然需要对齐，人员保留发布权限。

即使Turn的重放不够完美，也比从记忆中重建的提示要好。它为我们提供了真实的初始状态，并使剩余的漂移变得可见。下一个挑战是抵制简化该任务的冲动，直到基准变得容易运行且与产品无关。

ARIA评估任务包含的不仅仅是问题本身。某些失败情况取决于用户当时查看的页面。有些任务需要多次对话交互。有些任务需要在运行前具备特定状态，并在运行后进行检查。还有一些任务涉及停止判断：在耗尽预算后得出的答案可能是正确的，但仍可能未满足产品需求。

当前任务库大致可分为四类工作：

ARIA基准中的任务类型

任务类型 | 示例 | 任务需要保留的内容 ---|---|--- 找到正确证据 | 定位相关运行记录、制品、文档或评估结果；使用研究人员已查看的页面 | ARIA接收到的上下文、打开的来源以及是否找到问题所需证据 分析或调试研究 | 比较实验、解释回归、诊断训练问题或提出下一个假设 | 证据与结论之间的关联性，而不仅仅是答案是否听起来合理 在W&B中创建内容 | 创建报告或可视化图表、编辑现有视图或配置扫描 | 对象或操作是否实际存在，以及ARIA是否避免了被禁止的副作用 完成更复杂的调查 | 跨大型项目工作或进行多轮分析 | 轮次之间的状态、资源使用限制以及ARIA在任务完成后是否停止

WBAF任务可以包含结构化页面上下文、资源、沙盒环境、脚本化多轮交互、步骤和时间限制、设置、清理以及必须通过的行为。WBAF还可以运行支持的Codex和Claude Code配置作为基线，这有助于我们区分ARIA特有的回归与任何有能力的编码代理在相同条件下都能解决的任务。

检查标准需要保持相同的精确性。如果要求ARIA创建报告，精美的最终答案并不能证明报告确实存在。我们使用不同的评分器是因为它们回答的问题不同：

用于评估ARIA的评分器类型

评分器 | 检查内容 | 使用时机和原因 ---|---|--- 确定性 | 报告是否实际存在？ARIA是否触发了被禁止的副作用？ | 当结果可以直接检查且不需要裁判时使用 评分标准 | 答案是否有用、有充分支持或校准适当？ | 当质量需要判断时使用——但仅在我们将裁判与人类决策进行比较之后 轨迹 | ARIA在过程中使用了哪些证据和工具？ | 当通过错误路径得出的美观答案不足以说明问题时使用 参考 | 结果是否与运行前准备的真实数据匹配？ | 当我们有稳定答案或制品可供比较时使用。参考数据与代理保持独立

这些评分结果可以贡献到总体结果中，但我们仍然会单独显示它们。优秀的解释无法抵消确定性的安全失败。缺失的成本不等于零成本。在任务开始前沙盒就崩溃属于基础设施故障，而非错误答案。在决定需要修改什么之前，我们需要明确看到的是哪种失败。

随着这些检查变得越来越具体，基准测试已不仅仅是问题列表。每个任务都包含了我们希望保护的行为声明，以及测试该声明所需的环境和评分机制。添加任务很容易，但保持所有任务的有效性却更加困难。

基准测试不仅限于增长

我们采用了一种令人满意的策略，即每项变更都会针对所有历史任务进行验证。但实际情况并非如此。我们只会运行与变更能力相关的测试套件，并在需要更广泛的回归覆盖时使用 WBAF 的 wba-all 套件。

这种模式是通过逐步积累形成的。我们的初始任务简单明了：定位一个运行实例、检查评估结果、解释回归原因、生成报告。后续任务则来自更复杂的追踪模式。在某些情况下，ARIA 能找到正确的运行实例却从未打开解释指标变化的工件；在另一些情况下，它会生成令人信服的报告描述却未实际创建报告；还有任务会重复相同的广度历史查询直到轮次耗尽时间，尽管更精确的查询本可以解决问题。

这些示例是经过脱敏的复合案例。为了使生产模式适合评估，我们必须将其简化为想要测试的行为，同时剔除原始对话和项目数据。相关任务逐渐演变为测试套件，很快每个异常追踪都看起来像是需要永久覆盖的候选对象。基准套件的增长速度超过了我们明确说明每行数据保护范围的能力。

基准套件的范围应与变更范围相匹配。如果我们修改 ARIA 使用页面的方式，就会运行那些页面状态影响答案的测试任务。如果我们修改 ARIA 启动或批准工作的方式，就会检查其实际执行的操作，而不仅仅是后续声明的内容。当变更涉及多个上下文或工具流程部分时，我们会扩大测试范围，而不是像处理文档编辑那样对待它。

生产故障是新任务的来源之一，但不会自动添加。某些追踪可能包含私有数据、描述临时基础设施问题，或重复我们已覆盖的行为。是否值得研究某个追踪以及正确行为的定义，需要人工判断。

我们也会移除任务。产品行为发生变化时，两个任务可能被发现测量的是同一事物，或者曾经困难的任务现在已变得饱和。永远保留所有内容会教会代理满足一个旧论点的博物馆，使结果更难解读。

测试套件可以在研究之间演进。一旦比较开始，其候选对象、任务、尝试次数、运行时间和评分规则将保持固定。在看到结果后修改这些内容会创建新的实验。

实际上，这使我们最终形成了几种类型的测试套件，每种套件用于不同的决策场景：

ARIA 评估套件

套件名称 | 存在原因 | 使用场景 ---|---|--- aria-pr | 一个由人工编写的小型门禁，用于保护我们不愿失去的稳定行为 | 在 ARIA 提交请求和夜间运行中，将候选对象标记为可发布前 wba-all 和 wbax-all | 覆盖已建立的 ARIA 行为和完整研究工作的广泛回归测试 | 每晚运行，以及当变更可能影响多个能力而非单一功能时 guardrails-all | 将安全性和正确操作与答案质量分离 | 当变更涉及操作、数据访问、隐私、凭证或其他安全边界时

Harness 和生命周期烟雾测试套件

检查执行器、停止限制、设置、清理和多轮流程。

当框架、沙箱、超时或生命周期代码发生变更时。通过测试表明机制正常运行；但这并不能证明ARIA有所改进。

实验性、隔离性和演示性测试套件

在不将新任务、不稳定案例或开发路径混合到发布信号中的情况下，开发新任务、调查不稳定案例并验证开发路径。

在任务尚未稳定之前、易出错或敏感案例正在审核期间，或当我们测试评估设置本身时。这些测试套件不支持发布声明。

从一次失败到候选方案

当某回合失败时，我们首先寻找可能解决问题的最小变更。改进工作流会同时查看Weave追踪、相关代码和该回合使用的上下文。它可以建议对系统提示、脚本或技能进行一次有限的修改，即为特定任务准备的一组指令、参考资料和脚本，然后重新运行任务作为合理性检查。如果证据指向服务或基础设施问题，这将成为工程工作，而非另一条提示指令。

重复性失败需要更全面的视角。WBAF的夜间分类工作流将最近的一组生产会话转换为版本化的Weave数据集，然后检查基础设施问题、用户挫败感、安全风险和确定性策略信号。明确的用户反馈与裁判得出的比率分开处理。生成的问题注册表和仪表板帮助人们判断某个失败回合是孤立事件还是某种模式的一部分。

该注册表不会自动成为基准测试。当某种模式值得防范时，人员会将其转化为安全且具有代表性的任务：保留原有行为，排除原始对话和项目数据，定义成功标准，并在单一示例易脆时添加变体。随后，我们使用生产对齐配置和候选方案在Weave中运行该任务。如果任务揭示了更广泛的风险，经审核后它将加入相关能力套件或回归门。

我们还探索了一种名为BehaviorTrace的诊断系统。它重建了执行路径，将类似失败分组，并起草可能的覆盖率缺口。这项工作帮助我们思考追踪诊断，但它不是我们今天使用的生产到评估工作流。当前的流程将重要决策保留在人员手中：哪些模式重要、现有覆盖率是否足够、任务应测试什么，以及结果是否支持发布变更。

一旦我们获得经过审核的诊断，就会明确定义候选方案：具体是哪个提示、技能、脚本、模型路径、工具行为、配置或代码发生了变更。基线和候选方案接收相同的任务、上下文、尝试次数、停止规则、运行时类别和评分器。失败的尝试仍保留在分母中。

该比较是两次评估运行，而非一条魔法命令：

1
suite = resolve(eval_yaml)
2
3
baseline  = run_eval(suite, production_agent)
4
candidate = run_eval(suite, proposed_agent)
5
6
verify_same_task_and_trial_rows(baseline, candidate)

概念性伪代码。WBAF每次评估运行一个代理；在解释差异之前必须检查任务和试验的一致性。

用于诊断问题的示例属于发现过程。在选定候选方案之前，我们会固定一个独立的验证集，之后再开放该集合以观察变更是否生效。在看到结果后修改该集合，并非修复实验，而是改变了测试。

图2。用于选择变更的任务与用于验证变更的任务不同。保留集在候选方案确定前保持未被触碰的状态。

证据必须达成一致

Weave评估将任务数据集、代理预测、评分器及其子调用连接在一起。审核人员可以打开一行失败记录，追踪至代理的根调用，并检查答案背后的工具路径。如果我们修正了评分器，WBAF可以在新的评估身份下重新评分已存储的预测，而无需支付重新生成代理输出或重写旧结果的代价。

最后一部分的重要性可能超出预期。评估器既是软件也是产品政策，我们也会犯错。将预测与评分修订分开，使我们能够在不假装原始判断从未发生的情况下修复评估器。

我们仍然需要将计划与实际执行达成一致。从未启动的任务仍会缺失。缺少预期轨迹或评分的预测是不完整的。再精致的图表也无法弥补缺失的证据。

这就是实际的内部使用主张。Weave追踪是我们检查生产环境中ARIA的方式；Weave评估则是WBAF连接离线任务、预测和评分的方式。使用单一证据模型不会使评估正确，但它能让追踪、评分和对账中的错误对构建代理的团队可见。

人们仍然需要选择失败案例，审查诊断结果，决定良好行为的定义，并审查生产变更。我并未将这些交接视为未完成的自主权。它们阻止了同一系统自行提出问题、提供答案、自我评分并批准发布。

图3。ARIA可以帮助检查和测试拟议的变更。人们决定哪些内容成为任务，哪些返回生产环境；只有通过正常审查流程发布的变更才能形成闭环。

演变为Fugue的ARIA

ARIA的任务和诊断应属于WBAF。生产环境中的ARIA通过ARIA服务运行。但某些控制措施反复出现：锁定精确的候选方案和任务，对齐尝试，将私有真相与代理隔离，在执行前展示计划和成本，要求批准，隔离运行时环境，并将结果与证据进行对账。

这些控制措施演变为Fugue，一个独立的实验治理项目，用于管理ARIA之外的代理。它不运行生产环境的ARIA，也不会取代WBAF。其职责是使拟议的比较可检查，并防止代理自行批准预算或静默启动下一项研究。

我们希望ARIA能帮助改进ARIA本身。但如今我们信任的范围更窄：它能检查失败案例、提出变更建议，并在人们保留对预期行为和发布决策的控制权时协助测试。

当证据表明否定时，仍需有人愿意倾听。

进一步阅读

• CoreWeave ARIA 描述了当前的公共产品。

• 《AI循环：发布日即第一天》描述了生产证据如何驱动评估和改进。

• W&B Weave 介绍了共享的追踪和评估系统。

• 《理解操作、调用和追踪》文档说明了Weave的追踪模型。

• 评估概览记录了数据集、预测和评分器之间的关系。

• 《我为何构建 Fugue：用于智能体系统的受控实验》解释了这些控制机制如何源于评估工作。

‍

一次成功的重试并不能证明太多。以下是我们在 Weave 上对 ARIA 进行基准测试的方式：将提出的更改与生产版本进行对比测试，确保真正改进的特性能够上线，而回归问题不会被引入。

分享这篇文章： /think