打造 ML/AI 系统的内部开发者平台（IDP）——什么是MLOps?本章将涵盖：理解机器学习运维（MLOps）及其在

本章将涵盖：

理解机器学习运维（MLOps）及其在生产级 ML 中的作用
构建可靠 ML 系统时的关键挑战
MLOps 与传统 DevOps 的差异
通过结构化的 ML 流程建立信心

在第 1 章中，我们介绍了 ML 生命周期，以及成为高效 ML 工程师所需的基础技能。现在，让我们更深入地探讨机器学习运维（MLOps）的实践与原则——它们将帮助你通过 ML 系统可靠地交付价值。ML 和 ML 模型往往并不是一个组织的最终产品，而更像是达成目标的手段。

业务价值产出、需求与所需基础设施之间的鸿沟，是 ML、以及进一步的 MLOps 之所以困难的首要原因。真正做模型研发的公司并不多，更多公司会复用现成架构，并针对特定领域与问题集训练/适配现成模型。像 Hugging Face 这样完善的开源库，也可能让“建模”本身变得近乎轻而易举。当你定义了问题、选定了解决该问题的架构之后，真正困难的问题就会集中浮现：

模型如何训练？
数据如何进入模型？
模型如何与其他服务交互？
模型将运行在哪里？
我们如何确保模型随时间推移仍然准确？

在上一章，我们讨论了 ML 以及从业者在正常模型开发过程中会经历的不同阶段。现在，我们要更深入一点：ML 的价值往往来自它作为一个闭环的一部分，并且这个闭环会随时间持续改进。我们会先建立一个关于这个闭环的心智框架，然后拆解一些关键思想。接着，我们会对比 MLOps 与传统 DevOps，找出它们在哪些方面相似、又在哪些关键领域不同。最后，我们会补充大型组织如何看待 MLOps 的价值主张，以及它们在旅程中会遇到的成熟度层级。

从图 2.1 所示的整体 ML 流水线心智地图来看，我们将主要讨论方框 1 和 2：输入要求、问题定义与总体设计哲学，并会触及这些因素如何影响模型设计过程。

图 2.1 心智地图：聚焦问题定义（1）与模型设计（2）

2.1 迭代式 MLOps 生命周期

掌握 ML 工程的关键之一，是形成一个清晰的心智模型：ML 系统如何随时间演进。谈到真实世界的 ML，用“闭环”来思考往往最有效。模型、数据与超参数，最好被视为短暂的（ephemeral）并且是闭环的一部分；而整个闭环会随时间整体演化。这样的心智模型能帮助你预判挑战，并在系统设计上做出更明智的决策。

把 ML 项目看成一个闭环，也会自然引导你去思考：当模型变化时，应该建立怎样的流程。真实世界里的模型变化非常频繁；一套健壮的工作流能确保开发效率不会被拖慢，并让不同团队的流程得到标准化。迭代是 ML 开发的核心特征，这可能来自工程师对底层假设的变化、改进模型的方法与机会、或模型所处环境的变化。举例来说，假设我们为二手车经销商开发并部署了一个模型，用于预测汽车价格，让用户能找到自己车辆的最佳报价。随着时间推移，模型会随着客户需求与市场条件变化而演进。你甚至可能会针对商用车与工业车辆开发更多版本。建立一套健壮的构建、测试与部署工作流，意味着你可以推出新特性，同时把注意力放在模型提供的核心业务价值上，而不是陷在部署细节里。请记住：模型（权重 + 网络）与代码（模型架构与支撑代码）是两个独立实体，因此维护谱系（lineage）与跟踪（tracking）对构建可持续的 ML 工作流至关重要。

ML 闭环从定义问题与收集用于预测的数据开始（见图 2.2）。在启动 ML 项目之前，问题陈述必须被良好定义，并与相关方对齐。例如，“预测客户流失率”这样的表述不足以支撑正确建模与设定评估标准。

图 2.2 把 ML 看作一个闭环

下面是需要回答的关键问题。每组清单按相关方类别组织：

业务与产品相关方

需要 ML 方案解决的问题或任务是什么？为什么需要 ML？
业务目标是什么？成功的目标指标（metrics）是什么？
产出的业务价值与所需开发投入相比如何？
项目的时间线是什么？
在路线图（road map）的哪个位置，模型提供的价值最大？
预测错误会带来什么业务影响？可接受的误差容忍度是什么？

技术团队（ML 工程师与数据科学家）

该问题能用 ML 解决吗？ML 是最优方案吗？已有何种研究/文献？
数据存在哪里、以什么方式存？需要构建什么数据流水线？
模型将如何评估？应使用哪些指标？
模型训练与服务需要哪些算力资源？
哪种部署策略能支持未来升级与维护？
哪些指标应触发模型再训练？

法务与合规相关方

是否存在需要处理的伦理与隐私问题？
数据集中敏感信息应如何处理？
需要满足哪些数据治理要求？

跨相关方协同回答这些问题，有助于确保：

项目范围与交付物清晰
业务目标与技术实现对齐
尽早识别潜在挑战
数据科学家与 ML 工程师之间有效沟通

理解这种闭环结构对构建稳健的 ML 系统至关重要。闭环中的每个组件都有特定挑战与最佳实践，但看清它们如何拼在一起，能帮助你在系统设计与维护上做出更好的决策。随着你在真实项目中实践，你会逐渐形成直觉：闭环某一部分的变化会如何影响其他部分。

2.1.1 数据收集

一旦问题被定义清楚、可度量的关键绩效指标（KPI）也确定下来，就必须为建模收集数据。数据收集与数据整理（curation）必须非常谨慎，因为后续步骤都会依赖这一环节，并会把这一环节产生的任何偏差一路带下去。

这一环节也是研究型 ML 与企业级 ML 差异最明显的地方之一。研究人员往往以优化指标为目标，并假设已有数据集质量足够。在计算机视觉领域，研究人员经常依赖大型开源数据集，这些数据集通常经历多轮审查与修订，以确保高质量标注与类别均衡。相比之下，企业里的 ML 实践者往往没有可直接用于目标应用或领域的开源数据集。即便有，模型也通常仍需在部署环境的数据上进行微调（fine-tuning，也称迁移学习）。在我们的示例中，这相当于企业需要从零开始构建一个数据集。不过，无论是企业还是研究实践者，数据收集背后的核心要求，在精神内核上基本一致：

数据与问题领域的相关性
数据集规模相对于问题复杂度是否足够
数据集质量
防止有害偏差与非预期的样本泄露（leakage）
数据与特征的分布应能代表部署环境
数据收集过程具备足够多样性，以良好刻画问题领域
对原始数据、中间版本、增强数据与标注数据集的谱系与细粒度跟踪

上述大多数点都很直观，但在启动 ML 项目时，**谱系（lineage）**常被忽视。这很像技术债：用初期速度换取未来的复杂性与可维护性压力。数据谱系之所以关键，主要有以下原因：

数据谱系能建立数据的来源。换句话说，关于数据在何时、何地、如何、为何被收集的元数据，对理解数据的局限性与/或选择合适特征非常重要。
谱系让数据集版本化与编译成为线性过程，并让你能回溯并修正错误数据。以我们的经验来看，数据集的第一个版本往往不是最好的版本；修订是数据分析与收集这一迭代过程的常态。具备良好谱系，可能意味着：你只需写一个简单查询就能重新生成因错误而需要重建的数据集；否则你可能不得不重写/重跑复杂的抽取脚本。

我们用“二手车价格估计器”这个玩具示例，来说明如何设计数据收集活动。根据核心准则，我们首先收集与用例相关的数据：也就是二手市场上所有乘用车的数据，而不包括其他车辆（例如卡车或摩托车）。我们还要考虑合适的抽样技术，确保数据集能代表目标领域并避免偏差。最后，为了建立谱系，我们会使用一个带版本管理的 ETL（抽取、转换、加载）流水线来生成数据集。

数据选择必须谨慎，尤其要处理诸如类别偏差（class bias）这类情况：当某些类别被过度代表或代表不足时，需要特别小心，以确保公平性并避免任何偏差。很多时候，项目刚开始时这些条件往往会被违反；但因为我们已经知道整个过程高度迭代，我们可以先从一个尽可能满足上述条件的数据集开始。

在本书中，我们聚焦两个数据密集型项目，以及一个由大语言模型（LLM）驱动的检索增强生成（RAG）系统。它们的数据形态（modality）各不相同，这既是为了强调前述观点，也用来展示处理不同数据类型与模态时会遇到的挑战。对于身份证件检测器项目，我们将使用公开可用的 MIDV-500 数据集（见图 2.3）。该数据集包含 500 段视频片段，覆盖 50 种不同的身份文件类型，包括来自不同国家的身份证、护照与驾照。

图 2.3 MIDV-500 数据集中的视觉数据示例

作为身份证件检测器项目的一部分，我们还会介绍使用 Computer Vision Annotation Tool（CVAT）进行人工标注。CVAT 是一个开源、基于 Web 的图像与视频标注工具，用于为计算机视觉算法标注数据（见图 2.4）。我们会讲它的安装，并说明如何把图像标注纳入 ML 闭环。虽然这一节是可选的，但它给你一个机会亲自标注一些数据，并理解人工标注周期会给 ML 闭环带来的问题。

图 2.4 在 CVAT Web 标注工具中展示的一张已标注身份证示例：该工具用于标注图像与视频，常用于为计算机视觉模型制作标签数据

幸运的是，我们不会标注整个数据集，主要因为我们使用了合成数据：它的优势在于不需要任何人工标注，因为图像及其标签是通过程序过程生成的。

对于电影推荐项目，我们会使用广受欢迎的 MovieLens 1M 数据集：它包含 100 万条匿名评分，覆盖约 3,000 部电影，由 6,000 名在 2000 年加入 MovieLens 的用户提供。该数据集包含三个主要文件：users.dat、movies.dat 与 ratings.dat。本书配套仓库里提供了下载与处理数据的代码。

在准备阶段，我们会把数据集拆分成更小的部分，用来模拟：当模型在生产中运行时，用户持续产生新数据的情形。我们还会构建流水线来“抽取”更多数据并对其进行版本化——这也是我们开始做数据集版本管理的地方。

2.1.2 探索性数据分析

探索性数据分析（EDA）说白了，就是探索现有数据并理解其统计特性中的细微差别。这是最重要的步骤之一，因为它常常是对“问题定义不够清晰”等问题的第一道防线（包括数据集本身的问题）；同时，它对细化开发与维护模型所需投入的工作量评估也至关重要。你应该带着以下目标来做 EDA：

我的数据长什么样？它的 schema 是什么？schema 会变化吗？我如何防止无效值？数据需要清洗吗？
我的数据分布如何？各目标是否被同等代表？是否需要额外的类别均衡？
数据里是否有足够稳健的特征来完成我想做的任务？这些特征计算成本高吗？
输入数据是否存在周期性变化？它是否与一些未被建模的外部因素相关？
数据集中是否存在异常值（outliers）？在生产中应如何处理异常值？

在分析数据时，多变量分析（同时评估多个变量）可以提供关于底层分布与模式的线索，从而帮助你开发稳健特征。根据涉及变量的数量，可能需要使用降维方法，例如主成分分析（PCA）或 t 分布随机邻域嵌入（t-SNE）。

在这一阶段，理解我们对数据及其分布所做的假设非常重要。所有假设在被验证之前都必须被当作风险对待，并且应尽早在数据流水线中加入检查，以确保这些假设不被破坏。这些假设可能简单到“输入数据的 schema”，也可能是抽样中的隐性偏差，甚至是对某个数据字段的误解。这样做能在后续节省大量调试时间，并能更快缩小问题范围。正视并检验这些假设，也意味着当某条假设经不起推敲时，我们可以在流程早期就转向另一种方法。

对数据科学家而言，上述很多点可能是本能反应；但拥有同等经验与技能的 ML 工程师，往往也能为根因分析以及诸如漂移（drift）这类部署问题提供重要线索与上下文。

EDA 是一个迭代过程：随着我们沿着闭环推进、对数据集获得新洞见，或当某次实验不奏效时，我们都需要回到数据集假设并重新审视这一环节。闭环中的这一部分很耗时，你必须保持开放，愿意探索替代的建模方法，并调整你对问题陈述的视角。

2.1.3 建模与训练（Modeling and training）

在掌握了可用数据与特征的知识之后，下一步就是创建真正用于预测的模型。重点在于确保我们最初设定的目标能够被实现，并且模型具备交付所需指标的能力。

建模阶段从确定合适的模型或算法开始，以解决问题陈述。这个阶段的决策因素包括（理论上的）性能、输入数据类型、要解决的问题类别（分类、检测、回归等）以及相关的其他考量。在这一步，MLOps 工具箱中的一些重要组件会出现：

模型与数据版本管理
实验跟踪
模型训练流水线
超参数搜索

虽然我们会在后续章节详细讨论这些组件，但理解它们为何对 ML 闭环的成功至关重要很重要。这些组件共同触及的主线，是谱系（lineage）与可追溯性（traceability） ，同时减少可能导致错误的人工步骤。模型与数据版本管理确保所有模型都与某个特定的数据集版本天然绑定，并且可以从零开始轻松复现，用于调试或合规。实验跟踪把这种严谨性带到原型阶段，确保所有结果都会被记录：包括所用数据、精确的模型配置与检查点。这也意味着实验与结果不会丢失。并且，由于实验与模型跟踪使用统一的单一界面，协作与模型特性/性能的汇报也会得到提升。

最后一个组件——超参数优化——指在给定搜索空间中寻找最佳超参数、或优化某个给定函数的过程。有效的超参数搜索是自动化的：模型开发者提供搜索空间与损失函数即可。因此，在项目早期最好采用一种模块化的代码库结构：把训练好的模型视为“将配置与数据应用到代码库后得到的产物（artifact）”。这种方式除了带来谱系与可复现性的收益外，也是一种普遍更好的项目代码组织方式（见图 2.5）。

图 2.5 使用模块化代码库概念的再训练流水线视图。将模型、代码、配置文件与数据作为相互独立、可版本化的组件，并用谱系链接连接起来，可确保流程保持灵活、快速、可适配，同时支持实验、调试与迭代式开发。

这种模块化的代码结构还能提升实验速度：你只需要编辑一个配置文件，就能更换模型架构或训练策略。比如，如果怀疑模型过拟合，一个很简单的修复方式是通过配置参数降低模型规模与层数，然后验证假设，而不是手工跑一堆实验。这些配置文件应该用 Git 跟踪；当它们被纳入模型的谱系后，会提供非常强的自省与调试能力。训练参数与模型超参数同样可以配置化，从而让超参数搜索与优化更容易开展。刚才展示的图 2.5 也强调了：模块化代码库能让你更容易为数据与源代码都建立跟踪与谱系系统。我们会在后续章节更深入讨论这一点，但不难看出：在开发初始模型时就带着这种“分离”的思路，也会让未来的扩展、流水线化与模块化更顺滑。

注意：使用工厂模式（factory pattern）来构建灵活的模型与流水线固然重要，但同样要避免掉进“过度参数化”的陷阱。先从简单配置开始，迭代改进，在“速度 vs. 灵活性”的权衡中找到最优点。

在身份证件检测中，我们将使用非常流行的 You Only Look Once（YOLO）模型来训练一个定制的目标检测器。写作本书时，YOLO 已经发展到第 12 代。

开箱即用的 YOLO 并不能检测身份证件。它是在 Common Objects in Context（COCO）数据集上训练的，可检测 91 类物体，但其中并不包含身份证与护照。不过别担心！只要我们有一个标注良好的数据集，做一点微调，就可以训练 YOLOv8 来检测身份证件。

我们将用来训练 YOLOv8 的库也包含评估逻辑。我们会预留足够的图像用于训练、测试与验证。

对于推荐系统项目，我们从一个简单的基线推荐模型开始，在训练子集上训练它。我们会先在 notebook 里起步，然后构建再训练流水线，并把模型与实验记录到跟踪服务器里。

在完成监控之后，我们会回到这一步：把更复杂的模型与生产中的模型做对比评估。这里我们会聚焦不同架构之间的评估标准，以及如何在最小化负面影响的前提下部署并测试新模型。指标与评估标准也会被纳入一个汇报框架，用于与业务相关方沟通。

最后，在 RAG 流水线中，我们会换个节奏，加入一些 LLM 应用特有的新概念，例如嵌入（embedding）模型、向量数据库与聊天界面。核心思想是：MLOps 的核心概念仍然相同，并且可以复用到看起来完全不同的应用领域里。

2.1.4 模型评估（Model evaluation）

当我们训练出一个在训练过程中的测试集上表现良好的模型之后，重要的是确保它在目标领域也能表现良好。此时，“良好的问题定义”和“恰当的指标选择”的重要性就会凸显出来。选择指标时要记住：有些指标更适合某些领域；并且它们会受到类别不平衡、漂移等数据因素的强烈影响。比如，精确率（precision）、召回率（recall）与 F1 分数可能对分类与检测问题很重要；而平均绝对误差（MAE）、均方误差（MSE）等则更适用于回归问题。即便在分类任务中，目标领域对精确率与召回率的要求也可能不同。例如，医疗应用对误报率与精确率有更严格要求，以尽量减少伤害；而金融从业者可能更看重召回率，以减少漏检事件带来的机构损失。因此，必须理解选择评估指标时背后的含义与权衡，并把它们与最初设定的需求与业务目标对齐。

在更正式的场景里，模型评估会在一个独立的留出集（holdout dataset）上自动完成。这个留出集会被精心整理，以匹配生产数据的多样性、分布与特征，并特别注意防止数据泄露。评估自动化也意味着消除人为错误带来的波动，使结果可重复、可复现。还要注意：留出集也会随时间演进，并且在谱系、版本管理与跟踪方面，会以与训练集同等的严谨性来对待。如果测试/训练/留出数据的划分因为某些原因发生变化，数据泄露就会成为问题，从而需要重新评估并进入再训练闭环。

评估也是对模型错误进行严谨分析的地方。你需要仔细检查误分类样本，分析其中的模式，并识别模型的系统性问题与偏差。然后，这些结论会反馈到数据收集环节。在这里也会测试模型的敏感性与鲁棒性；对抗测试与边界案例模拟等方法，能帮助你在未来防住潜在模型错误。

如你所见，评估往往是一个多阶段过程，涉及组件、代码与数据——它会随时间演化，而且评估的几乎所有子组件都会反向影响前序步骤。为了管理这种复杂性，强烈建议使用自动化流水线与集中化的结果跟踪。对评估结果进行良好文档化并提供可见性，能避免重复劳动，并支持未来的比较与改进。

注意：有些组织在评估模型时会强制要求可解释性（interpretability）。解释模型时，可能会检查并可视化特征重要性、决策边界、激活层等模型组件；或者采用可解释 AI 技术，例如 LIME（Local Interpretable Model-agnostic Explanations）与 SHAP（SHapley Additive exPlanations），以更好理解模型行为及其固有限制。虽然这是非常强大的工具，但实现复杂。我们建议你在起步阶段，根据自身需求仔细权衡可解释性的收益，再决定是否纳入当前方案或规划到未来。

2.1.5 部署（Deployment）

当你有了一个初始训练好的模型之后，下一步就是把它送进生产环境，开始为业务创造价值。常见部署方式包括：

创建一个适配微服务架构的 API 端点——在这种设置中，模型运行在 API 层之下，由 API 层对外提供服务请求。
部署到特定硬件环境或边缘设备——尽管这类部署不如 API 端点普遍，但在汽车、安防设备与机器人等领域非常重要，因为模型需要在设备端执行关键任务（例如感知）。

这两类方法都关注模型性能与时延，因此通常会先做一次优化：把原始训练出来的模型转换为针对目标部署环境做过特定优化的版本，再进行交付与迁移。在这种语境下，模型性能测试必须在最终（优化后）版本上完成，这样实测表现才能与真实世界的表现相关联。比如，模型在 GPU 上训练时可能看起来满足性能要求，但部署到嵌入式设备后，性能可能会显著不同，原因可能来自加速器工作方式的差异，或设备工具链如何处理量化等操作的差异。

部署也常被拆为预发（staging）与生产（production）：预发模型以评估模式运行，用来对比其相对生产模型的效果。这意味着部署是一个两阶段过程：先把初始模型部署到预发环境；当它完成评估后，再自动迁移到生产环境。健壮的模型版本控制与谱系能帮助这一过程：它确保所有模型状态迁移都会被记录，并且回滚到旧版本可以简单到“把生产中的模型切回上一版”。

在本书前两个项目（身份证件检测与电影推荐）中，我们将使用 BentoML 通过 HTTP 端点提供模型服务。然后我们会把它打包成 Docker 镜像，并使用 Yatai（BentoML 团队开发的模型部署平台）进行部署。对于最后的 LLM 项目，我们会用 Chainlit 为 RAG 应用提供一个熟悉的聊天界面。

不过，模型部署并不止步于此。生产中的模型必须被监控，以确保持续产生业务价值。由于模型生命周期内的每一次预测都不可能被逐条评估，我们可以依赖 BentoML 构建的模型服务开箱即用暴露一些 Prometheus 指标，例如每秒请求数（RPS）等性能指标，以及 HTTP 响应码等跟踪指标。最后，我们还会探索一些概念，比如批处理（batching）、金丝雀发布（canary deployments）与 A/B 测试。

2.1.6 监控（Monitoring）

模型部署让模型能够响应用户请求并产生价值。但同样重要的是：确保模型持续表现良好，并能立刻发现并修复下游指标的任何偏离。正如你所想，模型一次错误预测就可能主动拖慢甚至伤害业务。

模型监控的目标就是通过跟踪各种指标、数据异常与模型性能，来确保模型在生产中按预期工作。这一步也至关重要，因为模型性能会随时间变化：输入数据变化、概念漂移、硬件或软件故障等都会导致性能波动。通过监控，问题能被即时发现并采取行动修复。模型监控主要有以下几种变体：

数据监控——通过评估输入数据的统计性质来识别异常。数据漂移（即输入数据发生变化）会带来问题，因为模型训练所用数据与生产数据不一致，可能导致意外且错误的预测。监控进入系统的数据并设计稳健指标，是评估生产中模型表现的关键。
性能监控——跟踪生产环境中模型的准确率、预测表现等性能指标，确保模型有效性保持在高水平。长期监控这些指标能帮助你识别性能问题并采取纠正措施。
错误监控——识别模型的错误预测并理解这些错误，是提升模型长期表现的强大工具。通过错误分析，你可以更好理解模型在边界情况下的行为，并主动降低错误影响，甚至消除错误。

监控高度依赖 ML 闭环中的几个组件。模型版本控制能为理解模型性能提供关键上下文，帮助定位训练过程或数据集中的问题。日志记录也有助于复现边界案例、调查系统性问题、以及追踪可能由某次代码变更引发的问题——这些在长时间跨度上往往很难排查。最后，日志与版本控制结合起来，在受监管行业还能提供重要文档支撑。

监控环节中一个关键部分，是可靠的告警与通知系统。你可以拥有最好的指标、记录所有日志、并为模型建立详细谱系；但如果告警与指标没能送达负责的人，效果将等同于什么都没做。

因此，实现可靠的监控系统，是确保模型在变化条件下保持最优性能、并在真实世界部署中持续可靠的关键组成部分。

本书的项目会展示漂移（drift）的概念，以及良好监控体系的重要性。我们会用新数据、替代模型、模型再训练与模型对比进一步强化这一点。我们会复用此前讨论的许多工具，并引入 Evidently：它用于识别漂移并触发相应的再训练任务。

2.1.7 维护、更新与评审（Maintenance, updates, and review）

最后一个组件——由维护、更新与评审构成——有效地闭合了 ML 闭环。在这里，模型监控的输出会被用来做以下事情：

实施 bug 修复，解决生产模型中的问题与不足
收集用于特定边界案例的数据，以训练模型并提升性能
通过通知数据收集环节来缓解数据漂移，并训练一个新模型

同样重要的是，把这一组件视为贯穿整个闭环分布的能力。我们前面讨论的所有组件，在其自然生命周期里都会包含一定的维护与更新。例如，部署组件本身就包含维护，因为它负责用新版本替换生产中的模型。类似地，数据收集也包含更新能力，用于应对监控发现的概念漂移与数据漂移。

把维护与更新纳入 ML 闭环后，组织才能确保 ML 模型持续有效、可靠，并与不断变化的数据与用户需求保持一致。定期更新与持续监控让模型能够适应变化条件，持续输出准确且有价值的洞见。

在本书的项目中，我们会引入新的数据与新的模型架构。如前所述，我们会依赖目前已经搭建好的工具体系，但会额外聚焦那些能让模型维护与更新在受控方式下进行的流程与工具。

对于身份证件检测项目，我们会深入研究：检测器模型在某种特定、可能从未见过的证件上的表现如何；以及在生产中监控与漂移检测系统如何捕获这类新数据。我们的身份证件检测器能否做到“无缝替换”（drop-in replacement）？
对于推荐系统项目，我们会引入更多用户数据，并再次使用漂移检测与监控系统来告警性能偏离。为了更有意思，我们还会尝试一种新模型架构，并把它与生产模型进行评估对比。我们会用定义明确的指标来评估模型表现，然后决定部署哪一个。
在 RAG 流水线中，我们会主要聚焦 LLM 特有的可观测性议题。我们会看看 Langfuse，然后进一步讨论护栏（guardrails）、对抗测试、输入清洗、提示词安全与幻觉测试。虽然其中一些并非 LLM 独有（例如对抗测试与输入清洗），但它们对一个面向公众的 RAG 流水线而言至关重要——而这正是该项目的定位。

2.2 为什么稳健的 MLOps 很重要？

正如我们在上一章讨论的那样，要成为一名高效的 ML 工程师，需要跨多个学科具备能力——从软件工程与高性能计算，到 CI/CD、版本控制、ML 与统计学。理解 MLOps 为什么困难，能帮助你更系统地应对这些挑战。

在 ML 闭环中，哪怕只是一个模块（例如数据收集），本身就是一个令人望而生畏的话题，要想在规模化场景下成功落地，往往需要专门的专家。闭环中的每一个模块都会为解决方案增加一层（甚至多层！）复杂性；缺了这些复杂性，模型就无法稳定地产生一致的业务价值。第一次就把这一切做对通常非常难，往往需要不断调整组件与基础设施，直到组织内逐步收敛出一个可行的好方案。

数据是 MLOps 工作流的关键组成部分，优质数据与稳健的数据流水线是 ML 项目成功的标志。然而，在规模化管理数据的同时不牺牲可见性、确保隐私、并实现稳健的数据安全，往往成本高昂；并且一旦处理不当，可能会让业务面临因违规而引发的诉讼风险，或造成重大财务损失。对数据进行整理（curation），并持续维持公平性、多样性与无偏差等原则，又会给这个核心环节叠加一层新的复杂度。

一个现代、稳健的 MLOps 系统（包括其工具链）本质上是一个异常复杂的“怪兽”。各个组件如何协作、如何交换数据、整体系统架构长什么样，以及无数细枝末节的决策，都需要做出具体选择，而这些选择可能对模型输出与项目整体产生巨大的影响。一个功能完备的系统如果包含数据管理、抽取、标注、版本控制、EDA、模型训练、部署与监控等组件，就会有太多“可动部件”，以至于更难看清全局、也更难诊断系统性缺陷。

在传统组织里，MLOps 困难的另一个原因是：各阶段的专家在工具与沟通方式上彼此共同点很少。例如，数据科学家可能会把工作重点放在通过精细建模与超参数优化来提升目标领域的 precision 与 recall，并用 precision、recall、F1 等指标的提升来沟通结果；而 ML 工程师则可能讨论模型注册表、服务时延，并用部署周转时间、扩缩容以承载客户请求、以及线上推理时延来表达成果。要实现一个成功的 ML 闭环，所有这些贡献者以及外部相关方必须“讲同一种语言”，能够相互理解，才能无缝协作。

优化与扩缩容通常不是多数团队刚启动 ML 项目时的最高优先级，但它们完全可能毁掉模型的可用性：世界上最好的模型，如果无法在生产中工作、或在高负载下崩溃，就没有任何业务价值。即便模型可以被优化，优化后的性能特征也可能与未优化版本截然不同。同样，把模型扩展到能服务成千上万乃至百万级请求，会带来与离线评估或玩具工作负载完全不同的挑战。性能刻画与稳健测试方法很难一次做对，需要非常谨慎的设计与架构。

与真实世界“又脏又乱”的数据接触，是 MLOps 以及 ML 本身会遇到挑战的另一个领域。如果你没有为此做好准备，边界案例与不合规数据会导致失败；最糟糕的情况是，它们会在没有任何明显报错的前提下悄悄扭曲输出。通过稳健的监控策略与强数据校验可以预防这类问题，但边界案例仍可能漏网并造成难以解释的输出。

治理与合规要求往往会强制需要可解释、可解读的 ML。要在落实负责任 AI 实践的同时确保合规，并处理潜在偏差，也是具有挑战性的。

最后，工具生态的碎片化也会让刚开始做正式 ML 的组织感到困惑。比如仅在模型注册表这个主题上，至少就有 10 种方案都声称能解决 AI 面临的问题。真正全面的解决方案很少存在；在我们的经验里，很多方案会聚焦 EDA 与模型部署等核心区域，却可能完全缺失数据管理与谱系（lineage）等关键环节。当前工具生态的思路似乎是：把多个“专精工具”与少量“上层总控方案”组合起来，以满足团队需求。

以上种种（以及更多因素）会让小团队常常跳过稳健的 MLOps 实践，而选择快速把方案堆出来。短期内或单模型场景下这也许能奏效，但长期来看会积累巨量技术债，使模型不可维护。要克服这些挑战，需要投入技术能力、跨职能协作，以及一种有利于持续学习的文化。MLOps 很难，但我们坚信：拥有并落实一套稳健策略，长期一定会在速度、可维护性以及——最重要的——业务价值上带来回报。

2.3 成熟组织中 MLOps 的角色

如你现在所见，对于希望用 ML 改进产品或提供 ML 产品的组织来说，稳健的 MLOps 能带来大量优势。在一个成熟的 ML 组织里，稳健的 MLOps 是高效开发、部署、管理、监控与优化模型的关键使能因素。主要收益包括：

加速创新与实验——具备稳健的 MLOps 基础设施与工具链，意味着数据科学家可以专注于核心专长：为业务问题开发模型并快速迭代。基础设施抽象、便捷的模型版本管理与对比工具（并由代码、配置、模型检查点与数据的强谱系支撑）、以及便于 A/B 测试的配套能力，使数据科学家能更快验证假设、调参，并更迅速响应业务变化。
成本优化——缺乏稳健的中心化 ML 工作流时，团队往往各自搭建孤岛式的开发与基础设施，导致资源利用率不佳与最佳实践碎片化。一个中心化、凝聚的 ML 策略让团队能复用彼此的能力来构建流水线并共享组件，从而更快提升组织内 ML 的可靠性。中心化策略与基础设施也让资源分配更易管理，并支持自动扩缩容与成本监控。
团队间协作——在稳健的 MLOps 策略下，团队可以跨领域协作解决共性挑战与业务问题；通过提升彼此活动的可见性与统一的工作流管理工具，甚至能改善团队内部协作。这一策略也建立了清晰的沟通与协作通道，最大化 ML 项目对组织的价值。
效率提升——MLOps 与 CI/CD 将 ML 生命周期中大量重复任务（如数据挖掘、预处理、特征工程、训练与部署）自动化掉。这意味着步骤更不易受人为错误影响，并且输出与行为更具确定性。数据科学家因此能把精力投入到更高价值的任务上，例如建模与创新。
更好的可重复性与可追溯性——正如我们一开始所说，模型会持续演进与变化。稳健的 MLOps 工作流让这种演进对数据科学家可见，并提供在出现问题时监控、调试与回滚的方法。借助稳健监控，也能应对漂移、模型偏差与回归。最后，强谱系让我们能轻松追溯用于训练某个模型的配置与数据集，并离线调试问题。
稳健扩展能力——MLOps 通过提供通用工作流与优化的资源分配，帮助组织标准化扩缩容与大规模数据处理的挑战，使模型能在生产中表现良好并处理大数据量。

总体而言，一个好的 MLOps 策略与落地会降低“好实践”的门槛。比如，如果模型日志记录已经预先配置好并集成到训练代码库中，数据科学家就会默认使用模型版本管理与日志记录，而不是手工管理训练运行并临时拼凑报告。在成熟组织里，MLOps 把人员、专长、流程与最佳实践串联在一起，让所有组件触手可及，并协同创造业务价值。

2.4 DevOps vs. MLOps

此时大家常见的问题是：为什么 MLOps 会作为一个独立领域存在，而不是 DevOps 的延伸？为解释我们的观点，我们先看二者相似之处：

倡导稳健自动化——二者的驱动目标都是通过自动化与流程简化来提升效率；都旨在自动化重复且易错的步骤，以获得更快的交付速度与更可靠的软件结果。
强调 CI/CD 精神——自动化测试套件与无缝的自动化生产部署，在两者中都很常见。
多学科交叉，常需要能跨多个领域的通才——两种方法都通过共享的工具链与汇报方式，促进项目团队与相关方的紧密协作。

虽然两者有重叠，但 ML 工作流的一些特殊特征让 MLOps 明显不同：

MLOps 主要关注训练、部署、监控与优化 ML 模型带来的挑战；这不同于 DevOps，后者聚焦软件与基础设施的生命周期。
数据是区分 MLOps 与 DevOps 的关键：MLOps 把数据视为模型与流程的核心构件，并将大量工作用于数据生命周期管理；而 DevOps 并不会对数据管理施加同等严谨度。
模型会持续变化与演进，即使代码库没有任何代码变更也可能如此。这使得 MLOps 需要引入持续训练（Continuous Training），并对模型管理与版本控制提出特殊要求。
MLOps 还天然关注模型可解释性与偏差（bias）：它包含监控模型并确保满足约定标准的技术。
在 MLOps 中，监控模型性能至关重要，因为输入数据特征的变化会导致性能劣化。正如 Google 提到的，ML 模型的性能退化方式比传统软件更多。
最后，MLOps 本质上是实验性与迭代性的，因此重要的是跟踪“实验本身”，而不只是一次构建（build）。

如你所见，MLOps 在一些关键方面与经典 DevOps 相当不同。尽管它们共享某些共通原则，但 MLOps 的焦点明确：管理在生产环境中部署与运营 ML 模型所特有的挑战。

2.5 MLOps 成熟度等级

根据 Google 的观点，我们在前面讨论 ML 闭环时提到的那些步骤，其自动化程度是衡量一家公司 MLOps 成熟度的一个很好的指标。这会直接体现为新模型开发的速度，或对变化的适应速度。

2.5.1 Level 0：基础（Basic）

Level 0 是大多数刚踏上 MLOps 旅程的公司所处的起点。它的主要特征是：用手工脚本驱动的流程来构建、训练与部署 ML 模型。在这个阶段，模型没有实现监控，发布迭代也很少，间隔往往很长。

2.5.2 Level 1：中级（Intermediate）

Level 1 的主要特征，是实验速度更快，并且能够在生产中持续再训练模型。Level 0 只部署模型本身；而在 Level 1 中，部署的是一整条再训练流水线，它能把模型持续交付到预测服务中，跟上新数据，并随着时间自动改进。

Level 1 团队的另一个关键点，是拥有模块化的流水线组件，这些组件可以在团队之间自由共享，并支持在开发环境与生产环境使用同一条流水线进行部署——我们称之为实验-运营对称性（experimental-operational symmetry） 。要支撑 Level 1 的活动，需要具备一些重要组件：

稳健的数据与模型验证机制
特征库（如有需要）
流水线监控、谱系（lineage）以及相关元数据
可根据自定义触发器自动触发运行的 ML 流水线

2.5.3 Level 2：高级（Advanced）

最后一个阶段，是把流水线本身的构建与部署也自动化，并让流水线组件成为 ML 闭环的关键组成部分。在这一阶段，除了数据分析与模型分析之外，几乎一切都被自动化。流水线与组件也不再仅由 ML 工程师“拥有”，而是由整个团队/组织共同拥有；基于他们的观察，数据科学家也可以贡献新的组件。

虽然这些等级只是一个粗略的指南，并不代表各阶段之间存在严格的线性难度递增，但理解你或你的工作场所在这条尺度上的位置，会帮助你规划下一步要做什么，从而在内部建立强健的 MLOps 文化并稳步前进。本书后续讨论的工具能够扩展到所有成熟度等级。

在本章中，我们从概念与组织视角探索了 MLOps，以理解它的重要性、挑战，以及它在组织内部如何走向成熟。这些概念将作为我们的基础，带领我们进入更偏动手的内容。

现在我们已经铺好了 MLOps 的理论基础与业务侧脉络，接下来的章节将深入构建一个可扩展的平台来运行 ML 工作负载——从容器化与 Kubernetes 开始。具体来说，在下一章里，我们会通过深入 Kubernetes 来启动 ML 平台的构建：它将作为基础，帮助我们以可扩展、可靠的方式落地这些 MLOps 实践。我们会把已经建立的理论理解，开始转化为可执行的实践实现。

总结

ML 的存在是为了解决业务问题，因此在启动 ML 项目之前，深入理解需求非常重要。
MLOps 是一个迭代过程：开发、监控并改进 ML 模型。
模型是 ML 闭环中的一个产物（artifact），目标是让模型性能随时间提升。
MLOps 困难的原因包括数据管理、复杂工具链、组织架构、扩缩容挑战，以及真实世界的不确定性。
跳过既定的 ML 实践，短期看似更快，但重复劳动与技术债会很快抹平这些收益。
DevOps 与 MLOps 有相似之处，但在数据与模型管理等方面不同，MLOps 也有其独特挑战。
稳健的 MLOps 是一个高度实验性、迭代性的过程，需要组织层面的学习与快速原型来找到适合你和你组织的做法。