对于媒体和大众来说，这两年深度学习的讨论热度有所下降， 但对于圈内人来说深度学习的热度却在逐年升温，每年顶尖学术会议的投稿量都在以百分之几十的速度递增。几年之前，关于机器学习、AI的文章还比较稀少，在田意新看来，AI 的落地并没有像互联网爆发期那样迅猛。在AI产业化应用过程中，算法研究人员要抓住业务的核心问题、理解业务场景的约束，实现高效的AI业务系统。

AI落地是在约束条件下实现业务目标

田意新认为，偏学术型的算法研究主要关注点是算法的理论深度和创新性，工业界更关注应用落地可行性并解决场景问题。每个场景都有非常独特的目标和一些约束条件，AI架构师的工作就是要找到在当前所有算法中能够满足场景约束条件，并尽可能好地实现目标的方法，落地到业务系统中。这也是所有工程师都会面对的问题。

由此可见，AI的落地应用与学术型研究之间存在着明显的差别。以NLP的分词为例，田意新刚加入百度时业界最好的分词方法是条件随机场(CRF)⸺在深度神经网络之前最好的模型，但在百度当时的实际业务场景中采用的却是前后向词典多模匹配加简单策略消歧这种解决方案。原因在于，分词作为搜索业务的第一步，即便采用多模匹配这种简单的分词方法，在当时的搜索系统中性能开销占比仍十分可观。在百度搜索业务中，分词的目的是为搜索系统提供合适的检索「粒度」，以便高效、准确的找到结果，而不仅仅是追求分词的正确性，这与传统意义上学术优化的目标不尽相同。受限于当时的资源条件限制和对效率的追求，多模匹配加上简单策略消歧能恰好满足业务的需求——保证了分词基本正确的同时又简单高效，像条件随机场这种复杂的模型在当时的 条件下便难以落地。随着百度系统计算能力的提升，以及业务场景对分词高精度要求的不断提升，几年之后开始逐渐调研和使用了像条件随机场、深度神经网络等方案。

构建一个商用AI平台的挑战

由于巨大的人才缺口，当前AI架构师普遍很贵且难求。投入和产出的平衡自然是首先要考虑的因素。但在田意新看来，解决不同问题的AI技术或算法琳琅满目，但通用AI目前尚不存在，AI架构师在建设一个有用的AI平台更困难的地方在于怎样弥合业务方多样性需求和平台方标准化技术能力的匹配问题。一个业务问题能否用AI技术方案解决比较容易回答，但解决方案的成本差异很大。从某种意义上说，特定业务的核心问题和AI标准化算法存在较大的鸿沟，而由哪一方来弥补这个鸿沟尚难定论。

首先，作为平台方，是否有足够的能力和生态体系能完全覆盖需求方的业务场景，其次是否有把握汇聚足够多 的需求方或者足够大的需求体量来支撑平台方的持续运营。把很多开源的算法和框架堆砌成一个平台，显然离AI的实用性阶段还有相当的距离。田意新认为，像人脸识别、OCR这种问题，属于通用性较好、需求规模大，AI鸿沟较小的业务场景，但这样的业务在AI行业中并不多见，更多的是大量散点的业务。

快速支撑各种业务的AI架构

能够支撑快速演进业务的架构一般具备两个特征，其一是万变不离其宗的设计理念或者设计思路，其二是一定的灵活性。现在一般行业对发展的预判都是说靠数据驱动，大家都倾向于采用低耦合的系统设计，但在实际业务中还是考验AI架构师对行业问题的理解深度、对行业发展的预判能力——进而决定业务架构是高速变化还是长期稳态。

设计理念需要对行业的发展有一定的预判，如果我们预判未来几年会不断有新的算法出来，我们需要充分考虑不停地更换系统部件的情况，这时要更多地考虑一个高速变化的设计实现，此时的设计就应该是低耦合的系统、组件之间的关系十分清晰；反之，如果我们需要设计的是一个非常明确的稳态业务系统，外界的干扰因素比较少，这时我们更多地要考虑系统各组件之间怎么结合会使得运行效率更高。

确保业务策略系统的持续演进

假如我们构建了一个商用AI平台，并且解决了平台方和需求方的匹配问题，那么接下来要考虑的必然是平台的持续演进。任何一个业务系统，首先要明确的就是业务目标，而在实现业务目标的时候通常要有一个设计理念，不管技术怎么演化、框架怎么更迭，平台最重要的优化目标是不会频繁改变的。为了实现优化目标，平台方应该有一个基本的技术思路。例如，长期看是要用数据驱动的方式来不断提升系统的能力，还是基于什么其他的方式来持续优化系统。

有一些需要提前规划的设计，例如系统到底该设计成低耦合还是强耦合，基于设计思路开始进行实际的系统设计和建设。系统中的AI框架可能会随着业务的变化而变化，例如起初用Caffe解决业务问题，现在觉得PaddlePaddle(飞桨)很好，需要换PaddlePaddle（飞桨）的话是否能方便地进行切换，等等。

也就是说，在平台的发展过程中，我们可能会不断地“换轮子”或者换部件，但平台系统的整体体系不会也不应该有大的变化。设计任何一个系统都不可能一步到位，而平台的演化也是一个持续渐进的过程。一步到位的系统很难成功，但只要我们有一个很好的设计理念，然后随着业务需求的变化和AI技术的变迁不断把系统中的次优部件替换为更优的部件，这样的系统才能不断迭代、并有机地存在很长一段时间。

AI算法工程师的转型镜鉴

算法人员转型AI架构师的挑战

田意新回顾自己的从业经历时表示，自己是从对技术的深入理解到对业务的深入了解的一个渐进过程。开始做算法工程师的时候，更关心和聚焦AI技术的原理是什么、某个算法原理是什么，技术层面有什么巧妙之处；随着工作的展开，关心和聚焦的方向就一点一点的变成算法的价值在哪里、算法能解决什么问题；再到面对把算法应用到真实的业务场景里，解决算法落地的瓶颈以及存在的其他问题。这个过程相当于从算法本身到业务本身或者说问题本身的一个融合与渐进的过程。AI架构师既需要知道现在业界解决问题最好的方式方法是什么，也需要了解这些方法的局限性。

在这个过程中，会踩许多坑，经验也是这样一点点积累出来的。把时间的维度拉长一点来看，最初解决的问题往往是业务中的一个点，随着资历的增长，所能解决的问题开始覆盖更大的业务范围。从这个阶段开始，AI算法人员需要找到属于自己的发展方向，沿着方向性的轨迹发展下去，通常会建立该方向的技术体系并且逐渐能 了解自己的技术体系最适合解决哪些问题，也更擅长从算法型工程师的角度去解决业务的实际问题。

当算法工程师成长到AI业务型人才之后，需要从业务系统的角度对整个业务有深度抽象的能力⸺抓住业务最重要、最核心的问题，理解业务场景的约束，然后融合很多算法和工程等方面的知识和经验，实现高效的AI业务系统。对于一个大型业务的AI架构师来说，不仅要掌握传统意义上的机器学习或者深度学习算法，还需要对整个行业的业务有充分的理解，才能设计出符合业务发展的AI系统。从能做好一个点一直到能做好一个系统需要很长时间的积累和锻炼。经常有很多人片面地以为AI系统就是算法，其实AI系统和算法差别非常大，前者包括了算法、工程架构、多样性综合性的优化目标以及一系列的约束条件等。从工程系统角度，AI平台本身是一个技术型产品，算法是里面关键的组成部分⸺但不是全部。AI架构师要做的核心工作是在具体的业务场景中设计并实现相应算法的最佳实践。

AI架构师的价值评判标准

工业界和学术界一个非常大的不同是评判工作质量的标准。学术界更看重的是理论深度、创新性、在理想实验环境下的效果等，说的再简单直白一些就是能不能发表顶级学术会议论文，或研究成果能否得到同行和相关组织机构的认可；但在工业界，最重要的是解决问题，能不能解决问题、能不能高效地解决问题。田意新坦言， 这种价值判断标准从解决问题的方法是否fancy变成了是否work，成为许多刚刚毕业的Ph.D. 进入AI工业界时最常见的挑战。

特别是一些有深度的学术背景的新Ph.D.首先会惯性地按照学界的评判标准来衡量自己在工业界的工作，如果当前的解决方案并没有使用行业内最好的技术或方法，便会认为做这些不能代表业界最高水平的工作很low、可能会对相关工作的认可度和热情不高。通常这种认知会有一个转变的过程或者说适应期，随着周围环境的不断反馈⸺不管是工作进度上的还是评价方式上的，能实现这种转变的Ph.D.通常会很快取得不错的成就、并且未来的发展潜力非常好，因为这类人不仅能解决问题，而且还能高水平地解决问题。当然也有一些从工业界又重新回到了学术圈的例子，这些人回到学术界经常也做得非常好。但对于有志从业AI工业化，将技术成果影响到更多人的研究人才来说，需要对这个转变提前有一定的思想准备。

除了算法模型之外的关键能力

在田意新看来，AI行业变化非常快，AI的商业化仍处在初期阶段，这与云计算的早期阶段有些类似，因此对于AI架构师需要具备的能力也会随着行业的发展而有所差异。例如在有云计算之后和没有云计算之前，对运维工程师的要求是截然不同的。在当时这个阶段，传统行业里的AI工程师需要不断提高对行业业务的理解能力，以及把传统行业问题转化为机器学习问题或者AI问题的抽象能力。至少能够做到可以判断传统行业的业务问题是 不是可以抽象成机器学习问题或者是AI问题，然后大致应该用什么样的方式解决，这是第一步也是很关键的一步。

简单来说，第一个关键能力是问题抽象，第二个关键能力是技术选型。到底该选用开源框架还是自研、或者采 用商用平台如飞桨里的EasyDL、BML等服务，然后基于这些服务去构建系统，需要具体问题具体分析。最后一个关键能力是技术执行或者说技术实现，实现的过程或者结果可能有较大的差异，但前两个核心能力最为重要。