当在线奖励方差突然增大3倍时，如何触发自动回滚？
解读
在国内工业级强化学习系统中，奖励方差是在线策略健康度的核心指标。方差突然放大3倍，往往意味着数据分布漂移、策略震荡或外部攻击，必须秒级止损。面试官想考察的是：
- 你是否能把统计异常检测与工程回滚链路打通；
- 是否熟悉国产A/B平台（如阿里ChaosBlade、腾讯蓝鲸、字节A/B Scheduler）的灰度熔断接口；
- 能否在合规审计前提下保留现场证据，满足等保2.0对日志6个月可回溯的要求。
知识点
- 三西格玛漂移检测：基于指数加权移动方差（EWMS）实时流计算，窗口长度按业务心跳动态调整（电商15s、金融3s）。
- 双阈值策略：先触发熔断降级（停止探索，固定ε=0），连续两个窗口仍异常才回滚模型权重到上一稳定checkpoint，防止误杀。
- 国产流水线：通过KubeVela的ApplicationRevision机制，在ACK/腾讯云TKE集群内原地热回滚，无需重建Pod，P99回滚时间<5s。
- 审计留痕：把方差序列、决策原因、操作人写入Loki+OSS双副本，AES-256加密，RAM角色最小权限读取，满足银保监会现场检查要求。
答案
- 指标采集：Flink SQL每500ms计算一次增量奖励方差，写入Kafka Topic: reward_stat。
- 异常判定：
σ²t > 3×σ²t-1 且持续两个滑动窗口（默认30s）即判定P3级故障。 - 决策引擎：
Agent侧Sidecar容器内嵌OPA（Open Policy Agent）规则，收到异常事件后调用平台熔断API：- 先关闭探索，把温度系数τ→0；
- 若60s内方差未回落，则通过KubeVela CLI执行
vela rollout restart --rollback-to=revision=last-known-good，原地热替换模型权重。
- 通知与审计：
回滚完成立即钉钉群机器人+短信通知值班，TraceID写入SLS日志，快照保存24h供事后根因分析。
拓展思考
- 非平稳奖励场景：若业务本身存在大促脉冲，可引入动态基线（Holt-Winters预测）替代固定3倍阈值，减少误召回。
- 多Agent协同：在多智能体博弈中，单Agent方差放大可能是对手策略突变，此时需联合假设检验（Hotelling T²）判断是否群体回滚，避免羊群效应。
- 合规升级：生成式Agent上线前，需在网信办备案算法，回滚逻辑应写入算法安全自评估报告，确保自动决策可解释，防止**“黑箱”处罚**。