📚 课程目录第3章 AI模型基础

3、AI模型基础：机器学习模型生命周期、模型文件格式、模型依赖管理

3.1 机器学习模型生命周期：从训练到推理的完整链路

在CI/CD流水线中集成AI模型，首先需要理解模型并非一个静态的“产物”，而是一个贯穿多个阶段的动态实体。机器学习模型生命周期通常包含以下六个核心阶段：

数据准备：采集、清洗、标注原始数据，并划分为训练集、验证集与测试集。此阶段产出数据版本清单与特征工程代码。
模型训练：选择算法（如XGBoost、PyTorch神经网络），在训练集群上执行训练任务，输出模型权重文件与训练日志。
模型验证：使用验证集评估模型指标（准确率、F1、AUC等），并对比基线模型决定是否进入下一阶段。
模型打包：将模型权重、预处理逻辑、推理代码及依赖清单封装为可部署的模型制品（如MLflow模型、ONNX包）。
模型部署：将制品发布到测试/生产环境，提供HTTP推理服务或批处理任务。
模型监控与退役：持续跟踪线上推理延迟、数据漂移指标，当模型效果衰减时触发重新训练或下线。

在CI/CD流水线视角下，上述阶段被映射为可重复执行的自动化任务。例如，Git提交触发数据验证→训练任务→模型注册→灰度发布。理解生命周期有助于定位异常发生的环节：训练阶段报错多为代码或资源问题，而部署阶段报错则常与依赖冲突或接口不匹配有关。

3.2 模型文件格式：不只是“一个文件”

模型文件格式决定了制品如何被保存、加载与跨平台迁移。常见格式包括：

格式	典型框架	内容构成	适用场景
Pickle/Joblib	Scikit-learn	序列化的Python对象	本地实验、小模型
SavedModel	TensorFlow	图结构+权重+签名	TF Serving生产部署
TorchScript	PyTorch	序列化图+权重	跨语言/移动端推理
ONNX	多框架互转	计算图+算子	硬件加速/跨框架
MLflow Model	框架无关	模型+conda.yaml+requirements	模型注册中心/CI/CD

在CI/CD流水线中，推荐使用MLflow Model或ONNX作为统一制品格式。MLflow模型自带依赖声明（conda.yaml），能显著降低部署时的环境配置成本。而ONNX则适合需要跨语言调用（如Java/C++服务）或部署到专用推理芯片的场景。

实践建议：在流水线中增加“格式校验”步骤，使用 mlflow.models.validate 或 onnx.checker.check_model 验证模型文件完整性，避免将损坏的制品推送到制品库。

3.3 模型依赖管理：环境一致性的关键

模型依赖管理是CI/CD集成中最容易出错的环节。一个典型的模型推理环境包含三类依赖：

Python包依赖：如 numpy==1.24.3、torch==2.1.0、transformers==4.36.0。版本不匹配会导致算子执行失败或精度偏差。
系统库依赖：如CUDA、cuDNN、libgomp。GPU推理时CUDA版本必须与PyTorch编译版本兼容。
模型内部资源：如分词器词表（vocab.txt）、标签映射文件（labels.json）、配置文件（config.json）。这些文件缺失会导致加载异常。

推荐使用虚拟环境隔离+锁定文件策略。在训练阶段生成精确的依赖锁定文件，并在部署阶段复用：

# 训练环境导出依赖（MLflow自动生成）
conda.yaml:
  channels:
    - conda-forge
  dependencies:
    - python=3.9.18
    - pip
    - pip:
        - torch==2.1.0
        - transformers==4.36.0
        - numpy==1.24.3
        - onnxruntime==1.16.0

在流水线中，通过哈希校验确保依赖文件未被篡改，并使用缓存机制加速依赖安装。例如，在Jenkins中配置 requirements.txt 的MD5值作为缓存key，避免每次构建都重新下载数百MB的PyTorch包。

3.4 典型故障场景：依赖冲突引发的推理异常

某推荐系统团队将训练好的XGBoost模型部署到Java推理服务时，遇到以下错误：

java.lang.UnsatisfiedLinkError: no xgboost4j in java.library.path
Caused by: java.io.IOException: libxgboost4j.so: libgomp.so.1: cannot open shared object file

根因分析：训练环境使用Python的XGBoost 1.7.5，而Java服务引用的xgboost4j版本为1.6.2，两者依赖的libgomp版本不兼容。此外，Docker镜像基于alpine基础镜像，缺少GNU C库（glibc），导致原生库无法加载。

解决步骤：

统一模型训练与推理的XGBoost版本为1.7.5，并在pom.xml中锁定。
将基础镜像更换为ubuntu:20.04，并安装libgomp1。
在CI流水线中增加原生库预检：运行 ldd libxgboost4j.so 检查动态链接库是否齐全。

常见误区：仅锁定Python包版本而忽略系统库版本。例如，PyTorch 2.1默认依赖CUDA 12.1，若部署机器仅安装CUDA 11.8，模型加载时不会直接报错，但GPU算子会回退到CPU执行，导致推理延迟暴增数倍。务必在流水线中记录nvidia-smi输出与torch.version.cuda的匹配关系。

3.5 复盘：模型生命周期管理中的三个关键教训

从大量生产事故中，可以总结出以下高频问题与应对策略：

教训一：模型文件与代码分离不彻底。将模型权重直接提交到Git仓库会导致仓库膨胀（数百MB），且无法追踪模型训练参数。应使用模型制品库（如MLflow Model Registry、S3+版本管理）存储模型，Git仅保存训练代码与配置文件。
教训二：忽略数据与模型的双重版本控制。仅记录模型版本而忘记关联训练数据集版本，当线上效果异常时无法回溯是哪一批数据导致。应在模型元数据中同时记录dataset_version与training_code_commit。
教训三：将“能跑通”等同于“可部署”。本地Jupyter中模型加载成功，不代表容器化后能正常工作。必须验证：模型文件是否包含相对路径引用？分词器资源是否被打包？端口与协议是否匹配？

建议在CI流水线中设置三阶段门禁：单元测试（验证预处理函数）、模型加载测试（验证权重与依赖）、端到端推理测试（发送真实请求并比对输出）。只有全部通过，模型制品才能进入发布候选状态。