当前位置：首页 > news >正文

数据科学家们会被 AutoML 代替吗？

news 来源：原创 2024/5/4 1:30:51

AutoML是什么？当前有哪些可用的平台？以及数据科学家们所面临的最关键问题：数据科学家们的末日就要来了吗？

作者 | @UT Austin

译者 | 王艳妮，责编 | 郭芮

出品 | CSDN（ID：CSDNnews）

以下为译文：

2018年，科技巨头Google和Microsoft向全世界推出了他们的AutoML服务：Google Cloud AutoML和Azure Machine Learning。从那时开始，人们对AutoML服务的欢迎程度和兴趣就迅速增长。

在此篇博文中，我们将讨论AutoML是什么，当前有哪些可用的平台，以及数据科学家们所面临的最关键问题：他们会被AutoML取代吗？

AutoML简介

提到AutoML就不能不说到机器学习项目的生命周期，其中包括数据清洗，特征选择/工程，模型选择，参数优化，以及最后的模型验证。即使技术已经发展到了很高的程度，传统的数据科学项目仍然包含许多既耗时又重复的手动过程。

资料来源：R.Olson等（2016年）“Evaluation of a Tree-based Pipeline Optimization Tool for Automating Data Science.”

AutoML一登场便可以自动完成从数据清洗到参数优化的整个过程。就时间的节省和性能表现而言，它对机器学习项目来说有着巨大的价值。

有哪些可用的AutoML平台？

1. Google Cloud AutoML

于2018年推出的Google Cloud AutoML凭借其友好的用户界面和高性能表现而迅速流行。下图展示了Google与其他AutoML平台的性能比较（蓝色是谷歌）。

资料来源：Tackling High-Value Business Problems Using AutoML on Structured Data (Cloud Next ‘19)

2. Microsoft Azure AutoML

同样发布于2018年的Azure AutoML为不熟悉编程的用户提供了透明的模型选择过程。

3. H2o.ai

“ H2O一直以来都是大规模地构建模型的推动者。这牵扯的可是数十亿项的索赔业务。仅使用标准的现成开源技术是无法做到这一点。” — H2o.ai

H2o成立于2012年，既提供开源软件包，又提供名为Driverless AI的商业化AutoML服务。

自成立以来，H2o有着金融服务和零售等行业的广泛业务。

4. TPOT

TPOT（基于树的管道优化工具，Tree-based Pipeline Optimization Tool）是一个由宾夕法尼亚大学开发的免费Python软件包。虽然免费，但功能非常强大，且在各种数据集中均展现了出色的性能：Iris数据集的准确性约为97％，MNIST数字识别的准确性为98％，波士顿住房价格预测的准确性为10 MSE。（来源：TPOT文档）

AutoML与数据科学家

既然我们已经知道了AutoML是什么以及有哪些可用的选择，接下来要谈到最关键的问题了：这些平台会取代人类数据科学家吗？我们将从成本的角度来看待这个问题，并进行一次黑客马拉松（hackathon）来比较AutoML与人类的性能。

成本比较

根据Indeed.com的数据，在美国，数据科学家的平均年薪为121,585美元。同时，如果公司采用AutoML来完成一份全职工作的任务（每周40小时，每年52周），则费用在每年4,160美元至41,600美元之间，具体花费取决于选择哪个平台。

的确，以上并不算是科学合理的比较，因为我们都明白，数据科学家的工作不仅仅是运行模型。然而，这是一种非常快速简便的能显示出数据科学家和AutoML在成本方面差别的方法。

性能比较：Hackathon

我们将通过一次两个数据集的黑客马拉松来继续比较AutoML平台和人类数据科学家的表现。在每个数据集中，一个由人类数据科学家组成的队伍将与AutoML平台竞争。两方都将进行数据处理，特征选择/工程，模型选择和参数调整，最后提供一个具有预定性能指标的最佳预测结果。

Hackathon数据集1：快速约会（分类, classification）
Hackathon数据集2：ASHRAE（回归, regression）

数据集1：快速约会数据集

数据集概述

这个数据集是从多个实验性质的快速约会参与者中间收集的。在这些约会中，参与者们将填写一份调查表，其中包括他们的个人信息，以及他们期待的伴侣特质。例如，满分十分，他们如何评价自己的志向高低，这个志向具体是什么活动，以及你希望伴侣的志向如何。这个数据集的目标是把参与者的喜好作为特征来预测这个人是否能够匹配到伴侣。这是一个分类问题，把“匹配”作为我们的因变量。

数据科学家进行的数据预处理和特征工程

为了获得比AutoML平台更优的结果，我们需要对数据集进行特征设计，处理类不平衡问题，处理缺失值，以及对分类变量执行one-hot encoding。由于数据是通过调查收集的，因此我们面临整个数据集中存在缺失值的问题。如果参与者没有或者不愿意回答一道问题，他们就会直接空着。这些缺失值通过适当地进行估算平均值，中位数或众数来填补。数据在某些自变量之间具有共线性，因此某些变量会被弃用。只有29％的从属标签的二进制值为1，而其他标签的二进制值为0。为解决此问题，我们使用了SMOTE（合成少数采样率，Synthetic Minority Oversampling Technique）。SMOTE从少数类创建合成样本而非简单地复制数据。One-hot encoding变量在Google平台上尤其会遇到困难，因为该平台无法用能提取有意义信息的方式对它们分组。

现在，我们将使用原始的以及特征工程之后的数据对Azure和Google两家AutoML平台的整体有效性进行分析。

数据科学家vs AutoML平台

数据科学家：我们尝试了几种不同的模型，然后发现XGBoost和神经网络模型表现最好。我们会查看AUC ROC分数，以便将我们的模型结果与这些AutoML平台创建的模型进行比较。我们XGBoost模型的AUC ROC得分为0.77，而神经网络模型的得分为0.74。

采用原始数据的AutoML平台：Google比Azure的XGBoost模型表现要更好一些。Google的AUC ROC得分为0.881，而Azure的AUC ROC得分为.865。Google平台不会向我们透露哪种模型被选为最佳，因为该信息享有专利。另一方面，Azure会明确告诉您总共运行了多少个模型，每个模型的得分是多少，以及训练每总共个模型所花费的时间。

采用处理后数据的AutoML平台：现在我们想要测量模型在我们特征工程后的数据集上的性能。有几件事情引起了我们的注意：Google的表现下降了，而Azure的表现有所提高。如前所述，one-hot encoding对Google的AutoML来说是个问题，且平台的创建是为了执行其自身的特征工程。因此，为特征工程后的数据提供one-hot编码的变量会降低整体性能。Azure的表现从0.865提高到0.885。

快速约会数据集之总结：

数据科学家可以通过向AutoML平台提供经过良好特征工程后的数据集来提供附加价值。
Azure平台在告知预测中使用了哪种模型方面更加透明；Google的模型创建和选择信息是享有专利的。
Google不能很好地处理one-hot编码的变量。

数据集2：ASHRAE

数据集概述

该数据集来自ASHRAE 能源预测Kaggle竞赛，要求参赛者开发出一个预测模型，用于测算1,449座建筑物内的热水，冷水，蒸汽和电表读数。数据由建筑物的元数据组成，其中包括平方英尺，建成年份和楼层数；仪表类型和带有时间戳的读数；以及天气数据（带时间戳的气温，云层覆盖，降水深度，风速，风向（度），海平面压力）。天气数据是由距离最近的气象站在站点级别收集的。

数据科学家所做的数据预处理和特征工程

气象数据集中的缺失值是一个亟待解决的大问题，因为云层覆盖和降水深度这两项特征分别缺失了50％和35％的值。某些气象站点的云层覆盖和降水深度数据全部缺失。为了克服这一障碍，我们尝试在气温，露水温度，风速和海平面压力这些包含很少null值的特征中插入缺失值，并使用这之后的数据为云层覆盖和降水量建立预测模型。

我们使用10倍交叉验证为每个特征选择了插值方法，并将其应用于我们的训练以及测试数据。我们运行了一系列模型来预测云层覆盖和降水深度，但未能找到一个足够准确的能用来生成缺失值的模型。根据间隔将风向重构为一组分类变量，由于其严重的右偏，我们把风速对数转换了。此外，我们还构建了例如假期，周末和我们特征的滞后项等特征。总共，我们在13个原始特征之上又加了19个特征，总共32个变量。

最后，我们把一个气象站点收集的异常天气数据删除了，然后向前，向后和逐步选择来确定最佳的预测特征，最终用到了32个变量中的13个。

数据科学家vs AutoML平台

数据科学家：我们为数据集中的每个建筑物构建了一个轻度梯度增强模型（Light Gradient Boost model），而没有创建一个适用于所有建筑物的通用模型，因为训练和测试集包含的建筑物是相同的。通过这种方法，我们获得了0.773的RMSLE结果。

采用原始数据的AutoML平台：经过一个小时的训练，Google Cloud的RMSLE为1.017；又经过了3小时的训练，RMSLE优化了0.011。Azure的RMSLE为2.22，Google轻松取胜。这个比较并不是很公平，因为我们限制Azure只能使用随机森林，因为只有这样才能算出RMSLE。

采用处理后数据的AutoML平台：用Google Cloud运行处理后的数据，经过4个小时的训练，我们惊讶地发现Google Cloud的RMSLE为1.7。经过进一步调查，我们发现我们的特征选择方式抑制了AutoML的性能，因为AutoML平台会自己进行特征选择。我们再次在两个平台上用所有的32个变量（而非仅仅13个）来运行处理后的数据。这一次，两个平台的性能都得到了提升。一个小时的训练以后，Google Cloud的RMSLE达到了0.755，四个小时以后，达到了0.656，在数据科学家们的基础上有了重大提高！一小时的训练后，Azure的RMSLE为3.826，四小时后为3.653。

ASHRAE数据集之总结：

尽管AutoML是强大的预测工具，但它仍然无法在数据预处理方面胜过人类。
多花几个小时来训练可以大大提高AutoML平台的性能。
请允许AutoML平台代您选择特征；否则，您可能会严重限制平台的性能。
把数据科学家在业务问题方面的专业知识与AutoML的特征选择，特征预处理，模型选择，以及超参数调整功能相结合，就会得到一种强大的解决方案，可用于获得宝贵的洞察力和强大的预测结果。

结论和要点

最后，我们想通过对三个问题的回答来给我们的项目划上句号。

AutoML会取代数据科学家吗？

答案是不会。

尽管AutoML擅长构建模型，但它们仍然无法胜任大部分数据科学家的工作内容。对于业务问题，我们仍然需要数据科学家们来定义。我们仍然需要数据科学家们运用他们的领域知识来提出更多有用的特征。现在来说，AutoML只能处理有限几种类型的问题，例如分类和回归。目前，它们还无法建立推荐（recommendation）和排名（ranking）模型。最重要的是，我们仍然需要数据科学家们从数据中提取出具有可行性的洞见，而仅凭AutoML做不到这一点。

然而，AutoML对数据科学家们来说依然是个能为利益相关者们创造价值的强大工具。因此，接下来要问的一个主要问题是：我们应该如何，以及在什么时候使用AutoML？数据科学家们什么时候能最大化地利用AutoML平台？

接下来我们要提一些可能值得思考的例子。

性能高于可解释性：

有时候，利益相关者们可能只关心模型的精度，而可解释性并不是要考虑的最关键因素。根据我们的实验，把AutoML以及合理的特征工程结合到一起似乎可以达到令人满意的性能。但是，在我们的示例中，可解释性仅限于两个平台的特征重要性。换句话说，如果特征重要性足以解决您的问题，则各AutoML平台可能是您实现更高精度的正确选择。

生产速度：

Google和Azure两家都提供了能方便地将模型部署到生产中的方法。例如，只需单击几下Google Cloud就可以进行批量预测和在线预测。它还允许您使用他们的API将模型部署到您自己的网站上。这些功能选项可以减轻数据科学家们的工作量并加快生产过程。

更好地利用您的时间：

数据科学家们肩上的责任太重大了，压得人喘不过气。对一名数据科学家来说，时间可能是最宝贵的资源了。与利益相关者（产品经理，业务部门的员工，以及客户）开会，维护现有模型，收集/清洗数据，为下一次会议做准备，以及等等其他事情会把您的一天塞得满满当当。AutoML可以被当做一个节省时间的好工具，因为您只需花费几美元，点几下鼠标就可以训练出具有足够性能的模型。因此，您可以更专注于那些能产生最大价值的任务（有时候花时间来准备一次精美的展示，比把模型的准确性提高1％更加有价值）。

哪种AutoML更好？

我们总结了Google Cloud和Azure上的AutoML使用体验，接下来我们讨论一些细节。

用户体验：

在使用Azure时我们遇到了一些错误。当我们在用ASHRAE数据集（约2千万行，30列）训练模型时，三分之一的实验遭遇了失败。我们限制了训练时间，来让两个平台具有可比性，但是似乎对于像ASHRAE这样的大数据集来说，一个小时的时间限制会导致一些错误。但是，当运行较小的数据集（如我们的快速约会数据集）时，过程却很高效。相较而言，我们在Google平台上没有遇到任何问题。

可解释性：

Google的AutoML用的是其享有专利的深度学习算法。因此，就可解释性而言，Google AutoML最多只能打印出特征重要性。另一方面，在Azure中，可解释性基本上取决于您使用什么模型。尽管并不是Azure中的所有模型都比Google的模型解释性更好，但Azure仍然是更加灵活的。例如，如果您使用由Azure调整过的XGB模型，则可以下载模型并在上面运行SHAP，这样就能了解特征如何影响模型的输出。

在您尝试使用AutoML之前的一些提示：

使用Google的AutoML时，把特征选择留给平台负责。如我们的实验所示，在运行Google的AutoML处理数据集之前选择或删除特征会降低性能。一个更好的方法是，在原始数据集上尽量多地添加您认为合适的特征，然后让Google的AutoML来选出最佳特征。

如果您要处理的数据集很庞大，则Google的AutoML可能会是个更好的选择。如果必须要用Azure平台，请务必设置一个更宽松的时间限制（或直接不设置任何限制）以防止潜在的错误。另一方面，如果您的数据集相对较小（少于一百万行），则Azure的表现可能会更好。

给列命名时不要加空格。在这两个平台上，如果列名称中有空格，上传数据集时都会产生错误，因此请确保正确地给列命名！在Python中，建议使用下划线代替空格。

要熟悉评估指标（evaluation metrics）。有时您可能找不到您想要用来训练模型的那个指标，这种情况下您就需要一个代理指标了。因此，了解每个指标的属性可以帮助您选择评估指标，以及选择合适的AutoML平台。

原文：https://towardsdatascience.com/the-death-of-data-scientists-c243ae167701

本文为 CSDN 翻译，转载请注明来源出处。

相关文章：