CI/CD 在 AI 平台的落地

一句话定位：AI 平台的 CI/CD 比传统软件多了”数据”和”模型”两个需要版本化联动的维度，评估门禁则是防止”代码没 Bug 但模型效果变差”这类 AI 特有风险上线的关键卡点。

1. 代码/数据/模型三者版本联动

• 传统 CI/CD 只需要管理代码版本；AI 平台还要让数据版本（训练用的是哪份数据）和模型版本（哪次训练产出的权重）与代码版本绑定，三者任意一个变化都要能触发对应的流水线，且能追溯”这次上线的模型是用哪个代码 + 哪份数据训出来的”（对应 8.1 的血缘能力）。

2. 流水线触发条件

• 代码变更（如推理服务逻辑更新）→ 触发构建 + 部署流水线。
• 新数据到位或定期重训 → 触发训练流水线。
• 触发条件需要明确区分，避免”改了一行推理代码却触发了整个重训流程”这类资源浪费。

3. 离线评估门禁（核心差异点）

• 这是 AI 平台 CI/CD 与传统软件 CI/CD 最大的不同：传统软件只要测试用例通过就能发布，AI 模型即使代码没 Bug，新训练出的模型效果也可能不如旧版本。
• 评估门禁：训练流水线产出新模型后，必须先跑离线基准测试（对应 5.4 的性能基线思路，但评估对象是效果指标而非性能指标），效果指标不达标就不允许进入部署阶段，杜绝”未经验证的模型效果退化直接上线”。

4. 渐进式发布

• 门禁通过后也不是直接全量上线，而是配合 8.2 提到的多版本灰度机制，从小流量开始逐步放量，同时持续监控线上效果指标，异常则自动/人工触发回滚。

5. 面试落点

• 能讲清”AI 平台 CI/CD 比传统 CI/CD 多了什么”：数据/模型版本联动 + 效果评估门禁，这是最容易被问到、也最能体现 AI 平台工程理解深度的点。
• 可迁移话术：评估门禁的设计思路和大数据平台”上线前必须过数据质量校验才能进入下游”的门禁思路一致，只是校验对象从数据质量变成了模型效果。

参考：Google《MLOps: Continuous delivery and automation pipelines in machine learning》；Kubeflow 官方文档