AI 应用离线评测变好了，为什么还要灰度发布？怎么安全回滚？

知识点详解：测试集上更好，真实用户为什么仍然会遇到问题？

离线评测回答的是哪一部分问题？

假设咱们给客服助手换了模型，并调整了提示词。固定测试集里，新版本解释更完整，答错的问题也少了一些。

这说明改动有继续验证的价值，但真实用户未必按照测试集提问。

有人连续追问十几轮，前后修改退款条件；有人粘贴很长的订单记录；高峰期还有大量请求同时进入系统。这些情况下，回答质量、延迟和工具执行都可能发生变化。

例如，新版本回答更详细，却总要多调用几次工具。离线只比较答案，可能看不出来；线上并发提高以后，响应变慢、成本上升，用户又会觉得更难用了。

因此，离线评测和灰度检查的问题不同。前者帮助我们在可控样本上比较，后者继续检查真实使用条件下是否成立。

灰度时，究竟把什么分给一部分用户？

先把“版本”说明白。

AI 应用的一版方案，可能包含模型配置、Prompt 版本、工具 Schema、检索设置和应用代码。不一定每次都改全部，但应该能确定这次请求使用了哪一套组合。

可以给这个组合一个发布标识，比如 release-B，再由服务端分流。部分会话进入 B，其余仍然进入已经运行的 A。

对于多轮客服，按会话保持分组通常比每轮随机换版本更容易解释。否则第一轮按照旧规则收集信息，第二轮突然换成新流程，测试到的可能是混用问题，而不是某个版本本身的表现。

Google SRE 的灰度发布实践强调小范围验证以及与对照组比较。这里把这个思路用到 AI 应用，还需要额外记录模型、提示词等配置，方便定位行为差异。

评估时不能只看一个总平均。退款任务变差，可能被大量简单咨询的提升盖住。应该按业务类型、对话长度等维度拆开，同时检查延迟较高的那部分请求和每次成功任务的成本。

影子流量和灰度流量，有什么不同？

影子验证会把一部分真实请求复制给候选版本，用于观察和比较，但候选结果不直接交给用户。灰度则让一部分用户真正使用新版本。

AWS 的模型影子部署提供了候选模型并行验证的机制。把类似方法用于 Agent 时，不能只复制入口请求就不管后面了。

假设旧版已经执行了一次退款，新版作为影子也执行一次，就不是“悄悄评测”，而是在制造重复业务动作。

因此，影子任务需要使用不会产生真实副作用的执行路径。例如复用已经取得的只读结果，或者让写工具进入模拟环境，只记录它想提交的操作。邮件、支付、工单创建等行为都应检查，不能只想到数据库写入。

影子验证有助于比较，但也不是免费的：额外模型和检索调用会增加成本；模拟工具结果也未必覆盖真实执行中的所有问题。这些限制要在设计时说明。

发现问题以后，先停什么，再处理什么？

假设新版本开始漏掉退款条件，第一步应该停止扩量，必要时让新任务回到旧版本。

但这只处理了入口。已经进入新版本的任务，有的正在生成答案，有的在等待工具，还有的已经做了外部操作，需要分别判断。

可以在发布前约定处理方式：低风险任务按原配置收尾；风险不明确的任务暂停或取消；已经执行的写操作根据业务记录核查，必要时走补偿或人工处理。

如果新版本修改了持久化状态结构，旧代码未必能继续读取它的检查点。这时直接把服务镜像退回去，可能连恢复任务都做不到。需要提前验证向后兼容，或者保留能够处理旧任务的执行器，必要时设计状态迁移。

发布门槛也应该在上线前写清。哪些质量退化可以观察，哪些越权或资金问题一出现就停止，不能等看见结果以后再临时改变标准。

最后做一次演练：新会话能否切回 A，B 中的在途任务去了哪里，是否仍有后台 Worker 继续执行。只有管理页面上的流量比例变成零，还不能证明新版本的影响已经结束。

面试官继续追问

灰度放多少流量合适？固定 5% 行不行？

没有通用比例。低流量产品的 5% 可能很久都碰不到关键场景，高风险动作即使只有少量流量也可能造成损失。

应按风险、样本覆盖和观察时长决定。先保证能识别关键问题，再逐步增加，不把某个百分比当成安全标准。

线上没有参考答案，怎么判断新版本更好？

可以结合抽样人工复核、明确规则校验、任务完成情况和用户反馈，不必只依赖一个自动评分。

对比时尽量保持分组条件一致，也要关注反馈是否存在延迟。用户暂时没有投诉，不能直接等同于回答正确。

回滚和补偿有什么区别？

回滚让后续执行回到旧方案；补偿是在处理已经发生的业务结果。

例如发出去的邮件不会因为模型退回旧版就消失，已经创建的工单也需要单独处置。两者可以先后进行，但不能混成一个按钮的承诺。

面试速记卡

• 离线评测：比较固定样本，不代替真实流量验证。
• 灰度发布：少量稳定分流，并保留同期对照。
• 影子验证：候选结果不直接给用户，尤其不能重复真实写操作。
• 停止条件：质量、延迟和成本分层看，严重风险单独设门槛。
• 回滚边界：新流量、在途任务、已经发生的动作分别处理。