王咏刚：为什么 AI 工程师都要懂些架构？

21CTO导读：如今的AI工程师炽手可热，刚入行的同学AI年薪在30-45万左右，可见其多金程度。人工智能工程师大多数以算法为主，这样会存在一些小问题。本文王咏刚先生就阐述AI工程师如何懂得一些架构，会更有价值。

AI 时代，我们总说做科研的 AI 科学家、研究员、算法工程师离产业应用太远，这其中的一个含义是说，搞机器学习算法的人，有时候会因为缺乏架构（Infrastructure）方面的知识、能力而难以将一个好的算法落地。
 
我们招的算法工程师里，也有同学说，我发的顶会 paper 一级棒，或者我做 Kaggle 竞赛一级棒，拿了不少第一名的，不懂架构就不懂呗，我做出一流算法，自然有其他工程师帮我上线、运行、维护的。

为什么我要说，AI 工程师都要懂一点架构呢？大概有四个原因吧：

原因一：算法实现 ≠ 问题解决

学生、研究员、科学家关心的大多是学术和实验性问题，但进入产业界，工程师关心的就是具体的业务问题。简单来说，AI 工程师扮演的角色是一个问题的解决者，你的最重要任务是在实际环境中、有资源限制的条件下，用最有效的方法解决问题。只给出结果特别好的算法，是远远不够的。

比如一些算法做得特别好，得过 ACM 奖项或者 Kaggle 前几名的学生到了产业界，会惊奇地发现，原来自己的动手能力还差得这么远。做深度学习的，不会装显卡驱动，不会修复 CUDA 安装错误；搞机器视觉的，没能力对网上爬来的大规模训练图片、视频做预处理或者格式转换；精通自然语言处理的，不知道该怎么把自己的语言模型集成在手机聊天 APP 里供大家试用……

当然可以说，做算法的专注做算法，其他做架构、应用的帮算法工程师做封装、发布和维护工作。但这里的问题不仅仅是分工这么简单，如果算法工程师完全不懂架构，其实，他根本上就很难在一个团队里协同工作，很难理解架构、应用层面对自己的算法所提出的需求。

原因二：问题解决 ≠ 现场问题解决
 
有的算法工程师疏于考虑自己的算法在实际环境中的部署和维护问题，这个是很让人头疼的一件事。面向 C 端用户的解决方案，部署的时候要考虑 serving 系统的架构，考虑自己算法所占用的资源、运行的效率、如何升级等实际问题；面向 B 端用户的解决方案要考虑的因素就更多，因为客户的现场环境，哪怕是客户的私有云环境，都会对你的解决方案有具体的接口、格式、操作系统、依赖关系等需求。

有人用 Python 3 做了算法，没法在客户的 Python 2 的环境中做测试；有人的算法只支持特定格式的数据输入，到了客户现场，还得手忙脚乱地写数据格式转换器、适配器；有人做了支持实时更新、自动迭代的机器学习模型，放到客户现场，却发现实时接收 feature 的接口与逻辑，跟客户内部的大数据流程根本不相容……

部署和维护工程师会负责这些麻烦事，但算法工程师如果完全不懂得或不考虑这些逻辑，那只会让团队内部合作越来越累。
 
原因三：工程师需要最快、最好、最有可扩展性地解决问题
 
AI 工程师的首要目的是解决问题，而不是显摆算法有多先进。

很多情况下，AI 工程师起码要了解一个算法跑在实际环境中的时候，有哪些可能影响算法效率、可用性、可扩展性的因素。

比如做机器视觉的都应该了解，一个包含大量小图片（比如每个图片 4KB，一共 1000 万张图片）的数据集，用传统文件形式放在硬盘上是个怎样的麻烦事，有哪些更高效的可替代存储方案。

做深度学习的有时候也必须了解 CPU 和 GPU 的连接关系，CPU/GPU 缓存和内存的调度方式，等等，否则多半会在系统性能上碰钉子。

扩展性是另一个大问题，用 AI 算法解决一个具体问题是一回事，用 AI 算法实现一个可扩展的解决方案是另一回事。要解决未来可能出现的一大类相似问题，或者把问题的边界扩展到更大的数据量、更多的应用领域，这就要求 AI 工程师具备最基本的架构知识，在设计算法时，照顾到架构方面的需求了。

原因四：架构知识，是工程师进行高效团队协作的共同语言

AI 工程师的确可以在工作时专注于算法，但不能不懂点儿架构，否则，你跟其他工程师该如何协同工作呢？

别人在 Hadoop 里搭好了 MapReduce 流程，你在其中用 AI 算法解决了一个具体步骤的数据处理问题（比如做了一次 entity 抽取），这时其他工程师里让你在算法内部输出一个他们需要监控的 counter——不懂 MapReduce 的话，你总得先去翻查、理解什么是 counter 吧。这个例子是芝麻大点儿的小事，但小麻烦是会日积月累，慢慢成为团队协作的障碍的。往大一点儿说，系统内部到底该用 protocol buffers 还是该用 JSON 来交换数据，到底该用 RPC 还是该用 message queue 来通信，这些决定，AI 工程师真的都逆来顺受、不发表意见了？

Google 的逆天架构能力是 Google AI 科技强大的重要原因。这个不用多解释，大家都知道。举几个现成的例子：
（1）在前 AI 时代，做出 MapReduce 等大神级架构的 Jeff Dean（其实严格说，应该是以 Jeff Dean 为代表的 Google 基础架构团队），也是现在 AI 时代里的大神级架构 TensorFlow 的开发者。

（2）在 Google 做无人驾驶这类前沿 AI 研发，工程师的幸福感要比其他厂的工程师高至少一个数量级。比如做无人驾驶的团队，轻易就可以用已有的大数据架构，管理超海量的 raw data，也可以很简单的在现有架构上用几千台、上万台机器快速完成一个代码更新在所有已收集的路况数据上的回归测试。离开这些基础架构的支持，Google 这几年向 AI 的全面转型哪会有这么快。
 

作者：王咏刚
简介：原Google软件工程师，著名技术撰稿人和IT演说家。现创新工场AI工程院副院长