ML 解决方案的基本组件
曾经有一段时间，构建机器学习模型需要大量工作（涉及实现您自己的算法，在此过程中编写大量代码，并希望您在将学术工作转化为函数库时不会犯重大错误）。现在我们有了 scikit-learn、XGBoost 和 Tensorflow/PyTorch 之类的东西，一个很大的障碍已经消除，非专家可以用较少的领域知识和编码经验创建模型，并可能在数小时内得到初步结果。在此过程中，有时我们很容易忘记 ML 解决方案的本质是什么。我们是否倾向于尝试从头开始解决 ML 问题，我们需要什么？我一直认为任何 ML 解决方案都有四个关键部分：
- 数据：训练数据对于任何 ML 算法都是必不可少的。
- 代码：选择您的库，但需要一些代码才能使用它。
- 环境：我们需要在某个地方运行代码。
- 模型：我们将用来进行预测的东西。
由此产生的输出是预测，这不可避免地是企业感兴趣的东西，但要做到这一点需要付出不小的努力。我提出这个是因为我想将其作为一种查看不同时代 ML 平台的方式，基于它们所关注的四个元素（上面列出的）中的哪一个：
- 第 1 代 ML 平台是基于代码和环境的：重点是编写代码、协作以及使代码易于执行。
- 第 2 代 ML 平台是基于模型的：重点是快速创建和跟踪实验，以及部署、监控和理解模型。
- 第 3 代 ML 平台是基于数据的：重点是特征（features）和标签的构建（这是大多数场景（用例）真正独特的方面）以及 ML 工作流其余部分的自动化。
正如我们将在下面看到的，平台可以根据他们的关注点发生很大变化。适合您组织的平台很大程度上取决于您的目标：您是否需要一个平台来简化面向研究的数据科学家的开发生命周期（第 1 代 ML 平台），或者帮助您的企业以最小的风险尽快执行 AI 场景（用例）的平台（第 3 代 ML 平台）？
第 1 代 ML 平台：协作数据科学开发
2000 年后期，随着 Python 开源库生态系统的出现，ML 平台的现代风格开始形成，这使得开发数据科学的任务相对容易。 NumPy (2006)、pandas (2008) 和 scikit-learn (2007) 等软件包使得在 Python 中转换和建模数据比以前更容易，并且结合 matplotlib (2003) 和 IPython (2001) 等工具，让数据科学家可以相当快速地启动本地开发环境，并且很容易拥有大量工具供他们使用。许多早期的数据从业者来自学术界，之前习惯于使用 Mathematica 和 Maple 等面向 Notebook 的工具，因此 2011 年 IPython Notebooks 的发布（后来在 2015 年更名为 Jupyter Notebooks）大张旗鼓也就不足为奇了（尽管我们将在本文中采用以 Python 为中心的方法，但值得注意的是，RStudio 也是在 2011 年发布的）。到了这个时候，由于 Pypa（维护 virtualenv 和 pip 等工具）的出现，使得 Python 包和环境管理也变得更加容易；几年后，数据科学家使用 XGBoost (2014)、TensorFlow (2015) 和 PyTorch (2016) 获得了更强大的建模工具。对于 Python 数据专业人士来说，所有这些都很到位。
下图展示了通过 Jupyter Notebooks 工具使用 Lorenz Attractors 来解决您的业务问题。
Notebooks 曾经是并将继续是数据科学家日常使用的主要工具之一。不论你是是爱他们或恨他们，他们都以一种其他编辑器技术没有的方式在 ML 领域扎根。尽管它们可能很棒，但随着公司开始将 notebooks 应用到他们的技术栈中时，他们也不可避免地发现了许多缺口（gaps），例如：
- 分享工作并与同行进行合作
- 建立一个有效的环境来运行别人的notebook
- 访问正确的基础架构以运行代码
- 调度 notebooks
- 强制执行编码标准
早期采用 notebook 的高科技公司可能已经构建了某种定制解决方案来应对上述挑战（也许更多）。其余的软件供应商开始出现提供“协作数据科学”的工具。这些工具是为数据科学家构建的：它们围绕着notebook，并试图减少在企业级协作和运行代码的冲突。如果我们回顾机器学习的早期的基本组件，这些工具完全专注于代码和环境。当代的解决方案基于云的，并在容器中运行，从数据科学家那里抽象出更多的复杂性。一般来说，他们往往擅长他们所做的事情。因此，为数据科学家提供一个很好的开发沙箱来探索和协作非常有用。
然而，多年来，这些工具已经证明它们在这几个领域都存在不足，例如：
- 缺乏运营模型：通过使平台尽可能通用和灵活，自动化常见任务变得更加困难。
- 艰难的生产之路：Notebooks 是该平台的核心资源，但众所周知，它们在生产工作中难以依赖并且极易出错。
- 以数据科学家为中心：基于代码的方法非常适合数据科学家，但这意味着您组织中的其他用户将获得很少的价值。即使是你付钱给写代码的大多数人（软件开发人员）通常也不喜欢使用 Notebooks。
- 鼓励流水线丛林：平台手动的本质意味着任何生产工作都需要复杂的数据和 API 流水线，以确保事情真正有效。
- 更难的任务是“留给读者的操作”：特征工程、特征平台（Feature Store）、模型部署和监控，所有这些都是手动或外部完成的。
尽管第一代 ML 平台在开发周期中有它们的用途，但时间证明它们对于生产工作来说是糟糕的系统。我相信大多数负面新闻（关于 ML 是一个众所周知的难以操作的领域）都是由于第一代平台的错误。 Notebooks 可以很好地制作一个新的、困难的用例（场景）的原型，但随着想法的成熟，它们应该很快被丢弃，以便专注于更强大的系统。因此，它们通常不是创建生产 ML 系统的良好的起点。
第 2 代 ML 平台：基于模型为中心的解决方案
大约在数据科学领导者对基于 Notebooks 的平台（无论是内部构建的还是供应商收购的）感到沮丧的时候，很多人开始谈论“数据科学工作流程”或机器学习开发生命周期 (MLDLC)。重点是开发一个类似于软件开发生命周期的框架，这在软件开发团队中是相当规范的，并有助于指导该团队从开发到生产。在 ML 中非常需要这样的东西来帮助陷入困境的团队将各个部分组合在一起，以便构思一个合适的 ML 生产策略。
下图展示了机器学习开发生命周期。
正如我们所讨论的，协作数据科学工具在生产过程中留下了许多空白，而 MLDLC 确实突出了这一点。 协作数据科学工具主要用于这个周期的早期阶段：围绕特征工程和模型训练。 在这个周期的剩余时间里，我们需要寻找其他工具。
Notebooks 可能很有用，但它们仍然会留下很多未覆盖的 MLDLC。
幸运的是，新工具已经在兴起：用于模型训练的 AutoML 工具和实验跟踪器、用于模型部署和监控的 MLOps 工具、用于模型洞察的可解释 AI 工具 (XAI) 以及用于端到端自动化的流水线工具。 有趣的是，特征平台（feature store）工具在过去几年才真正开始出现，我们将在第 3 代 ML 平台中讨论更多。在任何情况下，只要有足够的奉献精神和金钱，你就可以把 MLDLC 中的所有盒子都覆盖，并为自己构建了一个强大的 ML 平台而感到满足。
所有这些工具都解决了 MLDLC 中的一个特定问题，它们都专注于模型，而不是代码。这代表了对 ML 平台的思考发生了相当大的转变。与其期望数据科学家通过编码从头开始解决所有问题，或许更合理的方法是简单地为他们提供工具，帮助他们自动化工作流程的各个部分并提高他们的生产力。许多数据科学领导者意识到他们的团队主要使用“现成的”算法，所以让我们专注于自动化这个过程中难度较低的部分，看看我们能否将拼图排列成某种连贯的生产过程。
