现代机器学习 (ML) 平台的起步已经大约有十年的时间了，这一平台的灵感主要来自数据科学家不断增长的基于Python的开源技术生态系统。现在是让我们来回顾已经取得的进展，同时突出企业在现有 ML 平台上存在的主要问题，并讨论下一代平台会是什么样子的好时机。正如我们将要讨论的，我们相信 ML 平台市场的下一个颠覆将是数据优先的 AI 平台的增长。

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 平台的思考发生了相当大的转变。与其期望数据科学家通过编码从头开始解决所有问题，或许更合理的方法是简单地为他们提供工具，帮助他们自动化工作流程的各个部分并提高他们的生产力。许多数据科学领导者意识到他们的团队主要使用“现成的”算法，所以让我们专注于自动化这个过程中难度较低的部分，看看我们能否将拼图排列成某种连贯的生产过程。

这并不是说每个人都欢迎这些工具。尤其是 AutoML ，可能会因为数据科学家不相信该过程的结果，或者可能会因为它的存在而感到威胁而遭到抵制。前者是采用 XAI（可解释AI）与 AutoML 一起协作的绝佳案例，而后者我相信随着时间的推移会逐渐消失，因为数据科学家意识到 AutoML 不是在与他们竞争，而是他们可以用来为业务获得更好更快的结果的东西。没有仔细检查就不应该信任任何东西，但是 AutoML 可以成为一个伟大的工具，用于在一个又一个用例（场景）中工作时自动化和模板化可能会成为一个非常繁琐的过程。

从表面上看，所有这些基于模型的重心的解决方案看起来都很棒。像神奇宝贝一样汇集它们，你就完成了 MLDLC。

然而，将这些解决方案组合在一起也并非没有缺陷，具体如下所示：

• 集成困难：要执行一个简单的用例，解决方案的 ML 部分需要四个或更多不同的工具。当出现故障时，只能祝您好运。
• 流水线（Pipeline）丛林仍然存在：可以说，它们比第1代 ML 平台中的情况要糟糕得多。您现在有最初的流水线进入到 ML 平台，以及所有新工具之间更多的流水线。整个系统的流水线就会变得无比冗长，而你可能逐渐迷失在这混乱的丛林中。
• 与数据平面隔离：这些工具都以模型为中心，并在模型而非数据上运行。您仍然需要像第1代 ML 平台中 Notebook 这样的工具来协作处理任何需要完成的数据工作，因为它们不提供这些功能。
• 产品是由 API/SDK 组成的复杂网络：第 2 代 ML 平台中的一个现实生产场景是：编写一个生成训练数据的脚本（可能从 Notebook 中编写），通过 API 或 SDK 将生成的 Dataframe 传递到您的 AutoML 框架，通过 API 或 SDK 将生成的模型传递到您的 MLOps 工具，然后通过您的 XAI 框架（如果您有的话）运行它以生成见解。你如何为新数据打分？同样，编写另一个利用更多 API 的脚本。在 Airflow 之类的东西中运行所有这些，或许在您的第1代 ML 平台可能具有调度程序功能。
• 更难的任务是“留给读者的操作”：特征工程、特征平台（Feature Store）、实体关系映射等……你仍然需要在其他地方做了大量的工作。
• 需要专家团队：这些工具喜欢宣称，因为它们自动化了流程的一部分，所以它们“使机器学习大众化”，使任何人都可以轻松地自助服务。然而，我还没有真正找到一个将业务环境放在首位、不需要K8s/云工程师、机器学习工程师和数据科学家团队来操作的平台。

值得一提的是，第2代ML平台已经进化：更多成熟的供应商要么在迭代新产品，要么收购初创公司以扩大产品范围。您可以从同一个供应商处购买所有解决方案，而不是从多个供应商处购买多点解决方案，通常被称为“企业人工智能”。不幸的是，结果并没有充分解决上面列出的任何问题，除了可能使集成稍微不那么痛苦。主要的好处实际上就是你可以从同一个供应商那里购买所有亮点的工具，当你开始使用开箱即用的技术时，你很快就会意识到你又回到了原点，试图在几乎没有共同点的产品上建立自己的生产流程。

不要将此与第 3 代 ML 平台的方法混淆，肯定是有更好的办法。

第 3 代 ML 平台：数据优先的 AI

什么是真正的机器学习模型？ 如果我们抽象地看待它，它会将数据作为输入并输出预测，并希望还能提供对模型的了解，这样我们就可以评估模型的表现如何。 如果您接受它作为机器学习的范式，那么您的机器学习平台显然需要以数据为中心。 第 1 代 ML 平台和第 2 代 ML 平台不必要地关注该模型内部发生的事情，因此，普通公司几乎不可能将可靠的生产流程串联起来。 但是，通过数据优先的方法，这实际上是可以实现的。

值得称赞的是第1代 ML 平台和第2代 ML 平台的方法，没有它们，第3代 ML 平台就不会存在。既是因为它建立在他们建立的一些概念之上，同时，如果没有人们努力使用第一代和第二代工具来实际操作 ML，它可能永远不会出现。数据优先方法的核心是人工智能已经足够先进，您应该能够简单地向您的平台提供一组训练数据，以及少量元数据或配置，并且平台将能够在数小时内创建您的用例并将其部署到生产环境中。无需编码。没有流水线。作为数据科学家，无需使用 DevOps 工具。操作这个工作流程再简单不过了。

这怎么可能？好吧，正如我所说，我们正在构建我们在本文中已经讨论过的许多概念。有以下三个核心要素：

• 特征平台（Feature Store）：注册您的特征和关系。自动化特征工程。与同行合作，这样您就不必在每次需要转换数据时都重新创建轮子。让特征平台弄清楚如何为训练和推理提供数据。
• 声明式 AI 引擎：提高抽象级别并自动构建模型和生成预测。允许高级用户通过配置自定义实验。
• 持续的 MLOps 和 XAI：认识到世界不是静止的。自动化模型部署和升级。自动生成模型见解（可解释性）。允许数据科学家充当审查和批准工作的看门人，但将其余工作置于自动驾驶仪上。

如果您想看看这在实践中是什么样子，您可以尝试使用 Continual 构建的数据优先 AI 平台。它位于您的云数据仓库之上，并不断构建预测模型，从不停止从数据中学习。用户可以通过 CLI、SDK 或 UI 与系统进行交互，但生产使用可以通过简单的声明式 CLI 命令轻松操作。

我们并不是唯一一个以数据为中心的方法来考虑机器学习的人。 这个想法已经在 FAANG 公司（美国市场上五大最受欢迎和表现最佳的科技股）中流传了好几年，比如 Apple 的 Overton 和 Trinity 以及 Uber 的 Ludwig。 最近一篇关于声明式机器学习系统的文章很好地总结了这些成果。 最近，Andrew Ng 与特斯拉的 Andrej Karpathy 一样对以数据为中心的 AI 进行了反复讨论。 我们预计还会有更多的人上路。我们还认为，声明式数据优先的 AI 是现代数据栈的重要组成部分，它有望降低在云中运行数据平台的复杂性。

下图展示了现代数据栈的如何操作人工智能。

数据优先的 AI 是一个令人兴奋的新概念，它有可能极大地简化来操作 AI 并帮助企业推动 AI/ML 对业务的影响。数据优先的人工智能的一些重要性如下：

• 可靠的路径到生产：通过定义明确的操作工作流程简化生产机器学习。
• 端到端平台：通过减少集成任务和流水线丛林来加速实现价值。
• 人工智能民主化：提供一个所有数据专业人员都可以使用的简单系统。并允许数据科学家控制过程。
• 加速用例采用（选定）：在几天内设置生产工作流程，而不是几周或几个月。用更少的资源管理更多的生产功能。
• 降低成本：少买东西，降低维护成本。

尽管我们相信数据优先平台将成为日常 AI 的主要 ML 平台，但它们并非没有限制。对于真正前沿的人工智能研究来说，可能没有什么可以绕过需要手动工作的事实。对于最具技术性的公司之外的公司来说，这可能不是一个大问题，但在这种情况下，有一个以开发为中心的工具是有帮助的。我们相信，数据优先的平台非常擅长解决 95% 的已知 ML 问题，而另外 5% 可能需要更多的 TLC。然而，我们认为这是一项巨大的改进，让您的 95% 的用例由数据工程师/分析师处理，并由数据科学家进行一些监督，并允许数据科学团队更多地关注困难的 5% 问题。为此，他们需要一个出色的系统（一个数据优先的平台）来自动化一切，并让他们来管理和维护工作流程而几乎不需要任何干预。

什么工具适合您的团队？

我们在本文中涵盖了很多内容，并讨论了很多工具选项。有时，ML/AI 工具环境会让人感到不知所措。数据优先的人工智能方法打破了许多先入为主的观念，人们最好相信它的操纵力。在 Continual，我们坚信 ML/AI 解决方案应该使用您的真实世界用例（场景）进行评估。对于许多解决方案，这可能需要数周或数月的时间，才能暴露出现实中的夸张地宣传。在 Continual 中，我们的目标是让您能够在一天内交付您的第一个生产用例。这就是与您的云数据仓库原生集成的声明式数据优先AI方法的强大之处。

原文链接：Is Data-First AI the Next Big Thing?