推荐系统的天时地利

Posted ResysChina

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了推荐系统的天时地利相关的知识,希望对你有一定的参考价值。

推荐系统的天时地利

推荐系统的成功,不仅仅是算法的功劳,而是天时地利各方面因素共同造就的

机器学习算法现在在互联网的各行各业中都得到广泛应用,但并不是每个场景都得从中获得同样的收益,推荐系统作为最早吃螃蟹的算法应用行业,一直都能高效收割各种算法技术发展的红利,而这一切也并非偶然,而是推荐系统天然具备的诸多优势条件所导致的。相比来说,其他也在应用机器学习的行业则没有这么幸运,很少有一个领域在算法应用方面具有推荐系统这么多的优势。这篇文章就来细数一下推荐系统究竟占据了哪些天时地利。

问题定义明确,建模方法直接明了

要想在一个领域中应用机器学习算法,第一步是将领域问题清晰地定义为某个机器学习可解的问题。大多数推荐系统的业务问题都可以分解为点击和转化两个子问题,而这两个子问题都可以直接建模为一个二分类问题,然后所有可以用来解决二分类问题的模型就都可以为推荐系统所用了。

这看起来是一个微不足道的点,甚至很多人会想当然地觉得每个场景下都是这样,但事实是在有的场景下问题定义本身也是个问题,在这些场景下业务问题并不能如此自然直接地映射为一个机器学习问题。例如业务问题是A问题,但A问题由于各种原因无法直接建模,只能建模A的一个子问题或代理问题B,但这就会导致得到的结果不能直接应用到业务中,毕竟优化目标是B问题,建模结果能不能对A问题产生收益还不一定,用起来还要费几番周折。如同鸡肋,食之无味,弃之可惜。这就会让机器学习技术在这种场景下处于非常尴尬的境地:说没用吧,毕竟也能产生一些有价值数据;说有用吧,这些用起来又不那么自然,着实别扭。著名的机器学习播客Talking Machines在2019年10月的一期名为“How to Ask an Actionable Question”的节目中介绍了在医学领域中如何提出一个适合机器学习解决的问题,本质上也是在解决如何建模的问题,也从侧面说明了为业务问题找到合适的建模方法本身也是一件有挑战的事情,不应视作理所应当。

回过头来看推荐系统,这方面就简单太多了:面向CTR建模,然后直接按照预估的CTR排序(CVR同理),除了少量业务干预,中间没有任何弯弯绕,模型优化的目标就是你要提升的业务目标。而从业务角度来看,优化模型能够解决业务80%以上的问题,使得整个业务中算法占了绝对主导的地位。也正是因为模型收益以极大比例转化成了业务收益,中间的损失极少,才使得推荐系统能够乘着算法的东风地位持续提升。

样本数据量大,含义明确

样本是模型的粮食,推荐系统的粮食可以说是相当丰富了,从来不需要为样本量发愁,只要是一个有一定规模的网站,每天的样本量怎么也能到千万级别,最低也是百万级别,多天累计之后,对于大部分模型的训练已经是比较够用了。

但是在很多场景下,样本的获取本身就是建模的第一大难题。典型的例如一些用户画像标签的挖掘以及一些图像识别的场景,是没有渠道可以规模化获取可信真值的,只能是绕着弯子想办法去构造置信度比较高的真值样本,或者花大力气去人工标注样本,而无论那种方式,都是比较费工费力的,而且在可靠性上距离推荐系统这种自然产生的样本仍然有一定差距,例如人工标注带来的样本质量不一致等。

为什么推荐系统会具有这样的优势呢?推荐系统本质上是一个系统和用户之间的互动系统,用户的每一次行为,既可以充当特征,同时也都是样本,凡是这种有海量用户和系统互动的系统,都可以产生大量的样本,而很多其他应用机器学习算法的场景并不直接面对用户,无法与用户形成规模化的互动,因此样本的获取就会比较困难。

训练和预测数据同分布,评测结果可靠

机器学习技术的应用有一个很重要的前提,那就是使用模型时的数据和训练模型时的数据要是同分布的,也就是说在什么样的数据上训练,就在什么样的数据上使用(预测),才能得到预期的效果。比如说,不能在一个全是男性的数据集上训练模型,然后用这个模型来预测女性的行为,这样的使用方式违背了数据同分布的原则。

但在一些场景下模型的训练和使用是分离的,典型的如在用户画像系统中,使用用户的驾驶行为训练开发了一个标签,例如是否出租车司机,放到标签库中,然后某业务方恰好需要这个标签就拿来用了,但发现效果不好,后面分析才发现,该业务的使用场景是三四线城市,而这个标签是使用一二线城市用户的行为训练的,二者的移动app行为存在显著的差异,所以效果不好。这个错配的过程中最大的问题在于模型的开发者和使用者不是一批人,相互不知道对方的业务背景和数据来源,都想当然地认为自己的理解是普适的、不存在歧义的,直到接受了社会的毒打。

在推荐系统中基本是不存在这个问题的,虽然也会在部分情况下使用A场景的数据训练模型给B场景用,以及信息茧房导致的一些数据偏置,但在大部分情况下都能做到训练和预测尽可能的同分布,这样可以最大程度保证模型的可用性,最小化精度损失。

完整的数据闭环,效果可监测

机器学习算法以数据为粮食,以用户反馈为镜子,完整一致的数据闭环是完成快速和可靠迭代不可或缺的基础。推荐系统在这方面具有天然优势,但有很多离线挖掘的系统并不具备此条件,它们所挖掘的结果属于较为底层的基础数据,因此本身无法形成回路来监测,而是要靠上层业务的使用效果来判断这个数据本身的效果。但这种效果监测方式很难体现数据本身的真正质量,毕竟上层业务的效果好坏和太多因素相关,它们作为底层数据的使用方,没有足够动力去做复杂的评测来验证底层数据本身的独立效果,它们更多关注的是各种方法加起来能不能把我的业务目标做上去,所有它使用的数据都是它的工具和方法。

拥有完整数据闭环的最核心的好处是给了推荐系统一面镜子,模型或架构的一举一动,每一次改动,都可以保质保量地在这面镜子里快速、如实地看到变化,从而让开发者可以准确量化评估这次改动的价值,而这也是快速迭代的基础能力之一。

高维ID特征,成功收割DL红利

对深度学习技术红利的成功收割,算得上是推荐系统这几年最幸运的事情了。深度学习技术虽然高大上,但是要在业务系统中真正得到收益,至少要满足两个条件:

  1. 业务不要求太高的解释性。
  2. 数据特点符合深度学习的优势条件。

对于第一点,如果业务要求稳定性和高解释性,就不太适合用DNN,典型的如金融风控业务,由于涉及钱的问题,很多客户还是希望模型的工作原理大体可解释,并且保持一定的稳定性。但是大多数场景下的推荐系统是不要求过多的解释性的,只要用户用点击和转化表达了认可就行,除此以外,无论是用户还是产品经理都不会要求过多的解释性。此外,即使在需要解释性的场景下,例如想生成推荐理由的时候,现在更加流行的是类似LIME这样模型无关的解释方法,因此对于推荐模型的可解释性也并无过多要求。

对于第二点,不是所有的机器学习问题把模型换成深度学习都会有效果提升,关键是要根据数据特点来看这个问题是否是属于深度学习擅长的类型。相比浅层机器学习模型,深度学习的本质优势在于特征表示能力的提升,本质上是表征学习的胜利,那么什么场景下需要这种所谓更高级的表征呢?从目前的主流实践来看,数据中有海量高维的ID类特征是表征学习能够发力的最好场景,DNN最初取得成功的图像、语音以及后来的NLP场景都具有此特点。而推荐场景恰好也有典型的高维ID类特征:用户ID和物品ID,尤其是物品ID以行为序列的形式出现的时候,非常适合用深度学习来进行更为高阶的表征,也正是因此,近年来各种基于embedding的推荐技术得到了广泛的发展和应用,而embedding技术说到底就是表征学习技术[1]。但并不是每个场景和业务都这么幸运,如果你也做过其他非搜索推荐场景下的机器学习问题,就会知道现在仍然有很多场景下只适合使用传统浅层模型,虽然也有一种可能是这些场景不需要深度学习,但终究是没有吃到深度学习的红利。

错误代价低,用户反弹小

没有任何一个机器学习算法能够做到不犯错,那么在应用算法模型的时候有一个重要条件就是对于犯错的容忍度要足够高。容忍度低的典型代表是医疗场景,模型的一次判断错误可能会导致病人的误诊,这是非常大的代价,是不可以忍受的,这也是为什么医疗场景下无法让算法完全替代医生的重要原因之一。用算法来生成文本是犯错代价小一些的场景,毕竟写错一段话不会发生人命官司,但这也只是和医疗这种极端场景作对比,其实绝对代价也比较大,比如将一篇标题有错误的文章作为push素材推送下去,会影响大量用户的直接体验,大家会吐槽说这个app真不靠谱,推送个新闻都写不对标题。

推荐系统就不一样了,推荐系统中模型犯错的后果是什么呢?不过是给你推荐了一个你不感兴趣的东西,不小心推出不可说的物品已经是推荐系统中犯错后果的极限了,除此以外,都谈不上什么严重的后果,所以我们才可以大胆尝试各种算法,而不用担心产生明显的用户反弹。

但反过来想,这也不全是一件好事,犯错代价如此之低一定程度说明推荐系统所起到的作用并没有那么大,只有对于不那么在乎的东西,人们才会拥有最大的容忍度。推荐系统一直以来都被认为是一种主业务的附属品,做得好了让人惊喜,做的不好也不会太让人反感。即使是一些以推荐为主业务的app,也总被看做生活的附属品,可好可差,甚至可有可无。有一种言论吐槽说最聪明的一批脑袋都用来研究怎么让用户多点一下广告,点一下推荐,这对于人类进步有多大帮助呢?这个问题就比较复杂了,如有必要可以单独撰文讨论。

展现约束小,发挥空间大

要说什么系统可以在给用户展示信息的时候充分放飞自我,那绝对是推荐系统莫属。前几天看到一篇文章,文章作者说他和几个朋友在某电商平台上同时搜索一个商品关键词,出来的排序结果在价格上差异很大,因此他怀疑系统在使用收集到的用户信息操纵价格歧视。看到这篇文章我的第一反应是:做搜索的同学们可真惨,搞点“个性化”都要被用户骂,要是在推荐系统里给用户出几个贵的东西,用户说不定还会觉得你是在捧他,在夸他有钱「手动狗头」。

玩笑归玩笑,但是推荐系统在信息展示层面的发挥空间,真的是非常的大,大到只要不推荐一些黄暴恐的东西,基本上是不会有人来找麻烦的,所以说发挥空间非常的大。发挥空间大意味着约束小,这里包括两类约束:

**业务约束较小。**推荐和搜索是每家公司重要的流量入口,但相比推荐,各业务方更喜欢求助于搜索来协助满足自己的业务需求。究其原因,是因为搜索入口可以通过搜索词来判断用户的意图,进而可以将具有某种意图的用户倒流到特定的业务场景中去。而推荐因为无法准确控制用户意图,被插入特定业务逻辑的情况要少很多,所以结果展示上可以更大程度地忠于算法的结果。

**用户约束较小。**推荐系统经过多年的发展,已经在用户心中形成了相对成熟的认知,而这个认知的核心可以概括为一个字:“猜”,在这个背景下,用户是准备好了接受系统任何“猜”的结果的,结果就是猜对了用户很高兴,猜不对用户也不会苛责。

在一个约束小、空间大的场景下,出的结果没有绝对的好和坏,更多是比较相关和不太相关,相当于是给了工程师们宽广的尝试空间,从而也增加了找到最优结果的可能性。

初始门槛低 & 收益粒度细

在业务中使用机器学习系统的目标可以粗略地分类两类:

  1. 通过完成之前完全无法完成的事情,产生全新的价值
  2. 对已经存在的事情进行优化,一般不产生新的价值,而是将已有价值进行最大化,以及将生产过程降本提效

第一类的典型代表包括医疗影像识别、天网监控系统以及基于人脸识别的各种应用等,这一类应用对于算法模型的典型要求是初始门槛高,即只有当准确率达到一定水平时才可上线应用,否则该系统非但不会产生新价值,反而会带来更大的问题。例如当医疗影像识别系统准确率不够高时,可能会带来显著的误诊和漏诊,那么医疗系统是断然不敢应用的,还不如老老实实地让医生辛苦一点做判断,人脸支付等应用也是一样,准确率不足带来的后果是非常严重的。初始门槛高的另一面则是后续提升价值低,因为初始门槛通常已经足够高,所以后面上再提升准确率难度比较大,而且模型效果提升对于系统的整体效用不会再有本质的提升,也就是边际效用在显著降低。换句话说,这种类型的应用对于算法模型的要求属于“一步到位”式的要求。

而推荐系统则属于第二类的典型代表。推荐系统最早使用的算法是经验公式,后来升级到协同过滤,然后继续升级到机器学习,在机器学习的模型框架内又在从逻辑回归到深度学习一路不断升级,可以看到在这个系统中应用各类算法并没有所谓的初始门槛,只要新的做法能够比旧的做法好就可以上,如果再有更好的就再继续上,而且这个过程中边际效用几乎是线性的,也就是说模型效果提升多少,最终业务价值就近似提升多少。

像推荐系统这样的第二类应用方式相比第一类有着巨大的优势,主要体现在:

  1. 初始门槛低。不需要精雕细琢即可尝试使用,可以快速拿到收益,并验证方法可行性,更符合移动互联网时代MVP式的开发原则
  2. 收益颗粒度细腻。不需要一次放个大卫星,小步快跑地提升方法反而更符合各方面预期,每一次提升对业务都有价值,支持快速的迭代开发
  3. 效果上限高。以推荐系统最关注的点击率为例,该指标的行业平均水平在百分之几到百分之十几左右,距离“次次猜中”的美好愿望还有很远距离,足够工程师们奋斗上一些年的了。这一点和上面一起加起来,可保推荐系统工程师若干年饭碗无虞

对于第一类系统,如果初始水平不够高的话,业务或者客户是根本不会用的;而对于第二类系统,只要比当前水平做得好,是可以快速先用起来的,然后再逐步优化的,即使永远也到不了第一类系统的准确率,只要在进步,老板就会开心。更重要的是,这种“每年能提升,提升边际效用近乎线性”的模式,可以保持老板们对推荐系统持续有兴趣有期待,一定程度上也保住了大家的饭碗,可以让大家像撑杆跳高女皇伊辛巴耶娃每次只破纪录一厘米一样在行业里混下去。

总结

以上是推荐系统作为一个机器学习应用系统能够取得巨大成功的一些非技术层面的原因,也从侧面描绘了机器学习应用系统发挥作用的理想场景,这些点对于推荐系统从业者来说都是理所当然,但在很多机器学习应用的场景中都有不同程度的困难。这些条件中有些是工程师无法改变的,但如果可以的话,在这些方向上努力做出改变,对于机器学习系统的影响将是根本的、整体的、持久的,如果你是一个机器学习团队的leader,那么就更应该在这些方面多思考多发力,好让工程师们能够酣畅淋漓地作战。

参考资料

[1]

可参考《》


以上是关于推荐系统的天时地利的主要内容,如果未能解决你的问题,请参考以下文章

基于 Apache Flink + Hologres 的实时推荐系统架构解析

实时数仓入门训练营:基于 Apache Flink + Hologres 的实时推荐系统架构解析

清华博士教你如何用推荐算法技术「找到女朋友」

清华博士教你如何用 Python 推荐算法「找到女朋友」

(源码推荐)快速开发10几天时间纯代码高仿《内涵段子》

推荐系统