优秀的数据科学家不会创造复杂的模型

作者 | Hari Devanathan

译者 | 王强

策划 | 冬梅

如果你决定成为一名数据科学家。祝贺你！作为一名数据科学家同行，我可以说这一职业是充实和有价值的。话虽如此，现实总是会和人们对工作的期望有差距。

很多有抱负的数据科学家问我他们应该关注什么内容。

我听过的范围包括深度学习 Udacity Nanodegrees、Coursera 上的高级统计分析、Tableau 培训网站上的可视化教程、关于数据管道 /Spark 的软件工程文档等等。虽然这些都是同样重要的，但要关注这么多内容确实并非易事。

当我第一次参加工作时，我并没有掌握所有这些知识，但我只学习了完成手头任务所需的部分。是的，这需要牺牲一些周末和停机时间来学习某种技术。但是，只学习我的确需要的那些信息是很重要的，因为这样我就不会被外面庞大的内容资源所困扰。

成为数据科学家好奇心是必选项

所以，是的，学习新工具和概念的好奇心是必要的。作为一名数据科学家 / 软件工程师，你已经意识到了软件世界的变化有多快。每个月，你的工具所依赖的软件包都会更新。此外，每 6 个月就会有新的软件工具发布，解决你之前试图解决的问题。

此外，我相信还有一项技能是每一位数据科学家都应该掌握的：分析数据的能力。等一下。数据科学家不应该做更复杂的工作吗，比如构建机器学习模型？并非如此。构建一个机器学习模型是非常简单的。假设我想提取 Medium 博客文本来构建我自己的 NLP 分类器。首先我想构建一个标签系统，确定哪些博文是政治、体育相关、商业相关、娱乐相关等等。我真正需要做的是写一行代码来读取文本和相关标签，写一行代码来向量化文本和标签（从文本转换为数字格式），写一行代码来构建一个在文本 + 标签上训练的朴素贝叶斯分类器，写一行代码来将分类器部署到终端（Sagemaker 等）。这一共就 4 行代码，就能在生产环境中构建一个模型了。

当然，也有一些数据科学家可以使用 Pytorch 构建自己的神经网络。这确实需要研究生水平的数学和统计学知识。但这些工作很少见，而且通常是为 FAANG/ 拥有研究工作数据基础设施的公司才会做的。

许多数据科学家坚持使用简单的机器学习模型，并专注于为它们提供正确的数据。确定正确的数据需要分析他们有哪些数据，并提取其中有用的部分。但如果我们想提高预测速度呢？我们不应该有一个复杂的机器学习模型来实现这样的目标吗？也许吧。微软 AI 已经构建了一个惊人的梯度提升模型，称为 Light-GBM。我对它做了测试，并与 XGBoost 做了对比，后者是最快的 skikit-learn 分类器之一。Light-GBM 是轻量级的，所以预测的速度比 XGBoost 快。Light-GBM 还支持并行和 GPU 学习，因此优化了速度。然而在有些情况下不建议使用 Light-GBM。Light-GBM 建议至少有 10,000 个训练数据点才能有效。否则，它很容易过度拟合。

此外，如果你不完全了解一个算法的工作原理，仅仅为了速度而选择该算法是不明智的。

就拿我们前面例子中的 NLP 分类器来说吧。为什么我使用朴素贝叶斯而不是提升算法？为什么我选择朴素贝叶斯而不是决策树算法？原因是，朴素贝叶斯是直接了当的数学方法。这是你能得到的最快速度。它确实是假设你对每个类别 / 标签的观察是相互独立的。但是朴素贝叶斯在速度上优于任何提升算法。提升算法和决策树算法的速度较慢，因为它们需要通过一定的树形路径来获得最佳预测。此外，朴素贝叶斯在较小的数据集上表现良好，而决策树在这些数据集上表现过剩。

退一步讲，从广义上考虑 NLP。当构建一个算法时，你需要为你的模型提供特征。在 NLP 中，这些特征最终是文本中的独特词汇。在一段博客文本中，这可能意味着超过 2000 个特征！其中可能包括过滤掉停顿的词语 / 不必要的词 / 等等。想象一下，构建一个有 2000 个特征的随机森林算法需要多长时间。

在一个 CPU 上构建这个算法需要几个小时，而对一段新的博客文本进行分类可能需要接近几秒钟的时间。在预测速度方面，Boosting 比决策树有进步，但朴素贝叶斯仍然会比任何决策树算法更出色。然而，准确度则是另一回事。决策树算法比朴素贝叶斯更准确，但它们可能过度拟合，这取决于你的数据集。

如果你要为你的公司构建一个 NLP 分类器，你必须了解你可以接受什么样的权衡取舍。这一切都取决于你所拥有的数据，你必须对其进行分析，以确定哪种算法效果最好。

注：如果你想了解这些算法背后的细节，我推荐 StatQuest 来学习更多关于统计学和不同的机器学习算法的知识。有道理，但这不就是数据分析师已经在做的事情吗？数据科学家真的只不过是头衔好听的分析师吗？是的。数据科学家只是比数据分析师拥有更多的技术能力（软件工程、算法设计、云开发）。随着工具越来越容易使用，这种情况在未来可能会改变。好吧，那么为什么我不能让分析师做这项工作，而我则专注于很酷、很复杂的模型呢？你可以这样做，但这只会影响你作为一名数据科学家的发展前景。就像我之前的观点，用干净的数据喂一个简单的模型总是比用糟糕的数据喂一个复杂的模型要好。获得干净的数据需要在你的终端分析数据，以便你能设计一个管道来有效地构建和训练你的模型。

简单的模型也能完成复杂的工作

为了说明这一点，我会分享一个实际案例。在我的工作中，我们的团队正在为病人的医疗记录构建一个 NLP 分类器。我们的客户希望有一个自动化的标签系统，这样他们就可以遍历 1000 页的医疗记录，了解每一页记录都说的什么内容。我们有 50 多个分类标签，范围从心脏状况到脑损伤等等。

我们还得到了每个分类的有限训练数据。我们每个分类有 5 个 pdf，每个有 20-1000 页的长度。我不能告诉你我们解决这个问题的方法细节，总之我们得到了 90% 以上准确率的模型。

我们的团队想知道是否可以将这些模型发布到 Github。我们希望有某种版本历史来跟踪我们为提高模型准确性所做的修改。问题是我们正在分析医疗记录，我们必须确保任何代码 / 脚本 / 模型中没有受保护的健康信息（PHI）的痕迹。如果 Github 资源库对我们来说是私有的，这并不重要；如果 Github 将来发生数据泄露，我们将面临暴露 PHI 的危险。

对于那些不熟悉的人来说，PHI 的范围包括病人的名字、姓氏、SSN、地址、出生日期等。这些信息理论上不会成为模型特征的一部分，而且我们已经删除了所有的痕迹。然而，当涉及到连字符时，病人的名字就很棘手了。以 hailey-hailey 为例，这是一种皮肤病的名字，而不是一个人的姓。对于我们的模型来说，这将是一个相关的特征。因此，在我们保留连字符名字的时候会有一些边缘情况。

我在仔细检查背部受伤模型的模型特征时发现了这个有趣的特征。

注意，由于 PHI 的原因，我不能列出实际的病人姓名。我使用的是一个虚构的人物名字（Emma Geller-Green）。

所以在这种情况下，这是一个出现在某个特征中的某位病人的全名。但我们对它是如何出现的感到疑惑，原因有二：

背部受伤训练数据不应该把一个人的名字作为一个重要的特征。一个人的名字通常在 400 页的医疗记录中出现 5 次，所以对于背部受伤模型来说，这个频率是最低的。此外，在描述背部受伤的页面中，很少提到这个人的名字。我们的停止词列表中有像 emma 这样的名字。由于我们没有解决连字符姓氏的逻辑，所以应该用 green-geller 来代替。emma 应该被删除。

我们接下来仔细检查了光学字符识别（OCR）将这些医疗记录的文本读作什么数据。我们检查后发现，OCR 把 geller-greenemma 读成了一个词。像 Tesseract 这样的 OCR 工具令人印象深刻，在阅读混乱的 pdf 文件时相当准确，但它们离完美还有很远。

所以这解释了为什么 emma 没有被删除。但是，这仍然不能解释为什么背部受伤模型把这个全名作为一个关键特征。我们回到了背部受伤模型的 5 个训练 pdf，打开了一个 40 页的训练 pdf，几乎每一页都被归类为“背部受伤”。令我们惊讶的是，该 pdf 是 20 世纪 80 年代的。那份 pdf 的每一页都有 Geller-Green Emma 的大字标题，而且是加粗的。

一个机器学习模型并不知道什么是“背部受伤”。它只是注意到各种模式并做出假设。Geller-Green Emma 出现在了每一个标记为“背部受伤”的训练页面上，这一事实足以让模型假设这个名字代表了这个特殊的专业。当然，我们的团队添加了逻辑来处理那些 1980 年代的 pdf，并从其中删除了带连字符的病人名字。我们没有创建自己的 PyTorch 模型来处理这个异常，而是直接清理了数据集。这种方法对我们来说更容易测试，更容易快速部署到生产中。

在生产中，一个模型总是会对新的、未见过的数据进行预测，而且很可能在不同的名字上犯同样的错误。在将数据部署到生产环境中时，分析数据和清理数据太重要了。

另外，我不希望仅仅因为我告诉医生"我认为 Emma Geller-Green 的母亲看起来很可爱"而被诊断出有背部问题。

原文链接：

https://towardsdatascience.com/want-to-be-a-valuable-data-scientist-then-dont-focus-on-creating-intricate-models-3fd7569c02e6

你也「在看」吗？👇