跨国深谈← 返回←模型一换代系统就崩？evals 才是你该押注的持久资产

模型一换代系统就崩？evals 才是你该押注的持久资产

关联

人物 Ameya Bhatawdekar

公司 Braintrust

概念 评估 · 智能体 · RAG · React · 工具调用 · pass at k · pass wedge K · 记忆系统 · 飞轮

这一集是 Braintrust 的现场 CTO Ameya Bhattavdekar 的演讲。Braintrust 是一个可观测性平台（帮 AI 团队看清自己系统哪里出了问题的工具），他讲的主题是：过去三年，AI 应用架构换了一代又一代，每换一代，你原来建的评估体系（evals，用来验证系统是否可靠的那套测试）就作废一层——而 evals 恰恰才是你手里最该长期投资的资产 。

钩子在这里：demo 很容易搭，生产级很难做——这不是因为你当初建错了，而是因为你周围的一切变得太快。模型每隔几个月出一个新版本，每次都不是渐进升级，而是「阶跃式变化」：更擅长调用工具、处理超长上下文、生成能安全执行的代码、记忆系统变得实用 。

旧系统是围绕旧模型的局限设计的——你写了一大堆补丁逻辑去兜底模型不会调工具、会出错的问题。新模型一来，这些补丁反而成了拦路石：不彻底重构架构，你根本吃不到新能力 。而架构一动，你的 evals 也必须跟着动，因为每个新能力都带来新的出错面 。

五代架构：每一代怎么坏，evals 就怎么变

他用一个贯穿全场的例子来讲：一个 SRE 智能体（运维智能体），既能读信息，也能动手——回滚一次部署，或者升级给人处理、呼叫我一个人。它有读工具也有写工具 。

第一代：单次提示词。 一个输入、一次模型调用、一个输出。

评估只看最终答案：准不准、有没有幻觉、是不是引用了过时的训练知识。做法是攒一个黄金数据集，定义好几套评分标准，对着答案打分。够用，但很窄——没有工具调用、没有编排、没有检索 。

第二代：链（Chain），典型是 RAG。 调模型之前先跑一组步骤：解析用户输入 → 检索信息 → 拼上下文 → 交给模型综合出答案。

失败点一下子多了：解析器可能提错信息、检索可能拿错上下文、模型可能在长上下文里犯迷糊（早期模型窗口虽大但推理不动，即「上下文堆塞」问题）。所以你必须对每个环节分别做 eval，才能定位哪里出了错 。

第三代：ReAct 循环。 2023 年中后期到 24 年初，ReAct 论文火了：让模型在循环里跑，自己发起工具调用、看返回结果、推理出下一步，循环到满足用户意图或耗尽迭代预算。

想法很好——系统不再被钉死在固定工作流里，能自我编排。但那个年代的模型撑不住：参数写错、调错工具、出现「上下文坍塌」。想法没兑现承诺 。

第四代：工作流图。 模型控制不住怎么办？

把控制权拿回来，固化到系统里——把编排、执行、规划逻辑写成图或状态机，模型只在节点层面干活。可靠性和可预测性大幅提升，24 年底、25 年初大量生产系统是这么建的。

但代价是：系统只为特定的一组意图设计，一旦用户需求超出编排范围，系统就在接缝处崩裂；你只能往图里加特殊分支去兜，失败面越堆越多——分支一致性、节点间契约、分类节点自己犯错。evals 也随之膨胀：除了整体编排，还要做节点级 eval，还要测分支逻辑和重试循环 。

第五代（现在）：回到循环，但这次模型扛住了。 25 年中后期，Anthropic 和 OpenAI 推出的一些惊人的新模型能力让工具调用变得极其可靠，规划更准、能管长时程任务、偏了能自己拉回正轨。

基于图的系统反而吃不到这些新能力，于是大家回头重造 ReAct 循环，这次真的能用了 。但新问题是方差：同一个输入跑几次，轨迹截然不同，只是答案都对。

eval 的单位不再是「跑一次」，而是「跑 k 次看分布」——由此出现了两个新指标：pass at k（同一 eval 跑 k 次至少成功一次吗？衡量能力上限）和 pass wedge k（k 次里成功几次？

衡量可靠性）。一个 pass at k 很高的系统，要靠 pass wedge k 才能判断它到底可不可靠 。

再往后，系统已经不是「循环里的模型」而是「产品化系统」：外围多了记忆系统（跨会话存取经验）、代码执行沙箱（安全地跑模型生成的代码）、MCP 和技能目录（让模型接入外部能力的扩展机制）、技能仓库。你如果还拿着上一代的 evals，对这些新面就是部分覆盖——系统在新解锁的地方怎么脆弱，你根本看不见 。

飞轮人人都懂，多数团队就是不做

模式很清楚：模型创新 → 架构换代 → evals 必须跟着换代。归根结底，evals 是那种描述「系统应该如何运作」的持久资产，代际转换时它是你的保险：保证原来正常的东西没坏，同时新能力确实解锁了 。

配套的是那条著名的飞轮：从生产环境采集数据 → 反哺 evals → 让 evals 反映真实世界。Ameya 说他和很多团队聊过，大家都嘴上接受，实践中大量团队并不执行——evals 基本是静态的，于是逐渐失效 。

尤其代际转换时，你需要的机制不只是抓你「预料到」的失败（那些你已在 evals 里定义了什么算好），更要照亮「没预料到」的新失败类型——系统一定会以你没想过的新方式坏掉 。

Braintrust 对此的做法是一个叫 Topics 的功能：对所有生产数据做聚类分析，自动浮现你没设护栏、也没写 eval 覆盖的新失败类别，团队据此扩展 eval 集合。这样既持续拿到已知失败模式的新案例，更能在架构大改时看清新失败方式，从生产数据建出有效数据集 。

本集带走

• 换模型 ≠ 换零件：旧系统里兜底模型缺陷的补丁逻辑，正是吃不到新能力的原因；要吃到新解锁，就得重新架构，而不是 drop-in 替换。
• 架构每次换代，evals 同步重写：单次调用查答案 → 链式查每个环节 → 图架构加节点级、分支、重试 eval → 循环架构看 k 次分布。拿旧 eval 测新架构 = 系统性盲区。
• 循环架构用两个指标分开看：pass at k 量能力（k 次至少成一次），pass wedge k 量可靠性（k 次成几次）；能力高不等于可靠。
• 别让 evals 静态化：飞轮（生产数据 → 新 eval 用例）人人都认可但多数人不执行，不执行它 evals 就在悄悄失效。
• 专门防「没想到的失败」：用聚类分析之类的手段在生产数据里找未预期的新失败类别——系统一定会以你没预料到的方式坏。
• 这是长期战：模型不会放缓、没到平台期，未来几个月到几年你都要对 AI 智能体做大量「手术」，健壮的 evals 纪律是管理代际变化的根本 。

架构跟随模型更新，而你的 evals 必须跟随你的架构。
And so, you know, architecture follows model updates and your evals have to follow your architecture.
—— Ameya Bhatawdekar · [04:41]

你接过控制权，并把这种控制固化到你在模型周围构建的系统中。
You take the control and you bake that control into the system that you’re building around the model.
—— Ameya Bhatawdekar · [09:51]

你期望某一套应用或用户交互能很好地工作，因为它们可以由你设计好的编排来完成，但当用户意图需要超出编排所规定范围的其他事情时，系统就会开始在接缝处崩裂。
You expect a certain set of applications or user interactions to work well because they can be fulfilled by the orchestration that you have designed, but when the user intent requires other things to happen beyond what’s specified in the orchestration, the system can start breaking at the seams.
—— Ameya Bhatawdekar · [10:55]

因为归根结底，evals 才是那种描述你的系统应该如何运作的持久资产。
Because ultimately, it’s the evals that are sort of your durable asset that describe how your system is supposed to work.
—— Ameya Bhatawdekar · [18:14]

在接下来的几个月、几年里，你将会对你的 AI 智能体做大量的「手术」。
You’ll be doing a lot of surgery on your AI agents in the coming months, years.
—— Ameya Bhatawdekar · [22:36]