先分级再动手
回答偏差、接口故障、数据污染三类的处置路径完全不同：前者可先收窄场景，后者要停写并核对来源。为什么先分级：不分类就急着回退，常把能局部收敛的问题扩成全员中断，事后也说不清。
开关比部署快
把模型版本、提示词、检索范围与下游写操作分别做成开关，出问题时按需关闭其中一层。为什么值得为开关多花设计时间：重新部署通常以小时计，切开关以分钟计；恢复时间差出来的几个小时，往往就是投诉与信任的分界。
回退别破坏数据一致
新版本可能已按新结构写入字段或调用记录，回退后旧版本读不懂，出现空白与报错。怎么做：版本迭代保持向后兼容，写操作先双写再切换，回退前确认数据结构能被旧版本正常解析。
通知与取证同时做
一边恢复一边固定现场：异常样本、请求日志、开关操作时间、影响范围，四样缺一不可。为什么不能只顾恢复：不留证，第二天复盘只能凭记忆，责任与根因说不清，同样的错误还会再犯。
回滚不是终点
恢复之后要重新走一遍上线门禁：补充样本、重跑评测、缩小放量范围、设更短的观察窗口。为什么不能就此结案：把回滚当终点，团队会在同一处反复出问题；当成带证据的重启则相反。
适用与不适用
适合谁
- 已上线或即将上线、涉及业务流程的系统
- 有多版本共存、需要快速降级的场景
- 能指定值班人与决策人的交付团队
不适合谁
- 纯离线批处理、失败可重跑且无用户感知的任务
- 尚未定义判据、只能凭感觉判断好坏的试点
典型场景
某快消企业的经销商订货助手在周三上午出现批量价格描述错误。值班人员先按分级把问题定为回答偏差，关闭价格类问题路由，保留库存类；同时导出异常样本与调用日志。两小时内业务恢复可用，次日复盘发现是知识库更新未做灰度，修订后按两成流量重新放开。
可执行步骤
- 预设三级判定：回答偏差、接口故障、数据污染，各配处置动作与决策人
- 为模型、提示词、检索范围与写操作分别做开关，标注影响面与责任人
- 出问题时优先切开关做降级，再判断是否需要整体回退到上一个版本
- 恢复过程中同步固定异常样本、请求日志、开关操作时间与影响范围
- 恢复后重走上线门禁：补充样本、重跑评测、缩小放量范围再观察一周
常见坑
- 一发现错答就整体停服，本可局部收敛的问题扩成全员中断，业务方当天转回人工，恢复后使用率再也没起来。
- 只回退应用版本没检查数据结构，旧版本读不懂新字段，页面大面积空白，二次故障比第一次更严重。
- 回滚过程没有留证，复盘会上各方说法不一，根因定不下来，同样的问题在两周后原样重演一次。
- 恢复后立刻按原流量放开，没有缩短观察窗口，残余问题在高峰期集中爆发，第二次回滚更难收场。
自检与验收清单
- 是否预设三级判定与对应的处置动作、决策人
- 模型、提示词、检索与写操作是否都有独立开关
- 回退前是否确认旧版本可以解析当前全部的数据结构
- 恢复过程中是否同步固定样本、日志与影响范围
- 恢复后是否重走上线门禁并主动缩小放量范围
常见问题
回滚和修复哪个优先？
先恢复可用，再谈修复。用户侧中断时间越长，恢复后的使用率越低，这一点在内部工具上尤其明显。除非问题只影响个别样本且能在一小时内定位，否则应先降级或回退，把修复放到恢复之后按正常变更流程做。
回滚要不要通知业务方？
要，而且要给出一句话结论：影响了什么、现在怎样、下一步什么时候同步。含糊的通知会让业务方自行猜测并向上汇报，信息在传递中失真；固定模板、指定发言人，能显著减少恢复期间的额外沟通成本。
每次都回滚会不会显得系统不稳？
恰恰相反，能快速回滚且回滚后不影响数据，是系统成熟的表现。真正伤信任的是一次故障拖一整天、期间没有任何说明。前提是回滚要演练过，且回滚后能给出明确的再上线计划与时间点。