原文：
www.kdnuggets.com/2020/11/essential-data-science-skills-no-one-talks-about.html
评论
由 Michael Kolomenkin，AI 研究员
在谷歌上搜索“数据科学家的核心技能”。前几名结果是长长的技术术语列表，被称为硬技能。Python、代数、统计学和 SQL 是一些最受欢迎的技能。之后，是软技能——沟通能力、商业洞察力、团队合作等。
1. 谷歌网络安全证书 - 快速进入网络安全职业的快车道。
2. 谷歌数据分析专业证书 - 提升你的数据分析技能
3. 谷歌 IT 支持专业证书 - 支持你在 IT 领域的组织
假设你是一个拥有上述所有能力的超级人类。你从五岁开始编码，是 Kaggle 的特级大师，你的会议论文肯定会获得最佳论文奖。你知道吗？即便如此，你的项目仍然很有可能难以成熟，成为完全成熟的商业产品。
最近的研究估计超过 85%的数据科学项目未能达到生产阶段。研究提供了许多失败的原因。我没有看到所谓的核心技能被提及作为潜在原因。
我是否在说上述技能不重要？当然不是。硬技能和软技能都是至关重要的。关键在于它们是必要的，但不够充分。此外，它们很流行，出现在每次谷歌搜索中。所以你很可能已经知道你是否需要提高数学能力或团队合作。
我想谈谈那些补充流行硬技能和软技能的技能。我称之为工程技能。它们对于构建真实产品并服务真实客户尤为重要。遗憾的是，工程技能很少教给数据科学家。这些技能通常通过经验获得。大多数初级数据科学家缺乏这些技能。
工程技能与数据工程领域无关。我使用“工程技能”一词来区分它们与纯科学或研究技能。根据剑桥词典，工程*是应用科学原理设计和建造机器、结构和其他物品。在本文中，工程是将科学转化为产品的推动因素。没有适当的工程，模型将只在预定义的数据集上表现良好。但它们永远无法接触到真实的客户。
重要且常被忽视的技能有：
-
简洁性。确保你的代码和模型简洁，但不肤浅。
-
稳健性。你的假设是错误的。深呼吸，继续编码。
-
模块化。分而治之。深入到最小的问题，然后找到开源的解决方案。
-
结果选择。不要只关注唾手可得的结果。但要确保你总是有东西可以选择。
图片来源：shutterstock
“实体不应无必要地增加”——威廉·奥卡姆。“简洁是终极的复杂”——列奥纳多·达·芬奇。“一切应尽可能简单，但不能更简单”——阿尔伯特·爱因斯坦。“这是我的口号之一——专注和简洁”——史蒂夫·乔布斯。
我本可以用关于简洁的引文填满整页。研究人员、设计师、工程师、哲学家和作者都赞扬了简洁，并表示简洁本身具有价值。他们的理由有所变化，但结论始终如一。你达到完美不是当没有东西可以添加时，而是当没有东西可以去除时。
软件工程师完全意识到简洁的重要性。关于如何使软件更简单的书籍和文章不计其数。我记得 KISS 原则——Keep It Simple, Stupid——甚至在我的本科课程中也有教授。简单的软件更便于维护、更容易更改，并且更不容易出错。这一点有广泛的共识。
在数据科学中，情况非常不同。例如，有一些文章，如 “The virtue of simplicity: on ML models in algorithmic trading” 由 Kristian Bondo Hansen 撰写，或 “The role of simplicity in data science revolution” 由 Alfredo Gemma 撰写。但这些只是例外，而非常态。大多数数据科学家最好的情况下不在意，最坏的情况下更倾向于复杂的解决方案。
在讨论数据科学家通常不关心鲁棒性、他们为什么应该关心以及如何处理这一问题之前，我们先来看看什么是简单性。根据剑桥词典，简单性是指容易理解或做的品质，以及朴素的品质，没有不必要或多余的东西或装饰。
我发现定义简单性的最直观方法是通过消极方式，即复杂性的对立面。根据同一本词典，复杂性是由许多相互连接的部分或元素组成的；复杂的。虽然我们不能总是说某物是简单的，但我们通常可以说某物是复杂的。我们的目标是避免复杂，避免创造复杂的解决方案。
在数据科学中寻求简单性的原因与所有工程学科中的原因相同。更简单的解决方案要便宜得多得多。现实生活中的产品不是 Kaggle 比赛。需求不断变化。当需要适应新条件时，复杂的解决方案很快就会成为维护的噩梦。
很容易理解为什么数据科学家，尤其是应届毕业生，喜欢复杂的解决方案。他们刚刚从学术界出来，完成了论文，可能还发表了论文。学术出版物的评判标准包括准确性、数学优雅、新颖性、方法论，但很少考虑实际性和简单性。
一个将准确性提高 0.5% 的复杂想法对于任何学生来说都是一个巨大的成功。而对于数据科学家来说，同样的想法则是失败的。即使它的理论是正确的，它也可能隐藏着证明是错误的基本假设。在任何情况下，增量改进几乎不值得付出复杂性的代价。
那么，如果你、你的老板、你的同事或你的下属喜欢复杂和“最佳”的解决方案该怎么办？如果是你的老板，你可能注定要找新工作了。其他情况下，保持简单，傻瓜。
图片来源：shutterstock
俄罗斯文化中有一个概念叫做avos‘。维基百科将其描述为“对神圣旨意的盲目信任和依赖纯粹运气”。Avos’ 是卡车司机决定超载的原因。而它也隐藏在任何不鲁棒的解决方案背后。
什么是鲁棒性？或者具体来说，数据科学中的鲁棒性是什么？与我们讨论最相关的定义是来自Mariano Scain 论文的“算法的鲁棒性是它对假设模型和现实之间差异的敏感度”。对现实的错误假设是数据科学家主要的问题来源。它们也是上述卡车司机问题的来源。
仔细的读者可能会说鲁棒性也是算法在执行过程中处理错误的能力。他们说得对。但这与我们的讨论关系不大。这是一个有明确解决方案的技术话题。
在大数据和深度学习之前，构建鲁棒系统的必要性已经很明显。特征和算法设计是手动进行的。测试通常是在数百甚至数千个例子上进行的。即使是最聪明的算法创造者也从未假设他们能想到所有可能的用例。
大数据时代是否改变了鲁棒性的本质？如果我们可以使用代表所有可想象场景的数百万数据样本来设计、训练和测试我们的模型，我们为什么还要在意？
事实证明，鲁棒性仍然是一个重要且未解决的问题。每年，顶级期刊通过发表涉及算法鲁棒性的论文来证明这一点，例如“提高深度神经网络的鲁棒性”和“基于模型的鲁棒深度学习”。数据的数量并没有转化为质量。用于训练的大量信息并不意味着我们可以涵盖所有用例。
如果涉及到人，现实总是会出乎意料和无法想象。我们大多数人很难说清楚午餐会吃什么，更不用提明天了。数据很难帮助预测人类行为。
那么，为了使你的模型更加鲁棒，我们应该怎么做呢？第一个选项是阅读相关论文并实现它们的思想。这是可以的。但这些论文并不总是具有普遍适用性。通常，你不能将一个领域的想法简单地转移到另一个领域。
我想介绍三种通用的做法。遵循这些做法不能保证模型的鲁棒性，但它大大减少了脆弱解决方案的可能性。
性能安全边际。安全边际是任何工程的基础。常见的做法是将要求增加 20–30%以确保安全。一个能够承受 1000kg 的电梯可以轻松承受 1300kg。此外，它经过测试能承受 1300kg 而不是 1000kg。工程师为意外条件做好准备。
数据科学中的安全边际是什么呢？我认为是 KPI 或成功标准。即使发生了意外情况，你仍然会高于阈值。
这一做法的重要后果是你将停止追求渐进改进。如果你的模型只提高了 1%的 KPI，你无法做到鲁棒。即使经过所有统计显著性检验，环境中的任何小变化都会破坏你的努力。
过度测试。忘记单一的测试/训练/验证划分。你必须在所有可能的组合上进行交叉验证。你有不同的用户吗？按用户 ID 进行划分，并进行数十次。你的数据随时间变化吗？按时间戳进行划分，确保每一天在验证组中出现一次。用随机值“垃圾”你的数据，或在数据点之间交换某些特征的值。然后在脏数据上测试。
我发现假设我的模型有缺陷直到证明其无误是非常有用的。
关于数据科学和机器学习测试的两个有趣来源——Alex Gude 的博客和“用 Python 进行机器学习，测试驱动的方法”。
不要在沙滩上建造城堡。减少对其他未经测试组件的依赖。绝不要在另一个高风险且未经验证的组件上建立你的模型。即使那个组件的开发者发誓不会出现任何问题。
图片来源：shutterstock
模块化设计是所有现代科学的基本原则。这是分析方法的直接结果。分析方法是一个将大问题分解为较小部分的过程。分析方法是科学革命的基石。
问题越小越好。在这里，“更好”不是锦上添花，而是必需。这将节省大量的时间、精力和金钱。当问题小、定义明确且没有大量假设时，解决方案既准确又易于测试。
大多数数据科学家在软件设计的背景下对模块化有所了解。但即便是最优秀的程序员，他们的 Python 代码清晰明了，往往也未能将模块化应用于数据科学本身。
失败很容易解释。模块化设计需要一种将几个较小模型合并为一个大模型的方法。机器学习中不存在这样的办法。
但有一些我认为有用的实用指南：
-
迁移学习。迁移学习简化了现有解决方案的使用。你可以将其视为将你的问题分为两个部分。第一部分创建一个低维特征表示。第二部分直接优化相关的 KPI。
-
开源。尽可能使用现成的开源解决方案。这使得你的代码在定义上就是模块化的。
-
忘记最优。从头开始构建一个针对你需求优化的系统是很诱人的，而不是适应现有解决方案。但是，只有在你能够证明你的系统显著优于现有系统时，这才是合理的。
-
模型集成。不要害怕采取几种不同的方法并将它们放在一起。这就是大多数 Kaggle 比赛获胜的方式。
-
划分你的数据。不要试图创建“一个伟大的模型”，虽然从理论上讲，这可能是可能的。例如，如果你要预测客户行为，不要为完全新客户和已经使用你服务一年的人建立相同的模型。
详细了解深度学习构建块，请查看 Compositional Deep Learning。要获取科学证明，请阅读 Pruned Neural Networks Are Surprisingly Modular。
图片来源：shutterstock
产品经理和数据科学家之间总是存在着紧张关系。产品经理希望数据科学家专注于易得的成果。他们的逻辑很清晰。他们说，业务只关心成果的数量和它们的来源。我们拥有的成果越多，我们的表现就越好。他们会使用各种流行词汇——帕累托原则、最小可行产品、最好是好的敌人等等。
另一方面，数据科学家表示，容易获取的成果很快就会变质并味道不好。换句话说，解决简单问题的影响有限，只处理症状而非根本原因。通常，这是一种学习新技术的借口，但他们往往是对的。
个人来说，我在这两种观点之间转换。读完 P. Thiel’s Zero-To-One 后，我确信容易得来的成果是浪费时间。在初创公司工作了近七年后，我坚信创建一个低成本的最小可行产品是正确的第一步。
最近，我开发了自己的方法来统一这两个极端。数据科学家的典型环境是一个动态且奇怪的世界，树木向各个方向生长。树木的方向会不断变化。它们可能会向下或侧面生长。
最好的水果确实在树顶。但如果我们花费太多时间搭建梯子，树木可能会移动。因此，最好是以树顶为目标，同时不断监测树顶的位置。
从隐喻转到实践中，长时间的开发过程中总会有变化。原始问题可能会变得无关紧要，新的数据源可能会出现，原始假设可能会被证明是错误的，KPI 可能会被替换，等等。
以树顶为目标是很好的，但要记住在每几个月推出一个有效的产品时做到这一点。这个产品可能不会带来最好的水果，但你会更好地理解水果的生长方式。
简介：Michael Kolomenkin 是三名孩子的父亲，AI 研究员，皮划艇教练，冒险爱好者，读者和作家。
原文。经授权转载。
相关：
-
初级和高级数据科学家的无声区别
-
获取数据科学职位比以往任何时候都难——如何将这一点转为你的优势
-
有志数据科学家的建议