一个数据科学负责人眼中的数据科学：太无聊了!

这里没什么好说的。在这个阶段，我们戴上耳机，喝点咖啡，伸展手指，锁定屏幕，打出漂亮的代码行，让魔术发生。

我们的代码通常分为五类，各个代码行数占总代码行数的百分比为：数据管道(50-70%)、系统和集成(10-20%)、ML 模型(5-10%)、支持调试和演示的分析(5-10%)。这与其他人的观察结果大致一致。

如你所见，我们大部分时间都在处理无聊的非 ML 内容。尽管 ML 组件非常关键，但现代的框架和编码语言(例如 Keras, XGBoost, Python 的 sklearn 等)已经将许多复杂的东西抽象出来了。这意味着实现我们需要的结果不需要沉重的代码库;工作流已经很好地标准化和优化了(做低级优化是不同的，但它可能只是 1% 的情况)。

预期：你将花费大部分时间开发和优化 ML 组件，其他人将负责其余部分。

现实：没有人希望 1)做你不想做的事情，2)你把所有的好东西都留给自己，3)你在一个已经很好优化的工作流程上花费了不相称的时间。

应对机制：我们都会根据自己领域的专业知识做出决策，并在对他人发挥支持作用的同时成为自己领域的主要开发人员(例如，贡献想法、进行实际开发或 QA)。这样做可以让我们在向他人学习的同时发挥自己的优势。更重要的是，它有助于避免为了做「性感的工作」而产生矛盾。

3.3 QA、Debug 和修复 Sh*t(至少 65% 的时间)

在我看来，这是任何技术开发工作中最无聊、最痛苦的部分，开发 ML 系统也不例外。

在 ML 中，有两种类型的「bug」：糟糕的结果和传统的软件问题。糟糕的结果是指低分数模型(例如，准确性或精确性)或不敏感的预测(例如，基于商业经验的概率非常不准确)。代码没什么问题，只是结果不合理或不够好。传统的软件问题包括诸如代码损坏或系统配置等问题。

预期：我们只需要处理糟糕的结果，并想出更聪明的方法来建立更好的模型。这件事情还是有点吸引人的，看到由于一些好的想法而提高表现是非常值得的。

实际情况：在我们花在 QA /debug/apply 修复上的时间中，大约 70-90% 是在传统的软件问题上。通常，在建立端到端的模型训练和验证流程之后，我们可以相当快地获得足够好的结果。然后，我们经常将建模的优先级降低，以关注系统问题。

应对机制：我使用 github 的 Issue 特性将其游戏化并保留一个「奖杯板」。当我关闭 issue 时，我会立刻分泌多巴胺。看到我们「征服」的问题，我感到更加自豪。当然，我更自豪的是，当我点击「go」时，一切都神奇地运行起来——这在大学里的编程作业中只发生过一次。我将终生记住这种感觉。如果它在现实生活中再次发生，很可能是出了问题。

3.4 应对突发事件(10-50% 的时间)

对于任何交付团队的经理来说，这都是一场噩梦，而不是数据科学。不管时间线是怎么安排的，总会有事情发生，让你偏离正轨。具体来说，这些突发事件可以分为三类：a)外部问题，如范围更改、上游系统依赖性和客户投诉;b)内部团队问题，如恼人的 bug 需要比预期长得多的时间才能解决;人们需要过渡来适应新的工作内容得到新的工作;人员配备，性格冲突等，C)我自己的无知等等其它问题。

期望：从头到尾按部就班;来自客户、老板和团队的热烈掌声和拥抱。

现实：意想不到的事情通常发生在最不方便的时候。没有什么万全的办法来避免这些问题，这令人沮丧。

应对机制：1)将项目的时间线乘以 2-2.5 倍，以便在涉及到深层次的技术问题或跨团队活动时留出足够的缓冲空间;2)在内部设定进度时要有紧迫感;3)我在脑海中大声发誓，好吧，在适当的情况下，有时会口头发誓;4)呼吸、微笑和倾听，5)与团队一起探索所有可能的选择，并根据可行性、需要的努力和阻力确定优先顺序，6)如果这些都不起作用，不要等待，寻求帮助!7)执行。其中许多机制本身并不是应对机制，但它们是良好的做法，且一直运作良好。

4.总结

我想强调的是，每个人都需要有一个应对机制。

所有这些都是想告诉你，现实世界的数据科学是困难的。有志于从事 ML 职业的人应该认识到，除了建立模型之外还有很多事情要做。你最终会感到无聊和沮丧，就像你对任何职业一样。这是正常的。但最重要的是，你应该建立一个应对机制，这样你就可以长期留在这个游戏中，享受一路上的小奖励和最后的胜利。

本文转自雷锋网，如需转载请至雷锋网官网申请授权。

（编辑：济南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!