148 篇博文 含有标签「evaluation」

黄金评估集的通过率为 94%。模型在本季度已经升级了两次，提示词修改了 11 次，工具库增加了 4 个，仪表盘依然是一片绿色。然而，一名销售工程师转发了一份对话记录，显示智能体（Agent）自信地将客户引导至一个两个月前就已停用的工作流；与此同时，支持团队负责人悄悄开启了一个讨论组，询问为什么在评估流水线显示没有回归的情况下，满意度评分已经连续下滑了六周。黄金集并没有撒谎。它只是在用上个季度的产品标准来衡量这个季度的流量，而除此之外没人要求它做别的事。

这是评估系统最难察觉的一种失效模式，因为本该检测质量回归的工具本身就是误报的源头。通过率是针对集合中的项目计算的；集合中的项目是根据某个时间点的使用快照精心筛选的；用户的使用方式已经演进，但通过率依然保持“干净”。团队信任绿色的仪表盘，发布了另一个模型升级，几个月后才发现生产环境的分布与评估集所衡量的东西已经南辕北辙，而这种状态持续的时间超出了所有人的想象。

解决方法并不是提高黄金集的更新频率。更新频率是一个错误的调节旋钮；正确的旋钮是拥有第二个针对不同时间窗口校准的工具，以便在用户发现问题之前，通过两者之间的分歧来暴露漂移。这第二个工具就是影子评估（Shadow Eval）—— 一个从当前生产流量中持续重建的并行评估集，它与黄金集并行运行，其明确的任务就是与黄金集唱反调。

LLM-as-judge 是解放生产力的关键，它让评估覆盖率在不增加人工评分团队的情况下扩大了 10 倍。问题在于，这种解放效果在评分范围内并非均匀分布。裁判与人类的一致性在分布的“模糊中间地带”（muddy middle）最高——即那些没人会去纠结的答案——而在决定功能是发布、回滚还是在凌晨两点触发告警的关键长尾输出上，这种一致性会发生崩溃。在没人满意的评分范围内，仪表盘上的图表却始终保持绿色。

这就是 LLM 裁判的天花板：一种具有非均匀误差分布的测量工具，而团队却将其解读为一个单一的数字。与人类 80% 的总体一致性是大多数供应商在页面上打出的标题；这同时也是让团队在裁判信息量最低的地方最信任裁判的数字。

打开任何交付 LLM 功能超过一年的团队的提示词库，你都会发现同样的情况：每个提示词都有三个略有不同的版本。一个是喜欢 Sonnet 及其指令遵循能力的工程师调优的。一个是由于延迟预算而切换到 Haiku 的工程师重写的。还有一个属于那个只在 Opus 上运行且从未迁移过的原型。每个版本都有略微不同的系统消息、不同的工具目录描述方式、不同的格式引导 —— 而且没有人追踪它们是如何产生漂移的。

""

这不是卫生问题。而是一种在每次模型升级时都会累积的协作税，它正在悄悄破坏你的评估套件与线上流量之间的关系。词库本应是共享资源。而在实践中，每个功能交付时都使用了作者最后测试的版本，评估套件运行的是评估作者偏好的版本，而路由层则根据成本而不是根据哪个变体实际通过了线上评估来选择。

那些没有察觉到的团队，已经在付出代价了。

在国际化发布的财务规划电子表格中，有一个清晰的项目：“将评估覆盖范围扩展到七个新语言区域 —— 假设为当前评估成本的 7 倍。”英语评估套件耗时两周，花费 4 万美元构建，因此七个语言区域将花费 28 万美元和一个季度的工程时间。CFO 签字了。产品 VP 签字了。发布启动了。

六个月后，实际的评估账单已经突破 31 万美元，团队仍在搭建最后两个语言区域。标注供应商在葡萄牙语（巴西）人员库中已经换了三批人，因为前两批产生的人员间一致性（inter-rater agreement）分数，任何诚实的审查都会称其为随机。德语裁判模型（judge model）在相同内容上的评分比英语模型低 6% —— 团队最初将其解读为德语模型的退化（regression），直到人工审核发现裁判模型本身才是退化的根源。评估负责人每周要花 40% 的时间处理一个没人预算过的问题：我们如何知道语言区域 A 的通过率确实比语言区域 B 差，而不是因为跨语言区域的测量比差距本身的噪声更大？

事故报告读起来就像一个单元测试的恐怖故事。一次 Prompt 编辑作为“前置说明清理（preamble cleanup）”的一部分，删除了一段五行的安全条款。测试套件中的每个 Eval（评估）都通过了。每个 Judge（裁判）评分都保持在容差范围内。两周后，一个面向客户的助手产生了一个本该被拒绝的响应，这种响应会在深夜 11 pm 触发信任与安全（Trust & Safety）页面的报警。复盘将这次回归追溯到了一个 PR 中的单处删除，而当时没有任何人标记它，因为负责捕捉回归的套件对安全条款是否存在没有意见——它只对模型在套件记得询问的情况下的表现有意见。

!["https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=Prompt%20Linting%20%E6%98%AF%20Eval%20%E4%B8%8E%E7%94%9F%E4%BA%A7%E7%8E%AF%E5%A2%83%E4%B9%8B%E9%97%B4%E7%BC%BA%E5%A4%B1%E7%9A%84%E9%82%A3%E4%B8%80%E5%B1%82"]

这就是行为评估（behavioral evals）与结构正确性之间的鸿沟。Eval 衡量的是模型生成的内容；它们不衡量 Prompt 本身是什么。而 Prompt 就像代码一样，有一个独立于行为而存在的结构层——必须存在的章节、必须解析的引用、必须插值的变量、必须遵守的长度预算、以及绝不能出现的弃用标识符。当结构层断裂时，行为表现通常会在一段时间内保持绿色，直到生产环境中的某个边缘情况将故障暴露为事故。

你 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 就不再像是产品承诺，而更像是对一个没人能复现的私人测试环境的声明。