斯坦福这门 ML 课，讲的是交付之后的事

在斯坦福的 CS 329S，65% 的成绩不来自考试，而来自期末项目：构建一个真实的 ML 应用，并在演示日上展示。评分方式本身就说明了这门课看重什么。

课程全称是 Machine Learning Systems Design（机器学习系统设计），由 Chip Huyen 讲授。课程网站注明，这是该课第二次开设。

课程日程从 1 月 3 日排到 3 月 9 日，教学团队的邮箱地址带有 2022 字样，可见这是 2022 年冬季学期的版本。课程目标写得很明确：提供一套迭代式框架，用于开发在真实环境中运行的 ML 系统。

如果你是前线部署工程师（FDE），或即将成为 FDE，最关键的词是“迭代”。原因就写在课程介绍里：数据分布一直在变，交付时表现良好的模型，等客户数据一变，未必还能保持水准。

这门课讲的是交付之后的工作

CS 329S 的课程大纲为离线评测和模型评测分别安排了课次。模型评测这一课附带一个 RecList 教程。接下来一课讲 ML 系统故障诊断、分布偏移和监控，随后是一个使用 WhyLogs 和 Evidently 的监控教程。生产环境监控占了整整一课，而不是在章节末尾带上几句。

大纲里还有一课叫“准确率之外的 ML”（ML beyond accuracy），涵盖公平性、安全和治理。最后一课讲 AI 的商业价值，这部分最接近 FDE 要向客户呈现的内容。这个顺序与真实项目如出一辙：先让它可衡量，再让它可运维，最后才证明它的价值。

ML 系统是一个闭环

课程网站写道，这门课教的是如何持续监控 ML 系统并部署变更，因为数据分布不会静止不动。配套书籍的官方仓库把目标描述为：系统要可靠、可扩展、可维护，并能随环境和业务需求的变化而调整。

Chip Huyen 为这本书写的页面说得更具体：如何选择训练数据、多久重训练一次、监控哪些内容，都会影响整个系统。

对 FDE 来说，这些问题应该在部署方案里回答，而不是等到第一次事故之后。和客户确定项目范围时，单独加一节，写明重训练频率和监控负责人。

自己先做离线评测，别让客户替你做

这门课给离线评测单独安排了一课，原因不难理解：测试集上的一个数字，很少能让客户真正信任模型。设想你即将把一个商品推荐模型交付给一家零售连锁企业，整体测试分数看起来不错。

交付之前，你按客户分群拆分测试集，重新打分。结果可能显示，新客户——恰恰是市场团队最在意的分群——拿到的推荐明显更差。在离线阶段发现这一点，代价远低于模型上线后由客户自己发现。

模型评测课上的 RecList 教程，正是养成这种分片评测习惯的地方。“准确率之外的 ML”一课补上其余部分：客户法务团队必然会问到的公平性、安全和治理问题。

检测变化容易，选择处理哪些变化才难

这是最值得记住的观点。Chip Huyen 在 2022 年 1 月 2 日发表的一篇关于实时机器学习的文章中写道，问题不在于检测变化，而在于知道哪些变化真正需要你关注。同一篇文章把重训练与检测到的分布偏移挂钩。

设想客户做了一次促销后，Evidently 在几十个特征上标出了漂移。如果每条告警都触发重训练，客户团队很快就会对所有告警视而不见。更好的做法是从一开始就和客户约定：影响业务指标的变化触发重训练，其他变化只做记录。

应该按什么顺序学？

课程讲义后来扩展成了《Designing Machine Learning Systems》（O’Reilly，2022）一书。所以先读书，建立整体认识。然后打开 stanford-cs329s.github.io 上的课程大纲，做完模型评测课上的 RecList 教程，再进入使用 WhyLogs 和 Evidently 的监控教程。

最后一步，是仿照课程期末项目——也就是占 65% 成绩的那部分——做一个自己的项目。构建一个小型 ML 应用，部署上线，加上监控，再演示给别人看。如果你瞄准的岗位需要把模型用到客户的真实数据上，这门课值得花时间。

自学时有两个错误很容易犯。第一，只报告一个整体数字，正是上面零售例子揭示的陷阱。第二，把漂移告警直接接到重训练命令上，结果系统不停地重训练，却没人知道为什么。

把项目写进简历时，不要只写“构建了一个准确率达到 X% 的模型”。要写清楚你在哪些数据切片上评测了模型，用什么工具监控漂移，以及按什么规则决定何时重训练。这几行能说明你运维过一个系统，而不只是训练过一个模型。

高准确率的模型只能证明它上线第一天没问题。CS 329S 的课程大纲，用了整整几课来讲之后发生的事。