机器学习工程师再次荣登全球 IT 高薪榜单，但是成为一名机器学习工程师却没那么简单。你不仅要处理代码中的各种问题，还需要不断学习、与其他部门的人员沟通、了解和学会使用各种新型代码库或模型……成为机器学习工程师的第一年，本文作者 Daniel Bourke 学到了 12 件重要的事，在此与你分享，如果你有共鸣，欢迎点赞和留言。

机器学习和数据科学都是含义较为宽泛的术语。举个例子，即便两人同为数据科学家，他们所做的事也可能大不相同。机器学习工程师也同样如此。两者的共同之处在于利用过去的（数据）来理解或预测（构建模型）未来。

我会先介绍一下我当时的角色，然后再展开讲述本文的要点。

当时我们有一个小规模机器学习咨询团队，从事数据收集、数据处理、模型建立及服务部署等各个环节的工作，凡是你能想到的任何行业，我们都有所涉及，所以每个人都身兼数职。

我使用“当时”这两个字眼是因为我现在已经不是一名机器学习工程师了，目前我专注于自己的事业。 你可以查看我做的一个视频。

作为机器学习工程师的一天

每天早上九点，我走进工作室，和同事打完招呼，把食物放进冰箱，泡上一杯咖啡，再走向我的办工桌。接着我坐下来开始看前一天的笔记，打开 Slack，查看新消息和团队分享的论文或博客链接。我总会发现一些可以阅读的内容，因为这个领域发展很快。

处理完消息，我就开始浏览论文和博客，然后阅读其中吸引我的内容。通常情况下，我都会读到一些可能对我正在研究的问题有帮助的内容。阅读时间一般会花费一个小时，有时会更长，视具体内容而定。

为什么用这么长的时间？

阅读是最基本的元技能，如果还有比这更好的方式，我会去学习和使用，好让自己节省时间和力气。

时针转到上午十点。

如果有一个项目的截止日期快到了，我就会缩短阅读时间，转而推进紧急的项目，这部分工作占用的时间最多。我会回顾自己前一天的工作，然后查看我的记事本看下一步要做什么。

我的记事本记的是当天的日志。

“我已经将数据处理成了正确的形状，现在我需要在模型上运行它。开始阶段我会设置一个较短的训练时间，取得一些进展后再逐渐延长。”

我也会遇到困难。

“出现了数据不匹配的情况。接下来我需要解决数据不匹配的问题，在尝试新模型前得到一个基线。”

大多数时间都用来确保数据形式能够成为模型。

下午四点，我开始进行收尾工作。我会清理一下自己创建的混乱代码使其清晰可读，然后添加一些注释，最后再进行重构。万一别的人会读呢？我一般都会这样想。当然通常情况下读的人会是我自己，因为我很快就会忘记当时的一连串想法。

下午五点我的代码就已经传到 GitHub 上，第二天要用的笔记也已经记好了。

上面描述的是理想状态下的一天，并不是每天都是如此。有时到下午 4：37 了，我的脑子里会突然蹦出一个好想法，然后我就得把它实践下去。

现在你已经大致了解了我作为机器学习工程师的一天是怎样度过的，接下来我会带你了解一些更具体的内容。

1. 最重要的是数据

如果你熟悉一些数据科学的第一原理，这点对你而言不过是老生常谈。 但奇怪的是我经常会忘记它。很多时候我们关注的是构建一个更好的模型，而非改善构建模型的数据。

构建更大的模型、使用更多算力可以带来不错的短期效果，但是，捷径走多了，最后就不得不走一些远路。

第一次接触一个项目，多花些时间熟悉数据。通常情况下，你首先会估计出一个时长用来熟悉数据，而所谓的“多花时间”就是多花两倍的时间。长远来看，这样做会节省你的时间。

这并不是说你不应该从小处着手。后文会谈到这一点。

面对新的数据集，你的目标应该是成为一名行业专家。你需要检查数据集的分布情况，寻找不同种类的特征、异常值的位置，并了解为什么它们是异常值。如果你都不能了解自己正在处理的数据，又怎么能指望你的模型呢？

探索性数据分析生命周期示例（每次遇到新数据集你会做的事）。更多相关内容可参考《探索性数据分析入门》

2. 沟通问题比技术问题更困难

我遇到的主要问题都不是技术性的，而是沟通层面的。当然，技术难题总是存在的，但解决它们不就是一名工程师的工作吗？

不要低估沟通的重要性，不管是外部沟通还是内部沟通。没有什么比解决错了技术难题更糟糕了。

这种情况是怎么发生的？

从外部层面上看，问题在于客户的需求与我们团队能提供的服务以及机器学习可以提供的服务之间不匹配，当然，跟后者的关系更大。

从内部层面上看，由于团队成员往往身兼数职，因此很难确保每个人都目标一致。

这些挑战并不独特。机器学习看起来很奇幻，在某些情况下确实如此，但在另外一些情况下就不是了，承认这一点很重要。

外部沟通问题如何解决？

经常联系。你的客户了解你能提供什么服务吗？你理解客户的问题吗？客户理解机器学习能提供什么，不能提供什么吗？什么样的方式才能有效传达自己的发现？

内部沟通问题呢？

你可以根据解决内部沟通问题的软件工具的数量来判断内部沟通有多难。 这些工具有 Asana、Jira、Trello、Slack、Basecamp、Monday 及 Microsoft Teams。

我找到的最有效的方法之一是在一天结束时在相关项目的交流通道中简单更新一条消息。

更新内容包括：

三至四项我做了什么为什么这么做

下一步：

根据以上内容，我接下来打算做什么

这种方式完美吗？ 不，但它似乎有效。 它让我有机会反思我做了什么以及想做什么。这样做还有一个额外的好处是公开化，这意味着如果有人不满意我的工作，我可能会受到批评。

作为工程师你有多优秀并不重要，影响你能否维护和获得新业务的是你的沟通能力，也就是你能不能把自己的技能及其带来的好处传播出去。

3. 稳定性＞先进性

我们碰到过一个将文本进行分类的自然语言问题。我们希望，用户在将一段文字发送到一项服务后，这段文字能被自动划分到两类中的一类。如果这个模型对预测结果不自信，这段文字就会被传送给人工分类员。每天可以发起 1000～3000 次分类请求，从数量上看不多也不少。

BERT是今年的热门，如果没有谷歌的规模计算，训练一个 BERT 模型来做我们需要做的事需要大量数据改动。这还只是投入生产之前。

于是我们使用了另一个方法ULMFiT，从理论上看它不是最先进的，但仍能产生非常多的结果，且使用起来更加容易。

与其执着于在一个东西上追求完美，不如尝试其它有用的东西，这会带来更多价值。

4. 机器学习的两大障碍

阅读全文，点击“了解更多”