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