--------点击屏幕右侧或者屏幕底部“+订阅”，关注我，随时分享机器智能最新行业动态及技术干货----------
人工智能这几年发展的如火如荼，不仅在计算机视觉和自然语言处理领域发生了翻天覆地的变革，在其他领域也掀起了技术革新的浪潮。无论是在新业务上的尝试，还是对旧有业务对改造升级，AI 这个奔涌了 60 多年的“后浪”，正潜移默化的影响着我们传统的技术架构观念。
AI 架构（尤其是以机器学习和深度学习为代表的架构方案）已经成为我们技术架构选型中的一个新的选项。
你是否需要 AI 架构的解决方案？AI 架构选型的主要依据是什么？这是我们今天主要讨论的问题。
我们先来看一个典型的 AI 架构：
- 1、首先需要采集训练模型所需要的数据，这些数据有可能来自业务系统本身，如 CTR 预估任务中的用户点击数据、用户下单数据等；也有可能来系统外部，公开购买或自主爬取，如图片分类任务中的图片、NLP 任务中的语料等。
- 2、这些数据被收集起来后，经过清洗、加工，被存储起来，因为毕竟不是只用一次。一般是存储在分布式存储设备（如 HDFS）或云端，多数公司还会建立自己的数据平台，保存在数据仓库中，长期积累下来。
- 3、需要使用的时候，先进行数据筛选，选择合适的特征数据，然后经过数据预处理，送入到算法模型中。模型的搭建可选的技术框架很多，可以是基于 spark mllib，也可以是 sklearn、tensorflow、pytorch 等。然后经过训练、评估和调参，完成模型的构建工作。
- 4、最后模型要应用到线上的具体业务中，完成分类、回归某一具体任务。在部署过程中，有可能是将模型打包，将预测模型直接部署到业务系统（客户端）中；也有可能是直接提供一个在线 RESTful 接口，方便跨语言调用。
总结一下，经过数据采集、加工处理、特征选择、数据预处理、模型训练、模型评估、模型应用几个环节，数据跨过业务系统、数据平台、算法模型三个系统，形成一个闭环，最终又应用到业务系统中，这就构成了整个 AI 架构的核心。
是否需要 AI 架构，如何衡量这套技术架构方案的可行性？我认为，主要是看以下三个要素。
1. 场景
我们讨论架构的可行性，是否适合业务及业务发展是第一衡量准则，AI 架构也不例外。
回顾那些经典的、已经广泛应用的机器学习场景，比如推荐、搜索、广告等，这些场景都具有这样的特点：场景相对封闭、目标单一、可控。
究其原因，无论算法模型多么复杂，其最终都要落实到损失函数上的，而后者一般都是单目标、单优化任务。或追求极值（损失最小化）、或达到某种对抗上的平衡（比如GAN）。在这种情况下，无论业务如何建模，还是要落地到算法模型和损失函数的，最终也就限制了场景和目标上的单一。
因此，看一个业务是否适合AI架构，就要先看这个业务场景目标是否单一、可控。或经过业务建模和架构拆解后，每个环节的场景是否单一。
举个例子，同程艺龙酒店系统为酒店商家提供了上传酒店图片的功能，在这个场景下，除了要审查图片的合法性，还要给图片打上分类标签，如“大堂”、“前台”、“客房”、“周边”等。为了能正常使用AI架构，就必须对场景内的各目标进行拆分，训练不同的分类器。具体流程如下：
其中，第2、3、4步涉及到多个图片分类器，每个分类器的目标不同，所需要的训练数据也不同。对于输入的同一个样本图片，每个分类器完成自己的职能，目标单一可控。对于一些不通过的样本，可能还涉及到人工干预。最后合法的图片存入系统。
从业务必要性上来说，也并不是所有业务场景都需要AI架构。算法模型是对事物的精确模拟和抽象，复杂度也是比较高的。但可能有时我们业务上并不需要如此精细的控制。比如有时一个简单的if...else...就解决了问题；复杂点的可能会设计几种“策略”，然后由业务专家针对每种情况进行配置；再复杂的可能还会考虑BI的方案：收集数据，然后展开多维度的分析，最后由分析师连同业务专家得到某种规律性的结论，再内置到系统里，效果可能也不错。
再举个酒店分销调价的例子，在将酒店分销给代理售卖前，一般会在底价基础上对产品卖价进行干预，调整一定的点数（百分比），保证销量的同时，最大化收益。
一开始，可能仅仅是一个固定的比率（比如加价6%）。随着业务发展，设计了一系列策略，比如针对“是否独家”、“是否热门”2维度将酒店划分到4个象限里，对“独家-热门”酒店实施一个较高的调价比率，而对“非独家-冷门”酒店实施一个较低的比率。结果收益提高了一大截，效果不错。
而后，业务人员希望施行更加精细的控制，于是对酒店的星级、地区、商圈、独家、房型等维度进行了更为精细的划分，并结合历史数据进行统计分析，对各种结果施以不同的调价比率。产量和收益又进一步提升了。
这时如果各业务方都比较满意、成本也不高，系统复杂度也不高，那就没必有再考虑更为精细、智能的AI架构了。引入AI，本质上，还是要带来效率、体验或准确性的提升，同时平衡成本和收益，控制系统复杂度。如果不能带来这些，那就要重新审视我们的方案了。
当然，有时我们也会考虑架构的扩展性和业务的发展，预留一些设计上的“开闭”空间。“策略模式”这时也许是个不错的选择。对于系统的默认策略，采用基于人工的、配置的方案，同时保留策略扩展接口，随着将来业务要求的增高，再引入“基于AI的策略”。这样即控制了当前的成本，又平衡了系统的扩展性。
2. 数据
数据决定了机器学习的上限，而算法和模型只是逼近这个上限而已。
数据的采集和获取通常需要很长时间，建立充分、全面的数据仓库，更需要长时间的积累和打磨，因此，数据在任何一个公司都是宝贵的资产，不肯轻易送出。而一个算法模型的成功与否，关键看数据和特征。因此，一套 AI 架构的解决方案，最终能否取得好的效果，关键看是否已经采集到了足够、充分的数据。
这些数据来源一般包括：自有系统采集、互联网公开数据收集（或爬取）、外购等。
自有系统采集是最常见的方案，业务系统自身产生的数据，一般也更适合业务场景的应用。可这样的数据珍贵且稀少，所以往往需要公司的决策者提前布局，早早的开始收集、整理业务数据，建设数据平台、充实数据仓库，这样经过几个月甚至几年以后，在真正用到AI架构时，弹药库里已经储备了充足的“弹药”了。
互联网公开的数据爬取也是一个快速且免费的方法，但在茫茫大海中找到适合自己的数据并不容易，且因为你能拿到、别人也能拿到，因此很难拉开和其他竞对公司的差异。
外购一般要花费巨额费用，且质量参差不齐，一般是互联网公司最后不得已的方案。
在数据获取成本高、难度大、积攒时间久这样的前提下，而场景又适合使用 AI 架构，面对数据匮乏，是不是就没有办法了呢？也不尽然，我们还是有些替代方案的。
- 1、 浅层模型通常比深层模型需要更少的数据量，因此，在数据量不足的时候，通常可以使用浅层模型替代深层模型来减少对数据量的需求。当然，模型的表达能力也会随之下降，但应对不是特别复杂的业务场景，浅层模型也一样能取得很好的效果。当然，随之而来的是对特征挖掘更高的要求和对模型选择的挑剔。拿分类任务来说，SVM、逻辑回归、随机森林、朴素贝叶斯...每种模型都有其特点和适用性，要充分考虑和权衡，才能利用好每一条数据。所谓数据不够、模型来凑，也是不得已的办法。
- 2、 采用预训练模型也是降低数据需求量的一个很好的办法，迁移学习已经在图像分类问题上广泛运用， BERT 模型也将预训练模型带入自然语言处理的大门。在一些特定问题上，如果能找到合适的预训练模型，再加之少量自己的数据进行微调，不但对数据的需求量降低，训练时间也大大降低，一举两得。只是合适的预训练模型可遇而不可求。
- 3、 还有一个减少数据需求的变通的办法是采用少量数据先“启动”，然后不断获取数据，并加快模型更新频率，直至采用“在线学习”的方法。这里实际上是将总的数据需求，拉长到时间维度去解决。当然，这里也需要业务上允许前期模型的准确度不是那么高，随着数据的增多和模型的不断更新，逐步达到预期效果。
- 举个例子，酒店 shopper 类产品的售卖，为了加快展现速度，通常采取供应商数据预抓取的方式落地。但供应商给的 QPS 极其有限，每次只能抓取一个酒店，高频率的抓取可以保证酒店数据的新鲜度，给客人更好的体验；低频率的抓取因库存、价格信息时效性不能保证，往往就会导致预定失败，造成损失。因此，如何在酒店间合理的分配 QPS 就是一个典型的机器学习问题。
- 我们从酒店热度、预定周期、节假日等多个维度进行了特征挖掘，最后却发现“季节”这个关键因素，我们却提取不到有效特征，原因是数据仓库里只有三个月的数据，也就是只有当季的数据。
- 为了解决这个问题，我们重新设计了模型，调整了架构方案，采用“在线学习”的方式，将模型更新问题纳入到了解决方案中。原始数据只用来训练一个初始模型，上线后，模型不断拿新产生的数据并进行迭代更新，同时对时间线更近的数据赋以更高的样本权重，以此来保证对季节性因素的跟进。系统上线后，取得了很好的效果。
- 4、 强化学习在初始数据缺乏的情况下，大多数时候也是一个备选方案。强化学习采用“试错”的方式，不断演化，并最终学到规律。当然这需要业务模型做相应的调整，同时，如果演化周期过长，那有可能模型在前期相当长的时间内，都不能做出较优的决策，因此需要业务容忍度较高。
3. 算力
众所周知，训练过程是一个典型的“计算密集型任务”，没有强大的算力，是难以支撑算法模型的训练和研究的。做机器学习的计算平台，GPU 几乎是标配，其训练时间比 CPU 一般能缩短 5 倍以上。
目前，主要有自建和租赁云平台两种途径获取。如果“不差钱”，当然可以选择自建，但现在 GPU 升级换代太快，基本一年一换。对于做机器学习的 GPU 来说，运算速度是关键，很可能花了大价钱搭建的 GPU 集群，过几年却变成了一台“老爷车”。
租赁云平台虽然可以随时享受最新 GPU 运算速度带来的“快感”，但所需花费的精力也不少。不但要详细对比每家云平台提供的服务和成本，还要合理的搭配 CPU和 GPU，做到资源利用最大化。
说了这么多，提的最多的可能就是“成本”和“收益”这两个词了，这也是业务最关心的问题。无论是计算资源还是系统架构，上一套 AI 架构的解决方案都是需要投入相当大的成本的，如果选择得当，在一个合适的场景下，AI 也是能带来相当不错的收益；但如果入不敷出，选择 AI 架构的解决方案就要慎重了。
最后，技术人员储备和法律因素也是上AI架构前需要考量的问题，前阵子还发生了国家工信部约谈AI换脸应用企业的事件。
AI 是一场浪潮，它不仅带来了新的技术和行业，也给了老系统焕发新生命活力的机会。作为技术人员，我们不仅要拥抱新技术带来的挑战，更要清楚其技术选型的主要因素和背后的风险，这样才能屹立浪潮之巅。那么，你是否需要 AI 架构的解决方案呢？
