📚 课程目录第2章 AI DevOps基础

AI DevOps基础：核心概念与CI/CD在AI项目中的应用

2.1 从传统DevOps到AI DevOps的演进

传统DevOps的核心目标是缩短软件从提交到上线的周期，通过自动化构建、测试和部署来提升交付效率。然而，当交付对象从“确定性代码”变为“数据驱动的模型”时，原有的流水线范式面临根本性挑战。AI项目不仅包含代码，还包含数据集版本、模型超参数、训练环境依赖以及评估指标，这些要素共同构成一个不可分割的交付单元。

AI DevOps的本质，是将DevOps的自动化与可观测性文化延伸到机器学习全生命周期，解决以下三类传统工具链无法覆盖的问题：

数据漂移与模型衰减：模型上线后，真实分布随时间变化，需要持续监控并触发重训。
实验可复现性：训练结果必须能追溯到精确的数据切片、代码提交和随机种子。
模型与服务的耦合：模型推理服务需要与业务代码一起进行版本化发布与回滚。

核心认知：AI DevOps不是“在DevOps流水线里加一个训练步骤”，而是将数据、模型、代码视为三位一体的交付物，重新设计每个环节的验证与发布策略。

2.2 AI项目CI/CD的核心原理

AI项目的CI/CD流水线在传统“代码提交→构建→部署”的基础上，增加了数据验证和模型评估两道关键闸门。其核心原理可以概括为“三阶段门禁”模型：

数据门禁（Data Gate）：在训练启动前，对数据集的schema、分布、缺失率、标签完整性进行自动化校验。若数据质量不达标，流水线直接失败，避免“垃圾进、垃圾出”。
模型门禁（Model Gate）：训练完成后，自动评估模型在验证集上的精度、召回、AUC等指标，并与当前生产模型进行对比。只有新模型在预设指标上不低于生产模型，才允许进入部署环节。
服务门禁（Service Gate）：部署后启动金丝雀验证，观察推理延迟、错误率、内存占用等SLO指标，在设定时间窗口内无异常后，才将流量全量切换。

典型AI CI/CD流水线定义（YAML片段）：

stages:
  - data_validation
  - train
  - evaluate
  - build_image
  - deploy_canary
  - full_rollout

data_validation:
  script: dvc repro validate_data.dvc
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

evaluate:
  script: |
    python evaluate.py \
      --model-path artifacts/model.pkl \
      --baseline-uri models:/prod/model
  rules:
    - allow_failure: false

2.3 方法流程：端到端的AI交付流水线

一个生产级的AI DevOps流程通常包含以下七个环节，每个环节都有明确的输入、输出与验证标准：

阶段	核心活动	自动化验证点	常用工具
1. 数据准备	数据采集、清洗、标注、版本化	Schema校验、分布对比	DVC, Great Expectations
2. 特征工程	特征计算、选择、存储	特征重要性漂移检测	Feast, Tecton
3. 模型训练	超参数调优、分布式训练	训练资源监控、收敛检查	Kubeflow, Ray Train
4. 模型评估	离线指标计算、公平性测试	与基线对比、阈值判断	MLflow, Evidently
5. 模型打包	模型序列化、依赖锁定	镜像安全扫描	Docker, BentoML
6. 部署发布	金丝雀/蓝绿部署	SLO健康检查、回滚触发	KServe, Argo Rollouts
7. 持续监控	数据漂移、概念漂移检测	告警规则、自动重训触发	Prometheus, Grafana

值得注意的是，模型评估阶段不应只关注单一指标。例如在信贷风控场景中，模型A的AUC比模型B高0.02，但模型A在特定人群（如年轻用户）上的错误率显著上升。因此，评估阶段需要同时检查分层指标和公平性指标，并将这些检查固化为流水线中的自动化测试用例。

2.4 实战案例：智能推荐系统的CI/CD落地

某电商平台的推荐团队将AI DevOps应用于商品推荐模型的迭代。他们的流水线设计如下：

数据触发：每天凌晨，当新的用户行为日志进入数据湖后，自动触发数据质量校验任务。校验内容包括：日志时间戳完整性、商品ID有效性、用户行为类型分布。
自动重训：若数据质量通过，流水线自动拉取最新特征数据，使用预置的AutoML配置进行模型重训。训练过程在Kubernetes集群上运行，GPU资源按需申请。
影子评估：新模型训练完成后，并不直接上线，而是先进入“影子模式”——将真实流量复制一份发送给新模型，但返回结果不生效。系统对比影子模型与生产模型的推荐点击率（CTR）差异。
渐进发布：当影子评估显示CTR提升超过1%且无异常时，流水线自动将新模型部署为金丝雀版本，先接收5%流量，观察30分钟后逐步扩大到50%、100%。

常见误区：很多团队在影子评估阶段只对比离线AUC，忽略了在线业务指标。离线AUC提升并不代表线上CTR提升，因为离线评估无法模拟真实用户的上下文特征和反馈循环。正确的做法是同时监控离线指标（AUC、LogLoss）和在线指标（CTR、转化率、人均浏览时长），并设置不同的通过阈值。

2.5 误区与复盘：AI DevOps失败的典型原因

根据对多个企业AI团队的调研，以下五个误区是导致AI DevOps落地失败的高频原因：

误区	表现	后果	正确做法
数据版本缺失	训练脚本直接读取“最新”数据	模型无法复现，问题难以定位	每次训练锁定数据版本哈希
评估指标单一	只看AUC或准确率	模型在少数群体上表现差	分层评估+公平性指标
训练与推理环境不一致	训练用Python 3.8，推理用3.10	线上推理结果异常	使用容器锁定完整依赖
缺少自动回滚机制	模型上线后靠人工发现异常	业务损失扩大	配置SLO告警并自动回滚
监控只覆盖系统指标	只监控CPU/内存/延迟	数据漂移未被发现	增加数据分布和特征漂移监控

一个典型的失败复盘案例：某金融团队上线了新的信用评分模型，离线AUC从0.82提升到0.85，团队直接全量发布。两周后，发现线上坏账率反而上升。排查后发现：新模型在训练数据中包含了某段时间的异常样本（因营销活动导致的虚假申请），模型学到了“短期高频申请=优质用户”的错误模式。由于流水线中缺少数据分布变化检测和分时段回测，这个问题直到业务损失出现才被发现。

复盘结论：AI DevOps的成熟度不在于自动化程度有多高，而在于验证的全面性。每一次模型更新，都必须回答三个问题：数据是否可信？模型是否真的更好？上线后是否在持续变差？只有将这三个问题的检查固化为流水线的强制门禁，AI项目的交付才能真正做到快速且安全。