几个月前，我试着挑战自己，开启一段从数据分析背景转向数据工程的旅程。到目前为止，我已经构建了两个有影响力的实际项目，它们确实教会了我一些有用的东西。我构建了一个 Git Hub ET L 管道，用于提取 Git Hub 仓库并将其加载到 SQLite 数据库中——它通过 Git Hub Actions 按计划运行。我还构建了一个 RSS 管道，用于从 RSS 订阅源中提取文章并将其存储到 Kestra 数据库中——由 Kestra 编排，按小时计划运行。既然我已经对 ET L 有了相当程度的了解，我想尝试一些新东西。我想在构建新东西的同时继续练习过去学到的一切。我一直对机器学习领域很着迷，但从来没有勇气涉足其中，因为我觉得它涉及复杂的数学。现在不再这样了。最近，我为一家虚构的电信公司构建了一个客户流失预测模型，我称之为 Northline Mobile（附注：我使用虚构公司是因为我通过真实场景最能理解事物）。我向它提供了 7043 名客户的数据，告诉它这些客户是签约了 1 年合同还是按月计划，客户时长、月费、附加服务等信息。此外，我还告诉它谁最终离开了 Northline Mobile。我用它未曾见过的客户对模型进行了交叉验证。它达到了 81% 的准确率。这教会了我构建模型所涉及的一切。显然，我并不理解所有复杂的代码，因为我更喜欢直观的拖放界面而不是复杂的代码。但我理解了构建模型的基本构建模块；我将在下面用简化的架构进一步解释。所以从机器学习的角度来看，构建这个模型感觉像是一次胜利；我的模型起作用了。但仍然有一个问题：它仍然不是真正有用的。假设一个需要预测的 Northline 员工来找我，我必须打开 Jupyter，加载正确的笔记本，按正确的顺序运行单元格，并手动调用 predict_churn()。是的，模型存在，但我是唯一知道如何使用它的人。Northline 的其他人无法直接将客户信息发送到模型并获取预测结果，它也无法与任何其他应用程序通信。本文将涵盖这些内容。我最近了解到，拥有一个模型和拥有一个服务之间是有区别的。如果一个模型只是放在笔记本里，只有构建它的人才能使用它。但将其变成服务后，所有人都可以使用它——其他团队、应用、仪表板和系统不需要知道或关心预测是如何做出的。事实证明，构建机器学习模型是最简单的部分，但让它变得有用是另一个值得探索的关键要素。在 API 之前 "完成" 意味着什么以下是构建模型的大致过程：基本上就是这样。没什么太花哨的。到最后，我有了一个训练好的流失分类器、一个清理和编码原始数据的预处理管道，以及我满意的评估数据（稍后详细介绍这些数据，它们并不完美，我也不会假装它们完美）。但正如我所说。假设 Northline 的留存团队构建了一个仪表板，他们希望它能自动标记有风险的客户。他们的仪表板无法合理地打开我的 Jupyter 笔记本并运行我的单元格。它需要完全不同的东西。像这样的：这就是本文涵盖的转变。不过先做一个快速声明：这不是一篇 Fast API 教程。Fast API 只是我碰巧用来将模型暴露为……