成为机器学习工程师第一年，我学到的 12 件事

机器学习工程师再次荣登全球 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. 机器学习的两大障碍

将机器学习应用到实践中存在两大障碍 ，一是从课程学习到项目落地的障碍，二是从电脑模型到实际生产模型的障碍（模型部署）。

在网上搜索机器学习课程，可以找到非常多的内容。我利用其中的一些内容创建了自己的人工智能硕士学位项目。

然而，在我学完许多最优质的课程，并开始成为一名机器学习工程师之后，我的技能还是建立在机器学习课程构建的骨架之上。在现实中，项目根本不是结构化的。

我缺少特定知识，这种技能在课程中是学不到的，比如如何质疑数据、要探索什么以及利用什么。

特定知识：课程中没有但可以学习的技能。

什么是修正？

我很幸运能和澳大利亚最优秀的人才一起工作，我愿意学习，愿意犯错。当然，犯错不是目的，但为了正确，你必须明辨什么是错的。

如果你正在学习机器学习的课程，那就跟着学下去，但同时你也要把所学知识勇于实践，开展自己的项目，用特定知识来武装自己。

关于部署

在这方面我仍然很弱，但我确实注意到了一个趋势————机器学习工程和软件工程正在融合。有了 Seldon 、 Kubeflow 和 Kubernetes 之类的服务，机器学习很快会成为堆栈的另一部分。

你可以在 Jupyter Notebook 上构建一个模型，但是怎样才能让几千人，甚至是几百万人都能获取呢？据我观察，在大公司以外没有太多人知道怎么做。

5. 20% 时间原则

我们有一个 20% 时间原则，意思是我们会用 20% 的时间来学习东西（things）。“东西”一词 的含义较为松散，在这里它指的是机器学习领域的内容，而且相关内容很多。

这一原则不止一次体现了它的价值，比如 我们就是在花 20% 的时间学习时才发现 ULMFiT 优于 BERT。

我们花 20% 的时间来学习就意味着剩下的 80% 的时间会花在核心项目上。

80% 的时间用在核心产品上（机器学习专业服务）

20% 的时间用在与核心产品相关的新事物上

时间不一定总是遵循二八比例进行划分，但有这样一个目标还是很不错的。

如果你的商业优势在于你是自己所在领域的最优秀的，那么未来你的优势应该是继续保持自己作为最优秀人才的地位，而这就意味着不断学习。

6. 被阅读的论文只占十分之一，被使用的就更少了

这是比较粗略的说法， 但如果你去探索任何数据集或现象，很快就会发现它确实普遍存在。 按照 Price 定律的说法，全部作者总量的平方根贡献了一半的出版物。

换句话说，在每年提交的成千上万篇论文中，可能会有 10 篇具有开创性。 而在这 10 篇开创性的论文中，有 5 篇可能来自同一所研究所或个人。

所以结论是?

你无法跟进每个新突破（新突破指的是创新性突破），所以最好学会基本原则，打下坚实基础，再去应用这些原则。 它们已经经受住了时间的考验。

接下来我要说的是探索 - 利用问题（exploration versus exploration problem）。

7. 做你自己最大的质疑者

你可以通过成为你自己最大的质疑者来解决探索 - 利用问题。

这个问题其实是体现了在尝试新事物与旧技重操之间的两难困境。

利用

运行一个你已经用过的模型来得到高精度数字是件很容易的事，你可以把它作为新基准汇报给团队。 但是如果你打算得到一个好结果，就要记得多检查几次你的工作，同时让你的团队也这样做。

探索

我们可以花 20％的时间来进行探索， 但其实 70%-20%-10% 这样的时间划分比例可能更好。 你可以在核心产品上花费 70％的时间，在核心产品的上层构建上花 20％的时间，然后在那些可能进展不顺利的事上花费 10％的时间。

我做机器学习工程师时没有亲身实践过这个比例划分，但现在我正在向这个标准靠近。

8. “玩具问题” 有用

玩具问题（toy problem）是有用的，尤其可以帮助理解一个新概念。先从小处做起，可以先构建一个你自己数据的子集，或者一个不相关的数据集。

在一个小团队工作的技巧就是先让一件事运作起来，然后进行重复迭代, 最后加快速度。

9. 橡皮鸭

我是从 Ron 那里学到这一点的。如果你在一个问题上卡住了，继续坐着盯着代码看可能会帮你解决它，也可能不能。但你还可以和其他的团队成员讨论一下，假装他们是你的橡皮鸭。

“Ron，我正试着遍历这个数组，并跟踪它的状态，与此同时我还要遍历另一个数组并跟踪其状态，然后我想将这些状态组合成一个元组列表。”*

“嵌套循环吗？你为什么不把它向量化？”

“我可以这样做吗？”

“试试看。”

10. 从零开始构建的模型正在减少

这点牵涉到了上文我们提到的机器学习工程正在与软件工程融合这一观点。

除非你的数据问题十分具体，否则许多主要问题都是十分相似的，涉及到分类、回归、时间序列预测及推荐。

谷歌和微软的 AutoML 及其它服务允许那些能上传数据集并选择目标变量的人获取世界一流的机器学习内容，虽然这些服务还处于发展的早期阶段，但它们的势头越来愈强，发展速度也越来越快。

此外，由于 fast.ai 之类的库以及各种 model zoo（一组预先构建的模型，如 PyTorch hub 和 TensorFlow hub）的存在，开发人员只需几行代码就可以调用最先进的模型。
这意味着什么？

了解数据科学和机器学习的基本原则是必须的，但知道如何利用它们来解决问题才更有价值。

现在你的基线可能要么接近先进模型，要么已经称得上先进了。

11. 数学还是代码？

处理客户问题时，我们都是代码优先。 所有的机器学习和数据科学代码都是用 Python 写的。 有时我在阅读论文并重现论文实验结果时会稍稍涉足数学，但 99.9％时间里，现有的框架就已经包含了数学。

这并不是说数学不必要，毕竟机器学习和深度学习都是应用数学的形式。

了解最小矩阵运算、一些线性代数和微积分知识，特别是链式法则，足以让一个人成为机器学习领域的从业者。

请注意，我的目标不是发明一种新的机器学习算法，而是向客户展示机器学习可以为他们的业务提供什么以及不能提供什么。

旁注：在这篇文章的过程中， fast.ai 发布了一个新课程《深度学习基础》，从零开始介绍深度学习涉及的数学和代码知识。 它面向的是跟我一样熟悉深度学习和机器学习应用但缺乏数学背景的人。 为了解决这个问题，我认真学了这门课程，并立刻将它添加到我最喜欢的机器学习和数据科学资源列表中。 如果基础扎实，你可以构建自己的先进技术，而无需在旧技术的基础上再去迭代。

12. 你去年做的工作到了明年可能就没用了

这是必然的。随着软件工程和机器学习工程日益融合，这种情况越来越多。

你所处的就是这样一个多变的领域。

有什么是一成不变的呢？

虽然框架和库都会发生变化，但底层的统计学、概率论以及数学是没有什么终止日期的（适逢 fast.ai 推出新课程，它们恰恰迎来了好时机）。

最大的挑战仍然在于：你如何应用他们。

原文链接： https://towardsdatascience.com/12-things-i-learned-during-my-first-year-as-a-machine-learning-engineer-2991573a9195