解读

面试官想知道三件事：

1. 你是否把“多版本”当成持续交付体系的一环，而非临时补丁；
2. 能否在算法、工程、业务三条线之间建立“可灰度、可回滚、可观测”的闭环；
3. 是否具备国内合规视角（算法备案、数据出境、A/B 上报）。
   回答必须体现“产品owner”视角：不是罗列技术组件，而是讲清“在什么阶段、用什么策略、让谁决策、对谁透明”。

知识点

1. 版本基线：Model Registry + Semantic Versioning（主.次.修订-场景标签），国内主流用自研或MLflow/Kubeflow。
2. 流量路由：Kubernetes + Istio/自研网关，按“用户尾号+业务分层”做灰度，支持“按省/按渠道/按客群”三维切流。
3. 影子模式：新模型跑100%流量但不下发业务系统，仅写日志做离线评估，符合《互联网信息服务算法推荐管理规定》第18条“安全评估”要求。
4. 指标双轨：业务指标（转化率、停留时长）与算法指标（AUC、F1）分开看板，防止“离线涨点、线上掉钱”。
5. 回滚SOP：30秒内完成权重切换，由产品经理在“战情室”拉群决策，技术只执行kubectl patch；回滚后触发“模型下线审批单”留痕，满足证监会/网信办抽查。
6. 合规留痕：版本号+备案号+训练数据来源+时间戳写入模型签名，审计时可直接追溯到“数据-标注-训练”三环。

答案

“多版本并行”我拆成三条主线：灰度设计、观测决策、合规兜底。

1. 灰度设计
   a. 先给每个模型打“场景标签”版本号，如v2.3.1-loan，统一注册到Model Registry，禁止“裸模型”上线。
   b. 流量分层：核心支付路径用“白名单+用户尾号双因子”，外围推荐位用“省分+渠道”二维切流，确保同一用户同一时刻只命中一个模型，避免交叉污染。
   c. 影子模式：新模型先跑48小时影子，产出“diff报告”，业务指标负向<0.3%才进入5%真实灰度。

2. 观测决策
   a. 建立“双轨仪表盘”：左侧算法指标（AUC、Calibration），右侧业务指标（GMV、投诉率），每30分钟自动推送到“算法战情室”企业微信群。
   b. 决策人不是算法同学，而是我牵头的产品+运营+风控三方，提前定义“熔断阈值”：GMV下降≥1%或投诉上升≥20单/小时，立即回滚。
   c. 回滚动作脚本化：kubectl patch vs weight=0，30秒内完成；同时触发“模型下线审批单”，记录回滚原因，3个工作日内提交给合规组备案。

3. 合规兜底
   a. 每个版本上线前，把“算法备案号+训练数据来源+时间戳”写进模型签名，审计时可一键追溯。
   b. 如果涉及跨省数据，训练任务放在本地政务云，推理服务放在私有云，避免数据出境风险。
   c. 重大版本（主版本号升级）走“算法安全评估”流程，先通过第三方测评机构做“风险识别+鲁棒性”测试，拿到报告后再上线。

用这套机制，我们曾在618大促期间并行运行4个推荐模型，灰度周期7天，零回滚、零客诉，GMV同比提升3.8%，也顺利通过了上海网信办现场抽查。

拓展思考

1. 当模型数量>20个/日时，人工审批会成为瓶颈，可引入“自动审批+人工抽检”混合策略：影子指标全部绿灯且历史3版本无回滚记录的模型，自动进入5%灰度；否则强制人工review。
2. 对于生成式AI，还要把“输出一致性”纳入灰度指标，例如同一prompt多次调用，新模型输出与旧模型BLEU<0.15才允许放量，防止“画风突变”引发舆情。
3. 长期看，把“版本-流量-效果”数据沉淀为知识图谱，可反向指导训练集采样策略，实现“灰度即标注”，让多版本并行从“成本”变“资产”。