灰度期间指标异常该不该立刻回退?

灰度刚放一点流量，看板上的曲线就跳了一下，群里立刻有人问要不要先切回去。这种时候常见的两种反应都不太靠谱：一种是看到红点就慌，直接全量回退；另一种是舍不得前面做的离线回放和适配工作，想着再观察观察。真正省事的办法是在开灰度之前就把话说清楚——哪些异常必须触发回退。门槛应该来自业务风险和服务承诺，而不是等新模型表现不好看了再临时商量。

先分清"必须停"和"需要看"

有些异常没什么可讨论的。关键任务质量掉了、工具调用执行不成功、结构化结果下游系统不接受，这些本来就该写进事前定好的红线里，碰到就按开关。回退不代表否定候选模型，它本身就是生产验证的一部分：先把影响范围止住，同时留够日志用来复盘。

另一类信号要模糊得多。用户开始更频繁地追问、改写问题，或者转人工的比例微微上抬，运营那边说要修的结果变多了。这类东西一时半会儿量化不成一个干净的指标，却往往最早暴露体验退化。遇到这种情况，先别急着下结论，问两个问题：新旧模型面对的请求类型是不是可比的？提示词版本、工具可用性、路由规则、缓存策略、兜底逻辑有没有同时改动过？如果分给候选模型的都是简单任务，或者应用层配置也一起变了，那这个"异常"未必是模型替换造成的。

按了开关，别浪费这次异常

回退只是止损，值钱的是它留下的证据。把观察到的问题落到任务结果、服务稳定性、用户与运营反馈、成本这四类信号里，看清楚到底是哪一类在退化、退化落在哪些请求上，写成一份能执行的差异清单，而不是留下一句"效果不太行"。带着清单回到离线回放去改提示词、适配输出解析、调整路由条件，或者干脆只让候选模型接风险较低的那部分流量，比在线上反复试探要划算得多。

尤其要提防那种账面好看的情况：单价确实降了，但输出不稳导致重试变多、工具调用变多、对话变长、人工介入变多，省下来的钱又被吃回去。灰度期间盯的从来不是接口单价，而是相同业务产出下单位有效任务的总投入有没有真的下降。

所以这事的答案不复杂：踩到事前划的线就立刻回退，不用犹豫；信号含糊就先确认灰度本身是否可比，再决定继续观察还是收手。犹豫的那段时间，成本是真实用户在承担，多按几次开关反而是便宜的。