在日前举行的2017 CSDI 中国软件研发管理行业峰会上,包括摩拜单车创始人及CTO夏一平、华为首席系统工程专家徐琦海、京东云、携程等一线互联网企业大数据平台负责人等在内的技术大咖齐聚一堂,分享了各自领域的顶尖技术实践。在峰会大数据专场上,达观数据CTO纪达麒围绕“数据挖掘算法落地实践”做了主题演讲,就个性化推荐系统商业化的五大要素进行了详细探讨。下面为大家献上演讲的精华内容。
机器学习的原理并不神秘
最近“人工智能”特别火。“人工智能”的概念虽然很高大上,但从算法角度来说,离我们是很近的。这些算法之所以能够得到广泛地应用,很大程度上是因为机器学习和人类学习很像,在本质上有很多相似性。
从人类学习的角度来说,我们教一个小朋友学数学,我们先要给他一些课本上的例题,让他知道加减乘除大概是怎么回事;然后给他一本习题集,让他不断地去算,去对答案,最终学得四则运算的技能。
在这个过程中,例题和习题就是训练样本,通过训练样本获得标准答案的过程,就是“训练”。“训练”的最终目的,是要找到一个“目标函数”。有训练样本,通过训练找到目标函数,这就是机器“学习”的方式,它和人类学习是很相似的。
举个实际的例子,比如我们的天气预报系统就是按照这个方式“学习”出来的一个人工智能系统。为了有一个好的预测结果,我们先要广泛地采集温度、湿度、风速、气压等各类数据和特征,构造训练样本;然后,根据之前是否下雨以及降雨量的结果,得到一个量化的目标函数;接下来,再通过建立一个学习模型并反复纠正完成一套训练过程,不断优化我们的目标函数,得到尽可能准确的预报结果。
接下来我们要展开讲的个性化推荐算法也是如此。它的实际操作需要克服很多细节问题,但是其基础是很容易理解的。
推荐算法的演进之路
对于一个内容提供商,不管是新闻媒体或者是电商,或者是文学网站,它们提供给用户的内容总是按照一定指标来做推荐的。为此诞生了很多经典的做法,但是最后的效果仍然不尽如人意,还有很大的提升空间。
最简单的方法是单一指标推荐,也叫“热门推荐”。比如就按点击量或者销量来做排序,优先推送阅读人数最多、购买人数最多的产品。各种类型的“热搜”“热销”类榜单就是如此。采用单一指标推荐最大的问题,是没有“个性化”。没有“个性化”会导致两个显著的后果——首先是体验相对较差,用户内心深处“想要变得不同”的需求没有被激发出来;另外一个问题,就是马太效应明显,本身得到曝光的产品会持续得到曝光,而处于长尾上的商品则持续得不到曝光,等于大量质量不错的产品或内容其实被闲置了。
图一:传统排行榜的逻辑
为了解决这两个问题,出现了两种针对性的方案,即基于用户(user)信息和物品(item)信息分别来做推荐。
根据物品信息来做推荐,关键是对物品的基本属性、类别、标签等进行标注,通过对物品信息的深度分析,为用户推荐和他之前浏览记录相似的物品。在这个过程中,要推荐的物品的形态是清楚了,但用户的画像仍然是模糊的。
根据用户信息来做推荐,关键是根据用户的行为日志来刻画他的偏好。通过对用户喜欢点什么,来为这个用户建立他的偏好模型,然后向他推送他偏好的那些内容。在这个过程中,用户画像是有些清晰了,但是用户仍然是个体化的,不同用户之间的相似性、用户行为的社会性并没有得到比较好的体现,推荐的精度也并没有一个很好的提升。
针对这些问题,出现了“协同过滤”的算法。协同过滤算法的核心,是利用群体智慧。具体来讲,分为基于物品的协同过滤和基于用户的协同过滤。举例来说,基于物品的协同过滤的思路,是说在一大群人中,我们发现看刘德华的人很多都会看张学友,这说明张学友和刘德华有相似度,那以后碰到点击刘德华的人,我们可以为他推荐张学友。而基于用户的协同过滤是说,在一大群人中,我们发现A和B两个人都喜欢看好莱坞大片,比如他们都看了变形金刚、木乃伊、神奇女侠,这说明A和B是同好中人,后面用户A又看了加勒比海盗,那就可以把加勒比海盗也推荐给B。
在商业实战中,协同过滤通常会和对物品以及用户的深度分析相结合,并进行进一步的模型融合,从而得到一个精准度更高的效果。比如基于物品的协同过滤在Amazon、Netflix等网站中成功应用,能为用户推荐同领域的更深入的结果;而基于用户的协同过滤则倾向于推荐范围更宽泛而热门的内容,在特定场景下运用,能实现跨领域、令人耳目一新的结果。
图二:协同过滤的模型融合
除了协同过滤,隐语义模型的广泛应用也是一个重要的技术突破。以前传统的分析方式分为两步,第一步是对用户打标签,比如“15-20岁,男性”;有了这个标签,第二步是根据这些标签来映射到结果。这两步都存在一些“硬伤”。首先,根据用户信息打出的标签不一定准确,比如用户填的注册年龄,不一定是真实的年龄;其次,通过标签来对其偏好的物品进行映射,准确度也不高。比如男性中确实很大部分喜欢体育类内容,但是所有男性都要给他们推送体育类内容吗?这样的推荐精准度是比较差的。隐语义模型的核心,是超越这些表层语义标签的维度,通过机器学习技术,挖掘用户行为中更深层的潜在关联,从而避免人工贴标签粗放、主观的缺点,使得推荐精准度更高。
协同过滤和隐语义模型已经应用在越来越多的商业场景中。不过,对于一个成功的算法来说,仅仅明确其模型基础是不够的,还必须要具备下面所说的这些重要优点。
五大要素缺一不可
从整个行业的实践来看,有五个要素至关重要,即自我进化、快速建模、模型融合、开放架构以及性能/效果/资源的良好平衡。具备这五个要素的算法,才能有效应对海量实时数据的吞吐,并高效持续地进行运转。
自我进化
一个推荐系统要长期运行,首先要解决的就是自我进化的问题。用户的兴趣、物品的价值以及用户数据的时效性都会随着时间的推延而变化。用户的兴趣有长期和短期的兴趣,曾经的短期兴趣并不能对预测其未来行为提供很好的参考;物品的价值也有它的高峰期和平原期,现在卖得好的产品未必以后也卖得好,反之亦然。
图三 模型融合
以前针对用户兴趣、物品价值的变化,通常是用人工设定规则的方法来加以应对。随着数据量呈几何级的增长,人工设定规则繁琐且低效的弱点越来越明显。人工设定100条、1000条规则可能还行,但是100万、1000万条规则呢?根本不可行。与之相比,通过算法设计,驱动推荐系统不断进行自我进化,不但更可行,而且更精准高效。
快速建模
在信息的洪流裹挟下,用户在每个平台停留的时间是很有限的,这就要求推荐系统必须根据这很短的停留时间内用户的行为数据,快速地捕捉其兴趣,为其建立和更新兴趣模型,从而迅速为其推荐个性化的内容。
对于新用户来说,这个问题特别明显,业界称之为“冷启动”问题。解决冷启动问题,从完全空白到建立起一个可以提供有效参考的用户模型通常需要几天。这个漫长的周期在实际的商业化过程中是很致命的。很难想象一个用户如果没有在首次浏览时获得满意印象后以后仍会经常来光顾。
要解决冷启动问题,有很多种方案,比如可以通过外部信息,如IP地址,注册信息等来完善用户的标签体系。但更重要的是,我们可以选择那些接受度比较高、同时又能代表细分领域的物品来测试用户的兴趣点。如何选择这些物品,以确保能快速地明确用户兴趣,是问题的核心。一个能快速捕捉到用户兴趣的推荐系统,是确保用户留存、提升用户转化率的重要因素。
模型融合
前面讲协同过滤时我们已经提到,商用的推荐算法中都融合了多套算法,以获得更佳的效果。在机器学习领域,每一个单一算法都是针对一类特定的问题,因而针对同一个推荐任务,不同的算法效果相差很大。但是,实践中的推荐任务千差万别,每个任务适应的算法往往并不相同,在这种情况下,将多个算法的预测结果进行融合,往往能取得10%以上的优化效果。
模型融合的出发点是想建立一个通用性更强的解决方案,以期用一个较一般的算法模型,来为尽可能多的任务提供支持。如何尽量兼顾“通用性”和“优化效果”,是在进行模型融合过程中需要考虑的关键。在实践中,我们开发出的独有专利的双层叠加算法模型就是这方面的一个典型案例,现在已经成为我们向客户提供推荐服务的技术基础。
开放架构
从推荐算法发展的历史来看,新的算法始终在不断的涌现,尤其是随着深度学习兴起之后,各种新兴算法更是层出不穷,包括强化学习、迁移学习等新方法、新领域都开始受到越来越多的关注。
对于一个优秀的推荐系统来说,即使现在的推荐效果已经相当好,但必须对新兴算法也持有海纳百川、兼容并蓄的态度,才能不断地进一步优化提升自己。要做到这样的理想状态,整个系统架构的开放性是至关重要的。比如我原来是采用协同过滤来做推荐的,现在要接入深度学习的算法,怎样才能保证我原来的系统仍然高效稳定的运行?如果是见猎心喜,跟风赶潮流地接入新算法,会有很大风险,系统的效率和稳定性可能都会打折扣。如何解决这个问题,是我们在做架构设计的时候一开始就该有所考虑的。
性能/效果/资源的平衡
和以前相比,现在的数据量的增长可以说是爆炸式的。用户数、商品数的急剧增长,随之而来的是为他们建立的模型的数量呈现几何级增长——每个用户不仅有长期兴趣模型还有短期兴趣模型,每个商品也要建立时效性变化的模型,而且在高并发的场景下,所有这些事情都需要在极短的时间内完成,但是运算所需的硬件资源却是有限的,这时候就需要在资源消耗和运算效果中找到一个平衡。
比如大家都知道分布式计算是解决海量数据运算的一个解决方案,但是分布式数据很难满足时效性方面的要求。要满足时效性的需求,很重要的一点就是要简化模型,去掉不必要的用户特征,从而降低运算量,并同时缓解存储资源紧张的问题。但是,降低了运算量之后,会不会对推荐效果产生消极影响?如何平衡好运算量和推荐效果,这也是一个大课题。
图四:三层火箭模型
在实际中,我们的操作方式是,专门抽取出高价值的用户和物品,让它们享受更复杂的算法和更快的更新频率,同时构建“三级火箭”的算法体系。“三级火箭”的核心思想是,按照离线、近线、在线这三个步骤,将一整套推荐算法拆分成三个部分。比如,对海量用户日志进行深入挖掘完全可以独立进行,可以离线进行操作;Cache、Model的及时更新、迅速捕捉用户点击反馈以及一些较轻量级的推荐算法的运行可以在近线部分进行完成;在线部分则负责及时响应请求并返回结果,保证高可靠高并发的能力。在算法设计中应用类似的思路,可以分摊运算压力,提升运算效率。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。