你的评估流水线分数在稳步上升。响应质量在持续改善。LLM 评判者（LLM judge）捕获到了更多劣质输出。仪表盘一片绿色。
与此同时，支持工单零星涌来："助手老是给我冗长正式的回答，我只是随口问了个简单的问题。"紧接着又来了一条："它不再主动给出下一步建议了，以前会的。"然后你们的产品经理给你看了一张图表：上个季度用户满意度下跌了 12%，而这段时间，恰恰与你自动化评估指标爬升最快的那段时期高度吻合。
这就是评估自动化陷阱。你的度量体系开始为自身的优化而服务，而非为用户真正看重的事情服务 —— 由于整个反馈循环完全自动化，没有人察觉到问题，直到伤害已经落地生产。
我见过的每一个发布过“小规模”输出 Schema 变更的 AI 团队，都经历过同样的一周。有人在系统提示词（system prompt）中重命名了一个字段——比如将 summary 改为 tldr，或者工具目录中增加了一个必填的 confidence 参数——结果下一次 CI 运行就在 800 个与该变更毫无关系的 Eval 用例中亮起了红灯。提示词的 diff 只有 15 行。而 Eval 的 diff 却变成了一个为期四天的迁移项目，且无人规划、无人负责，也从未包含在预算之内。
这就是 Eval 迁移税（Eval Migration Tax）。这是任何路线图都没有考虑到的维护成本，它以发布延迟的形式支付，而这些延迟往往被归咎于“不稳定的测试”（flaky tests），而非真正导致它们的架构选择。大多数团队在意识到这一模式之前已经支付了数年的代价，因为每一个单独的事件看起来都像是普通的日常损耗。只有当你统计一个季度内用于迁移 Eval 的工程小时数，并发现它们超过了用于改进 Eval 本应衡量的模型行为的时间时，这种复利效应才会显现。
你的 AI 功能上线时带有一个质量门禁：每个回复都会经过一个 GPT-4 提示词，根据帮助性、准确性和语气进行评分。绿色分值不会触发报警。仪表盘显示通过率为 97%。与此同时，你的支持工单翻了一倍。
问题出在结构上。你使用了与生成输出相同类型的系统来验证这些输出。当生成器产生一个听起来很合理的虚假事实（幻觉）时，基于相同互联网文本分布训练的评判模型会认为这个幻觉是可信的并予以通过。两个模型共享相同的盲点。你的质量门禁衡量的是置信度，而非正确性。
大多数团队通过在系统提示词中加入一句话来处理弃权（abstention）问题：“如果你不确定，就说你不知道。”模型偶尔会遵守，但经常不遵守，而且这种失败模式是不对称的。一个自信的错误答案会以全速发布——它直接落入用户手中，在 Slack 讨论串中被引用，在下游摘要中被采纳。而一个诚实的弃权则会触发客户成功（CS）升级，因为用户期望智能体处理请求，而现在必须有人解释为什么它没有处理。六个月后，团队已经了解到哪种失败的发布成本更低，而那个名义上控制弃权的系统提示词修改，已经被悄悄地调整为倾向于顺从，而非诚实。
解决这个问题的准则不是寻找更好的措辞。而是要认识到，弃权是一个路由决策，而不是一种提示词模式。它理应拥有一个一等公民级别的输出通道、自己的 SLO、自己的评估套件，以及在系统拓扑中的独立位置——位于提示词之外，可以被测试、维护和扩展。
高管演示进行得非常完美。模型回答了精选的问题，智能体（agent）完成了工作流，屏幕录像已保存到公司网盘，发布日期也已排入日程。六周后，上线部署遭遇惨败，复盘报告不言自明：模型需要更多打磨，提示词（prompt）需要更多迭代，团队低估了从原型到生产环境之间的工作量。
这种叙事是错误的，而且代价昂贵，因为它让团队回去重复那些已经失败的工作。演示并不是生产环境的“欠打磨”版本。它只是团队从未测量过的分布中的一个“单一采样”（single sample）。那个惊艳瞬间只是模型针对相同输入可能产生的数千个结果中的一次实现，而团队却把最好的那次当作典型表现发布了。演示与生产环境之间的差距不是质量下滑，而是团队尚未察觉的“方差”（variance）。
这种思维转变至关重要，因为方差问题的解决方法与打磨问题的解决方法完全不同。“打磨”导向会说：“迭代提示词，微调模型，雇个更好的产品经理。”而“方差”导向则会说：“在输入分布中进行 n 次采样之前，你根本不知道自己手里拿的是什么。”这两种诊断会产生不同的路线图、不同的预算以及不同的事故模式。那些在 2026 年能够可靠交付的团队，都清楚自己面临的是哪种问题。
我认识的一个团队在上个季度通过将支持邮件分类流程从顶级模型（frontier model）迁移到中级模型，将推理费用降低了 40%。CFO 还专门发了感谢信。六个月后，客户支持团队增加了两名全职员工（FTE），平均解决时间上升了 35%。没有人把这些点联系起来，因为这些“点”分布在不同的仪表盘上：推理费用在平台团队的仪表盘上，而支持工作量在运营团队的仪表盘上。在所有人都在追踪的唯一指标上，这次迁移看起来是一次胜利。但指标错了。
这就是“单 Token 成本”（cost-per-token）陷阱。你的账单告诉你花了多少钱在 Token 上，但它无法告诉你每个“正确”任务花了多少钱，因为推理供应商根本不知道在你的领域里什么是“正确”。他们卖给你的是原始算力。而你买的是结果——或者你以为你买的是结果。这两个单位之间的差距，就是 AI 单元经济（unit economics）悄然崩溃的地方。如果不去衡量正确的分母，团队就只算了一半的账，而在另一半的交付上处于盲目状态。
我认识的一个团队花了六个月的时间去追踪一个并不存在的回归 (regression)。每一次发布都通过了评估 (eval)。每一次发布都上线了。但每个季度，AI 服务群组的 NPS 都会下降一个点。最终，一名实习生在对黄金数据集 (gold dataset) 进行例行审计时发现，一名早已离职的合同标注员标注了 11% 的数据项，而这些项在团队一直试图修复的一个特定故障模式上，系统性地表现得更加宽松。评估结果显示模型正在变好。但模型并没有变好。评估结果被一个人的校准漂移悄悄地倾斜了，而没有人监督标注员，因为没有人认为标注员是一个威胁面。
这就是评估集毒丸 (eval-set poison pill)。大多数团队将他们的评估集视为一个值得信赖的产物：标签是由人类评分的，数据来自生产环境，而回归仪表盘是组织在发布时一致同意参考的唯一指标。但标注流水线是一个人类供应链，而人类供应链是可以被操纵的。如果不对评估集的输入应用供应链卫生管理，就将其视为真值 (ground truth)，那么你就是在信任一个你无法辩护其来源 (provenance) 的数字。
黄金评估集的通过率为 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 中的单处删除，而当时没有任何人标记它，因为负责捕捉回归的套件对安全条款是否存在没有意见——它只对模型在套件记得询问的情况下的表现有意见。
这就是行为评估（behavioral evals）与结构正确性之间的鸿沟。Eval 衡量的是模型生成的内容；它们不衡量 Prompt 本身是什么。而 Prompt 就像代码一样，有一个独立于行为而存在的结构层——必须存在的章节、必须解析的引用、必须插值的变量、必须遵守的长度预算、以及绝不能出现的弃用标识符。当结构层断裂时，行为表现通常会在一段时间内保持绿色，直到生产环境中的某个边缘情况将故障暴露为事故。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
