📚 课程目录第2章基础知识

2. 基础知识：持续集成（CI）基本概念、与传统软件CI的区别、AI模型开发流程概述

2.1 持续集成（CI）的基本概念

持续集成（Continuous Integration，CI）是一种软件开发实践，其核心思想是：开发人员频繁地将代码变更合并到主干分支，每次合并前通过自动化构建与测试来验证变更的正确性。CI 的出发点是消除“集成地狱”——当多个开发者长期在各自分支上工作，最后合并时往往冲突频发、问题难以定位。通过将集成过程提前并常态化，CI 让团队始终处于“可发布”的状态。

一个标准的 CI 流水线通常包含以下阶段：

代码提交（Commit）：开发者将本地改动推送到版本控制系统的共享分支。
静态检查（Static Analysis）：对代码进行格式检查、Lint 规则校验、复杂度分析。
单元测试（Unit Test）：运行针对函数、类、模块级别的自动化测试用例。
构建（Build）：编译源代码、打包制品（如 JAR、Docker 镜像）。
集成测试（Integration Test）：验证模块间接口、服务间调用是否正常。
报告与反馈（Report & Feedback）：将测试覆盖率、构建状态、失败日志反馈给团队。

CI 的关键要素是自动化与快速反馈。如果一次提交需要数小时才能得到验证结果，开发者就会失去等待的耐心，CI 的价值也会大打折扣。因此，CI 系统通常要求流水线在 10~30 分钟内完成，以便及时暴露问题。

核心要点：CI 不是简单的“跑测试”，而是一种团队协作规范。它要求：主干分支保持可部署状态、提交粒度足够小、测试覆盖关键路径、失败时立即修复（而不是绕过检查）。

2.2 AI模型开发流程与传统软件CI的区别

传统软件 CI 处理的对象是确定性代码——同样的输入必然产生同样的输出。而 AI 模型开发的核心对象是数据 + 算法 + 模型参数，其行为具有统计性和不确定性。这种本质差异导致 AI 项目的 CI 在以下维度上与传统 CI 截然不同：

对比维度	传统软件 CI	AI 模型 CI
主要变更对象	源代码（.py/.java/.go）	代码 + 数据集 + 超参数 + 模型权重
验证方式	单元测试、断言、编译检查	模型评估指标（准确率、召回率、AUC 等）
结果确定性	确定性，可重复	统计性，受随机种子、数据分布影响
构建产物	可执行文件、镜像、库	模型 checkpoint、预处理流水线、推理服务
测试数据	固定测试用例	需要独立的验证集/测试集，且需防止数据泄漏
回滚策略	回滚代码版本	回滚代码 + 数据版本 + 模型版本（三者需对齐）
性能关注点	响应时间、吞吐量、内存占用	推理延迟 + 模型精度 + 资源消耗（GPU/内存）

传统 CI 中，如果测试失败，几乎可以确定是代码逻辑有误；但在 AI 项目中，评估指标下降可能源于多种因素：训练数据分布漂移、特征处理逻辑改变、超参数调整不当、甚至随机种子变化。这使得 AI CI 的问题定位难度显著增加。

此外，传统 CI 的“构建”阶段在 AI 项目中对应的是模型训练——这是一个计算密集、耗时且成本高昂的过程。因此，AI CI 不能每次提交都完整重训模型，而需要引入增量训练、缓存机制、早停策略等优化手段。

2.3 AI模型开发流程概述

要理解 AI 模型的 CI，首先需要梳理 AI 模型从数据到上线的完整开发流程。一个典型的机器学习项目生命周期包含以下环节：

业务理解与问题定义：明确预测目标、评估指标（如准确率、F1、AUC）、业务约束（延迟、成本）。
数据采集与标注：获取原始数据，进行清洗、去重、标注，形成训练/验证/测试三份独立数据集。
特征工程：设计特征、处理缺失值、归一化、编码类别变量、构造交叉特征。
模型选择与训练：选择算法（线性模型、树模型、深度学习等），设置超参数，在训练集上拟合模型。
模型评估与调优：在验证集上评估性能，通过交叉验证、网格搜索等方式调优超参数。
模型部署与监控：将模型封装为推理服务，部署到生产环境，持续监控推理质量与数据漂移。

在上述流程中，数据版本管理和实验追踪是 AI 项目区别于传统软件的两大关键实践。数据集的每一次更新（新增样本、修正标注、特征重定义）都可能导致模型行为变化，因此必须像管理代码一样管理数据版本。常用的工具包括 DVC（Data Version Control）、LakeFS 以及云厂商的对象存储版本控制。

实验追踪则记录每次训练的超参数、代码版本、数据版本、评估指标、模型权重路径等信息，工具如 MLflow、Weights & Biases、Neptune 等。有了实验追踪，团队才能复现历史结果、对比不同实验、定位性能回退的原因。

2.4 案例：一个图像分类模型的 CI 流水线

假设团队正在开发一个“产品缺陷图像分类”模型，输入为生产线拍摄的零件照片，输出为“正常/划痕/变形/污渍”四类标签。其 CI 流水线设计如下：

# .gitlab-ci.yml 片段（AI 模型 CI 示例）
stages:
  - data_validation
  - train_smoke
  - full_train
  - evaluate
  - package

data_validation:
  stage: data_validation
  script:
    - python scripts/validate_data.py --data s3://dataset/v3
    # 检查：图片数量、类别分布、文件格式、是否存在泄漏

train_smoke:
  stage: train_smoke
  script:
    - python scripts/train.py --epochs 1 --data s3://dataset/v3
    # 小批量训练，验证代码可运行、数据可读取

full_train:
  stage: full_train
  script:
    - python scripts/train.py --epochs 50 --data s3://dataset/v3
  artifacts:
    paths:
      - models/checkpoint.pt

evaluate:
  stage: evaluate
  script:
    - python scripts/evaluate.py --model models/checkpoint.pt --test s3://dataset/v3/test
    # 计算准确率、召回率、混淆矩阵，与基线模型对比

package:
  stage: package
  script:
    - docker build -t defect-classifier:${CI_COMMIT_SHA} .
    - docker push registry.example.com/defect-classifier:${CI_COMMIT_SHA}

该流水线的关键设计点在于：数据校验阶段前置，在训练前就发现数据问题；冒烟训练快速验证代码与数据的基本兼容性；完整训练与评估分离，避免评估阶段占用 GPU 资源；模型与代码使用同一提交号标记，保证可追溯性。

2.5 常见误区与复盘

误区一：将模型训练直接塞进传统 CI 流水线。 模型训练动辄数小时甚至数天，如果每次代码提交都触发完整训练，流水线会严重阻塞，开发者等待反馈的时间过长，最终会放弃使用 CI。正确做法是：提交阶段只做数据校验和冒烟训练，完整训练由人工触发或定时触发。

误区二：只关注模型精度，忽略数据版本对齐。 某团队在更新训练数据后，模型精度提升了 2%，但一个月后需要回滚模型时，发现无法找到与旧模型匹配的数据版本，导致无法复现。复盘结论：每次训练必须记录代码版本 + 数据版本 + 超参数 + 随机种子的完整组合。

误区三：用单一指标评估模型。 只盯着准确率，忽略了模型在少数类（如“变形”缺陷）上的召回率极低。当生产环境缺陷分布发生变化时，模型表现急剧下降。正确做法是同时监控多个指标，并设置最小可接受阈值（如召回率不低于 0.85）。

复盘建议：AI 项目的 CI 建设应当分阶段推进。第一阶段先实现“数据校验 + 冒烟训练 + 评估报告”；第二阶段加入“与基线模型对比”的门禁机制；第三阶段引入“金丝雀发布”和“在线监控反馈”。不要试图一步到位，而是让 CI 随团队成熟度逐步演进。

总结而言，AI 模型的持续集成并非传统 CI 的简单扩展，而是需要重新思考“什么是变更”“什么是测试”“什么是构建产物”这三个基本问题。只有将数据、代码、模型三者统一纳入版本管理与自动化验证体系，才能真正实现 AI 项目的持续交付。