每个发布 LLM 功能的团队最终都会开同一种会。有人会问：新模型 —— 或者新提示词、新的检索优化 —— 是否已经好到可以发布。整个周末都在进行测试的高级工程师说，感觉效果更犀利了。产品经理（PM）则提到，上周正好有客户投诉过这个问题。团队里的怀疑论者翻出一份对话记录，显示旧版本明显更好。45 分钟后，没人改变主意，最后的决定要么由发言最积极的人做出，要么由职位最高的人拍板。
那场会议是一个症状。它之所以反复出现，是因为团队正试图用轶事（anecdotes）来解决一个实证问题 —— 这次变更究竟是让系统变好了还是变坏了？而轶事是无法收敛的。你可以整天堆砌这些案例。争论永无止境的原因在于，缺乏一个大家都同意受其约束的共享工具。那场本该是 Eval 的会议，就是你发现自己正缺少一个 Eval 的时刻。
为什么轶事无法解决问题
人类对模型质量的直觉确实是真实的信号，但它是嘈杂的，且带有可预测的偏见。周末进行测试的工程师可能只运行了 30 个查询，这些查询都是他们自己选的，其中大部分测试的是他们个人关心的案例。PM 记得的是在 Slack 频道引发讨论的失败案例，而不是围绕它的上百次无声的成功。怀疑论者发现了一个退化（regression）点，一旦发现，他们就会陷入锚定效应。
这些人都没有错。他们各自掌握着输出分布中不同的、小规模的、非随机的样本，并像对待整体样本一样进行争论。这就是会议无法收敛的原因：你无法通过提高嗓门来平均三个有偏见的样本。你需要对比两个版本在相同输入下的表现并进行统计，而这恰恰是所有人开会前都没做的事。
还有一个更深层的问题。“好到可以发布”并不是一个单一的问题。它至少捆绑了三个问题：平均质量提高了吗？我们关心的特定行为是否发生了退化？成本或延迟是否超出了承受范围？模型升级可能会提升平均质量，同时悄无声息地破坏你最敏感的工作流。一个被广泛引用的例子：一个团队正准备将模型更换为公开榜单（leaderboard）中名列前茅且更便宜的新版本，在运行了他们自己的任务套件后发现，新模型在实际工作负载上的表现竟然差了 3 个点 —— 并且在 API 处理任务中多产生了 40% 的不安全代码模式。榜单说要升级，但他们的 Eval 说不要。如果没有这个 Eval，这次更换就会凭“感觉”发布，而退化将在两周后出现在生产环境中。
会议究竟在要求什么
剥离人的因素，这场反复出现的争论其实是在要求一件事：一个大家预先同意并视为标准的数据。不一定是一个完美的数据 —— 而是一个共享 的数据。Eval 的全部价值在于，它将“助手感觉变差了”转化为会议室里每个人都受其约束的东西，因为他们在看到分数之前就已经签字认可了该指标。
这就像软件工程几十年前在回归测试上所做的转变一样。没有人会召集会议来争论重构是否破坏了登录流程。那里有一个测试，要么是绿灯，要么是红灯。在某人编写测试的那天，争端就已经平息了，之后的每一次变更都免费继承了这一结果。LLM 功能似乎可以免受这种约束，因为它们的输出是模糊且主观的，因此团队断定它们无法被测试，转而诉诸会议。这个结论是错误的。模糊的输出评分更难，但并非不可能，且“更难”是一个有着已知解决方案的工程问题。
解锁一切的关键思路：反复出现的发布争论并不是一个需要被做好的决策，而是一个尚未建立的指标。每次会议召开时，它都在生成你所需的确切数据集 —— 即在真实的输入上，理智的人们达成了不同结论的真实分歧。这些就是你最难的 Eval 案例，是免费送上门的。这场会议其实是你一直拒绝记录下来的 Eval 的数据收集步骤。
将争论转化为常设指标
你不需要一个平台或耗费一个季度的基础设施工作来开始。你需要将争论的内容转化为一组固定的输入和达成一致的判决。以下是从反复会议转向常设指标的路径：
从分歧中挖掘案例 。怀疑论者翻出的记录、PM 记得的客户投诉、工程师运行的 30 个查询 —— 这些不是会议的弹药，而是种子的数据集。从业者的共识是从小处着手：选取 20 到 50 个源自真实失败、错误报告和支持工单的案例，而不是成百上千个合成案例。即使在小样本中，显著的质量差异也会清晰地显现出来，所以你不需要大规模数据就能开始捕捉退化。
记下判决，而不只是输入 。对于每个案例，记录下正确或可接受的答案是什么。这是真正起作用的一步，因为它迫使分歧在产生分数之前就公开化。如果两个领域专家无法独立地对某个输出是否合格达成一致，那么这个案例就太模糊了，不适合作为 Eval 案例 —— 要么细化它，要么剔除它。编写参考判决的纪律性会让你发现，一半的发布争论根本与模型无关，而是关于什么是“好”的潜在大分歧。
使用最廉价且有效的方法进行评分 。有些案例有客观的检查方式 —— 是否返回了有效的 JSON，是否调用了正确的工具，是否保持在 token 预算之内。对于这些，使用代码检测；它快速、可重复且免费。对于主观案例 —— 推理质量、语气、帮助程度 —— 使用 LLM 作为评委（LLM-as-judge），但在信任它作为决策门槛之前，先根据人类在样本上的判决对其进行校准。为每个维度使用专属的评委模型，而不是用一个提示词要求整体评分，并给评委一个明确的“不确定”选项，让它在无法判断时弃权而不是凭空捏造。目标不是一个完美的评分员，而是一个足够一致、其波动能追踪真实波动的评分员。
在两个版本上运行并阅读记录 。你想要的输出不是“v2 得分 84%”，而是“v2 平均优于 v1，但在以下四个案例中出现了退化，其中三个是安全敏感案例”。永远不要只看聚合后的表面数据 —— 数字告诉你去哪里 看，而阅读失败的记录则能告诉你这种退化是真实的还是评分器的误判。当没有人阅读底层输出时，通过率是具有欺骗性的。
以数字作为决策依据 编写评估（eval）只是工作的一半。另一半是文化上的：只有在团队预先同意评估结果具有约束力的情况下，这个数字才能为会议画上句号。如果评估只是填充了一个没人有义务根据其行动的仪表盘，那么它什么也改变不了——你们依然会开会，只是背景里多了一个图表，且双方都会选择性地引用它。
因此，要把指标融入决策中，就像把回归测试融入部署流程一样。挑选一小部分核心用例（anchor set）——即那些你绝不容许性能倒退的关键路径场景——并维持一个接近完美的通过率，一旦通过率下降就阻止发布。随着实验性功能的稳定，证明这些功能的用例将“晋升”到该回归集中，从而形成一种棘轮效应：每一次艰苦逐绝的改进都变成了无法跌破的底线。成本低、确定性强的检查可以在每次提示词（prompt）更改时在 CI 中运行；而昂贵的基于评判模型（judge-based）的检查可以在模型切换前运行。无论哪种方式，阈值都是一次性商定的，而不是在每次发布时重新审议。
这并不会消除人为判断——而是重新安置了它。你依然会争论，但现在你争论的是 正确 的事情：哪些用例应该放入测试集，阈值应该设在哪里，以及被标记的回归对于本次发布是否可以接受。这些是值得开会讨论的真正决策。“感觉变好了吗？”则不是，它绝不该消耗资深工程师 45 分钟的时间。评估并不会让团队变得不爱思考；它只是防止他们把思考精力浪费在脚本就能回答的问题上。
这里有一个诊断方法。下次预定“它够好了吗？”的会议时，注意到底缺失了什么。缺失的不是更多的讨论、更多的资深判断，或者拥有裁决权的协调人。而是包含一致判定结果的一组固定输入，且每个人都同意受其约束。如果这个交付物存在，会议将变成对某个数字 30 秒的匆匆一瞥。
那些交付 LLM 功能最快的团队，并不是拥有最强直觉或最果断领导者的团队。他们是很早就察觉到，那些反复出现的发布争端其实是伪装起来的常设指标——他们花了一个下午把它写下来，而不是在一年里每两周开一次同样的会。你一直在进行的争论，就是你一直拒绝构建的评估。构建它一次，会议就会消解为发布前运行的一次检查。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
