数据科学很性感？不，其实它非常枯燥！

本文主要是介绍数据科学很性感？不，其实它非常枯燥！，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

来源：大数据文摘

本文约3300字，建议阅读10分钟

本文作者将告诉大家自己如何应对“数据科学中那些枯燥的工作”。

很多人把数据科学（或者机器学习）工作描绘的令人向往，激励自己和别人加入其行列。大家把数据科学想得非常完美，事实上它容易让人感到“枯燥”。一旦感到枯燥，你就容易焦虑。如此，导致数据科学工作的离职率非常高。

希望能够对你有所帮助，让你对数据科学有一个正确的认识，让你在决定走上数据科学的征途时，好好享受这场漫长的游戏！

第一课

我的表弟Shawn是个年轻英俊的小伙，最近他来了加拿大攻读计算机硕士学位。和很多学生一样，Shawn对机器学习充满热情。他希望过2年毕业的时候，可以成为一名数据科学家，或从事其他与机器学习有关的工作。

身为Shawn的表哥，我也关心Shawn是否成功，我决定以自己数据科学生涯的教训，给他提供最谨慎的建议。《哈佛商业评论》杂志将数据科学称为“21世纪最性感的工作”，但它和其他职业一样会让人觉得枯燥，甚至使人心力交瘁，你还会屡屡受挫。

即便这些话会让Shawn感到失望，我还是有义务把事实告诉他。希望他对自己选择的职业道路有充分的了解。更重要的是，我不希望凌晨3点会接到我妈和叔叔的电话，告诉我作为家庭一员，有义务花耐心去好好指导晚辈。

Shawn十分聪明、积极进取且富有好奇心，他让我详细地给他说说，数据科学到底多枯燥。因此，我写了这篇帖子。

一些背景说明

首先，为了便于理解本文，我先介绍下自己是怎么进入数据科学行业（具体可以看我的领英）。作为一名数据科学经理，我不仅负责领导团队为财富100企业部署机器学习系统，还要管理客户关系，自己也会承担一部分的技术工作。

更重要的概率是：机器学习系统应是用于解决特定业务领域问题的一整套方案，除去机器学习组件，还要处理其他与人或系统相关事情。

部署系统意味着解决方案对实际业务运营有效。举例来说，搭建实验环境用于训练和验证机器学习模型称不上是部署，但如果搭建一个每月邮件发送产品服务的推荐引擎可以算是部署。相比较构建一个好的机器学习模型，部署机器学习系统需要攻克更多的难题。若是感兴趣，可以点击此处详细了解。

所以，我不会介绍如何在谷歌或其他高科技公司，从一名初级开发人员成长为技术经理。虽然这些公司在机器学习颇有成就，但他们只能代表“前1%”的公司。因为其他财富100企业在技术成熟度、技术采用的速度以及投资工具和工程人才储备方面都相对滞后。

AI学术让我们仔细看看

不少年轻数据科学家花费很多时间思考如何构建完美的机器学习模型，或者采用丰富多彩的视化手段向大家展示具有突破性的商业洞察。当然，这些确实算一部分工作。

然而，随着数据科学被广泛使用，企业更关注其实际的应用价值。企业想要部署越来越多的机器学习系统，但他们不关注系统使用了多少新的模型或者酷炫的仪表板。因此，数据科学家需要处理一堆与机器学习无关的工作，从此工作就变得枯燥起来。

数据科学有多枯燥？看看我周一到周五做点什么就知道了。接下来，我把日常工作进行分类阐述，从期望和现实两方面对比说明，并分享我的应对策略。

下面列举的案例都源自过往实验和团队项目，我将以“我们”的口吻来叙述。虽然这些案例可能并不详尽，但也足以论证我的观点。

设计（占5-10%时间）

在设计阶段，我们发挥各自最“高”智慧来解决问题和提出卓越的想法。这些想法可以包括新的模型体系结构、数据特性和系统设计等。但很快，我们就陷入低谷，受时间因素或受其他重要事情影响，我们只能采用最简单（通常也是最无聊）的解决方案。

期望：

我们的想法将被收录于著名的机器学习杂志，如NIPS、谷歌AI项目（Google AI Research）等，还幻想赢得下一届诺贝尔奖。

现实：

部署后一切正常运行。不错的白板绘图会拍照记录下来，作为参考框架。

应对策略：

1）不断与外行朋友谈论我们疯狂的想法，他们会十分诚实（甚至是粗鲁）地劝我打消那些疯狂、愚蠢的念头；

2）把看似疯狂的好想法作为附带项目；

3）结果发现，大部分疯狂的想法不起作用，或者只是比简单方法稍微好一点点。

所以，遵循简单原则（KISS，Keep-It-Simple-Stupid），让我如释重负。

编程（占20-70%时间，取决于你的开发角色）

此处不必多讲，想象你戴上耳机，喝一个口咖啡，拉伸你的手指，坐在在电脑屏幕前，敲打出一行行漂亮的代码后，坐等奇迹发生。

我们的代码分为5部分（此处用代码行数占比说明）：数据管道（50-70%），系统和集成（10-20%），机器学习模型（5-10%），调试和演示支持（5-10%）。其他同行基本也是这么认为的，这里有一幅大图可以说明此：

编写模型的代码占比（图），此处有一篇来自谷歌团队论述机器学习的隐性技术债的文章。

如你所见，我们大部分时间在处理与机器学习无关的事务。虽然机器学习组件非常重要，流行框架和编程语言（如Keras、XGBoost、Python的sklearn等）已经帮助我们减轻了许多繁杂的工作。为了达到目的，我们不需要很重的代码库，工作流已经是标准化和相对完善。虽说做底层优化不同，但其影响也就1%。

期望：

大部分时间我们在开发和重塑机器学习组件，其他人关注剩余部分。

现实：

没人愿意

1）做自己不想做的事情；

2）把所有事都留给自己做；

3）花费大量不成比例的时间去优化已经足够完善的工作流程。

应对策略：

我们依据各自的专业特长做设计决策，除了完成自己的开发工作，同时还会支持其他人。（例如，贡献想法、亲手写代码或者做质量评估）。我们互相学习，从而提升团队水平。更重要的是，如此可以缓解这份“性感工作”所带来的焦虑。

质量评估、调试和修复问题（起码占65%时间）

在我看来，这所有技术工作里最没劲、最痛苦的部分。部署机器学习系统也不例外。

一个机器学习系统有2类常见的bug：不好的结果和常见软件问题。不好的结果可能是模型得分太低（例如：准确性和精准度）或难以解释的预测结果（例如：基于业务经验的预测概率呈现偏态分布）。代码没有问题，只是结果不具有解释性或者不够好。常见软件问题则是诸如代码无法运行，系统配置等。

期望：

我们用更聪明的方法构建一个优化的模型就可以解决结果不佳的问题。这个过程需要一些智慧，如果想法可以凑效，那还是非常令人欣慰的。

现实：

在质量评估、调试和处理缺陷的过程中，我们有近70-90%时间在处理常见软件问题。通常，我们构建端到端的训练和验证管道后，可以很快得到好结果。然而，实际我们更关注系统问题，模型则次之。

应对策略：

我用GitHub的issue功能建立了一个游戏化的“奖杯板”。每次关闭问题卡片的时候，我都非常兴奋。看到我们“征服”的问题，我会感到十分骄傲。当然，如果我点击“启动”一切都能够奇迹般的正常运行，我会更加骄傲。虽然这一幕只在大学提交编程作业的时候出现过。我一生都记得那一刻的感觉。如果现实生活中再次发生，那可能是什么东西出错了。