107 篇博文 含有标签「evaluation」

你 Prompt 仓库中的 diff 显示有三行发生了变化。生产环境中的行为差异却显示一切都变了。安全团队将一条拒绝规则从第 14 行移动到了第 87 行，目的是为了“将其与相关的防护栏归类”；产品团队没有注意到这一点，因为措辞完全相同；一周后，评估套件显示在对抗性输入上的得分下降了 9 个百分点。没有人修改这条规则，只是有人移动了它。在一个拥有 2,400 token 的系统 Prompt 中，由于对防护栏存在首因效应（Primacy Bias），对指令遵循存在近因效应（Recency Bias），移动一条规则所带来的行为改变与重写它一样具有承重性——而你的工具对这两者都无法感知。

这是 AI 团队在回归评审结束时，而非开始时才会发现的合并冲突模式。系统 Prompt 在 2025 年底的某个时候增长到了 2K token 以上。安全团队负责顶部，产品团队负责中间，智能体（Agent）团队负责底部。三个月的“小幅编辑”在无声无息中重新排列了每个人的意图，因为原本适用于代码的基于行的 diff 工具无法告诉你一条指令已经跨越了区域边界。Bug 不在任何一次单一的编辑中。Bug 在于位置现在即策略，而你对位置却没有任何策略。

一个典型的 RAG 流水线包含两个模型，而不是一个。检索器从向量数据库中提取 50 到 100 个候选文档，而重排序器（reranker）——无论是交叉编码器（cross-encoder）、LLM-as-judge 提示词还是混合方案——都会对这些候选文档进行重新评分，并将前 5 个结果交给回答模型。你的评估套件测量端到端的回答质量，测量检索器的 recall@k，但它并不测量重排序器。因此，当重排序器发生隐性偏移（drift）时，仪表盘上显示的“回答质量下降了 4 个点”却没有任何因果线索，团队会花费三天时间去调试一个根本不是问题的提示词。

重排序器是那个隐性的第二个模型。它介于检索器和生成器之间，拥有自己的评分分布、自己的提示词（如果是基于 LLM）或自己的权重（如果是交叉编码器），并且它可以独立于其他任何组件发生性能退化（regress）。大多数团队从未单独对它进行评分。他们编写的评估套件将流水线视为一个具有长上下文窗口的单一模型，而实际上它是两个串联的模型，且其中间接口并不属于任何一个团队。

一个多语言发布版本，如果只是将英文提示词翻译成 N 种语言，并将英文评估集也翻译成同样的 N 种语言，那它并没有发布一个真正的多语言产品。它只是将同一个产品发布了 N 次，并让所有的失败模式在它自己的仪表盘上变得不可见。该系统虽然表达流畅，但在文化层面上显得格格不入，而团队优化的指标——翻译质量——并不是衡量用户反应的正确维度。

发布当天的明显缺陷通常很小。一位日本用户收到的回复虽然语法正确，但显得生硬无礼。一位印度尼西亚用户发现助手以一种欢快直接的语体说话，听起来却很不礼貌。一位韩国用户收到的建议是围绕个人选择展开的，而提示词其实是关于家庭决策的。这些都不是翻译错误。它们是文化语体（cultural-register）错误，翻译无法修复，且经过翻译的评估也无法检测出来。

模型发布的公告在周二早上落地。博客文章开头是一张图表：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 更新而来的多模态退化。

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