134 篇博文 含有标签「evals」

一家世界 500 强公司的采购主管打开了你的支持智能体，询问为什么 SOC 2 报告中提到的某个合规控制项在你的产品中已不再执行。你的智能体用对待免费版个人用户的语气回答了她——带着三个感叹号、一个表情符号，以及一个“联系我们团队”的愉快建议，既没有升级路径，也没有引用出处。采购主管把这张截图转发给了她的首席信息安全官（CISO），只写了一行字：“这就是他们派来处理我们合规问题的东西。”你失去了续约机会，不是因为答案错了，而是因为语气在那个场合不对。

大多数团队之所以只发布一种智能体人格面具，是因为组织架构中只有一个支持团队。然而，客户群体很少是单一的。企业买家期望正式感、引用来源和明确的人员升级路径。自助服务用户想要快速回答和零摩擦。开发者想要代码，而不是长篇大论。单一的人格面具在某些群体看来是居高临下的，而在另一些群体看来则是不专业的。而“让用户选择语气”则是将一个本不该由用户承担的产品决策推卸给了用户。

确定性软件的 PRD 模板已经演变成了一种肌肉记忆。问题陈述、用户故事、验收标准、边缘情况、成功指标、范围削减。工程师知道如何阅读它，产品经理（PM）知道如何填写它，设计师知道该从哪些章节提取原型图。这是一个被磨损得恰到好处的产物，它交付了一代又一代的 CRUD 应用、仪表盘和 SaaS 工作流。

它也没有“模型在 5% 的情况下会出错”的字段，没有“我们接受的评估（Eval）合格分”的字段，没有“当模型拒绝回答时用户会看到什么”的字段，也没有“该 PRD 锁定了哪个提示词（Prompt）版本，以及发布后允许谁进行更改”的字段。每一个按照这种模板交付的 AI 功能，都带有一份谁也没写下来的隐性契约。复盘总是让人们在遭遇挫折后才痛苦地意识到这一点。

你账单上的模型名称与上季度完全一致。API 响应中的版本字符串也没有改变。模型卡片和定价页面看起来也一模一样。然而，你的评估得分却下降了 0.5 分，拒绝模式以你提示词中未要求的方式发生了偏移，上周二还收到了几起客户投诉，称输出结果“感觉不一样”。你调试了代码，却一无所获。代码没变。权重变了。

静默量化（Silent quantization）是你合同约定的模型与供应商实际交付的模型之间的差距。之所以发生这种情况，是因为推理经济学持续收紧——每一美元的 GPU 算力在本季度必须承载比上季度更多的请求——而消化这种压力的最廉价方式，就是在更廉价的精度层级上重新托管同一个模型。FP16 变成了 FP8。在某些路由中，FP8 变成了 FP4。混合精度分片被替换进来。版本字符串没有变动，因为版本字符串从来都不是精度合约，而是一份营销合约。

当你团队中的初级工程师第一次输入 --update-snapshots 并推送到 main 分支时，你的测试套件就不再是测试套件了，它变成了一份记录稿。虽然 Diff 依然显示为红绿颜色，CI 徽章依然会变为通过，但信号已经悄然反转：测试套件不再告诉你代码是否正确，而是告诉你是否有人费心看过输出。对于确定性的代码，这种风险尚在可接受范围内，因为大多数 Diff 确实是符合预期的。但当网络调用的另一端是一个随机模型时，同样的流程会让每一个 PR 变成一场硬币投掷，让每一位评审者变成一个橡皮图章。

快照测试曾是确定性世界里的一个美妙构想。你记录下上周二 render(<Button />) 的生成结果，断言本周二它会生成相同的字符串。从定义上讲，任何 Diff 都是值得人工核查的行为变更。这种模式在 Jest、Vitest、Pytest、整个 React 生态系统以及一代又一代的 UI 快照扩展中得以幸存，是因为底层契约依然成立：相同的输入加上相同的代码等于相同的输出。但这个契约对 LLM 调用并不奏效。相同的输入、相同的代码加上相同的提示词（Prompt），却会产生不同的字符串——而且这种差异并非 Bug，而是产品按设计正常运行的结果。

在你的 AI 团队中，被低估最严重的资产是每周一小时，由三个人坐在房间里阅读你的产品实际对用户说了什么。不是综合评分。不是移动平均值。不是仪表盘。而是实际的对话记录。逐字逐句的输出。模型悄然形成的懒散措辞。你的分类体系中未涵盖的意图。用户尝试了三次，用三种不同的方式表达需求，而你的评估准则（eval rubric）却将这三次对话都评为“满意”。

将这一小时制度化的团队，能够建立起仪表盘永远无法呈现的 AI 功能心理模型。跳过这一步的团队，会根据看起来不错的指标发布六个月的产品，然后在下一次季度业务回顾（QBR）中发现，在无人察觉时，中位数体验已经漂移到了令人遗憾的境地。

智能体最糟糕的两种失败模式看起来截然相反，但它们其实源于同一种失效的策略（Policy）。第一种智能体在执行任何操作前都会先问四个后续问题，这让它的用户因为繁琐而最终放弃使用。第二种智能体从不提问，它自信地生成用户不得不推倒重做的输出，这让它的用户对其产生不信任感。同样的策略，只是一个缺失参数的不同设置：即提问的成本相对于错误答案成本的比例。

大多数智能体根本没有任何策略。模型只是被要求“提供帮助”，然后被留下来独自应对模糊性。因为下一个 Token 预测（next-token prediction）机制奖励对答案的确定性，所以智能体倾向于猜测。又因为 RLHF 奖励礼貌，智能体偶尔会为了安全而过度纠偏并提出问题。其结果就是一种毫无原则的行为，这种行为在不同会话之间波动不定，团队层面也无法直观地判断智能体何时会暂停、何时会盲目推进。

澄清预算（Clarification budget）正是那个缺失的参数。它是针对每个任务制定的、允许智能体施加摩擦力的配额，并配有一套判断何时值得花费预算去提问的决策规则。你可以把它看作是对话领域的“延迟预算（latency budget）”——每个产品都有一个，即使没人把它写下来；而那些把它写下来的团队，就能停止交付那种让人困惑的智能体。

许多自称“有评估（evals）”的团队，其实际情况是：有一个仪表板，某人每周运行一次测试套件，然后将数据粘贴到没人看的 Slack 频道。评审人员批准提示词（prompt）更改时，甚至根本没看过它是否影响了测试套件，而回归问题（regression）两周后才在客户反馈单中显现。评估确实存在，但评估并未进入开发循环。

解决办法在于结构，而非意愿。只有当评估存在于变更发生的地方——即 Pull Request（PR）评论中，紧挨着代码差异（diff），并带有单个 PR 的增量变化和评审员无法忽视的回归提醒时，评估才能真正起到质量把关的作用。在其他任何地方，它们都只是表演性的产物：投入了大量精力构建，却什么也拦截不到。

“先创建后通知”的序列在开发阶段运行良好。而“先通知后创建”的序列则会为一个尚不存在的实体触发 webhook，导致消费者返回 404，接着你的团队会花上一周时间来调试这个看起来像是不稳定的集成测试。这种不稳定并非随机。它是确定性的，源于你的工具集拥有而你的规划器（planner）却不知晓的隐藏排序不变性。

这就是生产环境中 Agent 工具调用排序 bug 的常见形态：工具集在底层以偏序（partial order）方式组合——某些操作必须先于其他操作执行，而另一些则可以按任意顺序运行——但在规划器看来，它们只是一个无序的能力集合。模型选择了一个昨天行之有效的顺序。而明天，一次提示词修改、模型升级，甚至只是不同的 temperature 采样，都会选出另一个顺序。对于阅读追踪记录（trace）的人来说，这两种顺序看起来都很合理。但其中只有一个是正确的。

如果不声明顺序，团队交付的就是一个最终会被模型的提示词敏感性（prompt sensitivity）触发的 bug 隐患。

在 AI 工程领域流传着一个隐秘的神话：模型的一次“小幅”升级——比如 claude-x.6 到 claude-x.7，或者 gpt-y.0 到 gpt-y.1，甚至是按日期推进的补丁级快照更新——都应该是无缝替换的。厂商发布的更新日志里谈论着推理能力的提升、更低的延迟以及更好的工具调用。版本号轻轻跳动，没有任何迹象表明这些改动会破坏现有系统。

然后更新上线了。值班频道随即被各种警报点亮：摘要生成器莫名其妙多出了一段以前没有的话；JSON 提取器开始对以前不处理的 Unicode 字符进行转义；Agent 循环在以前只需三次调用就能完成的任务上，现在却触碰到了最大步数限制。从整体上看，评估得分似乎没什么问题，但用户可见的功能却在细微之处出了错。

浏览任何成熟工程团队的 PR 队列，你都会看到同样的现象：一个四行的 Bug 修复会引来三轮关于命名、错误处理和测试覆盖率缺失的评论；而对系统提示词（System Prompt）的四十行修改却能凭借一句 “LGTM, ship it” 轻松过关。作者对此不以为意，因为差异对比（diff）看起来就像文档；审查者也无所谓，因为他们对于那段英文块中什么是“好”没有心理模型。结果是，一个具有功能发布级别影响范围的提示词更改，却仅以修复拼写错误的门槛通过了审查。

这是每个在生产环境中使用 LLM 构建产品的团队所面临的隐秘质量危机。代码库拥有数十年积累的纪律——Linter、类型检查、代码所有者（Code Owners）、测试关卡、发布窗口。而真正引导模型的产物——系统提示词、评估准则（Eval Rubric）、工具描述、少样本示例（Few-shot Exemplars）——虽然存放在同一个仓库中，却通过为英文散文设计的审查流程进行发布。因此，提示词回归、评估准则漂移和工具模式（Schema）损坏，却能以团队永远不会接受的代码质量标准通过。

公平性审计曾是发布流水线中的一个绿色对勾。合规团队在 3 月签署通过了它。支持工单从 10 月开始涌现——来自一个模型从未被评估过的国家的的一组用户，得到的答案效用远低于其他人。模型本身没有任何改变。审计对模型的判断从未出错。它错在对世界的判断。

这是一个没人愿意大声说出来的失败模式：静态偏差评估只是已经发生漂移的数据流中公平性的一个快照。评估在运行时并没有撒谎。它告诉你的是一个关于不再存在的分布的真实情况。等到支持团队积攒了足够的工单并归纳出模式时，模型对该群体的处理不公已经持续了两个季度，而审计报告已经过时一年了。

你的 AI 路线图的瓶颈不是 GPU 容量、模型可用性或 Prompt 工程的品味。它是那一两个真正懂得如何构建能发现回归（regression）的评估（eval）的工程师的日程表。每个负责功能的产品经理都在他们的队列中。每一次模型升级都在他们的队列中。每一次群体漂移、每一次 Prompt 修改、每一个“这个评审模型（judge）是否仍然校准”的问题，最终都会进入同一个收件箱。而这位工程师在本季度已经说了三次“不，这还没准备好”，两次被否决，眼睁睁看着回归在生产环境中复合增长，现在正在更新他们的 LinkedIn。

这就是评估瓶颈，大多数组织在被咬到之前都意识不到它的存在。到 2025 年为止，显而易见的工作重点是 AI 工程师——招聘 AI 工程师、发布 AI 功能、迭代 Prompt、更换模型。到了 2026 年第一季度，吞吐量问题下移了一层。将 AI 团队人数翻倍的团队发现，增加更多功能工程师并没有让功能发布得更快，因为每个功能仍然需要一个评估（eval），而负责评估的工程师还是那个人。