“机器学习工程师”究竟是干什么的？

作者|Tomasz Dudek
译者|Liu Zhiyong
编辑|Chen Debra

AI前线导读：与炙手可热的数据科学家不同，数据科学不分领域部分专业，数据科学家的任务是收集、使用所有数据，而不是某一领域的数据；而机器学习工程师的职责则涵盖了软件工程师和数据工程师的职责，机器学习工程师不仅仅要了解，更要参与到软件架构和设计中去。那么，机器学习工程师究竟到底是干什么的呢？让我们来看看Tomasz Dudek是怎么说的。

O'reilly Data Show最近举办了“机器学习工程师需要知道什么？”的主题演讲，受此启发，我决定对这一富有吸引力的话题上阐述一些事情。虽然我并非一名专家，但我认为，鉴于我有一年半的职业经验，要写一篇关于这一切的简短的总结，应该还是可以的。

机器学习、人工智能和类似的流行词目前都是风投行业的热门话题。初创公司如雨后竹笋，许诺给世界带来一个令人震惊的智能未来。五大巨头为了进一步增加收入，收购了更好的公司。随着企业IT部门的增长，市场对开发者的需求也在不断的增长，这实际上可以交付承诺的人工智能应用。

因此，我们自然而然会想到聘请一个数据科学家团队来实践你的想法，对吧？

嗯，但并不完全是这样的。

不同于软件工程师，数据科学家通常来自不同的背景。他们未必会成为优秀的程序员。事实上，他们从来就没打算成为软件工程师：因为对于一个数据科学家来说，编码仅仅是解决当前难题的手段之一，仅此而已。与软件开发人员不同的是，数据科学家不会将代码视为一种艺术形式。当然，他们的智慧是无价之宝，但作为一个成功的数据科学家所需的技能范围已经很广了（尤其是在这个领域中，新的发现层出不穷，掌握的知识要随之发展，而每天都会有大量的辛苦学到的知识被淘汰）。这技能要求的范围实在太过宽泛了！你不能奢望从事计算机视觉或规范性分析（prescriptive analysis）这种高度专业化的人士也能成为实用的程序员，生产模型并将其放入强可扩展性的云环境中。同时还要让代码保持高质量、可重用。要使用函数式编程，或者响应式编程，或者两者兼而有之。

另一方面，软件工程师在机器学习方面是相当保守的。从他们的角度来看，整个概念是相当怪异的，尤其是当他们的数据科学团队创建的大多数所谓的模型，都是短小的、杂乱无章的脚本，它们会使用奇怪的方法调用不熟悉的语言中的不可读代码。所有的设计模式在哪里呢？干净代码在哪里呢？日志或监控又在哪里呢？为什么代码没有可重用性？解决这个复杂问题的代码不应该超过200行吗？天呐，这是一个非常丑陋的脚本！而且只有一个人可以理解！这还能称之为编程吗？

合并

随着这场冲突的爆发，一种需求应运而生了。需要一个人让交战双方重新团结起来。这个人在这两个领域都能够流畅地掌握并运行产品。他可以采用数据科学家的代码，并使它更有效和可扩展。他能够向他们介绍各种编程规则和良好的实践。他能够抽象出将来可能使用的部分代码。他还能加入可能无关任务的结果，以进一步提升模型的性能。他可以向开发运维团队解释设计意图背后的原因。他能够使软件开发人员的学习概念的方式免于超出他们的兴趣范围。

满足了这些要求，这个人就足以担任机器学习工程师。

所有关于机器学习的文章、教程和书籍，始终缺少的就是生产环境。它根本就是不存在的。数据从CSV中加载，模型在Jupyter中创建，并绘制ROC曲线。瞧，你的机器学习产品已经启动并正在运行，再来一轮种子基金吧！

等一等。

实际上，大部分代码都与机器学习无关。事实上，关于它的代码通常只占整个代码库的几个百分点！你的预训练黑盒给你的答案只是少量的JSON：有数千行代码需要根据这个预测来执行。或者，也许你得到的只是一个带有见解的生成数据库表。再次，整个系统需要建立在它之上以使其变得有用！你必须获取数据，进行转换并对其进行munge，让你的工作自动化，并向最终用户提出你的见解。无论问题有多小，即使你用诸如Apache Airflow或NiFi之类的技术来引导你的项目，机器学习本身要完成的工作量也是巨大的。

然而，必须有人将所有的“数据科学”和“软件”部分粘合在一起。这个人能够采取已训练的模型，使其在高质量的生产环境中工作。他还能计划批处理作业重新计算洞察表。他能够创建实时服务模型并在自然环境下监控其性能。而这些工作内容正是机器学习工程师所擅长的领域。

在创建软件时，开发人员自然会在应用程序中的每个部分寻找所有可能的结果。而你从数据科学家那里得到的只是一条“愉快路径”（译注：happy path，是指编写程序的基本逻辑代码。这意味着编写适用于基本条件的代码，即所有的数据都是可用的，所有的条件符合预期），它只会在特定的时刻，为特定的数据创建模型。除非是一次性的具体分析，否则该模型将在投入生产之后会存活很长一段时间。随着时间的流逝，bug和所有边缘情况都会出现（在编写代码的时候，其中很多情况都是不可能的）。突然之间，一个新的未知值出现在一列中，整个模型的表现开始变得更糟了。

作为一名机器学习工程师，你可以为这些事件准备应用程序。你不仅可以在机器学习任务中提供日志和监控流水线，还可以提供它们内部的日志和监控流水线。你试图保存所有的信息，这样就可以回答非常重要的问题：模型性能不良的原因是什么？从什么时候开始发生的？

它只是另一个API

因为你不将机器学习视为魔法，因此你会知道，在执行机器学习任务时也可能会出现所有其他的典型编程危险。比如数据库可能会拒绝连接；GroupBy可能会放大大型数据集；内存或磁盘可能已满；用户指定的参数组合对某些算法而言是非法的；外部服务可以使用超时异常而不是凭据响应；列可能不再存在。当这些事件每天都在安全的实验室环境中进行时，没人会关心，但你有责任确保在最终产品交付时，不会发生这些情况。

机器学习项目角色

数据科学团队总是充满着各种想法。你必须确保没有技术限制他们。团队提出的想法就像现在的机器学习框架一样好，还可以定制，你的队友迟早会有一个令人感兴趣的用例，而这些用例对任何一个人来说都无法实现。嗯，不是用标准的API。但是，当你深入研究它们的内部时，稍微调整一下，然后在另外一两个库中混合使用，就可以实现了。你勤用这些框架并充分发挥它们的潜力。这就需要你拥有广泛的编程和机器学习的知识，这是对于你在团队中所扮演的角色的独特要求。

即使机器学习框架提供了所有你需要的编程方式，仍然有可能存在缺乏计算能力的问题。大型神经网络需要大量时间进行训练。如果你使用在强大的机器上运行的GPU框架，那么这个宝贵的时间可以减少一个数量级。你可以查找各种可能性，查看各种云选项的优缺点并选择最合适的选项。

你还可以负责挑选其他工具和生态系统，并始终考虑整个项目的周期（而不只是鲁莽的研究部分）：例如Azure ML Workbench或IBM Waston可能就是引导项目和开展研究的绝佳工具，但在定制调度和监控方面，它们不一定满足最终版本产品的所有要求。

你必须及时了解最先进的技术，并不断寻找可以改善整体产品性能的地方。无论是久经沙场的编程语言，或者云中的新技术，还是智能调度或监控系统，通过更大的图景审视你的产品，并从工程、商业和科学方面都了解它，你通常是唯一有机会发现潜在改进领域的那个人。

这些通常意味着采用工作代码并将其完全用另一种技术和语言来重写。值得庆幸的是，一旦你“掌握了”这个模糊实际上是什么，以及在学习和生产模型的过程中总是采取了什么步骤，你就会发现，大多数这些API并没有什么不同。当你在各种框架之间进行切换时，整个过程中的绝大部分都保持不变。你带来所有最好的软件工艺实践，并迅速开始构建对数据科学团队无法实现自动化且软件开发团队不敢面对的许多重复性任务的抽象。你是两个世界之间的坚固桥梁，带给他们一个可靠的、健壮的工作软件基础。

未透露的的缺点

你可以自由地与业内所有最热门的技术交流：Keras、pyTorch、TensorFlow、H2O、scikit-learn、Apache Spark……选择一个名字，你可能会用到它。Apache Kafka！Pulsar！AWS！你参加的每一个会议都会大声讨论你的技术栈，就好像它是“天之骄子”一样。人们嫉妒地看着你，知道你就是那个使用最酷的东西的家伙。

有一件经常被忽略的事实是，那些很酷的东西，碰巧不是被广泛使用的东西。而当技术是新出的时候，你就只剩下槽糕的文档和一堆博客文章。你在会议和技术讲座上看到的只是快乐的绿径（类似你从数据科学团队获得的Jupyter notebooks）。你知道这不是软件的工作方式。很多时候，经过几小时的Apache Spark内部调试之后，我质疑自己是否还将继续从事机器学习的编程生涯。如果没有这一切，我会不会更快乐？Web开发真的有那么无聊么？

无论是在软件开发还是数据科学的领域中，你都应该了解许多概念。最重要的是，人们希望你能很快获得新知识。我通过拾起别人的代码片段，改变并打破它们，看看会发生什么，就这样我学到了很多东西。如果没有代码片段呢？你得到的堆栈跟踪（stacktrace）非常没有意义，你在Google上以这些异常名称进行搜索，你将只会找到GitHub上的代码，然后无奈放弃这个搜索结果？

甚至连四分之一的流行词汇都没有显示出来

在某些领域，学习和理解的曲线非常陡峭，特别是在实施用白皮书编写的想法时，尤为如此。正如这些趋势一样，它们很酷（有时也很奇特），它们的形式总是非常科学，只是逐步了解它们会耗费更长的时间。然后就是编码部分，这块要完全靠你自己了。即使你的应用程序编译的很好，并且不会到处抛出运行时异常，但通常不清楚如何确保你的实现能够正常工作。如果没有这个情况时，你就会思考你的代码是否存在bug，数据是否有偏差，或者整个想法可能并不适用你的用例。

要跟上数据科学的步伐已经很困难了。当你投入到经典软件开发和云技术时，你的大脑可能很快就会变得不知所措。你必须把你的学习资源组织好，源源不断地汲取新的知识。同时也要接受这样的一个事实：就是所有行业的“万金油”（译注：指博而不精的人）都有其缺点，因为你可能永远不会在你的领域中有着很深的学问。冒名顶替综合征（imposter syndrome kicks）的症状非常严重，而且是经常发生的。

但对有些人来说，这确实是一份理想的工作。合并两个如此相似但又如此不同的世界。

一名数据科学全栈开发人员真的是一份理想的工作，因为他连接了数据科学家和软件工程师的两个不同的世界。

总结

机器学习工程师应该做到以下几点：

• 断言所有生产任务在实际执行和调度方面都能正常工作；
• 勤用机器学习库，将机器学习库的作用发挥到极致，经常添加新的功能；
• 确保数据代码具有可维护性、可扩展性和可调试性；
• 自动化和抽象在大多数机器学习任务中存在的不同的、可重复的例程；
• 为数据科学团队带来最好的软件开发实践，并帮助它们加速工作；
• 与开发运营团队一起选择最佳运营架构；
• 不断寻求性能提升，并确定在生产环境中使用哪种机器学习技术。

原文链接： But what is this “machine learning engineer” actually doing?
https://medium.com/@tomaszdudek/but-what-is-this-machine-learning-engineer-actually-doing-18464d5c699