12 things I learned in my first year as a machine learning engineer 12 things I learned in my first year as a machine learning engineer

Machine learning and data science are both broad terms. For example, even if two people are both data scientists, what they do may be very different. The same is true for machine learning engineers. What the two have in common is to use the past (data) to understand or predict (build a model) the future.

I will first introduce my role at the time, and then expand on the main points of this article.

At that time, we had a small-scale machine learning consulting team, engaged in data collection, data processing, model building, and service deployment. We are involved in any industry you can think of, so everyone takes the number Job.

I use the word "at the time" because I am no longer a machine learning engineer, and I am currently focusing on my own business. You can view a video I made.

A day as a machine learning engineer

Every morning at nine o'clock, I walk into the studio, finish greeting my colleagues, put food in the refrigerator, make a cup of coffee, and then walk to my office desk. Then I sat down and started reading the notes from the previous day, opened Slack, and checked the new messages and links to the papers or blogs shared by the team. I always find something to read, because the field is developing very fast.

After processing the message, I started to browse the papers and blogs, and then read the content that attracted me. Under normal circumstances, I will read something that may be helpful to the problem I am researching. Reading time generally takes an hour, sometimes longer, depending on the specific content.

Why does it take so long?

Reading is the most basic meta-skill. If there is a better way than this, I will learn and use it so that I can save time and energy.

The hour hand goes to ten o'clock in the morning.

If the deadline for a project is approaching, I will shorten my reading time and move on to urgent projects. This part of the work takes up the most time. I will review my work the day before, and then check my notepad to see what I am going to do next.

My notepad keeps track of the day’s diary.

"I have processed the data into the correct shape, and now I need to run it on the model. At the beginning I will set a shorter training time and gradually extend it after making some progress."

I will also encounter difficulties.

"There is a data mismatch. Next I need to solve the data mismatch and get a baseline before trying a new model."

Most of the time is spent ensuring that the data form can become a model.

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

下午五点我的代码就已经传到 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 推出新课程,它们恰恰迎来了好时机)。

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


Guess you like

Origin blog.51cto.com/15060462/2678070