离线评测
用固定评测集跑候选模型，记录通过率、格式合规率、拒答率与延迟。怎么定通过线：先看业务能接受的最低标准，再看候选是否稳定达到；离线阶段就要暴露明显不合适的模型，别把问题带到线上，结论只对这批样本有效。
影子运行
把真实请求同时发给候选模型，只记录不对外，观察一到两周。怎么用结果：对比线上模型与候选的差异，统计失败类型与接管率；影子阶段能发现离线样本覆盖不到的长尾问题，成本也比灰度低，稳定性也看得更清楚。
小流量灰度
选一部分用户或一类请求切到新模型，比例从百分之五起步，再逐级放大。怎么设停止条件：错误率、投诉量或接管率超过阈值立即回滚，并保留切换记录；灰度期间要有值班人，别在下班前切换，每一步都要留下记录。
结论进验收
把评测集、指标、灰度比例与回滚条件写进验收条款，作为后续升级的基线。边界是验证只覆盖已验证的任务与流量，新场景要重新走一遍；不能拿一次灰度结论去承诺全部场景的效果，也不要写进对外承诺。
适用与不适用
适合谁
- 准备切换线上模型、需要控制风险的企业
- 已有一个线上场景、想稳妥升级的团队
- 需要为验收提供依据的项目负责人
不适合谁
- 没有线上流量、也无法做灰度的项目
- 希望一次切换、不做回滚准备的团队
典型场景
某出行平台要更换客服问答模型。团队先用三百条历史会话做离线评测，筛掉两个候选；剩下的模型跑两周影子流量，对比接管率与投诉关键词；通过后按百分之五、百分之二十、全量三步灰度，每步观察三天再决定是否继续。
可执行步骤
- 用固定评测集做离线评测，先把明显不合适的候选筛掉，只留两家，其余不再进入
- 让候选模型跑一到两周影子流量，只记录结果，暂时不向用户输出，也不进报表
- 按百分之五的比例起步灰度，同时设定错误率、投诉量与接管率的阈值
- 把评测指标、灰度比例与回滚条件，连同基线一并写进验收条款与附件
常见坑
- 跳过离线评测直接灰度，线上问题暴露给真实用户，投诉集中爆发，只能紧急下线，团队很被动。
- 影子阶段只看平均延迟，没看失败类型，灰度后才发现长尾错误多，只能临时补救，为时已晚。
- 灰度没有停止条件，出问题全靠人盯着，等发现时已影响大部分用户，只能整体回滚止损。
- 一次灰度通过就对外承诺全场景可用，新场景上线后问题成倍出现，客户投诉接连不断，团队疲于应付。
自检与验收清单
- 离线评测是否有固定样本，以及事先约定的通过线
- 影子运行是否覆盖一到两周的真实流量与时段
- 灰度比例与停止条件是否在切换前就已写明，并留档
- 是否安排了值班人，并准备了书面的回滚预案
- 验证结论是否写入验收条款，并作为升级基线
常见问题
影子运行要不要告知用户？
影子流量不对外输出，通常不需要单独告知，但要符合隐私与数据处理规定：日志脱敏、限定访问权限、明确保存期限。若涉及个人信息，先确认内部制度与合同条款是否允许。
灰度要跑多久？
看流量与风险。日均请求量大、风险低的场景三天可判断；请求量小或涉及资金、合规的场景，建议一到两周并覆盖不同时段。时间太短容易漏掉周期性出现的异常。别只看三天数据。
回滚后还能再切吗？
可以，但要先定位原因并修复。记录回滚时的指标与失败样本，修复后重新走离线与影子阶段，不要直接再灰度；同一问题反复回滚会消耗团队信心，也会让业务方抵触新模型。