印象最深的一次线上质量事故，怎么定位和修的？

有一次线上质量分数掉了 5 个点，告警响了。我们先查最近有什么变更，发现前一天上游模型做过一次小版本升级，就先回滚了模型，但分数没回来；又回滚了前一天改的 prompt，还是没回来。折腾到下午才发现是市场部前一天新接了一个渠道，那批用户的问题更长也更难，主要问退款政策。系统本身没问题，是流量变了。后来我们把新渠道的问题单独做了优化。

这个回答有完整的时间线、有结论、也承认了走过弯路，所以能过。

但它暴露的问题很典型：整个定位过程是「猜 → 试 → 猜 → 试」，两次回滚都是在没有证据的情况下做的动作，其中一次回滚本身还有引入新问题的风险。而且它没有沉淀——「后来对新渠道做了优化」不是收尾，下一次换个渠道还会再来一遍。

我讲一个查了三周才发现、而且监控完全没报的。

现象：客服助手的转人工率从 8% 涨到 14%，是业务同学在周会上提的。而我们的线上 judge 分数（判「回答是否有依据」）几乎没动，0.86 → 0.85，所有告警都是绿的。

第一刀：是系统变差了，还是进来的问题变难了？ 我们有一组金丝雀集——40 条固定输入，覆盖主要意图，在生产环境按小时跑、走同一条链路。它的分数也没动。同时看输入侧：query 长度分布、意图分布、渠道占比，三周内都没有明显变化。 两边都没动，那结论就很硬了：系统对固定输入的行为没变，输入分布也没变，但用户在跑。说明我们测的维度，和用户真正不满的维度，不是同一个。

第二刀：从用户离开的那一刻往回看。 我们捞了 60 条「转人工前的最后一轮对话」做错误分析，逐条写一句话，再归类。71% 落在同一类：用户问的是「我这个订单为什么还没退款」，系统答的是完整、准确、有出处的通用退款政策。 关键在于——这些回答的「有据性」是满分。文档里确实这么写。judge 判的是「有没有超出来源」，而用户不满的是「你没回答我这一个具体问题」。judge 测的是忠实度，没人测切题度。

第三刀：什么时候开始的，为什么。 按周切分这类失败的占比，发现拐点在三周前。那天上线了一个 prompt 改动：「优先引用政策文档作答」，本意是减少编造。副作用是模型在该调订单查询工具的时候也去引政策了。 更讽刺的是：当时的工具调用次数下降了 12%，还被当成一次成本优化的成果汇报过。 一个被当成改进的变更，在一个从来没有被测量的维度上造成了回退。

处置：止血和根因分两条线并行。

• 止血（当天，可逆）：在网关按意图分流——query 里含订单号或工单号的，走回旧版 prompt。爆炸半径立刻收窄，转人工率第二天回到 9%。这一步不需要知道根因，也不需要等根因。
• 根因（一周）：重写那段 prompt，把「优先引用文档」改成「先判断这是通用问题还是具体单据问题」；并加了一条轨迹不变量断言——输入中含订单号时，必须调用过订单查询工具，否则判失败。这条断言不绑定具体路径，所以后面改 prompt 也不会失效。

收尾，也是我认为最重要的部分：

1. 补了 12 条评测用例（去重后每个失败子类一条，最小可复现输入 + 冻结当时的检索结果）；
2. 给 judge 新增了一个维度：「是否回答了用户问的这一个问题，而不是给了一个正确但通用的答案」——并重新做了校准；
3. 把转人工率纳入发布护栏指标。这是最关键的一条：这次事故里，唯一真正报了警的是一个零成本、不需要 judge 的用户行为信号，而我们当时没把它接进发布流程。

我从这次学到的一句话是：judge 只能测你想到要测的维度。真正的质量回退，往往发生在你没定义指标的地方——所以那一层不需要模型的用户信号，必须先建全。