谷歌“数据科学家的基本技能”。结果最多的是一长串专业术语，名为hard skills。Python、代数、统计和SQL是一些最流行的方法。后来，就出现了软技能-沟通、商业头脑、团队合作精神等。

让我们假装你是一个拥有以上所有能力的超人。你从五岁开始编写代码，你是Kaggle特级大师，你的会议论文肯定会获得最佳论文奖。你知道吗？您的项目仍然有很高的机会努力达到成熟并成为成熟的商业产品。

最近的研究估计，超过85%的数据科学项目未能达到生产。这些研究为失败提供了许多原因。我从来没有看到所谓的基本技能被作为一个潜在的原因提到过一次。

我是说以上技巧不重要吗？当然，我不是。硬技能和软技能都至关重要。关键是它们是必要的，但不是充分的。而且，它们很受欢迎，出现在每一个谷歌搜索上。因此，机会是你已经知道你是否需要提高你的数学水平或团队合作。

我想谈谈与流行的硬技能和软技能相辅相成的技能。我称它们为工程技能。它们对于与真正的客户一起构建真正的产品特别有用。遗憾的是，工程技术很少教给数据科学家。他们带着经验来的。大多数初级数据科学家缺乏这些。

工程技能与数据工程领域无关。我使用术语工程技能来区分他们与纯粹的科学或研究技能。根据剑桥词典，Engineering是指运用科学原理设计和建造机器、结构和其他项目。在本文中，工程是将科学转化为产品的使能器组件。如果没有适当的工程，模型将继续在预定义的数据集上执行。但他们永远无法接触到真正的顾客。

外卖：

重要且经常被忽视的技能有：

1. 简单化. Make sure your code and your models are simple, but not simplistic.
2. 鲁棒性. Your assumptions are wrong. Take a breath and continue to code.
3. 模块化. Divide and conquer. Dig down to the smallest problem and then find an open-source to solve it.
4. 水果采摘. Don’t focus only on low-hanging fruits. But make sure you have always something to pick.

简单化

“实体不应该不必要地乘以”--奥卡姆的威廉。“简单是终极的复杂”--莱昂纳多·达·芬奇。“一切都应该尽可能简单，而不是更简单”--阿尔伯特·爱因斯坦。“这是我的口头禅之一--专注和简单”--史蒂夫·乔布斯。

我本可以用简单的引文填满整页。研究人员、设计师、工程师、哲学家和作家称赞简单，并表示简单有其自身的价值。他们的理由变了，但结论是一样的。你达到完美不是在没有什么可添加的时候，而是在没有什么可删除的时候。

软件工程师绝对意识到简单性的价值。关于如何使软件更简单的书籍和文章数不胜数。我记得亲吻原则--保持简单，愚蠢--甚至在我的一门本科课程上教过。简单的软件维护成本更低，更容易更改，更不容易出现bug。对此有广泛的共识。

在数据科学中，情况就大不相同了。有许多文章，例如，“简单性的优点：关于算法交易中的ML模型”byKristian Bondo Hansenor“Alfredo Gemma的简单性在数据科学革命中的作用”。但它们是一个例外，而不是规则。数据科学家的主流往好里说并不关心，往坏里说更喜欢复杂的解决方案。

在继续讨论为什么数据科学家通常不关心，为什么他们应该关心，以及如何处理这些问题之前，让我们看看简单性意味着什么。根据剑桥词典，是容易理解或做的品质，是平平淡淡的品质，没有不必要的或额外的东西或装饰。

我发现定义简单性的最直观的方法是通过negativa，作为复杂性的对立面。根据同一词典，复杂性是由许多相互联系的部分或元素组成的；复杂。虽然我们不能总是说某件事很简单，但我们通常可以说某件事很复杂。我们的目标不是复杂，也不是创造复杂的解决方案。

在数据科学中寻求简单性的原因与在所有工程学科中的原因相同。更简单的解决方案要便宜得多。现实生活中的产品不是Kaggle比赛。需求是不断修改的。当复杂的解决方案需要适应新的条件时，它很快就变成了维护的噩梦。

很容易理解为什么数据科学家，尤其是应届毕业生，更喜欢复杂的解决方案。他们刚从学院来。他们已经完成了论文，甚至可能发表了一篇论文。一份学术出版物的评判标准是准确性、数学的高雅性、新颖性和方法论，而很少是实用性和简单性。

一个把精确度提高0.5%的复杂想法对任何学生来说都是巨大的成功。同样的想法对于一个数据科学家来说是失败的。即使它的理论是合理的，它也可能隐藏潜在的假设，这些假设将被证明是错误的。在任何情况下，增量改进都不值得复杂性的代价。

那么，如果你、你的老板、你的同事或你的下属喜欢复杂的“最佳”解决方案，该怎么办？如果是你的老板，你很可能注定要失败，你最好开始找一份新工作。在其他情况下，保持简单，愚蠢。

鲁棒性

俄罗斯文化有一个“沃斯”的概念。维基百科将其描述为“盲目信任神圣的天意，指望纯粹的运气”。Avos是卡车司机决定超载的幕后黑手。它隐藏在任何非鲁棒的解决方案后面。

什么是稳健性？或者具体地说，什么是数据科学中的健壮性？与我们的讨论最相关的定义是“算法的鲁棒性是它对假设模型和现实之间的差异的敏感性”，来自Mariano Scain论文。对现实的不正确假设是数据科学家问题的主要来源。它们也是上面那位卡车司机的问题来源。

细心的读者可能会说，健壮性也是一个算法在执行过程中处理错误的能力。他们会是对的。但它与我们的讨论不太相关。它是一个具有定义良好的解决方案的技术主题。

在大数据和深度之前的世界里，建立强大系统的必要性是显而易见的。特征和算法的设计都是手工完成的。测试通常是在数百个，也许数千个例子上进行的。即使是最聪明的算法创建者也从未假设他们能想到所有可能的用例。

大数据时代是否改变了健壮性的本质？我们为什么要关心我们是否可以使用代表所有可以想象的场景的数百万数据样本来设计、训练和测试我们的模型呢？

它发现鲁棒性仍然是一个重要的尚未解决的问题。每年顶级期刊都会发表关于算法鲁棒性的论文来证明这一点，例如“提高深度神经网络的鲁棒性”和“基于模型的鲁棒深度学习”。数据的数量没有转化为质量。用于培训的信息量并不意味着我们可以覆盖所有的用例。

而如果牵涉到人，现实总会出乎意料，难以想象。我们大多数人都很难说出午饭吃什么，更不用说明天了。数据很难帮助预测人类的行为。

那么，怎样做才能使您的模型更加健壮呢？第一个选择是阅读适当的论文并实施他们的想法。这样很好。但这些论文并不总是可以概括的。通常，你不能把一个想法从一个领域复制到另一个领域。

我想提出三个一般做法。遵循这些实践并不能保证健壮的模型，但它大大降低了脆弱解决方案的机会。

性能安全裕度。安全裕度是任何工程的基础。通常的做法是为了安全起见，采取需求并添加20-30%。一部能装1000kg的电梯，轻松就能装1300kg。而且，它被测试为容纳1300kg而不是1000kg。工程师为意外情况做准备。

在数据科学中，安全边际的等价物是什么？我认为这是KPI或成功标准。即使发生了意想不到的事情，你仍然会在门槛之上。

这种做法的重要后果是，您将停止追逐增量改进。如果您的模型将KPI增加1%，您就不可能健壮。在所有的统计显著性测试中，环境中的任何微小变化都将扼杀您的努力。

过度测试。忘记单一的测试/训练/验证部门。您必须在所有可能的组合上交叉验证您的模型。你有不同的用户吗？按照用户ID划分，做几十次。你的数据随时间变化吗？根据时间戳进行划分，并确保每天在验证组中出现一次。用随机值“垃圾邮件”您的数据，或者在您的数据点之间交换某些特性的值。然后在脏数据上测试。

我发现假设我的模型有错误非常有用，直到证明不是这样。

关于数据科学和ML测试的两个有趣的来源--亚历克斯·古德的博客“用Python进行机器学习，一种测试驱动的方法”。

不要在沙子上建造城堡。减少对其他未测试组件的依赖。不要在另一个高风险且未经验证的组件上构建模型。即使该组件的开发人员发誓不会发生任何事情。

模块化

模块化设计是所有现代科学的基本原则。它是分析方法的直接结果。分析方法是一个将大问题分解成小块的过程。分析方法是科学革命的基石。

你的问题越小越好。这里的“更好”不太好。这是必须的。它将节省大量的时间、精力和金钱。当一个问题很小，定义明确，并且不附带大量假设时，解决方案是准确的，易于测试。

大多数数据科学家都熟悉软件设计中的模块化。但是即使是最优秀的程序员，他们的python代码非常清晰，也经常不能将模块化应用到数据科学本身。

失败很容易证明。模块化设计需要一种方法将几个较小的模型组合成一个大模型。目前还没有这样的机器学习方法。

但我发现有一些实用的指导方针是有用的：

• 迁移学习。迁移学习简化了现有解决方案的使用。你可以把它看作是把你的问题一分为二。第一部分创建低维特征表示。第二部分直接对相关KPI进行优化。
• 开源。尽可能使用开箱即用的开源解决方案。它使您的代码按定义是模块化的。
• 忘记最佳。很容易从零开始构建一个为您的需求优化的系统，而不是修改现有的解决方案。但只有当您能够证明您的系统的性能显著优于现有系统时，它才是合理的。
• 模型集成。不要害怕采取几种不同的方法，把它们扔进一个锅里。这是大多数Kaggle比赛获胜的原因。
• 划分数据。不要试图创造“一个伟大的模式”，虽然理论上，这可能是可能的。例如，如果你处理预测客户行为，不要为一个全新的客户和一个已经使用你的服务一年的人建立同样的模型。

CheckCompositional Deep learning，了解关于深度学习构建块的更多细节。为了科学证明，readPruned神经网络是惊人的模块化。

水果采摘

产品经理和数据科学家之间一直存在着紧张关系。产品经理希望数据科学家专注于低垂的果实。他们的逻辑很清楚。他们说，企业只关心水果的数量和它们生长的地方。水果越多，我们做得越好。他们抛出了各种各样的流行语--帕累托、MVP、最好的是好的敌人等等。

另一方面，数据科学家指出，低挂的水果腐败快，味道不好。换句话说，解决简单的问题影响有限，治标不治本。通常，这是学习新技术的借口，但通常它们是对的。

就我个人而言，我在两种观点之间移动。读过p之后。泰尔的零对一确信低垂的果实是浪费时间。在初创企业呆了将近七年后，我确信创造一个低级的MVP是正确的第一步。
最近，我开发了自己的方法，将这两个极端统一起来。一个数据科学家的典型环境是一个动态的、怪异的世界，树在四面八方生长。树木一直在切换方向。它们可以倒着生长，也可以侧着生长。

最好的水果确实在顶端。但是如果我们花太多时间建造梯子，树就会移动。因此，最好的是瞄准顶部，但要不断监测顶部在哪里。

从隐喻到实践，在漫长的发展过程中，事情总是有可能发生变化。原来的问题会变得无关紧要，新的数据源会出现，原来的假设会被证明是错误的，KPI会被替换等等。

目标是最好的，但记住在每隔几个月推出一个工作产品的同时也要做到这一点。产品可能不会带来最好的水果，但你会更好地感受到水果是如何生长的。