【摘要】作者 | Japson 来源 | 木东居士 0x00 前言 首先，《AI研发工程师成长指南》这个题目其实有些标题党了，准确地来说，本文内容应该是

作者 | Japson

来源 | 木东居士

0x00 前言

首先，《AI研发工程师成长指南》这个题目其实有些标题党了，准确地来说，本文内容应该是：“要想成为一名AI研发工程师，需要具备哪些技能”。

其次，本文对“AI研发工程师”这个title的定义，也并不是大家第一印象中的“算法工程师”、“数据科学家”。

再次，本文实际上作者结合现阶段行业发展、技术趋势以及自身工作性质做出的关于自身定位、职业技能、发展方向的思考。就像魔兽世界中的“职业攻略”，当我们在游戏中新建一个角色时，会先去了解这个职业的特点、天赋、技能树等信息，这样才会在“练级”的过程中少走些弯路。

最后，作者不是从一个很高的角度来对整个成长体系进行一个全面地阐述。而是站在道路的地点，不断摸索、不断前进、不断地调整自己的规划。因此本文不算是Best Practices，勉强算是Beta version，也希望能和大家不断交流，不断“发版”。

0x01 关于AI行业的思考

算法工程师的门槛

AI算法工程师年薪百万，应届毕业生年薪都有80w… 去年AI人才缺口就已经过百万，今年将达500w… 加入《XXX训练营》，XX天打造AI算法工程师…

在网络上充斥着各种类似上面那样的吸引眼球的文章标题，向你诉说着人工智能这一火的不能再火的领域美好的前景。仿佛我们看了两遍西瓜书、处理了MNIST和几朵鸢尾花、在自己的笔记本电脑上掉了几个包、得到了和教程上一样的结果，打了几场比赛，我们就已经拿到了AI领域的通行证、成功转型算法工程师、接大厂offer到手软了一样。

但实际，现在AI算法工程师的就业难度和准入门槛，远比我们想象的要高。

上一张网络上流传的“诸神黄昏”吧

可以说一点不夸张，现在很多大厂的校招算法岗，门槛就是海外名校/985工科院校的博士/硕士。除了拥有与学历匹配的学术能力以外，工程基础也要非常扎实。

有人说：“我看网上说，AI人才缺口非常大，我不去大厂不就行了？其他的公司要求没那么高吧？”

要求高不高我不知道，但是有一下两点：

绝大多数公司，是不需要雇佣AI算法工程师，即没有相关的业务需求，也负担不起算法团队的开销 2019年研究生报考人数290万人，预计招生70万人，其中计算机是热门专业，并且其中多数人的研究方向都是： 机器学习、数据挖掘之类。

此间竞争之激烈，诸如此类，虽未得其皮毛，也略见一斑。

AI企业痛点

当然，我说这些不是为了打击大家的信心，而是要指出现在行业内的痛点：AI工程化。

人工智能发展到现阶段，已经从实验室中的算法走向了工程化应用的阶段。但是算法落地并没有想象中的顺利，开始有越来越多诸如场景碎片化、应用成本高、实验室场景到实际应用场景效果差距较大等问题被暴露出来，而这些也成为当前阶段AI落地应用过程中新的痛点。

领域内高水平的paper都是公开发表的，除了少数的核心算法，人才济济的AI企业很难在算法性能上与友商拉开距离。那么AI企业想要商业化，想要创收，行业细分领域纵深成了决定成败的重要因素。需要下沉到业务领域，真刀真枪地进行拼杀。

在技术突破-商业化-产品化-工程化的阶段路线中，除了技术强，接下来还有很多路要走。谁能够更好更快地把算法从实验室中拿出来、卖出去；更好更快地将模型交付到业务场景，真正产生实际的价值，让客户满意，谁才能活得更久。

对于Scientist/Researcher而言，技术可以是一篇论文、一项 ImageNet 竞赛的冠军、也可以是一个重要数值（比如人脸识别准确率）的突破；但在商务侧来说，论文与冠军并不实用，如果技术无法融进安防、汽车、金融等行业，变成切切实实的产品，客户与合作伙伴就会拒绝买单。

对于AI企业来说，能否深入了解各行业的业务流程、业务规则、知识经验，进而将技术能力转化为业务解决方案创造价值，是发展的保障。

那么对于我们个人来说，应该如何发展呢？

0x02 AI研发

AI工程化

在《ML/DL科普向：从sklearn到tensorflow》一文中，我们谈到：

…… 那么对于我们这些非算法岗位的人来说，就没有办法涉及这一领域了么？其实我认为，对于企业来说，对于AI人才的需求分为两种：一种是学术界的牛人，发过大paper，有学术界比赛的结果的。公司需要他们去做算法研究，保持技术的领先性，在业内赢得口碑，这样才能在领域内保持头部领域。另一方面，人工智能早已不是一个概念了，企业需要把业务部门的算法落地的人，能够快速、稳定、高效地把实验室中的算法落实到生产环境中，解决实际问题的人。这就需要那些工程底子扎实、能够实打实地写代码，并且对算法模型理解深刻，能够快速将AI项目工程化、落地有产出的复合型人才。

还是基于这个观点，我决定将自身的技能树偏向企业需要的第二种人，也就是标题所提出的“AI研发工程师”。从实际的工程应用角度出来，focus人工智能项目落地的全流程以及解决方法，提高自己的AI工程化能力，以此作为个人核心竞争力。

AI项目全流程

网络上很多文章描述的所谓“机器学习项目全流程”，例如：数据收集处理、特征工程、训练模型、模型测试等等。这套流程对不对？对。但是远远不能满足企业的需求。

AI项目是团队创造出的具有商业价值的产品、服务以及交付产物。有着明确的需求、计划、周期、成本、交付流程以及验收标准。

以下以toB业务为例，对AI项目全流程进行简单梳理。toC业务大体如此，只是将客户替换成公司业务方即可。

初步需求沟通确认 该环节主要是由销售、售前完成。了解客户的基本情况，辅助客户根据自身业务挖掘AI应用场景。根据实际的业务需求、数据质量、硬件资源、期望产物来评估具体的方案以及建模思路。 POC阶段 Proof of Concept。在完成初步的评估之后，团队需要针对客户具体应用进行验证性测试，包括确定业务场景边界、业务评判指标、数据调研、资源需求、硬件/平台部署等。 场景方案确认 该环节需要售前、科学家、工程师等多角色与客户进行细致的场景沟通，明确需求、确定验收标准、评估工作量。因为该阶段结束后即输出SOW方案，因此需要反复沟通商榷。 建模开发阶段 4.1 项目详细规划 项目经理根据前期资料提供详细的方案设计、功能清单、资源投入、里程碑安排等内容，召开项目启动会，明确项目内容及分工职责。 4.2 数据处理 科学家在明确业务场景及需求后，对数据处理。其内容包括：数据质量检查、ETL处理（工作量较大）。还要对清洗后的数据进行探索性数据分析（Exploratory Data Analysis）以及可视化展示。EDA能够帮助我们在探索阶段初步了解数据的结构及特征，甚至发现一些模式和模型 4.3 特征工程 根据探索性分析得到的输出，结合对具体业务的理解，对分散的数据拼表并进行特征工程。 4.4 建模 形成初版建模，并对根据业务需求评估标准进行效果验证。后续需要不断进行模型迭代，直到满足需求，并做模型效果汇报。 4.5 系统研发 将训练好的模型发布服务、部署上线，开发外围对接系统以及部分定制化功能的开发。输出可运行的系统。 测试上线 对系统进行流程测试、性能测试，满足需求后对项目进行交付&验收。 0x03 核心竞争力&技能树

核心竞争力

通过对AI项目全流程的介绍，我们将目光瞄准到“建模开发阶段”的“系统研发”部分。虽然在上面只是一句话带过，但是其中的工作量和技术含量不小。

提起机器学习，尤其是深度学习，大家可能会对诸如Tensorflow，Pytorch，Caffee的工具耳熟能详。但其实在实际的机器学习的生命周期中，训练模型（上述工具主要解决的问题）只是整个机器学习生命周期的很小一部分。

数据如何准备？如何保证线上线下一致性？模型训练好了如何分布式部署？如何构建HA？需要批量处理还是实时处理？实时数据如何拼接？如何对模型服务进行监控、告警？做成PaaS还是MLaaS？

机器学习具有天然的Pipline特性，在企业需求中，大大小小的业务场景有众多的模型，这些模型如何进行打包、处理、发布？离线训练、批量预估、实施预估、自学习等任务类型交错，不同建模工具Sklearn、Tensorflow，Pytorch构造的模型如何进行整合？开发框架Spark ML、Flink ML等如何协同、对接。生产环境如何进行扩展和伸缩？如何支持AB Test？

为了解决这些问题，新生的开源框架层出不穷：Google自研的对接Kubernets和Tensorflow的开源平台Kubeflow；Spark团队打造的ML pipelines辅助工具MLflow；雅虎提供的机器学习及服务平台BigML；阿里巴巴推出的分布式机器学习平台SQLflow等等。众多厂商纷纷发力，目的就是解决AI工程化应用的痛点。

这些工作都是需要一大批工程师去完成。因此，我认为了解AI工程化场景、解决方案；熟悉AI项目流程、机器学习Pipline；掌握AI系统研发、服务部署上线能力的工程师将会逐渐成为AI团队的中坚力量。

技能树

之前铺垫了那么多，既是梳理思路，也是为接下来的系列做一个开篇。按照我的初步计划，技能树大概包括（不分先后）：

工程能力： 身为工程师首先要有工程能力，springboot/Netty/Thrift/等相关工具框架一定要掌握，微服务是机器学习平台的基础。 Spark SQL、Spark ML等更是大数据工程师用来做机器学习的利器，不但要掌握、更要从中抽象出流程和处理方法。 容器化： docker和k8s现在几乎是机器学习部署的必备技能，也是众多平台的基础。 是重要的前置技能。 机器学习&深度学习： 不要求能够手推算法、模型优化，但要能够了解含义、上手使用，起码要成为一名优秀的调包侠（也便于吹水）。 开源框架： 其实我最近打算学习kubeflow，并输出学习笔记及总结实践。 本文其实是这个系列的开篇。 当然，后续还有有调整。 0xFF 后记

其实这种类型的文章，比单纯的学习笔记、技术文章难写多了。一方面，拖延症迫使我把难写的文章放在后面写，另一方面，强迫症又迫使我一定要在系列前出一个开篇。其实写到最后，总觉得核心部分还差点儿意思，没有搔到痒处，这是因为目前我还没有能力站在一个全局的角度对职业技术体系进行划分，只能梳理出目前的规划和看法。后续要还需和朋友们进行交流。

有些事情是一定要做的，纵观一些大牛前辈，无一不是在正确的时候做了正确的事。明确自己的目标，在前进的道路上不断微调自己的方向，这样才能在这个竞争激烈的职业中生存下去。

接下来会有系列的技术学习笔记，考虑到学习的连贯性，前期可能是一些基础的docker/k8s等系列，后期会研究一些开源框架。技术文章可能会枯燥乏味，知识点也缺乏新意，但是经过自己的整理和实践，再加上自身的理解感悟，相信会不断完善自己的知识体系。