模型上线不是终点：为什么真正可靠的AI系统，必须在真实世界中持续学习与纠错？

周读：《Designing Machine Learning Systems: An Iterative Process for Production-Ready Applications》
作者：Chip Huyen
周读日期：2026年10月23日

一家企业决定引入机器学习，预测哪些潜在客户更可能成交。

项目初期进展顺利。

数据科学团队整理历史客户数据，训练模型，在测试集上获得很高的准确率。管理层看到报告，认为这套系统已经具备上线条件。

随后，模型开始参与真实业务。

几个月后，销售团队却发现：系统给出的高分客户并不总是最值得跟进的客户。一些真正优质的询盘被排在后面，而部分高分客户最终没有进入报价阶段。

模型没有报错。

服务器正常运行。

API持续返回结果。

监控面板甚至显示系统可用性接近100%。

但它正在逐渐失去业务价值。

问题究竟在哪里？

可能是训练数据已经过时。

可能是新的客户群体改变了输入数据分布。

可能是销售策略变化，使过去的成交规律不再成立。

也可能是训练数据中包含了预测时根本不可能获取的信息。

这些问题很难通过“换一个更强的算法”全部解决。

这正是Chip Huyen在《Designing Machine Learning Systems》中持续强调的核心问题：

机器学习系统不是一个训练完成后便保持不变的软件组件，而是一个需要围绕数据、模型、部署、监控和反馈持续运行的动态系统。

上一期《Incoterms® 2020》，我们讨论了国际贸易中责任、费用和风险必须具有清晰边界。

这一期重新进入AI工程，同样需要回答责任边界问题：

当模型给出错误结果时，问题出在数据、模型还是业务流程？

当环境发生变化时，谁负责发现？

当模型需要更新时，谁决定是否发布？

当系统无法可靠判断时，它应该继续执行，还是交还给人？

从训练模型到运营AI系统，真正改变的是我们对“完成”的定义。

一、一本2022年的机器学习工程书，为什么在2026年仍然值得读？

《Designing Machine Learning Systems》由O’Reilly于2022年5月出版。

作者Chip Huyen长期关注机器学习系统设计与生产部署。她后来出版的《AI Engineering》更加聚焦基础模型应用，而本书讨论的是更广义的机器学习生产系统。

原书覆盖11章，内容从业务目标与数据工程开始，延伸到训练数据、特征工程、离线评估、模型部署、数据分布变化、持续学习、MLOps基础设施，以及机器学习系统中人的角色。

它不是一本教读者逐行实现某个算法的教材。

作者在官方GitHub仓库中也说明，本书重点不是代码教程，而是帮助读者理解构建和运营机器学习系统时必须作出的关键设计决策。

全书围绕四个系统要求展开：

Reliability：可靠性。

Scalability：可扩展性。

Maintainability：可维护性。

Adaptability：适应性。

这四个要求，正是机器学习从实验室走向企业生产环境时最容易被忽视的部分。

一个模型可以非常准确，却无法承担真实请求量。

可以快速响应，却很难维护。

可以今天表现良好，却无法适应下个月的业务变化。

因此，真正的系统质量不能只由模型分数决定。

二、机器学习项目首先应该解决业务问题，而不是寻找算法

传统AI项目很容易从技术出发。

我们有一些数据。

能否训练一个模型？

能否使用深度学习？

能否换成Transformer？

能否部署一个Agent？

但Chip Huyen在第二章把问题重新放回业务目标：

为什么需要这个系统？

这是所有后续设计的起点。

例如企业希望利用机器学习优化销售线索分配。

业务目标可能是：

在不明显增加销售人员工作负荷的情况下，提高合格商机识别效率。

模型目标则需要进一步定义。

是预测客户成交概率？

预测客户是否进入报价阶段？

预测客户预期订单价值？

还是预测未来90天内成为合格商机的可能性？

这些看似相近的目标，对应的训练标签、数据要求、评估指标和业务效果却可能完全不同。

如果企业选择预测“是否回复邮件”，模型可能非常准确。

但它最终优化的只是回复行为，而不是真正的销售机会。

这就形成了一种危险的错位：

机器学习指标不断改善，业务目标却没有改善。

所以系统设计的第一步不是选择模型，而是建立一条可以解释的关系：

Business Objective → ML Objective → Evaluation Metric → Business Outcome。

如果这条关系没有建立，即使模型训练得再好，也可能只是在精确优化一个错误目标。

三、数据比模型更早决定系统的上限

机器学习系统与传统软件最重要的区别之一，是它的行为不仅由代码决定，也由数据决定。

相同算法、相同参数、相同程序，在不同数据上可能得到截然不同的结果。

因此，原书用大量篇幅讨论数据工程、训练数据和特征工程。

这些内容表面上不如模型架构吸引人，却往往是生产环境里最重要的工程工作。

例如一个企业希望预测客户质量。

数据可能来自CRM、网站行为、广告系统、表单、销售记录和历史成交数据。

这些来源很容易出现不一致。

CRM中“有效客户”指已进入报价阶段。

营销系统中“有效客户”可能只是留下了完整联系方式。

销售团队又可能把“值得继续跟进”当作有效标准。

同一个字段名称，在不同系统里对应三种含义。

如果直接汇总训练数据，模型学习到的就不是统一的商业事实，而是混合了不同部门判断标准的历史记录。

所以数据治理首先需要解决：

Source of Truth——什么才是可信的事实来源。

还要继续解决数据来源、字段定义、版本、更新时间、缺失值、异常值和权限边界。

这也是为什么企业AI系统的竞争力，不能简单等同于使用了哪一个大模型。

业务数据是否可靠，往往比模型名称更加影响最终结果。

四、训练数据中的一个隐蔽问题：模型可能提前知道了未来

机器学习评估中有一个危险但常见的问题：

Data Leakage——数据泄漏。

这里的“泄漏”不是指客户隐私外泄，而是指模型训练或评估时错误使用了实际预测时不应获得的信息。

例如预测客户是否会成交。

训练数据中包含一个字段：

quotation_approved

表示报价是否已经获批。

这个字段与最终成交很可能高度相关。

模型因此获得极好成绩。

但在真实业务里，我们希望系统在客户刚提交询盘时就作出预测。

此时根本没有正式报价，更不可能知道报价是否通过审批。

于是，模型在训练阶段掌握了一项现实中无法提前获得的信息。

实验结果自然过于乐观。

Google机器学习官方文档同样强调，必须确保训练过程中使用的特征在预测时真实可用，并专门要求检查Training-Serving Skew和Label Leakage。

这提醒我们：

离线评估不只是计算准确率，还必须证明测试条件与真实使用条件一致。

对于具有明显时间顺序的业务，训练、验证和测试划分也需要特别关注时间关系。

否则，我们可能在不知不觉中让模型“看到了未来”。

五、为什么离线表现优秀，不等于上线后表现优秀

在研究阶段，机器学习项目通常拥有相对稳定的测试条件。

数据已经准备好。

标签已经存在。

评估指标可以重复计算。

但真实世界不同。

输入可能不完整。

用户行为会变化。

数据来源可能中断。

某些类别突然出现。

业务流程可能被调整。

系统还必须面对延迟、吞吐量、成本和安全要求。

例如一个客户评分模型离线AUC非常高。

但上线以后，销售人员可能开始根据模型评分决定跟进顺序。

这意味着模型输出改变了人的行为，而人的行为又会影响后续用于训练的数据。

原本用于观察客户质量的数据，开始受到模型自身决策的影响。

于是系统出现：

Feedback Loop——反馈回路。

这里有一个更深层的问题：

过去的数据可能不再只是独立记录现实。

它已经部分记录了：

模型怎样改变现实。

如果不识别这种反馈，新的训练数据可能继续放大旧模型的偏差。

因此，离线评估之外，还需要真实环境验证。

Shadow Deployment可以让新模型在后台处理相同请求，但不影响正式业务决策，用于比较输出、延迟和异常。

Canary Release可以先把少量真实流量交给新版本，观察其表现，再决定是否扩大。

A/B Testing则可在适合的场景下比较不同方案对真实业务结果的影响。

这些方法回答的不是：

“新模型能运行吗？”

而是：

“它进入真实系统以后，是否确实比原有方案更好？”

六、Data Drift与Concept Drift：模型为什么会在没有报错的情况下变差

这是本书最值得反复阅读的部分之一。

传统软件出现问题，很多时候是代码、接口、依赖或基础设施发生异常。

机器学习系统还有另一类问题：

软件没有改变，世界却变了。

例如企业过去的主要客户来自欧洲。

后来业务进入中东、南美和东南亚。

客户使用语言不同。

采购周期不同。

询盘习惯不同。

行业应用也不同。

模型仍然基于旧数据作出判断。

系统可以持续返回结果，但预测质量可能下降。

这类问题通常涉及数据分布变化。

需要区分几个经常被混用的概念。

Data Drift常被用来描述生产环境输入特征分布发生变化。

例如某个地区的客户占比从10%上升到40%。

Concept Drift通常指输入与目标之间的关系发生变化。

例如过去高频访问技术资料的客户更容易成交，但后来由于竞争环境变化，这类行为不再具有同样的预测意义。

统计上可以通过输入分布 (P(X)) 与条件关系 (P(Y\mid X)) 的变化理解这种区别。

不过也必须特别谨慎：

检测到Data Drift，并不自动意味着模型已经失效。

如果输入变化发生在对预测不重要的特征上，模型可能仍然有效。

反过来，即使输入整体分布变化不明显，关键业务规律也可能已经改变。

因此真正需要同时观察：

数据分布。

模型输出。

有标签样本上的预测质量。

最终业务指标。

不能把Drift Detector简单当作模型质量的最终裁判。

七、监控不应该只回答“系统还活着吗”

传统运维监控非常关注：

CPU。

内存。

网络。

错误率。

系统可用性。

API延迟。

这些指标在机器学习系统中依然重要。

但完全不够。

一个客户评分API可能保持99.9%的可用性，却持续向销售人员推荐错误客户。

这意味着：

Service Health不等于Model Health。

更不等于：

Business Health。

真正完整的生产环境监控，至少需要三个层次。

首先是技术层。

系统是否稳定，延迟和成本是否可接受，工具与数据接口是否正常。

其次是数据与模型层。

输入字段是否缺失，数据Schema是否变化，预测分布是否异常，模型对不同客户群体的表现是否存在差异。

最后是业务层。

高分客户是否真的更容易转化，人工审核比例是否增加，用户投诉是否出现新模式，系统是否产生预期的经济收益。

还要注意：

业务标签经常存在延迟。

例如今天预测一个客户是否会成交，可能三个月之后才知道最终结果。

因此不能因为暂时无法获得真实成交标签，就放弃监控。

可以先结合领先指标、抽样人工评估和延迟结果回填，建立分层反馈机制。

真正成熟的监控不是堆积更多Dashboard。

而是能够及时回答：

系统什么时候开始不值得继续信任？

八、持续学习不等于“发现漂移就自动重新训练”

《Designing Machine Learning Systems》的副标题特别强调：

An Iterative Process。

这是全书的核心。

机器学习系统不是一次完成。

而是在真实使用中不断获得反馈，再调整系统。

但这里有一个特别容易误解的地方。

Continual Learning不应该被简化成：

每天自动重新训练一次模型。

重新训练是否有必要，必须根据具体情况判断。

有时模型下降来自新数据分布，重新训练可能有效。

有时是上游字段发生错误。

有时是标签定义改变。

有时是系统权限或调用流程异常。

有时只是数据量太少，漂移检测产生了噪声。

甚至有时，新模型在整体测试集上更好，却在关键客户群体上明显变差。

所以真正可靠的持续迭代应该具备以下逻辑：

发现异常。

定位原因。

形成改进方案。

在固定基准和新样本上重新评估。

进行受控发布。

观察结果。

必要时回滚。

Google Cloud的MLOps指南也将持续集成、持续交付和持续训练视为彼此关联但不同的工程能力。

其中Continuous Training并不意味着任何新数据都应该不经验证直接进入生产模型。

更重要的是：

让每次更新都可验证、可追溯、可恢复。

九、MLOps真正解决的是“模型生命周期”，而不是增加一套复杂工具

提到MLOps，很多人首先想到：

MLflow。

Feature Store。

Model Registry。

Docker。

Kubernetes。

CI/CD。

Workflow Orchestration。

这些工具确实可能有用。

但如果把MLOps理解成安装一组工具，就偏离了它真正的价值。

它需要管理的是整个生命周期。

从：

业务需求。

数据。

实验。

训练。

评估。

发布。

监控。

反馈。

直到更新、回滚或退役。

例如一个模型发布以后，企业至少应该能够回答：

它使用了哪一版数据？

采用了哪组特征？

训练代码是什么版本？

测试集是什么？

哪些评估结果支持本次发布？

谁批准上线？

当前生产版本是什么？

如果结果异常，能否恢复上一版本？

这些问题共同指向：

Reproducibility——可复现性。

以及：

Traceability——可追溯性。

如果一家企业无法重现三个月前的模型结果，那么即使今天部署非常顺利，未来遇到异常也可能难以定位。

从这个意义上说，MLOps不是为了让AI系统变得复杂。

它是为了让原本高度不确定的模型开发过程，获得尽可能可靠的工程管理能力。

十、2026年重新读这本书，必须区分传统机器学习与生成式AI

这里需要明确原书的时代边界。

《Designing Machine Learning Systems》于2022年出版，主要聚焦预测型机器学习以及更广义的ML生产实践。

它没有以今天成熟的LLM Agent、工具调用、RAG与多步骤生成式工作流作为主体。

因此，不能直接声称书中已经完整解决了2026年AI Agent的所有工程问题。

但它提供的方法可以迁移。

例如过去预测模型依赖：

训练数据。

特征工程。

模型版本。

预测服务。

生产评估。

今天的生成式AI应用则可能依赖：

基础模型版本。

System Prompt。

工具定义。

RAG知识库。

检索与重排序。

业务规则。

用户上下文。

权限。

模型生成结果。

执行轨迹。

人工审核。

也就是说，系统中的可变因素变得更多了。

过去一个模型表现下降，可能首先检查数据和特征分布。

今天一个RAG系统回答质量突然下降，还需要进一步检查：

知识库是否更新？

文档是否被错误切块？

检索是否遗漏重要资料？

重排序是否改变？

Prompt是否被修改？

模型版本是否发生变化？

工具是否返回过时数据？

权限过滤是否正确？

生成式AI没有消除传统MLOps问题，而是扩大了需要治理的系统边界。

这也是把《Designing Machine Learning Systems》和Chip Huyen后来的《AI Engineering》连接起来时，最值得理解的区别。

十一、AI Agent还增加了一类传统预测模型没有的高风险：行动

传统分类模型可能输出：

这个客户成为合格商机的概率是0.82。

但AI Agent可能进一步采取行动：

读取CRM。

判断客户优先级。

自动发送邮件。

创建报价。

修改客户状态。

安排跟进任务。

调用外部工具。

这意味着Agent的错误不再只停留在预测结果上。

它可能直接改变真实业务状态。

所以生产Agent不仅需要评估回答质量。

还必须评估：

工具是否选择正确？

调用参数是否正确？

有没有越权？

是否重复执行？

失败是否能够停止？

高风险动作是否经过批准？

执行记录是否可以追溯？

错误是否能够回滚？

OpenAI在2026年的Agent实践指南中也明确强调：应根据任务风险配置Guardrails，并针对敏感操作和失败阈值保留人工干预机制。

这与Chip Huyen的系统设计思想形成了直接延伸：

从Model Reliability，进入Workflow Reliability。

再进一步：

从Workflow Reliability，进入Action Governance。

因此，对于真正进入生产的AI Agent，不能只问：

“它能够完成多少任务？”

还要问：

“当它做错时，系统能否及时发现、限制影响并恢复？”

十二、一个外贸独立站案例：如何建设真正可靠的AI询盘评分系统

假设一家B2B出口企业希望利用AI改善网站询盘质量管理。

目前的流程是：

网站访客提交询盘。

营销团队记录。

销售人员人工分类。

高潜力客户进入优先跟进。

企业希望通过AI提高效率。

错误的建设顺序可能是：

先找一个大模型。

让它阅读询盘。

给出0—100分。

接入CRM。

上线。

但如果按照本书的方法设计，第一步应该是：

定义真正要改善的业务结果。

例如：

缩短高价值询盘首次响应时间，同时提高销售资源分配效率。

然后进一步明确：

什么叫高价值客户？

由谁标注？

哪些历史数据可以使用？

标注结果是否一致？

哪些字段在询盘到达时已经真实可用？

随后建立最简单的Baseline。

例如：

先用清晰的业务规则对询盘分类。

再测试统计模型或LLM方案是否确实优于这些规则。

评估时不仅看Accuracy。

还需要考虑：

高价值客户召回率。

误判产生的销售成本。

人工复核比例。

不同国家或产品类别的表现。

实际响应时间。

后续合格商机转化率。

如果模型达到最低要求，再采用Shadow或受控发布方式进入真实流程。

上线以后，继续监测：

新客户群体。

数据缺失。

模型分数分布。

人工纠错。

成交结果回填。

这样建立的才是一个真正的AI生产系统。

而不只是一个：

能够生成评分的模型。

十三、可靠AI系统还必须设计“无法确定时怎么办”

机器学习工程有一个非常重要的要求：

Smooth Failing。

即系统无法正确完成任务时，不应以不可控方式失败。

这一点在本书最后的用户体验和人类因素章节中也得到讨论。

例如一个客户询盘系统无法确定：

客户是真实采购商还是无效询盘。

最差的处理方式是：

强行给出一个看似精确的评分。

更加合理的方式可能是：

要求补充信息。

降低自动化决策级别。

进入人工复核。

输出无法确定状态。

对于Agent而言：

如果外部系统返回异常。

如果工具权限不足。

如果数据相互矛盾。

如果即将执行不可逆操作。

系统应该具备明确的停止与升级机制。

可靠性并不要求AI永远正确。

它要求的是：

AI不正确时，整个系统仍然能够安全、可控地运行。

十四、真正需要监控的不是一个模型，而是一条完整因果链

重新阅读这本书，我认为最值得进一步推进的思想是：

不要把监控对象局限为模型。

例如客户评分结果下降。

可能不是模型本身发生问题。

也可能是：

网站表单字段改变。

CRM记录不完整。

营销渠道发生变化。

销售人员修改了合格客户定义。

后续数据回填中断。

某个API返回异常。

人工审核策略发生变化。

这些问题属于不同层次。

但最终都会体现为模型质量或业务表现异常。

所以企业应该尽可能建立：

End-to-End Observability。

将一次结果关联到：

原始请求。

数据来源。

特征或检索内容。

模型与Prompt版本。

评估结果。

工具调用。

人工干预。

最终业务反馈。

这样在出现问题时，才有可能回答：

究竟是哪一次变化导致了结果偏移？

这也说明，AI系统治理不能只关注模型。

必须同时关注数据、配置、工具、人员和流程。

十五、本周实践：建立一张Production AI Readiness Card

这一期不要求读者训练一个新模型。

更适合的实践，是选择一个已经使用或准备部署的AI系统。

可以是：

AI客服。

客户分类。

询盘评分。

内容审核。

RAG知识库。

销售辅助Agent。

然后用下面八个问题完成一次生产就绪检查。

1. Business Objective

系统最终应该改善哪个业务结果？

不能只写“提高效率”。

2. Data Contract

输入数据来自哪里？

字段定义是否明确？

错误与缺失如何处理？

3. Evaluation

是否有真实案例构成的固定评估集？

有没有明确的Baseline？

4. Deployment

怎样上线？

能否先小范围验证？

出现问题能否回滚？

5. Monitoring

除了可用性，还监控哪些模型质量与业务结果？

6. Drift

哪些输入或业务关系可能随时间变化？

变化以后怎样发现？

7. Human Intervention

什么情况必须交给人？

谁拥有暂停系统的权限？

8. Iteration

真实反馈怎样进入下一轮改进？

谁批准版本更新？

如果八个问题无法回答，那么这个系统可能还只是：

技术上能够运行。

未必已经：

具备生产运营能力。

十六、如何为一个AI系统建立最小可行的迭代机制

不需要一开始就建设复杂MLOps平台。

可以先采用一个轻量循环。

第一周：建立Baseline。

收集具有代表性的真实案例。

明确什么叫正确结果。

记录当前人工流程或旧系统表现。

第二周：建立Evaluation。

将常见案例、边界案例和高风险案例分开。

定义核心质量指标与不能触碰的失败条件。

第三周：小范围试运行。

先观察结果，不急于扩大自动执行权限。

记录用户反馈、错误、成本和处理时间。

第四周：分析与改进。

找出最主要的失败类型。

判断问题来自：

数据。

Prompt。

模型。

检索。

工具。

业务规则。

或者实际工作流。

然后只修改有证据支持的问题，并重新运行评估。

这个循环不一定需要大量基础设施。

但它必须做到：

每次改动有原因。

每次发布有依据。

每次失败有记录。

每次改进可以验证。

真正的生产工程能力，往往就是从这类小而可靠的循环中建立起来的。

十七、这本书最需要谨慎理解的地方

《Designing Machine Learning Systems》很系统，但不应该成为所有企业部署AI时必须照搬的复杂架构清单。

不同规模的系统，所需治理强度完全不同。

一个每天处理几十条记录、允许人工完全复核的内部工具，未必需要完整Feature Store或复杂模型训练平台。

一个面向数百万用户、自动作出高价值决策的系统，则需要更加严格的监控、部署与验证机制。

同样：

不是每个业务问题都应该使用机器学习。

如果清晰的确定性规则已经能够可靠完成任务，使用传统程序可能更加经济、透明和容易维护。

如果只是知识检索，首先应该评估传统搜索、结构化数据库或RAG是否足够。

如果工作流相对固定，也不必为了“智能化”强行增加复杂Agent。

所以工程成熟度不应该用：

用了多少新工具。

部署了多少模型。

建立了多少微服务。

来判断。

更好的标准是：

系统复杂度是否与实际问题、规模和风险相匹配。

这才是长期可维护系统应该遵守的原则。

十八、从《AI Engineering》回到《Designing Machine Learning Systems》，我们能够看见什么

前面的周读已经讨论过Chip Huyen的《AI Engineering》。

两本书很适合放在一起阅读。

《Designing Machine Learning Systems》更加关注：

如何把机器学习系统从实验带入真实生产环境，并持续运营。

《AI Engineering》则进一步进入基础模型时代，讨论模型选择、Prompt、RAG、Agent、Evaluation和AI应用工程。

两者并不是相互替代。

它们形成了一条非常清晰的技术演进路线。

传统机器学习告诉我们：

数据会变化，模型会退化，线上表现必须持续评估。

基础模型应用告诉我们：

模型之外还有Prompt、检索、知识、工具和业务流程。

Agent时代进一步提醒：

系统不仅会给出结果，还可能实际行动。

因此，我们需要关注的对象不断扩大：

Model

↓

ML System

↓

AI Application

↓

Agentic Workflow

↓

Business Operating System

但不论复杂度怎样增加，最基础的工程原则依然成立：

真实系统必须能够被观察、被评价、被纠正。

结语：AI系统最大的风险，不是今天做错，而是明天开始变差，我们却没有发现

《Designing Machine Learning Systems》出版于2022年。

四年之后重新阅读，最让我印象深刻的不是书中讨论的某一个算法或工具。

而是Chip Huyen始终坚持的一种系统视角：

模型只是整个生产系统的一部分。

企业真正需要负责的，是最终的业务结果。

一个模型在测试集上获得很高分数，值得高兴。

但这只是开始。

它进入生产环境以后，仍然需要面对：

新的用户。

新的输入。

变化的业务规则。

延迟的真实反馈。

不可预测的异常。

不断调整的技术条件。

所以训练成功并不意味着工作完成。

上线成功也不意味着工作完成。

甚至今天运行良好，也不能证明明天仍然可靠。

真正成熟的AI系统，不是：

一次训练出最好的模型。

而是：

持续发现变化、判断风险、评估结果并改进系统。

这种能力到了AI Agent时代更加重要。

因为Agent不仅处理信息，还可能直接影响客户、数据、交易和真实业务流程。

一个错误如果只能产生一段文本，影响范围相对有限。

但如果错误通过自动化持续执行，就可能迅速扩大。

因此：

AI能力越强，工程治理越不能只停留在模型层。

真正值得建设的是一套可以持续回答以下问题的系统：

它为什么做出这个结果？

使用了哪些数据？

依赖哪个模型版本？

是否符合业务规则？

当前表现是否仍然可靠？

发生错误后怎样停止？

谁承担最终责任？

下一次怎样做得更好？

这些问题看起来不像最热门的AI话题。

但它们决定了AI究竟能否成为一家企业长期可信赖的生产能力。

如果说《AI Engineering》帮助我们学习如何把基础模型变成应用，那么《Designing Machine Learning Systems》进一步提醒：

应用能够运行，只是工程的开始。

能够长期可靠运行，并随着真实世界变化不断改进，才是生产系统真正成熟的标志。

本期互动

回顾一个自己正在使用的AI系统。

如果它明天开始输出质量下降10%，但接口仍然正常、程序没有报错：

我们会在什么时候发现？

更重要的是：

发现以后，谁有能力解释原因，并决定如何纠正？

如果这两个问题尚无明确答案，那么下一阶段最值得投资的，可能不是更强的新模型。

而是：

Evaluation、Monitoring与Feedback Loop。

本期参考资料

以下优先列出作者、出版社及官方工程资料。

1. O’Reilly：《Designing Machine Learning Systems》官方书籍与目录

2. Chip Huyen：书籍官方GitHub仓库及章节总结

3. Chip Huyen：Data Distribution Shifts and Monitoring

4. Google：Production ML Systems — Monitoring Pipelines

5. Google Cloud：MLOps Continuous Delivery and Automation Pipelines

6. OpenAI：A Practical Guide to Building AI Agents

说明：本文关于数据工程、模型部署、分布变化、持续学习与MLOps的主要讨论来自原书。关于2026年基础模型、RAG和AI Agent治理的部分属于基于原书方法的延伸分析，不作为作者在2022年提出的原始观点。

下期预告

周读：《Designing Data-Intensive Applications, 2nd Edition》·Martin Kleppmann、Chris Riccomini

下一期，我们继续向生产系统的底层深入。

如果《Designing Machine Learning Systems》主要回答：

怎样让机器学习系统在真实环境中可靠运行？

那么新的问题马上出现：

这些系统赖以运行的数据基础设施，究竟应该怎样设计？

当数据来自多个服务、多个数据库和多个地区时：

为什么数据一致性如此困难？

为什么分布式系统无法假设网络永远可靠？

数据库、数据仓库、消息队列和流处理系统分别解决什么问题？

如何在Reliability、Scalability、Maintainability和Consistency之间作出工程取舍？

我们将结合2026年已经出版的第二版，从传统数据库与分布式系统出发，进一步理解：

为什么AI系统最终的可靠性，往往取决于那些并不直接属于AI模型的数据基础设施。

标签

Designing Machine Learning Systems,Chip Huyen,#机器学习,MLOps,#MachineLearning,#AI工程,生产环境,#模型部署,Data Drift,Concept Drift,Training Serving Skew,Data Leakage,Model Monitoring,Continuous Learning,#模型评估,#数据治理,AI Agent,Agent Governance,#RAG,#生产系统,#终身学习,#周读

推荐阅读:

周读：《Incoterms® 2020》·International Chamber of Commerce

周读：《Good Strategy/Bad Strategy: The Difference and Why It Matters》