第 5 章 模型生命周期与工程视角

学习目标

• 区分研究生命周期与生产生命周期，理解「训练完不是结束」；
• 掌握模型卡、数据卡、实验追踪、版本管理的作用与做法；
• 认识「从 Notebook 到生产系统」的鸿沟具体指什么；
• 厘清 MLOps、LLMOps、ModelOps 三个概念的区别与联系；
• 理解 LLM 工程的特殊性：Prompt、上下文、RAG、Agent、Token 成本。

---

5.1 研究生命周期 vs 生产生命周期

同一个模型，研究与生产的生命周期完全不同：

阶段	研究生命周期	生产生命周期
目标	验证假设、刷指标	稳定服务、持续迭代
数据	固定基准集	线上数据回流、漂移检测
训练	一次或几次	持续训练（CT）、定期重训
评估	离线指标	离线 + 在线 + A/B
部署	无/演示	灰度、蓝绿、回滚
监控	无	全链路可观测
结束	论文/报告	模型退役、数据迁移

研究生命周期是「一条线」：数据 → 训练 → 评估 → 报告。生产生命周期是一个「环」：数据 → 训练 → 评估 → 部署 → 监控 → 反馈 → 数据。 这个环就是本书第 1 章画的那个环形图。

工程上最贵的认知偏差是「把研究生命周期的习惯带进生产」：训练一次就上线、没有监控、没有回流、没有版本管理。本书第 5 章起的全部内容，本质都是在把「研究的一条线」改造成「生产的闭环」。

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart LR
    subgraph 研究
    A1[固定数据] --> B1[训练一次] --> C1[评估] --> D1[写报告]
    end
    subgraph 生产
    A2[线上数据] --> B2[训练/微调] --> C2[评估] --> D2[灰度部署] --> E2[监控] --> F2[反馈回流]
    F2 --> A2
    E2 -->|漂移| B2
    end

5.2 模型卡、数据卡、实验追踪、版本管理

生产生命周期的第一步，是给模型和数据和实验建立「档案」。

5.2.1 模型卡（Model Card）

Mitchell et al.（2019）提出，是一份随模型发布的「说明书」，回答：这个模型是什么、怎么训练的、用什么数据、能做什么、不能做什么、有什么已知限制与风险。规范内容包括：模型概述、预期用途、训练数据、评估结果、伦理考量、公平性、安全与可复现性。模型卡是「模型治理」的最小单元（第 23 章会把它放进合规语境）。

# Model Card: 客户意图分类模型 v3

## 模型概述
- 用途：客服对话意图分类（12 类）
- 结构：Qwen2-7B + LoRA 微调

## 训练数据
- 来源：2025-01 ~ 2025-12 脱敏客服日志 + 人工标注
- 规模：120 万条，意图标签
- 偏差：缺少方言与投诉激烈场景样本

## 评估
- 准确率 0.93 / F1 0.91 / 延迟 p95 350ms
- 失败模式：口语化长句易错分类

## 限制与风险
- 不适用于语音转写后的乱码文本
- 需配合提示注入防护

5.2.2 数据卡（Data Card）

数据卡是数据集的「说明书」：数据来源、采集方式、清洗流程、标注规范、分布统计、偏差与隐私风险。它让「模型为什么有偏见」变得可追溯——数据卡是模型卡的溯源基础。

5.2.3 实验追踪（Experiment Tracking）

每个训练实验要记录：超参数、数据版本、代码版本、随机种子、指标曲线、模型产物。工具：MLflow、Weights & Biases、Neptune、TensorBoard。没有实验追踪，就无法回答「上个好模型是怎么训出来的」——这在研究里只是麻烦，在生产里是事故根源。

5.2.4 模型版本管理

模型是「制品（Artifact）」，要像代码一样做版本管理：

• 模型仓库/注册表（Model Registry）：存放模型文件 + 元数据（来源、指标、审批状态）。MLflow Model Registry、HuggingFace Hub、Seldon 都有此能力。
• 版本语义：model:7b-int4:v20250919 这样「结构-压缩-版本」的命名，让部署、回滚、审计都清晰。
• 与代码/数据/配置联动：一个模型版本要能追溯到「哪份代码、哪份数据、哪组超参数」训出来的——这就是「可复现性」。

第 19 章会把模型版本管理放进 CI/CD/CT 的完整发布工程里。

5.3 从 Notebook 到生产系统的鸿沟

Notebook 里「训练一个模型」到「生产可用」，隔着一条鸿沟。列举鸿沟的每一个具体断面：

鸿沟	Notebook 世界	生产世界
数据	一次性 CSV/静态加载	持续更新、版本化、血缘
训练	单卡、临时环境	多机分布式、资源调度、断点续训
推理	慢、一次一个	低延迟、高并发、批处理
服务	无	API、鉴权、限流、灰度
监控	无	指标、日志、告警、漂移
可靠性	失败重跑	SLO、容错、回滚
团队	个人	模型/平台/SRE/业务多方协作

为什么这条鸿沟比传统软件更大？ 因为模型是「非确定性制品」：同样的代码，不同数据、不同种子、不同版本可能产出不同行为；模型的行为还会随线上数据漂移而劣化。传统软件的 CI/CD 只管「代码」，ML 还需要管理「数据 + 模型 + 线上行为」——这就是 MLOps 存在的原因。

5.4 MLOps、LLMOps、ModelOps 的区别

三个概念经常混用，厘清它们：

概念	范围	关注点
MLOps	机器学习全流程工程化	数据、训练、评估、部署、监控的自动化与治理
LLMOps	LLM 应用与服务的工程化	Prompt、上下文、RAG、Agent、Token 成本、对齐治理
ModelOps	所有模型的统一治理	跨 ML/规则/统计模型的统一运维与治理框架

关系：

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
graph LR
    subgraph 治理层
    M[ModelOps
统一模型治理]
    end
    subgraph 工程层
    ML[MLOps
传统 ML + DL 工程化]
    LLM[LLMOps
LLM 应用与服务]
    end
    M --> ML
    M --> LLM

• MLOps 的核心是「训练-部署-监控」闭环的自动化：数据管道、实验追踪、模型注册、CI/CD、监控告警。
• LLMOps 是 MLOps 在 LLM 时代的延伸与突变：LLM 大多是「拿来用」而不是「从头训」，所以重心从「训练流水线」转向「应用编排」——Prompt 管理、RAG 管道、Agent 编排、Token 计量、内容安全。LLMOps 里「模型生命周期」的边界模糊了：模型是外部服务还是自训模型，直接影响 ops 的形态。
• ModelOps 站在更高层：不管什么模型（LR、GBDT、LLM），都要有统一的治理（审批、审计、合规、退役）。

一句话：MLOps 管「怎么把模型做好并上线」，LLMOps 管「怎么把 LLM 用好并运营」，ModelOps 管「所有模型怎么被合规治理」。

5.5 LLM 工程的特殊性

LLM 工程与传统 ML 工程相比，有几个「新变量」决定了一切：

5.5.1 Prompt 是「可运行代码」

在传统 ML 里，输入是特征，模型是固定的。在 LLM 里，Prompt 本身是改变模型行为的「指令」，并且是运行时可变、用户可注入的。于是：

• Prompt 要版本管理、测试、监控（改了 Prompt 就像改了代码，但更隐蔽）；
• Prompt 引入安全风险——提示注入（第 23 章）；
• 系统提示是「最高优先级代码」，要被保护。

5.5.2 上下文是「临时记忆」

模型的输入不止是「问题」，而是「系统提示 + 历史对话 + 检索结果 + 工具结果 + 用户问题」拼成的上下文。上下文管理与成本控制直接挂钩：上下文越长，KV Cache 越大、token 成本越高（第 4 章的账）。「塞多少上下文、怎么塞」成了 LLM 服务的关键优化点（第 17 章）。

5.5.3 RAG 是把「记忆」外置

LLM 的「记忆」是训练时固化的，有知识截止与幻觉问题。RAG 把记忆外置到检索系统：每次问答现查现用。这让「更新知识」从「重训模型」变成「更新索引」——知识更新的成本降低几个数量级。但引入新的工程组件：分块、嵌入、向量库、重排序（第 17 章）。RAG 是 LLMOps 最重要的模式。

5.5.4 Agent 是把「模型」变成「执行者」

Agent = LLM + 工具 + 循环。模型不再只是「回答问题」，而是「规划 → 调用工具 → 观察结果 → 再规划」。这让「评估与监控」从「输出好不好」变成「行为对不对、工具链是否可靠」（第 26 章）。

5.5.5 Token 成本是新的成本中心

传统 ML 的成本是「GPU 时数」。LLM 的成本是「Token 数」——输入/输出分开计费，且受上下文长度影响。Token 成本要进账单、进监控、进容量规划（第 17、21 章）。「少用 token、用好 token」是 LLMOps 的日常优化。

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart LR
    A[LLM 工程新变量] --> B[Prompt 可运行代码
版本+测试+安全]
    A --> C[上下文临时记忆
成本+窗口管理]
    A --> D[RAG 外置记忆
索引更新替代重训]
    A --> E[Agent 执行者
行为评估]
    A --> F[Token 成本中心
计量+优化]

---

本章要点回顾

1. 研究生命周期是一条线，生产生命周期是一个环；生产的核心是「反馈回流」。
2. 模型卡、数据卡、实验追踪、版本管理是生产生命周期的「档案系统」，也是治理的最小单元。
3. 「Notebook 到生产」的鸿沟在于：模型是非确定性制品，行为随数据漂移，需要比传统软件更重的运维。
4. MLOps 管「做好并上线」，LLMOps 管「用好并运营」，ModelOps 管「统一治理」。
5. LLM 工程的五个新变量：Prompt、上下文、RAG、Agent、Token 成本——它们重新定义了工程边界。

习题

1. 为你的上一个模型写一份模型卡（可以是虚构项目），必须包含「限制与风险」一节。
2. 你的团队正在从「训练一次就上线」转向「持续训练」，列出需要补的 5 个工程环节。
3. 区分：你的项目需要 MLOps、LLMOps 还是 ModelOps？举出三者各覆盖你项目中的哪部分。
4. 设计一个 Prompt 版本管理方案：Prompt 改动的测试、灰度、回滚怎么做？
5. 为什么说「Token 成本」是 LLMOps 独有的成本维度？列出 3 个降低 token 成本的工程手段。

延伸阅读

• Mitchell et al., Model Cards for Model Reporting, 2019
• Gebru et al., Datasheets for Datasets, 2021
• Kreuzberger et al., Machine Learning Operations (MLOps): Overview, Definition, and Architecture, 2023
• 关于 LLMOps，推荐阅读 LangChain 与 LlamaIndex 的工程文档，以及各云厂商的 GenAI 运维白皮书
• Sculley et al., Hidden Technical Debt in Machine Learning Systems, 2015（ML 工程债务的经典）

第 1 篇小结

到这里，第 1 篇「模型基础与 LLM 概念」结束。你已经建立了：

• 模型是什么（结构+参数+目标函数）、模型家族全景（六维度贴标签）、LLM 内部机理（token→attention→KV Cache）、规模怎么算（参数量/FLOPs/显存）、生命周期与工程视角（研究 vs 生产、MLOps/LLMOps/ModelOps）。

下一篇进入生命周期真正的起点：第 2 篇「数据、训练与评估」，从数据工程讲起，然后训练、微调、评估。这是「把模型真正造出来」的部分。