这场本该成为评测 (Eval) 的会议

每个发布 LLM 功能的团队最终都会开同一种会。有人会问：新模型 —— 或者新提示词、新的检索优化 —— 是否已经好到可以发布。整个周末都在进行测试的高级工程师说，感觉效果更犀利了。产品经理（PM）则提到，上周正好有客户投诉过这个问题。团队里的怀疑论者翻出一份对话记录，显示旧版本明显更好。45 分钟后，没人改变主意，最后的决定要么由发言最积极的人做出，要么由职位最高的人拍板。

那场会议是一个症状。它之所以反复出现，是因为团队正试图用轶事（anecdotes）来解决一个实证问题 —— 这次变更究竟是让系统变好了还是变坏了？而轶事是无法收敛的。你可以整天堆砌这些案例。争论永无止境的原因在于，缺乏一个大家都同意受其约束的共享工具。那场本该是 Eval 的会议，就是你发现自己正缺少一个 Eval 的时刻。

为什么轶事无法解决问题

人类对模型质量的直觉确实是真实的信号，但它是嘈杂的，且带有可预测的偏见。周末进行测试的工程师可能只运行了 30 个查询，这些查询都是他们自己选的，其中大部分测试的是他们个人关心的案例。PM 记得的是在 Slack 频道引发讨论的失败案例，而不是围绕它的上百次无声的成功。怀疑论者发现了一个退化（regression）点，一旦发现，他们就会陷入锚定效应。

这些人都没有错。他们各自掌握着输出分布中不同的、小规模的、非随机的样本，并像对待整体样本一样进行争论。这就是会议无法收敛的原因：你无法通过提高嗓门来平均三个有偏见的样本。你需要对比两个版本在相同输入下的表现并进行统计，而这恰恰是所有人开会前都没做的事。

还有一个更深层的问题。“好到可以发布”并不是一个单一的问题。它至少捆绑了三个问题：平均质量提高了吗？我们关心的特定行为是否发生了退化？成本或延迟是否超出了承受范围？模型升级可能会提升平均质量，同时悄无声息地破坏你最敏感的工作流。一个被广泛引用的例子：一个团队正准备将模型更换为公开榜单（leaderboard）中名列前茅且更便宜的新版本，在运行了他们自己的任务套件后发现，新模型在实际工作负载上的表现竟然差了 3 个点 —— 并且在 API 处理任务中多产生了 40% 的不安全代码模式。榜单说要升级，但他们的 Eval 说不要。如果没有这个 Eval，这次更换就会凭“感觉”发布，而退化将在两周后出现在生产环境中。

会议究竟在要求什么

剥离人的因素，这场反复出现的争论其实是在要求一件事：一个大家预先同意并视为标准的数据。不一定是一个完美的数据 —— 而是一个共享的数据。Eval 的全部价值在于，它将“助手感觉变差了”转化为会议室里每个人都受其约束的东西，因为他们在看到分数之前就已经签字认可了该指标。

这就像软件工程几十年前在回归测试上所做的转变一样。没有人会召集会议来争论重构是否破坏了登录流程。那里有一个测试，要么是绿灯，要么是红灯。在某人编写测试的那天，争端就已经平息了，之后的每一次变更都免费继承了这一结果。LLM 功能似乎可以免受这种约束，因为它们的输出是模糊且主观的，因此团队断定它们无法被测试，转而诉诸会议。这个结论是错误的。模糊的输出评分更难，但并非不可能，且“更难”是一个有着已知解决方案的工程问题。

解锁一切的关键思路：反复出现的发布争论并不是一个需要被做好的决策，而是一个尚未建立的指标。每次会议召开时，它都在生成你所需的确切数据集 —— 即在真实的输入上，理智的人们达成了不同结论的真实分歧。这些就是你最难的 Eval 案例，是免费送上门的。这场会议其实是你一直拒绝记录下来的 Eval 的数据收集步骤。

将争论转化为常设指标

加载中…