客户支持团队升级了一个问题：“你的助手以前能正确处理退款资格问题。但上周开始出错了。”值班工程师调取了对话记录，在开发账号中使用相同的模型标识符回放了完全相同的提示词（prompt），得到了正确的回答，于是以“无法复现”为由关闭了工单。两周后，另一名客户提出了同样的投诉。工程师再次在同一个开发账号中进行回放，结果依然正确。团队开始归咎于没人做过的提示词更改。
请求中的模型标识符从未改变。响应字段中的字符串与请求字段中的字符串匹配。评估套件在六周内一直保持绿色。生产流量使用的模型权重与评估套件使用的模型权重是两套不同的集合，而且在该账号的整个生命周期中一直如此——直到过去这六周，它们变成了同一套权重，而团队注意到这一点仅仅是因为客户先发现了。
评测集（eval set）是一个文件。但它也暗含了对 AI 功能用途的理论定义。这两者并非一回事，混淆它们的团队建立了一个质量网关，而其校准完全依赖于单个人的工作记忆。当那个人离职时，文件留下了，但那套理论也随之而去了。
这是你在组织架构图中看不到的失败模式。你规划了一个提示工程（prompt engineering）角色。你雇佣了一个优秀的人才。他们发布了 v1 版本的提示词，审视了简陋的基准测试，并将其重写为内容丰富的东西——一个失败模式分类法、每个类别的权重，以及一套能够消除边缘情况歧义的标注指南（rubric）。评测集变成了“该模型是否好到足以发布”的契约。六个季度后，你发现这份契约除了编写它的那个人之外，其他人都看不懂。
你的事故时间线显示“过去 72 小时内没有部署”。你的 Prompt 注册表也印证了这一点：prompt v37 已经冻结三周了。你的评估工具链在周二晚上运行正常。但在周三早上，你其中一个 Agent 的结构化输出失败率翻了三倍，另一个 Agent 的重试预算翻了一倍，而第三个 Agent 开始愉快地忽略一条它已经遵守了一个月的指令。什么都没变。除了确实有东西变了，而且变在组织中两边都没盯着的地方：模型。
Prompt 注册表记录 Prompt 版本。模型网关记录模型版本。但在实践中，几乎没有人追踪这两者的“配对”关系。Prompt v37 并不是一个独立的工件——无论你的工具链是否承认，它都是一份针对特定模型协商后的契约。当平台团队将 claude-sonnet-latest 别名向前推进一个补丁版本时，另一端的契约已经被悄悄修改了。由于部署发生在别人的基础设施上，且名称未变，你的事故时间线依然显示“没有部署”。
一个平台团队发布了一项质量改进。推理阶段的一个图层会读取用户的近期交互记录，并悄无声息地调整响应风格：这里更正式一些，那里更简洁一些，或者当历史记录显示是一个工程师在提问时，响应会更具技术性。A/B 测试显示，整体满意度提升了几个百分点。发布公告的标题是“更智能的响应，无需更改 API”。没有人修改 API 中的标志位。没有人更新文档。响应内容中也没有任何迹象表明模型刚刚采用了哪种人格。
六周后，一位企业客户提交了一个支持工单，称“你们的模型比宣传的要差”。他们的内部评估套件——运行的是你们团队发布基准测试时所用的相同提示词——得分低了 8 分。你团队的第一步是核实提示词的一致性。提示词完全匹配。解码参数匹配。模型版本字符串也匹配。差异最终追溯到了个性化层，它为客户新开设的测试账号推断出一个“历史记录贫乏的默认人格”，而为你衡量基准测试的长效用户账号推断出了一个更丰富的人格。关于个性化究竟是功能还是缺陷的讨论，不再仅仅是一个产品决策，而演变成了一场合同谈判。
一个用户问：“这是否符合第 28 条规定的‘转移’（transfer）？”四十轮对话后，模型给出了一个针对不同问题的答案。对话记录显示，模型回答了它收到的问题。用户正在阅读一份看起来像幻觉的投诉。两者都对。模型从未看到用户的提问——它看到的是你的摘要生成器对其进行的礼貌改写：“用户询问了第 28 条的适用性。”
“转移”一词就是问题所在。摘要生成器把它丢弃了，因为摘要生成器的损失函数被调优为保留事实而非措辞，而且评估准则从未学会区分改写主题和改写约束。主题被保留了。约束变成了迷雾。
这种失效模式是结构性的，而非偶发性的。任何通过模型生成的摘要来压缩长对话的应用，在关键路径上都有第二个模型——其质量契约通常被视为 Token 预算旋钮，而非一段产品逻辑。这种不对称性正是 Bug 所在。
你的评估流水线每周会产生 800 条 trace 供人工审核。你的标注人员每周大约有 90 分钟的预算来处理这些数据。他们打开队列，对前三条进行打分，再将其余几条标记为“跳过”，然后就关闭了标签页。你在周一早上盯着看的排行榜，现在只是反映了哪些 trace 碰巧排在了列表顶部，而不是对系统质量的真实衡量。
这不是一个标注问题。这是一个披着质量问题外衣的吞吐量问题，也是评估项目退化最隐蔽的方式之一。Trace 仍在流动。仪表板仍在渲染。数值仍在变动。你没看到的是，你的“人工评分评估得分”的分母已经悄然缩减到了寥寥几项，而这些项是由一个没人刻意设计的排序函数挑选出来的。
一个用户打开你的长会话智能体（agent），在第 3 轮对话时说：“我是素食主义者，而且预算有限。”对话继续进行。11 轮之后，裁剪器（pruner）开始运行。它计算 Token 数量，发现第 3 轮内容既陈旧又短小，于是为了将窗口维持在预算范围内，将其丢弃了。第 14 轮用户问：“我今晚该做点什么菜？”模型查看一个约束条件已不存在的窗口，推荐了一份 40 美元的肋眼牛排。用户觉得智能体变得越来越难用，打开满意度调查，给这次会话打了一个 2 分。
你的技术栈中没有任何环节会报告记忆失败。Token 预算仪表盘会显示窗口健康地维持在上限之下。延迟仪表盘会显示绿色。评估套件——将单轮回答与预留集进行对比评分——会报告没有退化。唯一能体现智能体能力下降的信号是一个差评，而你的产品团队会将其归咎于“模型方差”。但这并不是模型方差，而是裁剪启发法在错误的目标上，精准地执行了它被调优后该做的任务。
一个团队将一个 200B 的教师模型压缩成一个 7B 的学生模型，因为评估套件——包含五万个覆盖产品发布时所有功能的样本——显示学生模型仅落后教师模型不到两个点，且推理成本降低了一个数量级。迁移上线了。成本曲线下降。客户满意度曲线持平。三周后，客服开始看到一类团队无法在评估中复现的故障。
学生模型不再识别教师模型曾默默处理的边缘案例输入格式。它不再能从教师模型曾可靠消除歧义的特定模糊指令中恢复。它不再产生那种罕见但关键的“与其猜测不如询问澄清问题”的行为——因为评估集以这些提示词是“坏数据”为由，清除了其中的模糊提示词。
评估结果显示蒸馏是忠实的。评估对于“忠实性”的定义是错误的。
你的综合评估分数在上个季度上升了两个百分点。没人能告诉你这究竟是系统变好了，是打分的人类群体变得更宽松了，还是你在三月份升级的评判模型开始以不同的权重衡量文本的冗长程度。数字变动了。但该数字旨在衡量的事物并不一定随之变动。
当一个评估准则同时被两个群体——人类和 LLM 评判者——阅读时，就会发生这种情况，而且这两个群体的漂移轴线和原因各不相同。综合分数将两者的运动混合在一起，除非你有一套测量方案能在其中一个变动时保持另一个固定，否则你发布的指标，其变化是无法归因于任何因素的。
你的每周评估（eval）仪表盘变平了。曾经在 0.71 到 0.78 之间波动的曲线，已经在连续三个发布周期中紧缩成 0.84 左右的一根细线。团队将其解读为达到了天花板——模型已经达到了评分准则（rubric）允许的上限，进一步的工作需要更难的评估。有人安排了一场规划会议来“设计 eval v2”。
这种解读看似合理，有时也确实正确。但还有第二种解释，它会产生同样的图景，并悄悄摧毁你的发布准入信号：你的标注员（无论是人类还是 LLM 评判员）已经在意见上趋同，评估不再是在衡量模型，而是在衡量模型产出标注员心目中“正确”输出形态的能力。
你选择了基础模型，“因为它是更安全的那一个”。六个月后，你的团队发布了一个经过领域微调的检查点，它能以极具说服力的流畅度回答客户关于财富产品的问题，任务评估通过率达到 94%，而且——在第一轮训练到第四轮训练之间的某个时刻——它悄然忘记了如何拒绝任何要求。没人注意到这一点，因为你的发布评估套件从未衡量过微调消除了什么。它被剥离的能力从未出现在你的任务分布中，因此也从未出现在仪表盘上。
这是目前生产环境中 LLM 系统最少被报道的故障模式：训练后的对齐并不是模型家族的固有属性。它是某个特定检查点的属性，而有监督微调（SFT）默认会腐蚀这种属性。进行微调的团队发布的并不是他们评审过的模型的微调版本。他们发布的是一个不同的模型——其模型卡描述的是根本没有在提供服务的权重。
调出过去四次模型升级的仪表盘，查看安全指数（safety number）旁边对应的帮助指数（helpfulness number）。在每次发布中，总有一个指数在变动，而且几乎从不是同一个。负责安全评估的团队发布了一个“将拒绝加固提升了 6 个点”的修复程序，三周后，负责帮助性评估的团队发布了一个“在合法查询完成度上恢复了 5 个点”的修复程序。然后，循环再次开始。
这并不是两个团队在各自取得独立进展。而是一个模型在沿着同一个轴摆动，而组织却在用两把相反的尺子测量它，每把尺子上所谓的胜利都是另一把尺子上无声的损失。刚刚庆祝了安全性能提升的团队，在不经意间发布了一个拒绝更多合法医疗问题、法律问题和“如何做”问题的模型——而这些问题的词干恰好看起来像训练数据中的不安全内容。由于这种帮助性的倒退属于不同的冲刺周期、不同的负责人和不同的仪表盘，因此它被忽视了。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
