6.2 机器学习工程（MLOps）

概述与动机

机器学习工程，通常称为 MLOps，是这样一门学科：把机器学习从笔记本和实验中带出来，带入可靠、可观测、可维护的生产系统。传统软件的行为方式，由其代码所决定。而一个机器学习系统的行为方式，则由其代码、数据以及习得的模型参数三者共同决定。这使得机器学习系统更难测试、更难复现，并且当现实世界逐渐偏离其训练数据时，还容易悄无声息地失效。MLOps 把软件工程的严谨性（版本控制、测试、持续交付和监控），带入了”代码加数据加模型”这一三重现实之中。

对大型团队而言，MLOps 正是把一个在演示中惊艳全场的一次性模型，与一支众多团队能够安全构建、部署和运营的模型舰队区分开来的关键。没有共享的平台和实践，每个团队都会重新发明数据流水线、训练循环和部署方式，最终得到的是六个月后没有人能够复现的脆弱系统。企业依赖 MLOps 在数十个模型间实现规模化，满足服务水平目标，并回应那些追问”某个预测是如何产生的”的审计人员。

在政府和受监管行业中，MLOps 常常是伪装成工程实践的合规要求。可复现性、血缘关系和版本管理，正是让一个机构能够回答一个具有法律意义的问题的关键：究竟是哪个模型，用哪些数据训练，用哪些代码，产生了那个影响到某位公民的决定？一套成熟的 MLOps 实践，能让这个问题在多年之后依然可以被回答，这既是良好的工程实践，也是一道法律保障。

另见： 第 8.1 章（CI/CD 与交付）、第 9.2 章（可观测性与监控），以及第 6.6 章（人工智能基础设施与运营）。

关键原则

把数据、代码和模型当作联合进行版本管理的工件；改变其中任何一个都会改变系统行为。
把从数据到训练好的模型、再到部署的路径自动化，使其可重复、可审计。
让每一个模型都能被追溯到产生它的确切数据、代码和配置。
在部署之前，用具有代表性的、预留的数据评估模型，部署之后也要持续评估。
假设模型会退化；从第一天起就监控漂移（drift，即实时数据或输入，输出关系与模型训练所依据的数据逐渐产生分歧）、数据质量问题和性能衰减。
优先选择乏味但可复现的流水线，而不是聪明却不可复现的实验。
把实验速度和生产可靠性这两种关切分开，并有意识地在两者之间架起桥梁。

建议

显式地管理完整的机器学习生命周期

明确定义并为每个阶段建立监测：数据摄取与验证、特征工程、训练、评估、部署和监控。让各阶段之间的边界明确，使每一个阶段都能被测试、重试和审计。避免那种常见的失败（）模型在一个临时的笔记本中被训练出来，然后被扔过墙交给运维团队。相反，应把整个生命周期包裹在一条经过编排的流水线中，使任何被授权的工程师都能从一份干净的检出（checkout）开始运行它。

使用特征存储、实验跟踪和模型注册表

特征存储（feature store）把特征定义集中管理，使同一套变换逻辑在训练和线上服务中都能运行。这消除了训练，服务偏差（training-serving skew，即特征在训练时与在线上预测时的计算方式不一致），并让团队能够复用特征，而不是重复计算它们。实验跟踪（experiment tracking）记录每一次训练运行的参数、代码版本、数据版本和指标，使结果可比较、可复现。模型注册表（model registry）是已训练模型的记录系统，保存版本、血缘关系、评估结果、审批状态和部署阶段。三者结合，使你能在行为发生变化时回答”发生了什么变化”，并通过受治理的阶段来推广或回滚模型。

让数据和模型可复现，并带有血缘关系的版本管理

对你的数据集进行版本管理，而不仅仅是对代码进行版本管理。使用内容寻址存储或数据版本管理工具，使一次训练运行所引用的是一个不可变的快照。用 git 提交来固定代码，用锁定的依赖项和容器镜像来固定环境。端到端地捕获血缘关系：哪些原始数据产生了哪些特征，哪些特征和代码产生了哪个模型，以及该模型部署在哪里。当事件或审计发生时，血缘关系能把一场法证噩梦变成一次简单的查询。在结果依赖于随机性的地方，记录随机种子和硬件信息。

选择与工作负载相匹配的部署模式

批处理（batch）评分按计划在大型数据集上运行；运营最简单，能容忍延迟，适合报表和周期性决策。
在线（实时）（online）服务在严格的延迟预算内响应单个请求；需要低延迟的特征检索和细致的容量规划。
流式（streaming）随着事件到达持续进行评分；适用于新鲜度至关重要的欺诈检测和监控场景。
边缘（edge）出于延迟、隐私、连接性或数据主权方面的原因，在设备或本地硬件上运行模型，在政府和现场作业场景中很常见。

选择满足需求的最简单模式，并用影子部署（shadow deployment）、金丝雀发布（canary）和即时回滚来设计你的上线方案。

监控漂移、退化和数据质量

在生产环境中为输入和输出建立监测。关注数据漂移（data drift，输入分布发生偏移）、概念漂移（输入与目标之间的关系发生变化）、数据质量故障（空值、模式变化、上游数据源损坏），以及在有条件的情况下对照延迟到达的真实标签所衡量的性能退化。设定告警阈值，编写操作手册，并把监控与你的重新训练触发条件接通。悄无声息的性能退化是机器学习系统经典的失效模式，监控是你抵御它的唯一防线。

权衡：优点与缺点

决策	选项 A	选项 B	权衡
服务模式	批处理	在线	简单性和成本，相对于新鲜度和延迟
特征计算	特征存储	按模型各自的流水线	一致性和复用，相对于搭建开销
平台	购买托管的 MLOps 平台	自行组装开源工具	速度和支持，相对于灵活性和锁定风险
重新训练	按计划进行	由漂移触发	可预测性，相对于响应速度和复杂性
可复现性的严谨程度	完整数据版本管理	轻量级跟踪	审计强度，相对于存储和工作量

总体的权衡在于现在的投入与日后的脆弱之间。重量级的可复现性和监控基础设施在前期需要投入精力，但它们能防止那种代价远为高昂的问题：无法解释的失败、无法复现的模型，以及被侵蚀的信任。托管平台能加快团队的速度，但可能造成锁定；开源技术栈能带来控制力，但代价是集成工作量。大型组织通常能从一个共享平台团队中获益，由后者把这种复杂性隐藏在铺好的标准化默认设置背后。

与团队讨论的问题

在客户或公民受到伤害之前，我们要如何得知一个已部署的模型已经悄悄退化了？这个告警由谁负责？ 悄无声息的衰退是机器学习经典的失效模式：代码依然在运行，模型依然自信地返回评分，而质量却随着现实世界偏离训练数据而滑坡。对于运营着众多模型的大型团队而言，这个问题需要按模型逐一回答，而不是为整支舰队回答一次，因为每个模型都有自己的漂移特征和自己的真实标签延迟。带上你目前针对数据漂移、概念漂移和数据质量故障的监控器、告警阈值，以及说明谁来响应的操作手册。在真实标签要延迟数周才到达的受监管场景中，讨论一下与此同时你可以观察哪些代理信号，因为等待延迟到达的真实标签，就意味着等待去发现伤害已经发生。如果一个模型的漂移告警没有指定唯一的负责人，那么这个模型实际上就处于无人监控的状态。
如果一位审计人员要求我们复现十八个月前的某个具体预测，我们能否真正端到端地做到？ 可复现性正是隐藏在良好工程实践之中的合规要求：它让一个机构能够准确回答，究竟是哪个模型、用哪些数据训练、用哪些代码，产生了那个影响到某人的决定。带上一个真实的例子，尝试去追溯它：不可变的数据快照、git 提交、锁定的依赖项和容器镜像、记录下来的随机种子，以及从原始数据经过特征到已部署模型的完整血缘链条。关键信号在于这条链条中是否有任何一环缺失或依赖人工操作。对政府和受监管行业而言，要确定法律实际要求的保留期限，并确认你的存储方案能在整个时间窗口内保持血缘关系可回答，因为一个缺口会把一次例行查询变成一场法证紧急事件。
我们把模型推广到生产环境、以及回滚模型的规则是什么？它是由注册表强制执行的，还是仅仅依靠信任？ 不受治理的推广，正是笔记本实验渗漏进生产环境的方式，也是一个糟糕的模型因为无人能够干净地回退它而滞留下来的方式。对许多团队而言，成熟与脆弱之间的差别，就在于模型注册表是否用强制性的审批和评估来把关推广流程，还是一名工程师能够手动推送权重。带上你目前的推广路径、你的回滚机制，以及影子部署或金丝雀发布确实在全流量之前运行过的证据。讨论一下重新训练是按计划进行还是由漂移触发，以及重新训练出来的模型在部署前是否通过了验证关卡，因为在没有验证的情况下对实时数据进行自动重新训练，会放大漂移或数据投毒的风险。这个答案应当由平台强制执行，而不是写在一份靠大家自觉遵守的维基页面上。
我们的 MLOps 平台是基于开源工具自建，还是购买托管平台，还是两者混合？谁权衡过锁定的风险？ 这个选择决定了未来每一个模型能够以多快的速度上线，以及你对自己的数据和流水线保留多少控制权。一个托管平台能让团队快速走向生产环境并附带支持，但也可能把你的特征定义、血缘记录和模型工件困在一种你难以轻易脱身的专有格式中；一套自行组装的开源技术栈能让你保持可移植性，代价是真实的集成和维护工作量。带上每条路径的总拥有成本（授权费或自建成本、存储、用于重新训练的算力，以及运营平台所需的人手）、对团队运营基础设施能力的诚实评估，以及一个具体的退出测试：你能否导出你的注册表、特征存储和血缘记录，并在别处重建？在企业和政府场景中，还要加上采购约束和数据主权规则，因为一个把训练数据存放在你的监管机构所禁止的地区或格式中的平台，无论多么方便，都会被直接淘汰。
我们的特征存储和模型注册表，应该是一个集中式平台，还是按团队联邦化？训练，服务偏差今天让我们付出了什么代价？ 集中特征定义能消除偏差，，即某个特征在训练时用一种方式计算、在服务时用另一种方式计算，，这是一个悄无声息、代价高昂的准确度损失来源，但单一平台也可能成为拖慢每一个团队的瓶颈。联邦化能给团队自主权，但也会成倍增加管道数量，以及两个团队对同一个特征定义不一致的可能性。带上偏差曾经在哪里给你造成过损害的证据、有多少团队在复用特征而不是重新构建，以及一个共享平台团队可以提供哪些铺好的标准化默认设置。对大型组织而言，要权衡一个可审计的记录系统所带来的治理收益，相对于一个中央队列所带来的交付成本，并且在受监管场景中，应优先选择集中式的血缘关系，使审计人员能够把任何一次预测追溯到产生它的确切特征代码。
我们是否让每个模型的部署模式与其真实的延迟、新鲜度和主权需求相匹配，还是把一切都默认为同一种形态？ 批处理、在线、流式和边缘各自带有截然不同的运营成本和复杂性，选错模式要么在一份夜间报表从未需要的实时基础设施上超支，要么让一个欺诈评分器缺乏它所依赖的新鲜度。按每个工作负载来决定需求究竟能证明哪种模式是合理的，并抵制仅仅因为感觉更现代就统一采用最复杂选项的冲动。带上每个模型的延迟预算、数据量、过时答案的代价，以及真实标签的延迟情况。在政府和现场作业场景中，要审慎权衡边缘和本地部署，因为数据主权规则或间歇性的连接性，可能迫使模型运行在本地硬件上，而这个选择会重塑你对推送到那里的每一个模型进行版本管理、监控和回滚的方式。

行业视角

初创企业。 你最稀缺的资源是工程注意力，因此应保持 MLOps 轻量化，并直接购买现成方案。在一个简单的托管工具中跟踪实验，把每个已部署模型固定到其训练数据快照和 git 代码提交上，再增加一项廉价的漂移检查，而不是搭建一个完整平台。跳过特征存储和定制流水线，直到第二个或第三个模型让复用真正值得投入之前都不必考虑；一个你无力维护的脆弱技术栈，会比缺失某项能力更快地拖垮你。

小型企业。 你很可能没有机器学习平台专家，预算也很紧张，因此应把 MLOps 当作嵌入在你已经使用的工具中的东西，而不是一个需要专人配备的系统。优先选择能为你处理版本管理、部署和监控的托管服务，并把这门学科当作一个数据卫生和可复现性问题来对待：清楚知道是哪个模型和数据产生了某个结果，并保留回滚的能力。优先选择那些允许你导出数据和模型的供应商，这样日后更换供应商依然可行。

企业。 问题在于跨数十个模型和众多团队的规模化：一个共享的特征存储、实验跟踪，以及一个带有受治理推广流程的模型注册表，使各团队停止重复发明流水线。为一个提供铺好标准化默认设置的平台团队编列预算，把血缘关系和监控标准化，使每一个模型都可审计、每一次事件都可解释，并在一个能让底层工具可替换的接口背后，审慎地管理自建与购买的决策以及锁定风险。在平台层面强制执行验证关卡和回滚机制，而不是靠约定俗成。

政府。 可复现性、血缘关系和版本管理是伪装成工程实践的合规要求，因此应从第一天起就把它们当作头等大事对待。为每一个已部署模型背后确切的数据集和代码进行版本管理，把这份血缘关系保留法律要求的期限，并能够复现任何一次影响到公民的历史预测。让一个人来审阅重大决策，在数据主权规则要求的地方审慎权衡边缘和本地部署，并要求任何供应商平台都赋予你对自己的数据、特征和血缘记录完全的可移植性。

示例

初创企业。 一家小型分析初创企业，由一名数据科学家采用轻量化设置，交付了它的第一个流失预测模型。它在一个简单的托管工具中跟踪实验，把每一个已部署模型固定到其训练数据快照和 git 代码提交上，并增加了一个基础的每周任务，把近期输入与训练分布进行比较。当某个数据源改变了日期格式、预测开始出现漂移时，这个简单的检查在几天之内就发现了问题，而不是等到愤怒的客户来电之后，团队也得以复现上一个良好的模型并进行回滚。

企业。 一家零售银行运营着数十个信贷和反欺诈模型。它统一采用了一个跨团队共享的特征存储、一项实验跟踪服务，以及一个带有强制审批关卡的模型注册表。生产环境中的每一个模型，都能追溯回其训练数据快照和代码提交。反欺诈模型以流式评分器的形式部署；信贷模型则以批处理方式运行。一个监控层持续关注输入漂移，并在数据源模式发生变化时发出告警（）曾有一次，正是它在一个损坏的上游数据流破坏决策结果之前捕获了问题。

政府。 一个公共福利机构使用一个机器学习模型来为案件审查排定优先级。由于这些决定会影响公民获取服务的权利，该机构为每一个已部署模型背后确切的数据集和代码进行版本管理，把这份血缘关系保留法律要求的期限，并能够按需复现任何一次历史预测。模型以批处理方式部署，由人工审阅被标记的案件，一个漂移监控器会在流入人群发生变化时强制启动一次强制性的重新评估，因此该模型永远不会在其验证条件之外被悄悄使用。

商业论证：动机、投资回报率与总拥有成本

MLOps 通过把脆弱的实验转变为可靠的资产来实现自我回本。投资回报率（ROI）来自更快的模型投产时间、更少代价高昂的事件、更少重复的基础设施，以及用一个小型平台团队运营众多模型的能力。一个共享的特征存储和注册表，能大幅缩短每个模型的交付时间，因为各团队不再重复搭建同样的管道。

总拥有成本（TCO）涵盖平台的构建或授权费用、已版本化数据和模型的存储、用于重新训练的算力，以及运营这一切所需的人员。要把这些成本，与不采纳 MLOps 的代价进行权衡：无法复现或审计的模型、伤害客户或公民的悄然失败，以及监管方面的问题发现。在受监管场景中，一次审计中出现的无法解释的模型，其代价可能远远超过整个 MLOps 投资。向领导层论证时，应把 MLOps 构建为一种风险降低和交付加速的手段，而不是额外开销：它是一条未来每一个模型都会走上的铺好标准化道路。

反模式与陷阱

从笔记本直接跳到生产环境。 部署在不受治理的笔记本中训练出来、毫无可复现性的模型。
训练，服务偏差。 训练时和服务时使用不同的特征代码，造成悄无声息的准确度损失。
没有数据版本管理。 只对代码进行版本管理，而不对数据进行版本管理，导致运行无法复现。
部署后不管不顾。 交付一个没有任何监控的模型，直到用户投诉才发现性能退化。
自动驾驶式的重新训练。 在没有验证的情况下自动对实时数据进行重新训练，放大了漂移或投毒风险。
一次性基础设施。 每个团队都构建自己的流水线，成倍增加成本和脆弱性。
忽视延迟到达的标签。 假设当真实标签数周后才到达时，你依然能够即时衡量准确度。

成熟度模型

启动。 模型在笔记本中临时构建；手动部署；数据或模型都没有版本管理；没有监控；复现过去的某次预测全靠猜测。
发展。 出现了一些实验跟踪和一个模型注册表，但实践因团队而异；部署是半自动化的；基础监控覆盖少数模型；数据版本管理不完整，血缘关系存在缺口。
标准化。 一个带有特征存储、注册表、可复现流水线和端到端血缘关系的共享平台，被形成文档并在全组织范围内强制执行；针对漂移和数据质量的监控在所有模型间运行；推广和回滚遵循一条每个团队都使用的受治理路径。
管理。 整支模型舰队被对照基准进行衡量：漂移率、数据质量故障、对照延迟到达的真实标签所衡量的模型准确度、训练，服务偏差、投产时间，以及每个模型的运营成本，都作为指标被跟踪；告警阈值和验证关卡基于证据被强制执行，每个模型的健康状况按固定节奏被评审，并有指定的负责人。
编排。 生命周期完全自动化、可审计、可自适应；由漂移触发的重新训练在验证关卡之后运行；自助式的铺好标准化道路让团队能够安全交付；持续评估把模型性能与业务指标联系起来，平台与交付、风险和合规整合在一起，使模型能够随着数据和条件的变化而例行性地被淘汰、替换和重新界定范围。

讨论议题

你如何在实验自由和生产可复现性之间取得平衡？
对你的使用场景而言，正确的重新训练触发条件（按计划、由漂移触发，还是由性能衰减触发）是什么？
你必须保留数据和模型血缘关系多长时间？是什么决定了这个要求？
特征存储和注册表应该是集中式平台，还是按团队联邦化？
当真实标签要经过长时间延迟才到达时，你如何监控准确度？
边缘部署在什么情况下才值得其额外的运营复杂性？

关键要点

机器学习的行为来自代码加数据加模型；应把三者一起进行版本管理和治理。
特征存储、实验跟踪和注册表，是可复现机器学习的支柱。
血缘关系让模型可审计、让事件可解释：这在受监管场景中至关重要。
根据延迟、新鲜度和主权需求，选择批处理、在线、流式或边缘部署方式。
模型会退化；对漂移、数据质量和衰减进行监控，不是可选项。

参考文献与延伸阅读

Chip Huyen, Designing Machine Learning Systems.
Andriy Burkov, Machine Learning Engineering.
D. Sculley et al., Hidden Technical Debt in Machine Learning Systems.
Mark Treveil et al., Introducing MLOps.
Valliappa Lakshmanan, Sara Robinson, and Michael Munn, Machine Learning Design Patterns.
Emmanuel Ameisen, Building Machine Learning Powered Applications.