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

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

我们的代码通常分为五类，各个代码行数占总代码行数的百分比为：数据管道(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」时，一切都神奇地运行起来——这在大学里的编程作业中只发生过一次。我将终生记住这种感觉。如果它在现实生活中再次发生，很可能是出了问题。

（编辑：西安站长网）

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