本章将涵盖：
- 理解生产环境中的机器学习（ML）系统
- 从实验到部署的完整 ML 生命周期
- 构建生产级 ML 工程所需的关键技能
- 搭建你的第一个 ML 平台
- 真实世界 ML 项目的架构
你准备好自信地构建生产级机器学习（ML）系统了吗？本书将把你培养成一名自信的 ML 工程师——能够成功把 ML 项目从构思一路护送到生产落地的人。通过动手示例与真实场景，你将学到以下内容：
- 如何设计并实现在生产中可用的可靠 ML 系统
- 完整的 ML 生命周期：从问题定义到监控
- 构建稳健 ML 流水线与服务的核心模式
- 企业真正需要的实用 MLOps 技能
- 在规模化场景下维护 ML 系统的真实技术手段
无论你是希望自信部署模型的数据科学家、转向 ML 的软件工程师，还是想提升生产能力的 ML 工程师，本书都会提供你在真实世界 ML 系统中取得成功所需的实践知识。我们不会用大量理论把你淹没，而是采取务实的方法。
每一章都会在上一章基础上推进，并在需要时引入新的概念与工具。我们在本书中的旅程遵循清晰的推进路径，将完成以下目标：
- 夯实 MLOps 与可靠系统设计的基础
- 搭建我们的 ML 平台，并学习如何编排 ML 流水线
- 深入数据准备、模型训练与验证
- 掌握模型服务、监控与可解释性
- 了解如何构建现代 LLM 流水线
为了让这段旅程更具体，我们将走完两个受我们曾构建的生产系统启发的真实项目。尽管你的具体 ML 项目可能不同，但你将学到的模式、实践与技能可以跨领域复用。
最重要的是，你将获得信心，应对任何迎面而来的 ML 工程挑战。让我们从理解 ML 生命周期开始——这将作为框架，引导我们构建生产级 ML 系统。
1.1 ML 生命周期
虽然不同 ML 项目各不相同，但开发与部署 ML 模型的步骤在很大程度上是相似的。与通常更强调稳定性的传统软件项目相比，ML 项目往往更具迭代性。我们至今还没见过哪个 ML 项目第一次上线就算结束。
1.1.1 实验阶段
大多数 ML 项目都会经历一系列持续实验，包含大量试错。之所以需要反复实验，是因为要找到正确的方法，必须理解复杂数据，并不断调整模型，才能有效应对真实世界的挑战。图 1.1 展示了 ML 生命周期中这一实验部分的典型工作流。虽然图中的箭头指向单一方向，但几乎每一步都在反复迭代。比如，你可能处在模型训练与模型评估之间：如果评估指标不达标，你可能会考虑换一种模型结构，甚至更早回退去检查是否拥有足够的高质量数据。
图 1.1 ML 生命周期的实验阶段
注意，这些步骤中的每一步都可能相当复杂，而且它们之间的流转往往不是线性的，中间会出现回路（例如，在进行模型训练后发现底层数据集存在问题，回到数据准备阶段并不罕见）。因此，这些步骤通常会被组装成一条由编排器驱动的流水线（你将在后续章节学习如何实现）。从一开始就拥有一条被编排的流水线，可以把自动化内建进去，让你不必手工操作，从而避免那些难以追踪的潜在错误。当我们在 1.2 节进入开发/预发/生产阶段时，我们将把整条流水线彻底自动化。
问题定义（PROBLEM FORMULATION）
在任何潜在 ML 项目中，你首先应该问的问题是：这件事真的需要用 ML 吗？有时候简单启发式规则就够了——再诱人也要克制住去挥舞那把“传说中的 ML 大锤”。另一方面，虽然简单规则能提供高效方案，但当你面对复杂的高维数据、其中模式精细且非线性时，ML 就会变得必要，因为它需要更复杂的方法才能做出准确分析与预测。
因此，如果团队（由业务/产品与技术人员组成）深思熟虑后决定采用 ML 模型，那么第一步就是明确模型要解决什么问题。比如，光学字符识别（OCR）模型可以从身份证件中提取证件号码。用于反欺诈时，OCR 能帮助你及时识别欺诈交易，同时尽量降低误报。
数据收集与准备（DATA COLLECTION AND PREPARATION）
接下来，你需要确定数据从哪里来，因为训练与评估模型都离不开数据。以 OCR 为例，你需要有效身份证件的图像。（在我们的案例中，数据集包含来自不同国家的几种证件，因为我们的问题聚焦于在给定图片中找到身份证件。）如果真实数据难以获得，你甚至可以考虑生成合成数据。收集到足够的训练数据后——这取决于多个因素，例如问题领域、模型微调的基础、等等——你需要为它们打标并添加注释。
在 OCR 示例里，这意味着让标注人员在你关心的区域（也就是证件号码）画出边界框，然后再手工录入证件号码。如果你觉得这很费力——确实如此！在反欺诈场景中，这可能不仅包括在客户投诉时把交易标为欺诈，还需要领域专家对当前数据集进行梳理；甚至可能需要在领域专家帮助下构造合成数据。读取完标注数据后，还需要把数据组织成训练集、验证集与测试集。
数据版本管理（DATA VERSIONING）
ML 项目同时包含数据与代码。改变代码会改变软件行为；在 ML 中，改变数据同样会改变系统行为。数据版本管理让结果可复现：你希望在同样的数据与代码下，能够 100% 确认模型表现符合预期。
代码用版本控制管理很直接；而数据版本管理则完全是另一种“野兽”。数据形式多样（图片、CSV、pandas 数据帧等），而 ML 社区至今还没有一个像 Git 那样通用、无处不在的工具。
模型训练（MODEL TRAINING）
模型训练就是给 ML 模型喂入大量数据的过程。随着训练推进，模型参数（或权重）会被调整，以最小化模型预测值与真实值之间的误差。
一旦工程师定义好数据集与训练策略，训练过程就可以自动化。从一开始就做自动化，意味着数据科学家可以一次性启动多个实验；自动化也能保证实验可复现，因为参数与产物（训练好的模型、数据等）都会被跟踪。很多 ML 新手以为训练占据了大部分时间，但在我们的经验里，恰恰相反。尽管本书重点不在训练本身，我们仍会在项目推进过程中训练一些很有意思的模型。
模型评估（MODEL EVALUATION）
在模型训练过程中，作为健全性检查，你会希望用一个不属于训练集的数据集来评估模型表现。这能合理衡量模型在未见数据上的表现（当然也有前提与限制）。评估可使用多种指标，包括精确率（precision）、召回率（recall）、曲线下面积（AUC）等。
模型验证（MODEL VALIDATION）
如果模型通过了评估，下一步是确保模型表现符合预期。很多时候，这意味着验证由业务方来执行，而他们可能不同于构建模型的团队。
1.1.2 开发/预发/生产阶段
区分实验阶段与生产阶段至关重要，因为这标志着从探索与打磨模型，切换到把模型部署到真实世界并持续运行。理解这种转变很关键：实验可能永远不会“真正结束”，但关注点会从纯探索转向在生产环境中维护并持续改进模型表现。在这一阶段，伦理约束、安全、可扩展性、鲁棒性与实时性能等因素会变得至关重要。认识到这一点，有助于拆分两类阶段所需的职责与资源，确保 ML 模型能够顺利上线并稳定维护。
尽管此时我们已经有了一个可用的模型，但还有很多工作要做！首先，我们还没有部署模型。在我们继续往下之前，图 1.2 展示了这一阶段的样子。
图 1.2 ML 生命周期的开发/预发/生产阶段
乍一看，它与前面图 1.1 相似：数据版本管理、模型训练、模型评估、模型验证在两张图中都出现了。在实验阶段，你会有一条或多或少已自动化的编排流水线；而在这一阶段，你会把它变成完全自动化。
触发器可以来自持续集成（CI）或某种程序化调用，从而启动流水线依次执行各步骤。这里新增的一点是：流水线末尾出现了模型部署（见图 1.2）。这一步的输出通常是一个已部署的 ML 服务，常见形式是 REST API。很多时候，你还希望建立某种性能监控。在更复杂的用例中，如果性能指标跌破某个阈值，触发器会再次触发，整个流程重新跑一遍。
模型部署（MODEL DEPLOYMENT）
一旦你拥有了一个表现足够好的训练模型，下一步自然是部署它，让客户开始使用。在一些组织里，这一步会把工作交接给 IT 或 DevOps/MLOps；但我们也看到，让数据科学家参与部署能带来很多收益。
最简单的部署方式之一，是加一个执行模型推理的 REST API。下一步是用 Docker 等进行容器化，然后部署到 Amazon Web Services（AWS）或 Google Cloud Platform（GCP）等云平台上。但部署并不意味着任务完成。你还需要做压测，确保服务能承受预期负载；也可能需要考虑自动扩缩容，以应对突发的流量峰值。每次模型部署也都需要版本化，并且要具备在出问题时回滚的策略。
模型监控（MODEL MONITORING）
ML 模型往往经不起“第一次接触”。当模型进入生产、遇到实时数据时，它通常不会像在评估阶段那样表现良好，因此你需要机制来衡量模型上线后的表现。需要监控两大类性能指标：系统/运行指标与 ML 特定指标；它们衡量诸如每秒请求数（RPS）、HTTP 状态码统计等。对 ML 项目而言，监测数据漂移与模型漂移同样重要，因为如果放任不管，它们会显著拉低模型表现；此外还要监控关键业务指标，用于衡量模型带来的价值，例如客户流失率与留存率。
模型再训练（MODEL RETRAINING）
即便是最稳健的模型，也可能需要不时再训练。那么，如何判断模型应该再训练？和许多复杂问题一样——取决于具体情况。
当模型需要再训练时，应尽可能自动化。如果你在训练阶段已经自动化了流水线，那你已经有了很好的基础，但还不够。你还需要把模型部署也自动化：这样当新模型训练完成后，也能自动部署上线。模型再训练可以通过固定周期触发（例如每月一次），也可以在满足某些阈值时触发（例如贷款审批通过数量突然大幅下降）。
1.2 MLOps 所需技能
要作为一名 ML 工程师建立起自信，需要掌握跨不同领域的一组技能组合。虽然一开始这可能显得令人生畏，但请记住：你不需要从第一天起就样样精通。重要的是理解这些技能如何彼此配合，从而构建可靠的 ML 系统（见图 1.3）。在本书中，我们会通过真实示例带你走一遍，展示每个领域如何成功落地应用。
图 1.3 MLOps 是不同技能集的混合体。
1.2.1 ML 工程师的必备技能
你需要带着哪些“入场技能”来？最核心的一点是：你必须是一名合格的软件工程师，并且成功部署过一系列不简单的、非玩具级的软件系统——从移动应用到企业级系统都算。你必须擅长调试（因为事情几乎一定会出错！），并知道如何识别性能短板并修复它们。
下一个前置条件是理解 ML 与数据科学。具体到不同组织会有差异，但作为 ML 工程师，你不需要成为 ML 算法专家，也不必精通诸如反向传播的各种细枝末节。然而，你必须能熟练使用常见的 ML 框架（如 TensorFlow / PyTorch / scikit-learn），并且在需要上手新的、陌生的框架时不怵。
会训练 ML 模型是一回事，理解 ML 生命周期并真正体会其中的复杂性与挑战则是另一回事。大多数 ML 从业者都会同意：与数据相关的挑战往往最棘手，其中最典型的是获取数量足够、质量过关的训练数据。这就需要一定程度的数据工程能力。
MLOps 的很大一部分是自动化。自动化能减少错误、支持更快迭代，从而带来更快的反馈。另外，实验可复现性非常重要，它能确保你的模型在开发/预发/生产环境中表现一致；而当你的 ML 模型需要满足监管合规与审计要求时，可复现性就变得至关重要。归根结底，可复现的结果会带来信任。ML 工程师通常还会被期待掌握或快速补齐更多技能，但以上是一个很好的起点。
1.2.2 前置准备
如果你读到这里觉得压力山大，我们完全理解——这正是我们写这本书的原因！就像那句著名的“吃大象”比喻一样，处理复杂度的最佳方式，是一次啃下一小块。你遇到的问题往往可以拆成可管理的小问题。换句话说：这些技能并不是要你一口气全部掌握，你也不需要什么都懂。
为了让你能跟上后续章节，我们会先带你过一遍 Kubernetes 的最基础内容。这些技能会帮助你搭建自己的 ML 平台，从而在其之上构建 ML 系统（如果你已经熟悉 Kubernetes，可以快速浏览甚至跳过 1.3 节）。之后，我们会带你快速巡礼一圈 MLOps 工具。这些信息对希望快速上手、又不想被不必要细节拖慢的数据科学家尤其有价值。
1.3 搭建一个 ML 平台
一个设计良好的 ML 平台，是你自信开发与部署 ML 服务的关键。你可以把它当作构建可靠 ML 系统的地基——它提供完成 ML 生命周期各关键环节所需的工具与基础设施。虽然 ML 平台由多个组件构成，但别因此被吓到：我们会一步一步搭起来，在推进过程中理解每一块拼图。
图 1.4 给出了一个 ML 平台架构示例。你现有的其他数据系统——数据仓库/数据湖、批/流处理器、各种数据源等——都位于虚线边界之外。它们并非 ML 平台特有，我们不会深入太多细节；不过我们会稍微涉及数据处理器（如 Spark 和 Flink），因为它们处在 ML 平台的外围边界上。
图 1.4 ML 搭建的“心智地图”：从规划到部署的项目流，以及过程中常用的工具
虚线之内，才是“好玩的地方”。在本书中，你将学习如何从零开始搭建一个 ML 平台。首先，你会搭建 Kubeflow——一个运行在 Kubernetes 之上的开源 ML 平台。Kubeflow 的核心组件之一是 Kubeflow Pipelines，它提供流水线编排能力。我们会在全书中持续使用这张心智地图，并标出我们正在操作的组件。随着章节推进，我们会聚焦图 1.4 中不同的模块：基础设施组件用字母标记，数据组件用数字标记。标记的顺序既对应本书引入组件的自然顺序，也对应流水线里数据流转的常见顺序。
如果你觉得这太多太杂也别担心！我们会带你完成 Kubeflow 的安装，然后逐步介绍它的各项能力——先从 Jupyter Notebooks 开始，再到 Kubeflow Pipelines。接着你会学习如何把 ML 平台“长出来”：由具体用例驱动，在 Kubeflow 不足之处进行扩展。比如，Kubeflow 并不自带 feature store（特征库）——这是一类关键软件，用于存储经过治理的特征，服务于训练与在线推理。
没有“一刀切”的 ML 平台架构！
尽管我们在各自组织中成功使用了本书贯穿的这套 ML 平台架构，但它绝不是放之四海而皆准的答案！本书采取的路线是：让你的 ML 平台以增量方式成长——我们也强烈建议你在开启 ML 工程师旅程时这么做，尤其当你要从零开始搭建平台。等你跟着本书把 ML 平台完整搭过一遍、并逐步通过集成开源库把它扩展起来后，你会处在一个更好的位置，去构建真正适配你团队与组织需求的 ML 平台。
1.3.1 自建还是采购（Build vs. buy）
如果你所在组织已经选定了某家厂商的 ML 平台，比如 Amazon SageMaker（AWS）或 Vertex AI（GCP），你可能会问：还需要经历从头搭平台的痛苦吗？听我们说完：我们认为至少有一次从零搭建 ML 平台的经历非常有价值——你会在本书各章中逐步扩展平台，并把它与各种开源库集成。学会如何组装一个 ML 平台，并按自身需求定制，是一项非常重要、但在别处很少被系统讲清的能力。
完成这套练习后，你会更深入理解 ML 平台中的各类工具如何协同工作，也会学会在遇到限制时如何绕开与补齐。
1.3.2 展望：从 MLOps 到 LLMOps
前面图 1.4 的 ML 平台架构代表了传统 ML 系统的基础。正如你将在第 12 和第 13 章看到的那样，这个基础可以通过增加文档处理、检索与专门监控等组件，自然扩展到支持大语言模型（LLM）。
图 1.5 预览了这种演进：传统 MLOps 组件（左侧点线框）仍然必不可少，而 LLMOps 的扩展（右侧更大的虚线框）会增加诸如用于语义搜索的向量数据库、用于 LLM 安全的专用护栏，以及成本优化与提示词管理工具等能力。
图 1.5 左：传统 MLOps；右：加入 LLMOps 扩展后的生产级 LLM 系统。第 12、13 章将深入这些扩展。
现在，我们先专注于打基础：构建底层 ML 平台。你在这里练到的能力——流水线编排、模型部署、监控——会在后续扩展到 LLMOps 时直接复用。
关于工具选择的一点说明（A WORD ABOUT TOOL CHOICES）
开发者通常对工具选择有很强的偏好，而 ML 领域更是选择多到不缺“争论空间”。我们推荐的工具不是终局答案，而是起点。我们鼓励你做实验：用几天时间做个 PoC，看看某个工具是否适合你的需求。早期实验往往能提前暴露限制，否则这些限制可能会在后期变成“致命问题”。
即便在本书里，我们也会为同一目标使用不同工具（例如处理数据漂移），并根据具体用例选择更合适的那一个。我们的建议倾向于社区支持强、在生产中验证过的开源工具。当然，我们也不得不在某些地方做定制——这就是 ML 工程师工作的常态。
1.3.3 本书使用的工具
说 MLOps 工具生态“被工具淹没”一点也不夸张。我们选择了相对更稳定、并且在实践中最成功的方案。你的体验可能会不同，但它们能作为不错的起点。下面各小节会简要介绍你在项目过程中会遇到的主要工具。我们会在后续章节详细展开，但先有个全局概览会很有帮助。
ML 流水线自动化（ML PIPELINE AUTOMATION）
要实现 MLOps 生命周期，你需要 ML 流水线自动化工具，把各阶段“粘”在一起。对于本书，我们会使用 Kubeflow Pipelines——它在我们的经验中工作得很好，但你也可能找到更适合你的其他选择。在 Kubeflow Pipelines 中，ML 生命周期的每个阶段都对应一个流水线组件。每个组件可以从上游组件接收数据，并在完成任务后把数据传递给下游组件（见图 1.6）。
图 1.6 在 Kubeflow 中执行的一条自动化流水线
特征库（FEATURE STORE）
特征库已经成为 ML 平台不可或缺的一部分。特征库的核心价值之一，是让数据科学家与数据分析师共享特征，避免浪费时间重复造轮子。这些特征既可用于模型训练，也可用于在线服务。我们会在第二个项目（处理表格数据）中使用 Feast——一个开源特征库。
特征库通常在数据收集与准备阶段发挥作用。图 1.7 展示了特征库如何接收已经被转换后的数据：这些转换可以是简单的数据操作，也可以是需要跨多个来源、多次 join 的复杂加工。转换后的数据会被摄取进特征库。在底层，大多数特征库都包含以下组件：
- 特征服务（Feature server）：通过 REST 甚至 gRPC 对外提供特征
- 特征注册表（Feature registry）：对可用特征进行目录化管理
- 特征存储（Feature storage）：作为特征持久化层
图 1.7 特征库以转换后的数据（特征）为输入，并提供存储、编目与服务能力。
特征库通常以两种模式提供特征：离线（offline）——主要用于模型训练/批量推理；在线（online）——用于实时推理。此外，特征库同时支持离线与在线还有一个重大收益：防止训练-服务偏差（training-serving skew）。这种现象指训练阶段与推理阶段看到的数据不一致而导致性能偏移。它怎么发生？一个常见原因是：训练时的数据转换与线上推理时做的转换不一致。这非常容易被忽略，但特征库能很好地解决这个痛点。我们会在后续章节更深入探讨特征库，并教你如何在 ML 项目中用好它。
模型注册表（MODEL REGISTRY）
一次模型训练的输出不仅包括训练好的模型，还包括图表图片、元数据、训练使用的超参数等各种产物。为了可复现性，每次训练都需要捕获上述信息（见 1.1.1）。我们会使用 MLflow——一个覆盖 ML 全生命周期的平台——来跟踪实验，并管理我们的模型注册表。
模型注册表的一个用例，是把模型从预发（staging）提升到生产（production）。你甚至可以配置成：ML 服务直接从模型注册表中拉取并服务对应版本的模型（见图 1.8）。当我们进入各项目章节并深入时，会系统展开模型注册表。
图 1.8 模型注册表捕获元数据、参数、产物与模型本身，并对外暴露模型端点。
模型部署（MODEL DEPLOYMENT）
模型部署指把模型集成进一个（可能是开发/预发/生产）环境，让它能接收输入并返回输出。本质上，部署让你的模型对他人可用、可被消费。
模型部署非常“工程导向”。你要考虑可移植性（通常通过容器化解决）、可扩展性（Kubernetes 可通过多副本扩展 ML 服务）、性能（判断是否需要 GPU/更强 CPU/更多内存）以及可靠性。理想情况下，你会尽可能通过 CI/CD 把它自动化。例如，每次代码变更，都希望 CI/CD 自动构建并部署一个新的 ML 模型（见图 1.9）。
图 1.9 模型部署由镜像仓库、CI/CD 与自动化协同完成，用于部署 ML 服务。
该图展示了如何建立自动化模型部署：CI/CD 触发后自动构建 ML 服务的 Docker 镜像并推送到镜像仓库；随后生成引用该镜像的 Kubernetes 部署清单（manifest）；应用这些清单后，就会部署更新后的 ML 服务。当然，我们在这里省略了不少细节——等到各项目的模型部署章节时，你会看到这些组件如何真正拼起来并跑通。
1.4 构建 ML 系统
在一个扎实的 ML 平台作为基础之后，我们已经准备好自信地应对真实世界的 ML 项目了。我们将展示两类不同的 ML 系统，它们体现了你在生产环境中会遇到的不同挑战：一个处理图像，另一个处理表格数据。这些项目将帮助你建立处理多样化 ML 挑战的信心，同时强化那些让 ML 系统可靠的模式与实践。
这些项目未必与你所在组织正在处理的问题完全一致，但只要你忽略表面的差异，你很可能会发现许多可以迁移到自己项目上的共性。在你跟着项目推进时，可以想象我们正处在结对编程的场景里，或者同处一间会议室一起推敲系统设计。我们会走完 ML 生命周期中的每个关键部分，并以更偏运维的一侧收尾——也就是监控（数据与模型两方面）以及模型可解释性。
1.4.1 介绍这些 ML 项目
本书的核心目标之一，是尽可能给你提供一次“从头到尾构建 ML 系统”的接近真实世界的体验。为此，我们将向你呈现三个项目。在这些项目中，我们会带你走完整个 ML 生命周期：从数据准备，到监控，最后到模型退役（retirement）。这些项目旨在让你在常见的 ML 类型上获得广度体验。虽然我们不可能覆盖所有 ML 项目类型，但我们挑选的项目能很好代表真实世界中的 ML 问题。此外请放心：在我们深入搭建 ML 平台，并在其上构建/部署这些项目之前，你会先在第 2 章进一步学习 MLOps 的核心概念。
我们会复用一些工具（例如 Kubeflow Pipelines）；而在另一些地方，我们会直面前面工具带来的挑战与不足，然后给出替代方案。每个项目都会遵循 ML 项目的生命周期，并随着用例增长逐步引入不同工具。这些项目也被设计用来强化以下观察：
- ML 项目很少是线性的，而是高度迭代的。 有时你必须回到之前的步骤，重新审视假设、重新思考模型。比如，当模型训练效果不如预期时，你可能需要回到数据准备环节。我们也会把类似场景写进项目里，让你亲身体验哪些部分需要调整，以及该如何调整。
- 项目需求会随项目自然演进而变化。 这通常意味着你要重新考虑现有方案，并在探索其他工具与技术时更有创造性。
- 核心 MLOps 概念对几乎任何类型、领域或阶段的大规模 ML 项目都至关重要。 具体情境下，有些步骤可能会被跳过或与其他步骤合并，但围绕这些核心概念来思考，能为大型 ML 项目提供结构；并且在我们的经验里，它也能提供一个很好的工程化框架。
1.4.2 这些 ML 项目
这些项目灵感来自我们在工作中遇到的一些项目，只是做了些“轻量化”的删减版本。不过，步骤与思考过程几乎完全一致，我们也相信你能把它们应用到自己的项目中。
项目 1：构建一个 OCR 系统
OCR 是 ML 系统中非常常见的用例。在这个项目里，我们会从“检测身份证件”的问题陈述开始。我们会弄清楚如何构建数据集，然后训练一个图像检测器来识别身份证件。接着，我们会用一个开源库搭建初始实现，再用标注数据集对其进行微调。最后，我们会把它部署成一个服务。
项目 2：电影推荐系统
第二个项目是一个电影推荐服务。尽管步骤与核心思路与 OCR 示例相同，但表格数据有一些有趣的细节与工具需求。表格数据也更容易用来展示某些概念，比如特征库、漂移检测、模型测试与可观测性。此外，表格数据还有一个优势：它天然就是数值格式（或者可以很容易转换成数值特征）。
项目 3：由检索增强生成驱动的文档助手
第三个项目通过 DakkaBot 引入 LLM 驱动的系统：这是一个内部文档助手，帮助工程师使用自然语言查询公司文档。虽然它仍然建立在与前两个项目相同的 MLOps 基础之上，但检索增强生成（RAG）系统带来了围绕文档处理、语义搜索与提示词工程的新挑战。我们会实现一条完整流水线——从文档摄取、向量嵌入到 RAG——并进一步加入安全护栏、成本优化与语义评估。该项目展示了传统 MLOps 原则如何调整，以支持生产环境中的生成式 AI 工作负载。
总结
- ML 生命周期提供了一套框架，帮助你自信地把 ML 项目从想法推进到生产。虽然它本质上是迭代的，但理解每个阶段能帮助你穿越 ML 开发的复杂性。
- 构建可靠的 ML 系统需要跨软件工程、MLOps 与数据科学的综合技能。与其试图一次性掌握所有内容，不如先理解这些技能如何协同，从而形成稳健的 ML 系统。
- 一个设计良好的 ML 平台，是你自信开发与部署 ML 服务的基础。我们将使用诸如 Kubeflow Pipelines 做自动化、MLflow 做模型管理、Feast 做特征管理，并学习如何把它们有效集成以用于生产。
- 我们会通过构建三种不同类型的 ML 系统来落地这些概念：OCR 系统、电影推荐系统，以及 RAG 驱动的文档助手。通过这些项目，你将获得处理图像与表格数据的动手经验，并建立应对多样化 ML 挑战的信心。
- 传统 MLOps 原则可以自然扩展到 LLM，通过 LLMOps 增加文档处理、检索系统与专门监控等组件。理解这一演进能帮助你适应现代 ML 生态。
- 任何潜在 ML 项目的第一步，是明确 ML 模型要解决的问题；随后是收集与准备训练/评估所需的数据。数据版本管理带来可复现性，而模型训练则通过流水线实现自动化。
- ML 生命周期会贯穿全书作为我们的指南，帮助你不仅学会如何建模，更学会如何打造可靠、生产就绪、能交付真实业务价值的 ML 系统。
