这本 ML 书讲的，正是 FDE 最不起眼的那部分工作

Emmanuel Ameisen 在介绍这本书的页面上给出一个数字，让不少机器学习新手不安：据他所说，数据科学家 95% 的时间花在收窄产品用例、处理数据和部署上。训练模型——大多数课程几乎只讲这个——只占剩下的一小部分。

《Building Machine Learning Powered Applications: Going from Idea to Product》（O’Reilly，2020）就是为这 95% 而写的。Ameisen 称，书中提供的是机器学习里那些不太受关注的环节的实用技巧：构建和标注数据集、调试模型、部署模型。

对前线部署工程师（FDE）来说，这份清单几乎就是一份岗位描述。客户很少缺算法，缺的是定义清楚的问题、可用的数据集，以及上线面对真实用户后仍能持续运转的系统。

模型只是其中一环

据一位读者在 GitHub 上的笔记，这本书贯穿始终的观点是：光训练出模型，不足以把机器学习产品交到用户手里。

配套仓库 hundredblocks/ml-powered-applications 分三部分：演示书中概念的 Jupyter notebook，存放案例核心函数的 ml_editor 库，以及一个 Flask 应用。这正对应 FDE 工作中熟悉的三个阶段：做实验，封装成库，再为用户做成应用。

找到的数据，未必是需要的数据

第一个值得记住的观点，是书中一句简短的提醒：人们常把自己找到的数据集，当成自己需要的数据集。在客户现场，这个错误第一周就会冒出来——有人递过来一份数据库导出文件，说“数据在这儿”。

设想一家客服公司，想要“用 AI 帮员工更好地回复工单”。照字面理解，你会去生成完整回复，而这个问题范围宽、难衡量、难调试。

更窄的定义是：预测一份草稿是否需要修改。输入是草稿，输出是标签，指标是组长重写草稿的比例。

陷阱就在这里。客户提供的工单库可能只保存最终回复，不保存修改前的草稿。数据很多，却恰恰缺少问题所需的输入—标签对。

所以第一件事是问清楚：系统有没有记录修改历史？在向客户承诺任何数字之前，先问这个问题。

相信指标之前，先亲眼看数据

Substack 上的一篇书评指出，获取标注数据可能非常困难。书评还提到书中借鉴自 Monica Rogati 的一个习惯：快速浏览大量样本，留意任何异常。这条建议简单到容易被忽视，但比任何仪表盘都便宜。

放到工单的例子里：打开 notebook 之前，先读几十份真实草稿。你可能会发现一列列数字永远不会标出来的东西，比如重复工单、原样粘贴的模板回复、用多种语言写的工单。每一条发现，都会变成下次客户会议上的一个具体问题。

系统出错时，把模型变简单

据同一位读者的笔记，第三个观点是：用简单的东西替换模型，然后调试整条管道。听起来本末倒置，却是判断问题出在模型还是出在模型周边的最快办法。

对工单问题，临时的“模型”可以只是一条规则：凡是短于某个阈值的草稿，一律标记为需要修改。

如果这条规则在界面上给出荒谬的结果，那 bug 出在数据加载、字段关联或展示环节，而不在算法。

只有整条管道端到端跑通之后，才值得把规则换成真正的模型。

这本书过时在哪里

这本书出版于 2020 年，在大模型浪潮之前。Substack 那篇书评说，到了大模型时代，这本书该更新了，但仍然有用。这个评价公允：上面三个观点与模型类型无关，即使模型只是一次 API 调用，也依然成立。

FDE 需要知道的第二个短板：DEV Community 上的一篇书评批评这本书部署细节偏少。如果只能补一个缺口，先补监控和回滚，因为这两样决定了一次部署能否在客户现场撑过第一周。

在工单例子里，监控指上线后持续跟踪组长修改草稿的比例，赶在客户投诉之前发现模型退化。回滚指只改一项配置，就能退回简单规则或上一版模型。这两样都要在第一次演示之前做好。

适合谁读，怎么读

这本书适合懂 Python 和机器学习基础、却从没把模型交付给真实用户的软件工程师。读的时候把仓库开着，边读章节边跑 notebook。

之后，把大部分时间花在 ml_editor 和 Flask 应用上。模型要在这里变成别人能用的东西，这部分最接近你将来为客户做的事。

如果想让这本书成为简历上的一行，别停留在重跑作者的仓库。把同样的三段式结构用到另一个公开数据源上。

记下你找到的数据和需要的数据差在哪里，以及简单基线帮你抓到了哪些 bug。在 FDE 面试中，这些决策比任何准确率数字都更有说服力。

算法还会变很多次。那些没人炫耀的工作——定义对的问题、亲眼看数据——始终是客户雇用 FDE 的理由。