一、项目背景

某网关每次上新模型或切路由策略，流程都是先小流量灰度，再人工盯指标，没问题再全量。听起来稳妥，实际几次出事都是这么扩大化的：新版本质量掉了，监控上系统指标（延迟、错误率）都正常，没人发现模型输出悄悄变烂，等客诉堆起来才回滚，已经影响了一批用户。

我们复盘那几次，共同点是只看了系统指标，没看模型质量这个真正和用户相关的信号。传统监控对幻觉变多、格式开始不合规这种软降级是盲的，而恰恰这些才是用户能感知到的坏。靠人盯盘，再怎么认真也盯不过来全量流量。

二、落地场景

我们做的第一件事是定义质量信号，除了系统指标，还采集幻觉率、格式合规率、领域准确率这些和业务强相关的量。质量信号采集是第一段，灰度期间持续打分。自动回滚阈值是第二段，质量掉到线以下自动触发回滚，不等人。回滚无感放第三段，回滚时流量平滑切回旧版本，用户无感。误回滚控制兜底，阈值带迟滞，避免抖动误触发，回滚后留记录供复盘。

案例片段（已脱敏）： 灰度质量信号与自动回滚配置片段（示意）：quality_signals: [hallucination, format_compliance, domain_acc] canary:  sample_pct: 5 rollback:  on_quality_below: 0.92  hysteresis: true  cutover: seamless上线后质量问题发现时延从约 30 分钟压到约 2 分钟，回滚触发时延约 1 分钟，单次影响用户数从约数千降到约数百，误回滚率约 2%。

三、关键技术挑战与解决思路

第一个坑是质量信号定义。什么叫质量掉，不同业务标准不同，硬定一个会误伤。我们做法是信号按业务可配，阈值也按业务设，且灰度初期用历史基线做参照，不拍脑袋定数。这一步比接监控重要，因为信号不对，自动回滚就是在乱撤。

第二个难点是回滚阈值校准。定太松发现不了问题，定太敏又误回滚，用户会被频繁切版本搞晕。我们加了迟滞，信号短暂跌破不立刻动，持续跌破才回滚，把抖动滤掉。这里有个权衡，迟滞多长，太长漏检、太短误伤，按业务容忍度调，交互类短一点、后台类长一点。

第三个点是回滚无感。回滚如果让用户正在进行的对话断掉，体验比慢更糟。我们做的是流量平滑切回，已有会话走完旧版本，新请求进旧版，用户基本无感，代价是旧版本不能回滚就立刻下线，得留一段时间。

四、效果数据

质量问题发现时延约 2 分钟，回滚触发时延约 1 分钟，单次影响用户数约数百，误回滚率约 2%。和之前比，坏版本在用户感知前就被撤了，客诉量明显下来。我们复盘时发现，误回滚虽然少但存在，多是新业务基线没标好，补了基线后进一步降。（数据均为脱敏示意值）

发布侧把质量信号接进了发布平台。每次灰度除了看系统面板，还看质量曲线，发布负责人从盯延迟变成盯质量，视角对了。我们也沉淀了信号配置模板，新模型接入直接套，不用每次重新想采什么。回滚记录反过来成了质量门禁的训练数据，哪些版本容易掉，提前就能预警。

五、可复用经验总结

灰度不能只看系统指标，模型质量掉不掉的感知才是关键，加一层质量信号驱动的自动回滚，新版本一露馅就自动撤，比人工盯盘快一个量级。阈值要带迟滞，调太敏会误回滚，短抖动不该触发。回滚要无感，已有会话走完旧版，用户才不察觉。我后来判断，发布系统的成熟度不看能不能发，看能不能在质量露馅的第一时间自己收住，自动回滚就是那道保险。

结语

我们后来把质量信号的范围从模型输出扩到了链路，比如检索召回的质量、工具调用的成功率，只要能量化成信号就能进灰度看板，回滚的覆盖面更广了。还有一个之前低估的点，是回滚之后的复盘沉淀，每次回滚我们都会留一份原因记录，久而久之哪些改动容易掉、哪些基线没标好一目了然，新版本上线前先对照历史避雷。自动回滚不是终点，它是把试错成本压到最低的一种机制，让团队敢发、发得快、出问题收得也快。我们也踩过迟滞设太长的坑，有一版为了不死板把迟滞拉很大，结果质量掉了十几分钟才回滚，那次影响比预期大，后来按业务重新分了档。往后看，质量信号会越来越多地成为发布的唯一闸门，系统指标只作辅助，因为用户感知的永远是模型答得好不好，而不是延迟多少毫秒，这个视角一旦立住，发布体系就成熟了。

我们也把回滚的触发记录和发布系统打通，谁发的版本、为什么回滚，全程可追溯，复盘不再靠回忆。发布这件事最怕不可复盘，一旦能复盘，同样的问题就不会犯第二次，团队才敢持续往前冲。我们也因此敢做更激进的灰度比例，因为知道收得住。这份底气是系统给的，不是拍胸脯。