跨国深谈← 返回←让智能体自己研究自己:Weights & Biases 的 ARIA 评估飞轮

让智能体自己研究自己:Weights & Biases 的 ARIA 评估飞轮

关联

人物 Zubin Aysola

公司 Weights and Biases

概念 ARIA · Weave · 智能体 · 评估 · 轨迹 · 沙箱 · 可观测性

这一集是 Weights & Biases(机器学习开发者工具公司)的 Zuban Isola 的现场演讲,他刚发布了自家的智能体产品 ARIA(周一刚上线正式版)。这个演讲最抓人的地方在于:ARIA 已经足够强,可以直接让它给自己做研究——写新变体、跑评估、打分,自己把自己改得更好。整个演讲讲的就是支撑这件事的评估体系怎么搭。

核心问题:评估、智能体、配置全是联动的

Isola 说他每天睡前都在想一个问题:基准测试、评估、智能体本身、以及你怎么配置它,这几样东西全是协变的——系统在动态变化,你要对它做有原则的评估,就必须有好的测量手段。他借用了强化学习里的一个老概念「sim-to-real 差距」(如何把仿真环境里学到的东西迁移到真实环境):他的目标是让离线仿真环境和真实生产环境尽可能一致,这样才能放心地在离线侧优化。

他的方案分两半,拼成一个飞轮:

• 生产侧:用 Weights & Biases 的 Weave 平台(他认为是智能体生产端和离线追踪最好的可观测性工具)记录 ARIA 在真实用户那里的每一条调用轨迹。
• 离线侧:他构建仿真环境,在这些环境上跑 ARIA,同样记进 Weave。关键是两边记录格式完全相同,这样他可以把生产轨迹直接抽出来,塞进离线评估框架里,针对真实发生的失败(或成功)做爬山优化。

生产环境到研究环境之间还有一个大约四小时跑一次的同步作业,保证研究员切新变体、加新技能时两边不漂移。他强调:两边跑的是逐字节相同的智能体版本,研究代码和生产代码完全一致。

离线评估框架怎么搭

整套流程是一个 DAG(有向流程图):取一份 YAML 配置 → 水合(加载所需的真实数据,比如完整的机器学习训练日志,必要时还要模拟 GPU 执行,这是最费资源的一步)→ 重新水合(把没法写进 YAML 的运行时配置热补丁进去)→ 运行智能体(「运行智能体是小事一桩」)→ 评分。

几个关键做法:

• 配置变异要多。用 YAML 定义同一套配置的大量变体,并行全测一遍。他借用模型训练的老格言:「跑更多实验总是比跑更少实验要好。」智能体背后的软件栈相对中立,压缩、上下文准备、UI 组装都抽出来,方便换模型、换配置地批量测试。
• 沙箱不设限。他要给客户一个想干什么就干什么的沙箱环境。一个例子:演讲前一天他不确定 ARIA 能不能并行执行自己的研究循环,就直接让 ARIA 自己创建沙箱环境来跑。「拥有这种不受约束的环境,对让智能体做出涌现性的事情非常有用。」
• 评分分两种。规范性评分:这个任务过没过;相对性评分:比如一个变体会向用户提问、另一个不会,对比哪种行为更好。他说评分是他花时间最多的地方——怎么稳健地衡量结果,以及评估与生产之间有没有漂移,团队甚至有同事花一整天专门检查「评估的健康度」。
• 任务就是 YAML 规范:定义环境的起始条件、一组用户配置、一个想达到的结束条件。用户流程用三种方式模拟:最简单的是一句文本指令;进阶的是模拟一个带用户人设的语言模型,按特定顺序提问,模拟多轮交互。

目前他们有 886 个任务,按难度分级,并且开放给产品团队审核「这些任务是否足够好、是否反映了我们真正关心的东西」。任务会被反复运行很多次。

轨迹是核心资产

Isola 的核心论点(他自己原话很糙,大意是):先海量化地生成轨迹,再决定拿这些轨迹做什么。他们测量的是智能体的涌现特性,然后想办法把行为对齐到想要的方向——要么人工审查,要么直接让 ARIA 审查自己生成的 rollout,判断哪里好哪里坏,再通过提示词强化正确行为。

最有价值的闭环在这里:生产环境的每一次失误、每一次亮眼表现,都会变成评估框架里的一个新任务。他特意指出正向爬坡也有用——不只是修错误,好的行为也要固化下来。

现场演示:ARIA 给自己修 bug

演讲的演示环节,Isola 在 Weave 里随手挑了一条生产轨迹,开了个新 ARIA 会话说:「拿这条轨迹,记进我们的离线评估,然后在它上面运行候选智能体和生产智能体。」ARIA 自己完成了全程:它抓取轨迹、把它变成一个回归任务、复现源轨迹、发现问题出在沙箱里没有正确调用 SDK 的 weave.log、给自己加了一个爬坡目标(该怎么修)、运行智能体的多个变体对比、最后生成一份报告解释发生了什么。最终获胜的候选变体,只是在 system prompt 或某个技能里注入了一小段针对性的提示词,解决了那个 SDK 错误。

他现在的日常工作因此变成:在生产追踪项目里看轨迹涌入、在离线评估项目里看团队和自己要改什么,不用再回 Claude Code 手写基准。「我大概八个月没写过一行代码了,因为我只是让 Claude 替我写所有代码。」但他提醒了一个反直觉的坑:不写代码不等于免除思考——自动模式最大的挑战恰恰是太容易放手让智能体全做完,而人的价值在于把时间花在「真正的灰色地带」,思考怎么让系统更好地自我强化、在哪里加严密的护栏。

本集带走

• 让生产轨迹变成评估任务:每次真实世界的失败或成功,都沉淀为一个可复跑、可打分的离线任务——这是整个飞轮的发动机。
• 生产和离线必须逐字节一致:同一份代码、同一种日志格式,再加上定时同步作业防止漂移,离线优化结果才敢直接上生产。
• 配置变异优先于精心调参:用 YAML 批量定义同一配置的大量变体,并行全测;跑更多实验比跑更少实验好。
• 评分要双轨:规范性的过/不过告诉你有没有完成任务,相对性对比(如问不问用户)告诉你哪种行为更好;同时持续监控评估本身和生产的漂移。
• 先海量生成轨迹,再决定怎么用:轨迹是最值钱的资产,涌现问题先记下来,分析方式可以后定。
• 自动化不豁免思考:让智能体写所有代码没问题,但人的工作收窄到护栏设计和「怎么让系统更好地自我强化」——这部分省不得。

【背景】演讲开头自我介绍的姓名,语音转写为「Zuban Isola」,可能存在听写误差;其余内容(公司、产品、流程、数字)均出自本集转写稿。

但有一个大问题摆在这里，基本上就是我每天睡前都在想的事情：基准测试、评估、智能体、以及你怎么配置它们，全都是协变的。
But one big problem presents itself, which is basically the thing that I go to bed thinking about every day, which is benchmarks, evaluations, the agents, and how you configure them are all covariant.
—— Zubin Aysola · [01:32]

归根结底，你可以对怎么改进问题有洞察，但借用老的强化学习训练或简单模型训练里的一句格言：跑更多实验总是比跑更少实验要好。
Because ultimately, you can have insight into how to make the problem better, but if we take an adage from old reinforcement learning training or just simple model training, it’s just better to run more experiments than fewer.
—— Zubin Aysola · [07:48]

所以从根本上说，生产环境的每一次失误、也包括每一次亮眼表现——因为我认为朝正向爬坡也很有用——都会变成我们智能体框架的一个任务。
So fundamentally, every production miss or every production goodness as well, because I think it’s useful to hill climb in a positive direction, becomes a task for our agent framework.
—— Zubin Aysola · [12:21]

我大概八个月没写过一行代码了，因为我只是让 Claude 替我写所有代码。
And I haven’t written a line of code in maybe eight months because I just tell Claude to write all my code for me.
—— Zubin Aysola · [14:49]

我认为用这些工具来改进它们自身是非常有价值的，因为你可以把更多时间花在真正的灰色地带里，去思考我们怎么让这个系统变得更好。
And I think using these tools to improve themselves is very valuable because you get to spend more of your time in the gray of actually trying to think how we make this system better.
—— Zubin Aysola · [14:59]