92 篇博文 含有标签「evaluation」

模型发布的公告在周二早上落地。博客文章开头是一张图表：HumanEval 提升了 4 个点，SWE-bench Verified 提升了 6 个点，MATH 提升了 3 个点，而当前流行的 Agent 测试套件提升的数值在一年之前足以写成一篇研究论文。到了周二下午，你公司的 Slack 频道里就会出现该图表的截图，随之而来的还有一个类似决策的问题：“我们要切换过去吗？”这个讨论线程将基准测试的增量视为一种预测 —— 仿佛这些数字描述了新模型在 你的 产品中、使用 你的 提示词、在 你的 工具链下、针对 你的 评估准则所能表现出的效果。事实并非如此。厂商给出的数字是你可能看到的性能上限。你实际获得的提升大约在零到该标题数值的一半之间，如果不运行一次厂商从未运行过的评估，你无法得知确切结果。

这并非在抱怨基准测试的有效性。基准测试是真实的。它们是针对真实的评估套件运行的。厂商没有撒谎。问题在于厂商的评估套件是一个理想化的环境，剥离了生产部署中引入的每一个变量，而在这些条件下生成的数字在结构上无法预测模型在你环境下的行为。将其视为一种预测是一种范畴错误 —— 它会导致采购决策、容量规划承诺以及发布时间表都基于虚构的事实进行校准。

我上个季度合作的一个团队连续拒绝了三名进入 AI 工程师流程的候选人。三个人都挂在了编程筛选环节 —— 就是那种让你在 35 分钟限时内实现一个滑动窗口去重器的题目。团队随后录用了通过该环节的候选人。四个月后，正是这位工程师交付了一项功能，其 eval（评估集）在 CI（持续集成）中得分高达 92%，但上线后的第二天，支持队列就爆满了。那个 eval 衡量的是与精选测试集的精确匹配。而生产环境的用户提问方式完全不同。招聘小组里没有人问过候选人他们会如何捕捉到这一差距。

这就是 Bug 的轮廓。面试流程筛选的是工作中价值最低的技能，却对最重要的技能视而不见。团队没有“判断力”面试轮次。他们只有编程轮、系统设计轮和行为面试轮，运行的还是 2021 年的那套循环 —— 那套为编写针对稳定库的确定性代码的工程师量身定制的流程。

你的模型可以拥有一种能力，在关键时刻，这种能力比你发布的任何其他行为升级都更有价值：能够说“我没有可靠的答案”并且是认真的。不是那种基于关键词匹配的安全拒绝。也不是模型在处理争议性话题时，从 RLHF 中学到的那种模棱两可的坏习惯 (hedging tic)。而是真正的能力——一种经过校准的弃权 (calibrated abstention)，仅当且仅当模型的内部证据不支持生成自信的回答时才会触发。

你永远不会偶然获得这种能力。LLM 技术栈中的每一个默认设置都在反向推动。

评测团队在 PPT 上写下一个数字：“p95 延迟为 1.2s。” 产品上线。一周后，值班人员发布了一张图表：生产环境中的 p95 为 4.8s，并且在晚餐高峰期持续攀升。工程师们在接下来的五天里争论是否有性能倒退、为模型版本增加埋点、向供应商提交工单——最终发现，除了测量数字的地点之外，什么都没有改变。评测环境报告的是一台安静的机器在热缓存上运行串行调用的延迟。而生产环境是另一套系统。p95 从未出错；它只是在回答一个不同的问题。

这就是评测工具的延迟谎言。这并不是因为基准测试做得不好——大多数团队使用的工具都很合理，报告数字也很诚实。问题在于“模型延迟”与“用户感知的延迟”之间的鸿沟，以及你为开发构建的环境几乎总是测量前者，却暗示后者这一事实。一旦你理解了这一点，基于基准测试得出的延迟 SLO 就不再像是产品承诺，而更像是对一个没人能复现的私人测试环境的声明。

一位产品经理写下了一段话：“助手应当乐于助人、准确且简洁，绝不能让客户感到匆忙。”一位工程师读了这段话，打开一个 YAML 文件，编写了 47 个加权标准，以便 LLM-as-judge 能够为每一个追踪（trace）生成一个分数。六个月后，那个 YAML 文件成了产品的实际规范。每一次发布都受其把关。每一次回归警报都基于它触发。每一个“达到发布质量”的决策都通过它来路由。而产品经理从未读过它。

这是当今 AI 工程中最为常见的、无意间发生的产品所有权转移。评估准则（rubric）不是对规范的衡量 —— 它就是规范，就像编译器不是对语言的描述，而是它的运行真相。就像编译器一样，评估准则也有决定语义的实现细节。哪种失败模式得 0 分而不是 0.5 分？哪个标准的权重是 0.3 而不是 0.05？哪些行为在评估准则中缺失，从而完全未被计算？每一个都是产品决策。而它们都没有出现在最初的任务书中。

我合作过的一个团队曾有一个 JSON 提取提示词，其中包含 11 个手工调优的 few-shot 示例。在之前的模型上，这些示例将精确匹配准确率提升了 6 个百分点。模型升级后，同样的 11 个示例反而让准确率下降了 2 个百分点。没有人更改过提示词。没有人更改过评估集。这些示例就是失效了——而且更糟的是，它们开始产生误导。

这种退化并不是新模型的 bug。它是提示词本身的一种“腐化”模式。每当团队在迁移模型版本时将提示词视为固定资产，这种现象就会出现。Few-shot 示例并不是提示词独立的一部分，它们是“模型-提示词对（model-prompt pair）”的一部分。在不重新评估另一方的情况下迁移其中一方，会产生任何绑定在单一模型版本上的评估套件都无法捕捉到的退化。

我上个季度合作的一个团队看着他们的 LLM-as-judge 分数在六周的提示词（prompt）迭代中从 78% 飙升至 91%。他们发布了产品。但用户却非常讨厌它。新的提示词产生了更长、格式更丰富、听起来更自信的回答 —— 而评委（judge）爱死了每一个回答。团队并没有构建出更智能的提示词。他们只是对评委的偏见进行了逆向工程。

这是团队中没人审计的失败模式。LLM-as-judge 有据可查的系统性偏见：无论质量如何，更长的回答得分更高；在两两比较中，第一个选项胜出的概率高于随机概率；且看起来像评委自身训练分布的输出得分高于不符的。如果你在十二个月前接入了一个 LLM 评委，且从未针对人类进行重新验证，那么你的分数就不是质量信号 —— 它们衡量的是你的提示词学会如何操纵其评估器的程度。

令人沮丧的是，捕捉这一点的审计方法很直接，防止它的校准纪律也很廉价，但几乎没有团队会执行其中任何一项。

我上个季度交流过的一个团队发布了一个模型路由（model router），在离线基准测试中获得了 96% 的路由准确率，并使平均推理成本降低了 58%。但在运行三周后，支持工单开始集中在特定的用户群体中——即那些通过 API 运行脚本化批量查询的企业管理员。低成本路径向这些用户发送了大量垃圾回复。路由完全按照设计运行，但设计本身错了。

这个故事代表了常态，而非特例。“能用小模型就用小模型，必须用大模型时才用大模型”的架构是生产环境下 LLM 系统中最可靠的成本杠杆之一，在标准基准测试中记录的成本降幅在 45% 到 85% 之间。但每个路由演示中引用的节省数字都假设了基准测试的分布。生产流量并不具备这种形态，而两者之间的差距正是质量回退（quality regressions）存在的地方——这些回退集中在你的离线评估（eval）从未设计覆盖的细分领域。

仪表板显示，这个版本的质量提升了两个点。文本评估套件运行正常。你的模型供应商发布了一个新的 Checkpoint，在你跟踪的每个公开基准测试上都超过了前一个版本。你推进了发布。一周后，支持团队标记了一个隐蔽但持续增长的工单量上涨，内容关于上传的屏幕截图 —— 用户反映模型“读错了图表中的数字”或“漏掉了表格中的一行”。几天后，音频转录的投诉接踵而至，主要来自非美式英语使用者。这些都没有出现在你的评估流水线中。发布看起来很健康。但事实并非如此。

这就是多模态评估漂移（Multimodal Eval Drift），几乎每一个在以文本为核心的架构上硬塞进视觉和音频功能的团队都在发布这种问题。曾经适用于文本的评估规范 —— 黄金集（Gold Sets）、LLM 作为评委（LLM-as-judge）、漂移仪表板、以及决定是否发布的综合评分 —— 在多模态领域仅剩空名。每个模态的失败率不具可比性，捕捉文本错误的评分标准（Rubrics）捕捉不到图像错误，而且产生文本黄金集的标注流水线是针对每半年发布一次的工作量校准的，而不是针对伴随每次 Checkpoint 更新而来的多模态退化。

正确的心智模型是：多模态并不是同一个模型上的一个开关 —— 它是一个具有不同失败分布的不同产品面，而忽视了这一区别的评估规范在每次模型发布时都在输出隐形的退化。

你的团队第一次意识到 Agent 可以调用 revoke_api_key 是在某个早晨，一位好心的用户输入了：“这个 Token 感觉太旧了，能帮我轮换一下吗？” 这个工具是在六个月前作为认证团队 MCP 服务批量导入的一部分注册的。它通过了 Schema 验证，出现在目录枚举中，然后就一直闲置在那里。没有任何评测（Eval）调用过它，也没有任何生产环境追踪（Trace）触及过它。直到某条提示词（Prompt）、某个规划器（Planner）决策，事件频道（Incident Channel）才发现该工具竟然存在。

这就是隐藏在每一个拥有复杂工具目录的 Agent 中的失效模式。四十个注册函数和一个可以组合它们的规划器，产生了一个你从未观察到的计划可达图的长尾。假设“我们测试了常用路径”掩盖了一个事实：危险的分支几乎从定义上来说就是你从未见过的那一个。

你的 AI 技术栈中最危险的数据存储是那个无人设计的存储。这一切始于一次冲刺期间的 Slack 消息：“真实用户是捕捉真实 Bug 的唯一途径 —— 让我们把一定比例的生产流量接入评估流水线，以便我们可以每晚进行回放。”六名工程师给这条消息点了赞。九个月后，该存储桶包含了 430 万条追踪（traces），当失败率上升时，评估任务会呼叫值班人员，而失败案例会被逐字发送到一个有 40 人阅读的 Slack 频道。这些追踪包含电子邮件地址、公司内部名称、部分信用卡卡号、员工电话号码，以及用户解释其愤怒原因的客户支持对话记录。

没有人梳理过数据流。没有 DPIA（数据保护影响评估）涵盖它。上季度的隐私审查查看了模型供应商的 API；但它没有查看你的评估任务。然后，一份数据主体删除请求送达，团队发现“删除该用户的所有数据”这句话已经无法对应到他们实际能做的任何事情。

单轮评估擅长一件事：在用户输入一次后便离开的任务中对模型进行排名。但对于你实际发布时会遇到的故障模式，它们毫无用处。比如在第三轮对话时就忘记用户目标的 Agent；在礼貌的重复询问下（“你确定吗？能再检查一下吗？”）就屈服并推翻正确答案的 Agent；或者在第四轮对话时还在问第二轮已经问过的澄清问题的 Agent，因为它读不懂自己的历史记录。这些问题都不会出现在对话仅进行一次交互就结束的基准测试中。

你可以进行真实用户评估，但每次发布都需要耗费数百小时的人工审查，而且问题往往在发布三周后才浮出水面。或者，你可以构建由 LLM 驱动的合成用户——具有人物角色 (Persona)、目标、耐心和放弃阈值的机器人——每晚针对待选 Agent 运行数千次对话。这是 τ-bench、AgentChangeBench 以及 2025–2026 年大多数生产级对话评估方案背后的方法。这种方法行之有效，直到它失效为止，而它失效的方式往往能让你更深刻地了解你的评估流水线，而不是合成用户本身。