Prompt 上线后准确率从 82% 掉到 51%：七类失效症状的排查顺序

上周三早上 9 点，客服工单分类的准确率从 82% 掉到 51%。同一份 320 token 的 prompt，一个字都没改。

值班同学的第一反应是模型变笨了，第二反应是加约束。一个下午改了 11 版，准确率在 51% 到 63% 之间来回摆，改一次掉一次。第三天下午才定位清楚：三个问题叠在一起——模型小版本静默升级、few-shot 里两组示例被上游清洗掉、max_tokens 从 1024 调到 512 导致长工单被截断。

这篇不写 prompt 技巧，写排查顺序。失效的 prompt 都有症状，症状能反推病因，顺序错了就会在改指令上耗掉一整天。

症状一：答非所问，开始跑题

先别动指令，第一步是把真正送进模型的东西打印出来。我们那次 12% 的请求超了 8k 上下文，最前面的系统指令被静默切掉，模型等于裸奔。

• 查截断：打印 messages 全量 + token 计数，确认系统指令、业务约束是否完整抵达。截断不报错，只会让效果变差。
• 加边界：用户输入用固定分隔符包裹（==== 用户输入开始 ====），跑题率从 17% 降到 2%。分不清哪段是指令、哪段是数据，是跑题最常见的根因。
• 长上下文里重复硬约束：约束放在开头，中间塞了三千字正文后容易被稀释。在结尾用 20 个 token 再重复一次，比重写前半段便宜得多。
• 别堆否定句：模型对"不要输出多余解释"的遵循度明显弱于"只输出字段列表"。能改成肯定句的，全部改掉。

症状二：格式对了，内容错了

结构漂亮、字段齐全，值是错的。这类问题先算比例，别急着怪模型不听话。

• 先看是不是被截断：我们 6.3% 的 JSON 解析失败里，81% 是输出撞上 max_tokens 被切断，不是模型不会写。把上限从 512 提到 1200，解析失败率直接降到 0.4%。
• schema 描述必须无歧义：字段名只写 date，模型会给"10 月 28 日""2026-10-28""今天"三种。写成"ISO 格式 YYYY-MM-DD，示例 2026-10-28"，问题消失。
• 示例污染最难查：few-shot 里如果留着旧版字段，模型会照着示例抄，而不是照 schema 写。示例和 schema 必须同源，改一处就要同步另一处。
• 重试只救 0.4%：解析失败时把错误信息回灌重试一次，能救回的极少。别把重试当方案，它只是兜底。

症状三：越改越长，越改越差

一条 320 token 的 prompt 涨到 1450 token，准确率只多 1.4 个百分点，延迟从 1.1 秒涨到 2.3 秒。指令堆到一定长度就开始互相打架。

• 先分层再写：角色 → 硬约束 → 输出格式 → 风格语气。四层按序排列，冲突时明确上层优先，否则模型自己挑一条遵守。
• 每次只改一处：一次改三条，涨了不知道怎么涨的，跌了也不知道怎么跌的。这个习惯让我们多花了两天。
• 给指令做减法：把三个月里陆续加进去的补丁逐条删掉重测，1450 token 里删掉 700 token，准确率只掉 0.3 个百分点。大部分补丁治的是已经不存在的病。

症状四：同样的输入，两次结果不一样

线上有人反馈"昨天答得好，今天答得差"，很可能是随机性，不是版本问题。

• 先量化：同一批 200 条样本跑两次，temperature 0.7 时一致率 71%，降到 0.2 后 96%。先把温度钉死，再谈效果。
• 评测必须确定性：评测时温度 0、固定 seed（模型支持时），否则每天分数波动 5 个点，任何优化都测不出来。
• 压测时关缓存：命中缓存会掩盖不稳定，同一输入全走缓存，测出来的是一致性的假象。
• 多轮里顺序也会变：历史消息的拼接顺序、摘要插入的位置，都会影响输出。固定拼接模板，别在代码里随缘拼。

症状五：只在长尾样本上崩

评测集 500 条里 380 条来自同一个业务线，整体分数很好看，长尾一问就错。

• 按业务线分层抽样：改成分层各取后，长尾那一档的准确率涨了 19 个百分点。整体分数没怎么动，但工单里最难的那批变少了。
• 示例覆盖比数量重要：8 条 few-shot 有 6 条同源，等于只教了一个场景。加到 16 条、输入多 900 token，准确率只多 0.8 个百分点——覆盖是结构问题，不是规模问题。
• 把最像的示例放最后：近因效应真实存在，同业务线的示例排在末尾，比排在最前面效果好。

症状六：上线两周，慢慢变差

没有发布，没有改 prompt，指标在两周里掉了 6 个百分点。这类慢性失效有三个常见来源。

• 模型版本静默升级：上游小版本更新不会通知你。固定回归集每周跑一次，分数掉 3 个点以上就查版本。
• 输入分布漂移：新业务上线后工单变长，输入长度 P95 从 480 字涨到 1100 字。监控输入长度分布，比监控准确率更早发现问题。
• 上下文累积污染：多轮会话里历史一直带着，8 轮之后 12k token，前几轮的错误分类会反过来影响当前判断。改成每轮只带结构化摘要，准确率回稳。

症状七：评测集上更好，线上更差

改完 prompt，离线分数从 78 涨到 85，上线反而掉了 1.5 个点。评测集是旧分布，你把它调成了考试专用。

• 保留一份冻结集：200 条固定样本，只在需要纵向对比时用，不参与任何调优，避免被"刷"过头。
• 用回流样本更新评测集，但每两周只换一半，保持可比性。
• 看分桶不看总分：总分涨、长尾跌，是最典型的过拟合信号。

排查顺序本身就是方法

七类症状对应一条固定顺序，从便宜的查到贵的：

• 输入：有没有被截断、指令与数据有没有边界、硬约束在第几行
• 输出：schema 是否无歧义、上限是否够、示例是否与 schema 同源
• 参数：温度是否钉死、缓存是否干扰观测
• 数据：示例覆盖是否分层、评测集是否还是旧分布
• 模型：版本是否变过、输入分布是否漂移

顺序反过来做，就会像那天的值班同学一样，一个下午改 11 版，始终在 51% 到 63% 之间打转。

排查工具只需要三样：打印完整请求、逐段二分裁剪到最小可复现版本、一次只动一个变量。这三件事做到，绝大多数"模型变笨"都能在半小时内落到具体某一行。