被忽略的技能:无人谈及但不可或缺的数据科学技能

大数据
本文中,工程是将科学转化为产品的促成因素。如果没有合适的工程技能,模型将继续在预定义的数据集上运行。但他们永远也无法找到真正的顾客。

本文转载自公众号“读芯术”(ID:AI_Discovery)。

用谷歌搜索“数据科学家的基本技能”,搜索结果的前几位是一长串技术术语,叫做硬技能,包括Python、代数、统计和SQL等最普遍的技能。然后是软技能,包括沟通能力、商业头脑、团队合作能力等。

假设你是具备以上所有能力的超人,从五岁起就开始写代码,是一位Kaggle大师,你的会议论文必将获得最佳论文奖。但你的项目仍然极有可能难以达到成熟并成为完全合格的商业产品。

最近的研究估计,超过85%的数据科学项目无法投入生产。一些研究提出了许多失败的原因。笔者甚至从未把所谓的基本技能作为潜在的原因。

是上面的技能不重要吗?当然不是。硬技能和软技能都至关重要。关键是它们是必要的,但仅仅掌握这些还不够。此外,它们很受欢迎,出现在每条谷歌搜索中。因此,你可能已经知道自己是否需要提高数学水平或团队合作能力。

笔者想谈谈对现在流行的硬技能和软技能起补充作用的技能,可称之为工程技能。在与真正的客户一起构建真正的产品时,它们会极其有用。遗憾的是,数据科学家们很少学习工程技能,这有助于丰富行业经验。但大多数初级数据科学家缺少这些技能。

工程技能与数据工程领域无关。用“工程技能”这个词来将其与纯粹的科学或研究技能进行区分。《剑桥词典》里对于engineering(工程)的解释是“运用科学原理来设计和建造机器、结构和其他物品。”

本文中,工程是将科学转化为产品的促成因素。如果没有合适的工程技能,模型将继续在预定义的数据集上运行。但他们永远也无法找到真正的顾客。

重要却经常被忽视的技能包括:

  • 简单性。确保你的代码和模型是简单的,但不是过分简单化的。
  • 鲁棒性。你的假设是错误的。做个深呼吸,继续编码。
  • 模块化,分而治之。深入研究最小的问题,然后找到一个开源解决它。
  • 采摘果实。不要只关注低挂的水果。但要确保你总是有物可挑。

简单性

[[356658]]

图源:shutterstock

  • “如无必要,勿增实体”——奥卡姆的威廉
  • “简单是终极的复杂”——达芬奇
  • “一切都应该尽可能简单,但不要太简单”——爱因斯坦
  • “专注和简单一直是我的秘诀之一”——史蒂夫·乔布斯

关于“简单”的名人名言多得可以占满本文篇幅。研究人员、设计师、工程师、哲学家和作者们都赞扬这种简单性,并表示简单性本身具有价值。他们的理由变了,但是结论是不变的。达到完美的程度不是没有什么要添加的,而是没有什么要删除的。

软件工程师绝对意识到简单性的价值。有很多书籍和文章是关于如何简化软件的。笔者记得KISS的原则(让事情变得简单易懂),这甚至在笔者本科的一门课中讲授过。简单的软件维护成本较低,易于更改,并且不易出现错误。人们普遍认同这一点。

在数据科学中,情况大不相同。有很多文章,例如Kristian Bondo Hansen的《简单的优点:算法交易中的机器学习模型》或Alfredo Gemma的《简单性在数据科学革命中的作用》。但它们是例外,而不是规则。主流的数据科学家们并不在乎最好的时候,而在最坏的时候更喜欢复杂的解决方案。

在讨论数据科学家通常不关心简单性原则的原因,为什么他们应该关心,以及如何处理这些问题之前,让我们看看简单性意味着什么。剑桥词典的解释为,它的本质是易于理解或操作,舍弃不必要或多余的东西或修饰。

笔者发现定义简单性的最直观方法是通过“否定法”,这与复杂性相反。剑桥词典:复杂性是由许多相互连接的部分或元素组成的;错综复杂。虽然我们不能总说某事很简单,但我们通常可以说某事很复杂。我们的目标是不要太复杂,也不要创造复杂的解决方案。

在数据科学中寻求简单性的原因与在所有工程学科中都一样。更简单的解决方案成本要低得多。现实生活中的产品不是Kaggle竞赛。要求不断修改。当复杂的解决方案需要适应新条件时,很快就会成为维护人员噩梦。

不难理解,为什么数据科学家,尤其是应届毕业生,更喜欢复杂的解决方案。他们刚从学术环境中走出来,完成了毕业论文,甚至可能发表了论文。学术出版物的评判标准是准确性、数学巧妙性、新颖性、方法论,但很少以实用性和简单性为标准。

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

那么,如果你、你的老板、同事或下属喜欢复杂而“最佳”的解决方案,该怎么办?如果是你的老板,你很可能注定失败,最好开始找一份新工作。

鲁棒性

[[356659]]

图源:shutterstock

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

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

细心的读者可能会说,鲁棒性也是算法在执行过程中处理错误的能力。这是对的。但这与我们的讨论不太相关。这是一个有明确解决方案的技术话题。

在前大数据时代和前深度学习时代,建立强大系统的必要性显而易见。特征和算法设计都是手动的。测试人员通常对成百上千个例子进行操作。即使是最聪明的算法创造者也不敢说他们能想到所有可能发生的情况。

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

结果表明,鲁棒性仍然是一个重要且尚未解决的问题。每年顶级期刊都会发表关于算法鲁棒性的论文来证明这一点,例如,《提高深度神经网络的鲁棒性》和《基于模型的鲁棒深度学习》。数据的数量还没有转化为质量。用于训练的信息量之大并不意味着可以涵盖所有的情况。

如果有人参与进来,现实总会出乎意料、难以想象。我们大多数人都很难说出午餐吃什么,更别提明天了。数据很难帮助预测人类的行为。

那么,如何使模型更稳固呢?第一种选择是阅读合适的论文并执行他们的想法。这很好。但这些论文并不总是概括性的。通常,不能把一个想法从一个领域复制到另一个领域。

笔者想介绍三种常规做法。遵循这些做法并不能保证创造强大的模型,但它大大降低了出现脆弱解决方案的机率。

性能安全裕度。安全裕度是任何工程的基础。为了安全起见,通常的做法是增加20-30%的要求。一部能承载1000公斤的电梯很容易就能承载1300公斤。此外,测试时它的承载量为1300公斤,而不是1000公斤。工程师为意外情况做好准备。

在数据科学中,什么才是安全裕度?笔者认为是关键绩效指标或成功标准。即使发生意外,仍然会位于临界点之上。

这种做法的重要结果是,你将不再追求渐进式的改进。如果模型关键绩效指标增加了1%,将无法保持强大。在所有统计显著性检验中,环境中任何微小的变化都会扼杀你的努力。

超多测试。忘记单一测试/训练/验证部门。你必须在所有可能的组合中交叉验证你的模型。你有不同的用户吗?根据用户ID进行划分,并进行几十次验证。你的数据会随着时间而改变吗?根据时间戳划分,并确保每天都在验证组中出现一次。在数据点之间使用某些特征的随机值或交换值“滥用”你的数据。然后对脏数据进行测试。

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

模块化

[[356660]]

图源:shutterstock

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

问题越小越好。这里的“越好”并不是完美,这是必须的。它将节省大量时间、精力和金钱。当问题很小、定义明确且没有大量假设时,解决方案便是准确且易于测试的。

大多数数据科学家都熟悉软件设计中的模块化。但即使是最好的程序员,他们的python代码非常清晰,也常常无法将模块化应用于数据科学本身。

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

但笔者发现一些实用的指导原则是有用的:

  • 迁移学习。迁移学习简化了现有解决方案的进程。可以将问题分为两部分。第一部分创建低维特征表示。第二部分直接优化相关的关键绩效指标。
  • 开源。尽可能使用现成的开源解决方案。它使代码按定义模块化。
  • 忘记最佳。真应该从头开始构建针对你的需求优化的系统,而不是调整现有的解决方案。只有当证明你的系统明显优于现有系统时才发现这是值得的。
  • 模型集成。不要害怕采取几种不同的方法,然后将它们放到一起。这是大多数人在Kaggle竞赛中获胜的原因。
  • 划分数据。不要努力创建“一个伟大的模型”,虽然理论上,或许是可能的。例如,如果要预测顾客行为,不要为一个新顾客和已使用服务一年的人建立相同的模型。

采摘果实

[[356661]]

图源:unsplash

产品经理和数据科学家之间始终存在紧张关系。产品经理希望数据科学家专注于低挂的果实。他们的逻辑很清晰,说企业只在乎果实的数量和在哪里生长。拥有的果实越多,做的越好。他们抛出各种各样的流行语——帕累托(Pareto)、最简化可实行产品(MVP)、最好的是好的敌人等等。

另一方面,数据科学家指出,低挂的果实变质快、味道差。换句话说,解决简单的问题影响有限,并且治标不治本。这通常是学习新技术的借口,但又常常是正确的。

笔者个人观点介于这两者之间。读完彼得·泰尔(P.Thiel)的《从0到1》后,笔者曾坚信那些低挂的果实是在浪费时间。在初创公司工作了将近7年之后,笔者确信创建一个低挂的最简化可实行产品是正确的第一步。

最近,笔者开发了自己的方法,将两个极端融合在一起。数据科学家的典型环境是一个充满生机和怪异的世界,树木向四面八方生长。树木一直在变换方向。它们可以倒立或侧向生长。

最好的水果确实是在最顶端的。但是,如果花太长时间建造梯子,那棵树就会移走。因此,最好的方法是瞄准最高处,但要不断监测最高处在哪里。

把隐喻迁移到实践中来看,在漫长的发展过程中事物总有可能会发生改变。原来的问题将变得无关紧要,新数据源将出现,原始假设将被证明是错误的,关键绩效指标将被替换等等。

瞄准顶端是很棒的,但切记每隔几个月推出一款有效产品时做到这一点。该产品可能不会带来最好的果实,但是你会更好地了解果实的生长方式。

这些技能不被人谈及,但却是有助于你职业生涯发展的重中之重,一定要认真体会。

 

责任编辑:赵宁宁 来源: 读芯术
相关推荐

2013-07-30 14:27:14

IT领导

2019-08-05 10:00:13

LinuxBash命令

2024-01-12 07:32:35

数据科学Python库项目

2020-05-07 18:20:52

Git脚本Linux开源

2013-01-04 09:53:32

大数据技术大数据

2020-11-09 06:51:46

开源工具开源

2021-11-30 05:51:46

React开发工具

2013-09-18 09:40:32

企业BYOD企业应用商店

2013-04-25 16:06:01

Windows PhoWindows Pho

2012-04-18 17:06:41

PhoneGap

2017-03-27 17:53:45

Linux

2014-01-09 14:25:19

MacOS X工具

2020-10-27 12:43:53

数据分析技术工具

2011-02-22 08:55:42

Chrome企业浏览器

2019-09-26 18:37:22

数据科学受访者技能

2022-11-08 08:49:09

IT专家职业要素

2022-03-29 10:03:12

IT领导者首席信息官

2023-10-06 12:47:35

模型训练

2014-03-03 11:02:35

开放网络SDN博科
点赞
收藏

51CTO技术栈公众号