如何增加用户的参与感?交互式推荐来了!

简介: 一方面,互动能让用户感受到更多的参与感,并能一定程度上干预推荐结果,而不只是被动接受推荐结果;另一方面,系统通过与用户的互动能更加了解用户的偏好,从而提升推荐效果。那么,我们是如何让用户和推荐系统互动起来的呢?且看下文。

小叽导读:推荐系统已在工业界广泛应用,虽然它们经常能帮我们找到想要的东西,但现有的推荐系统还存在两个问题: (1) 体验单一,我们只能被动浏览系统推荐给我们的东西;(2) 系统对我们的了解有限,有些推荐效果并不理想。让用户与推荐系统有效地互动能很好地缓解以上两个问题。一方面,互动能让用户感受到更多的参与感,并能一定程度上干预推荐结果,而不只是被动接受推荐结果;另一方面,系统通过与用户的互动能更加了解用户的偏好,从而提升推荐效果。那么,我们是如何让用户和推荐系统互动起来的呢?且看下文。


背景

日常生活中,我们常常会发现,相比于看电视,很多小孩更喜欢玩手机和IPAD。这个现象的一个重要原因是,小孩在看电视时只能被动地接受电视播放的内容(虽然可以换不同频道,但交互性非常有限),而在玩手机/IPAD时(比如玩王者荣耀),小孩可以与手机/IPAD大量地交互,使得小孩感受到更多的参与感,趣味性也就更强一些。同样的道理,主流的推荐系统(比如猜你喜欢的商品推荐)虽然已经取得很好的效果,但不管是在学术圈还是在企业级应用上,针对推荐系统的交互性还没有做足够的探索。

直觉上,引入交互性一方面可以增加用户在推荐系统中的参与感,提升用户体验,另一方面也有助于推荐系统更好地了解用户偏好,从而推荐更好的宝贝以进一步提升用户体验。为了解交互性在推荐系统(以下简称交互式推荐)中该怎么做,我们查阅了大量学术论文,在发表于KDD 2018的Q&R: A Two-Stage Approach toward InteractiveRecommendation [1]这篇论文中,我们找到了一个可行的框架,示意图如下:

image.png

图1. 交互式推荐框架

(图片取自Q&R: A Two-Stage Approach toward InteractiveRecommendation, KDD 2018 [1])

其中,当用户浏览推荐系统的item(比如猜你喜欢里的商品)时,系统会生成一个问题来咨询用户的相关信息,系统可以根据用户的反馈获取到用户的即时兴趣,从而进行item推荐。推荐系统的交互性就体现在"提问"和"反馈"的整个过程中。

接下来,我们针对框架中的每个模块依次分析:

Question Generation Model:首先面临的问题是生成什么形式的问题及如何生成。如果能用完整的人类语言生成问题,比如"天冷了,您是否想买条围巾?",那自然是很赞的。但是,虽然自然语言技术已取得很大的进步,但目前还很难根据用户的喜好生成大量如此高质量的问题。因此,如图2所示,我们将"问题生成任务"转换成"关键词推荐任务"。具体地,我们会生成几个关键词,比如"围巾","风衣","帽子"等,放在一个卡片里,推荐给用户供用户点击。这些关键词对应的潜在问题是"天冷了,您是否想买围巾/风衣/帽子?"。这样我们就明确了问题生成的形式,即关键词推荐。接下来又产生了一个新问题,即如何得到足够大的关键词候选集用于关键词推荐。我们最终决定将搜索日志中的搜索词作为关键词推荐的候选集,原因如下:

搜索日志中的搜索词是用户输入的,很多都是能表达用户需求的有意义的词。

搜索日志中搜索词的量足够大,覆盖的需求面广,这样针对不同的用户,在不同的环境下(比如不同的季节等)都能找到符合用户需求的词推荐给用户。

image.png

图2. 问题生成逻辑

User Feedback:接下来是用户反馈。以上面那个例子为例,如果用户点了围巾/风衣/帽子中的某个关键词,我们就认为用户回复了"是的,我想买围巾/风衣/帽子"。如果没点,就表示不想买。当然,用户反馈还可以包含其他信息,比如用户在点"帽子"前是否还点了"围巾/风衣",在点击"围巾/风衣"后的详情页里的滑屏,加购,收藏等行为,问题生成到用户反馈间的时间间隔等 (时间间隔长表示用户需求弱)。

Item Recommendation Model:最后是商品推荐。用户点了关键词,说明用户意图明确,直接将关键词作为输入调用搜索算法得到商品列表即可。可以看到,在我们的处理中,后2个步骤就是经典的搜索任务,示意图如下:

image.png

图3. 用户反馈和商品推荐逻辑

这本质上是"先推荐,后搜索"的过程,其中,"推荐"对应于关键词推荐,"搜索"对应于基于用户点击的关键词得到搜索结果。我们知道,相比于推荐任务,搜索任务因为用户意图明确,可以引导更多成交;而相比于搜索任务,推荐任务因为无需用户输入关键词,交互成本更低。而我们的处理既无需用户输入关键词,又能明确用户意图从而返回符合该意图的商品,可以说是集搜索和推荐双方之所长。

因为将后2个步骤转换为经典的搜索任务,可以直接调用现有的搜索算法解决(针对交互式推荐稍作定制化处理),因此第1个步骤“关键词推荐”是我们优化的重点。

需要指出的是,关键词推荐只是问题生成的一种方式,视频,攻略和单品也可以作为问题生成的素材,相应地,用户反馈和商品推荐的形式也就多种多样,比如用户针对攻略的反馈可以是用户在攻略页面的滑屏、点赞、评论、停留时长等。商品推荐也就变成了基于视频,攻略或单品的商品排序。

产品形态

在讲解关键词推荐算法前,先介绍一下产品形态 (为方便描述,我们将该产品命名为“风向标”),让大家有个直观的认识。风向标的产品理念是:

(1) 交互式;

(2) 需求聚焦,可解释,体感强;

(3) 场景感。

基于这些理念,我们设计的产品玩法如下: 如图4所示,用户首先在淘宝首页的猜你喜欢页面点击一个商品 (对应第1张图);进入商品详情页后 (对应第2张图),用户执行滑屏、加购、收藏等操作;在用户回退到猜你喜欢页面时,由算法决定是否出风向标,生成风向标的场景化文案(如第3张图中的"男宝这么穿"),以及在该场景下出哪些词(对应第3张图);在用户点击某个词后,跳转到二跳结果页(对应第4张图)。

image.png

图4. 风向标的产品形态

方案

整体技术框架如图5所示。首先基于搜索日志,商品信息,知识图谱数据生成基础数据表;然后是关键词的召回,排序过程;我们在做排序时不仅考虑用户的历史偏好,还考虑了用户在详情页的信息(端智能),并通过一个展现控制模块调整排序结果;用户点击关键词后就会触发搜索流程;最后把日志回流到搜索日志中。其中虚线表示后续还需继续优化的模块。下面我们分别讲解4个核心模块:召回,排序,展现控制和端智能。

image.png

图5. 整体技术框架

召回

整个召回过程可以套用一个metaPath模型[2]来统一描述。具体地,如图6所示,用户、商品、关键词、场景、类目都可以看成是异构网络中的异构节点,而通过不同的召回策略帮用户找到query对应不同的metaPath,召回类型和召回分分别对应metaPath类型和metaPath得分。目标是基于异构网络上的metaPath来判断用户和关键词是否有关系及关系强弱,从而把关系最强的词推荐给用户。下面依次介绍不同召回策略。

image.png

图6. metaPath模型

u2i2q:核心思想是根据搜索query到搜索结果页中商品的关系(即q2i)反向得到商品到query的关系(即i2q),从而建立起用户点击的商品和query的联系。其原理是,在搜索日志中,query和商品的共现次数越多,则其关系越密切。在metaPath模型里,该召回策略表示由用户商品query这条metaPath找到query,下同。

u2i2scene2q:如图7所示,该路召回分i2scene (左边)和scene2q (右边)两个过程,其中i2scene表示点击某商品会激活相应场景;scene2q表示由该场景生成相应的关键词。

u2i2c2q:主要思想是引入知识图谱,借助类目信息提升query召回效果。

image.png

图7. 场景化query召回的i2scene2q过程

现在召回的模态比较单一,只有关键词,之后会召回视频,攻略等其他模态的实体。另外,利用详情页行为数据和知识图谱提升召回效果也有很大空间。

排序

排序分精排和重排两个过程。精排过程先后有如下两个版本:

版本一:xftrl

ftrl的理论性研究已有10多年历史,但正是Google发表于KDD 2013的一篇论文[3]将这个理论模型彻底工程化,使得很多企业级在线学习模型都基于ftrl实现。xftrl是xps平台基于ftrl开发的定制化模型,能处理淘宝网千亿级的离散特征。离线实验中,我们将前4天的数据用于训练,后1天的数据用于测试,xftrl在测试集上获得了0.67的AUC。

版本二:Attention_GRU

(1) 动机

虽然xftrl (ftrl)很有效,而且有成熟的工程化实现。但是,xftrl (ftrl)有如下不足之处:

已有很多工作证明用户的长短期兴趣和行为的序列性[4,5]有助于提升推荐效果,但xftrl (ftrl)只能通过特征工程捕获长短期兴趣和行为序列性的少量信息。

xftrl (ftrl)本质上是一个线性模型,其特征交互只能通过在特征工程中加入交互特征完成,这严重依赖于算法工程师对业务的理解和经验。一般地,算法工程师在做特征工程时只考虑二阶交互特征,这样特征之间的高阶交互关系就无法捕获。总而言之,用特征工程去捕获特征交互,容易造成无效交互特征的加入或重要交互特征的遗漏。

为此,我们提出使用定制化的Attention_GRU模型来提升关键词推荐的效果,一方面,Attention_GRU已被证明能很好地对序列数据(包括历史行为序列)建模;另一方面,Attention_GRU本质上是一个神经网络模型,特征之间的(高阶)交互关系可以由神经网络中的非线性激活函数捕获,当然我们可以将置信度较高的一些交互特征也输入到神经网络中,从而对这部分交互特征显式建模。该定制化的Attention_GRU模型主要基于本人发表于IJCAI 2017和IJCAI 2018的2篇论文[4,5]。

(2) 模型框架

image.png

图8. 风向标的模型架构

模型分4块特征,分别是用户侧非实时特征,用户侧实时特征,query侧特征,以及其他特征。得到4部分特征后,concate起来,输入到1个3层神经网络中,然后基于神经网络的输出和标签计算loss。

(3)Attention_GRU

image.png

image.png

其中,Attend和Generate是函数。是一个向量,其元素表示第j个输入的注意力权值。被称为glimpse。Recurrency表示循环激活函数,在Attention_GRU中,循环激活函数是GRU。

在我们的GRU实现中,以上公式中的x对应于图8中的i。

我们针对Attention_GRU做了一系列实验,其中第一个实验仅利用query侧的类目特征(我们没用query id是因为query id太稀疏,所以用粒度较大的类目)进行推荐,AUC为0.5685,高于0.5,说明关键词本身的(类目)热门程度是有助于关键词推荐的。加上用户历史行为序列中商品的类目特征(用商品类目而不是商品id的原因同上)后,AUC提升到0.6037,说明历史商品(类目)及其序列信息有用。在此基础上,我们再加上商品标题和关键词的文本特征,AUC提升到0.6203,说明利用文本信息能进一步提升关键词推荐效果。最后,我们将图8中的所有特征加上,AUC达到0.6830,超过了基准方法xftrl。表1是我们的实验结果。
image.png

表1 xftrl,Attention_GRU,改进后的Attention_GRU的离线实验效果。

(4) 针对Attention_GRU的改进

为进一步提升关键词推荐效果,我们针对Attention_GRU中的Attention机制进行了一些原创性改进。主要动机如下:

用户的历史行为发生的越久远,则其对关键词推荐的影响应该越小,相应Attention的权重也就越小。即Attention权重的时间衰减性。

不同行为类型对关键词推荐的影响是不一样的,比如购买行为的影响要比点击行为更强,相应Attention的权重也就不同。即Attention权重的行为类型干预。

在公式(1.1) (1.2)中,计算的示意图如下:

image.png

图9 计算Attention权重

image.png

image.png

图10 计算Attention权重时考虑时间衰减性和行为类型干预

其中,每种行为类型对应1个image.png
矩阵,假设image.png
的维度是d,则image.png
是一个d x d维的矩阵。时间间隔表示历史行为发生时和关键词推荐时的时间差,Time_decay是一个单调递减函数。如表1所示,对Attention_GRU改进后,AUC达到0.6999。另外,我们将odps数据转为tfrecord格式作为模型输入,训练速度加快40%。

(5) 一些思考

xftrl包含了Attention_GRU中没有的特征,而Attention_GRU建模的序列性和长短期兴趣也是xftrl没有有效建模的,因此2个模型是互补的关系。之后可以将2个模型融合,进一步提升效果。

精排过程还有很多改进空间,比如,如何对关键词,视频,攻略等多模态的实体进行排序;用户在详情页的行为等实时特征对关键词推荐非常重要,如何更好地对这些特征建模;如何有效利用知识图谱数据,来进一步提升模型效果。

重排过程比较简单,主要是在保证排序效果的基础上,生成更加多样化的关键词。

展现控制

展现控制分2块:(1) 位置、时间、意图等的控制;(2) 场景化、行业干预。

位置、时间、意图等的控制:位置,时间控制主要是防止一些bad case的出现。意图控制表示用一个模型识别用户意图,从而决定是否出风向标。

场景化、行业干预:由排序生成的词在需求聚焦方面做的比较好,但场景感和发散性不够,因此通过一个模型来使生成的4个词更具场景感,并生成相应的场景文案(比如图4中的"男宝这么穿")。另外,我们还在双十一和黑五引入了行业干预,一方面通过引入行业知识提升风向标效果,另一方面也能完成一些行业指标,达到双赢的效果。

端智能

用户在商品详情页有丰富的行为信息,包括加购、收藏、停留时长等,这些信息对捕获用户的即时兴趣非常重要。在模型中引入端智能信息后,已经显著提升关键词推荐效果。

当然,该模块还有很大改进空间:

很多端智能信息,包括滑屏轨迹,查看宝贝介绍,查看买家评论等还没建模到我们的模型,更多有用信号的引入将提升推荐效果;

用户在详情页的行为也构成一个序列,使用Attention_GRU模型对详情页的行为序列建模将进一步提升推荐效果;

现在的召回,精排、重排、展现控制等过程都是在服务端完成,但实际上每个终端都可以存储自己的模型,这样上述过程都可以移到终端上去做,做到模型的实时更新。在服务端的框架下,一个模型服务所有用户,在端智能的框架下,每个人都拥有自己的个性化模型。

双十一

风向标在双十一取得了非常不错的成绩,各项业务指标都超出预期。根据用户的收敛和发现性需求,我们在双十一当天不同时段执行了相应的调控策略:前半场用户购物意图明确,主推收敛性query;疲软期发现性需求更强,主推场景化query;晚上再收割一波购物需求,增加收敛性query的数量。

图11 双十一风向标调控策略

image.png

总结和展望

交互式推荐是一个比较有前景的方向,我们在首页猜你喜欢做了交互式推荐的一个创新尝试:风向标。通过大家的努力,风向标在2018年双十一已经取得一定的成绩。

但是,风向标还有很多可以改进的地方,包括:

现在利用的详情页数据还比较有限,包括加购,收藏,停留时长等。接下来,我们将获取更多的详情页数据,包括在详情页点了哪些按钮,看了哪些板块,滑屏轨迹及滑屏速度等,并进一步优化模型来更好地对这些详情页数据建模。

场景化query的召回逻辑现在还比较简单。接下来,我们会引入知识图谱信息,来提升场景化query的召回和精排效果。

特征体系和目标函数有待改进。现在的特征体系主要包括用户侧特征和query侧特征,而没有充分利用trigger item的信息。另外,现在的目标函数主要是考虑一跳点击率,但二跳的ipv和成交金额显然更重要,因此如何将二跳指标也考虑进目标函数也是一个优化点。

现在二跳页是调用搜索的接口。但搜索的接口主要是考虑二跳结果页与关键词的相关性和用户的个性化,而没有把一跳的trigger item考虑进去。因此,改进二跳算法,或重新设计新的二跳算法也是一个待优化的点。

交流相关技术问题,请联系zy143829@alibaba-inc.com。

引用:

[1] Christakopoulou, Konstantina,Alex Beutel, Rui Li, Sagar Jain, and Ed H. Chi. "Q&R: A Two-StageApproach toward Interactive Recommendation." KDD, pp. 139-148. ACM, 2018.

[2] Zhao, Huan, Quanming Yao, JiandaLi, Yangqiu Song, and Dik Lun Lee. "Meta-graph based recommendation fusionover heterogeneous information networks." KDD, pp. 635-644. ACM, 2017.

[3] McMahan, H. Brendan, GaryHolt, David Sculley, Michael Young, Dietmar Ebner, Julian Grady, Lan Nie et al."Ad click prediction: a view from the trenches." KDD, pp. 1222-1230.ACM, 2013.

[4] Zhu, Yu, Hao Li, Yikang Liao,Beidou Wang, Ziyu Guan, Haifeng Liu, and Deng Cai. "What to do next:Modeling user behaviors by time-lstm.", IJCAI, pp. 3602-3608. 2017.

[5] Zhu, Yu, Junxiong Zhu, JieHou, Yongliang Li, Beidou Wang, Ziyu Guan, and Deng Cai. "A Brand-levelRanking System with the Customized Attention_GRU Model.", IJCAI, pp.3947-3953. 2018.

[6] Chorowski, Jan K., DzmitryBahdanau, Dmitriy Serdyuk, Kyunghyun Cho, and Yoshua Bengio."Attention-based models for speech recognition." NIPS, pp. 577-585.2015.

[7] Mnih, Volodymyr, NicolasHeess, and Alex Graves. "Recurrent models of visual attention." NIPS,pp. 2204-2212. 2014.

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
8月前
|
SQL Java 关系型数据库
从系统报表页面导出20w条数据到本地只用了4秒,我是如何做到的
最近有个学弟找到我,跟我描述了以下场景: 他们公司内部管理系统上有很多报表,报表数据都有分页显示,浏览的时候速度还可以。但是每个报表在导出时间窗口稍微大一点的数据时,就异常缓慢,有时候多人一起导出时还会出现堆溢出。 他知道是因为数据全部加载到jvm内存导致的堆溢出。所以只能对时间窗口做了限制。以避免因导出过数据过大而引起的堆溢出。最终拍脑袋定下个限制为:导出的数据时间窗口不能超过1个月。
|
9月前
|
安全 Java Windows
不可或缺的BCUninstaller:全面显示软件信息、批量垃圾删除、强制卸载程序……
不可或缺的BCUninstaller:全面显示软件信息、批量垃圾删除、强制卸载程序……
|
网络协议 测试技术 Go
海量用户通讯系统-显示在线用户列表(1)|学习笔记
快速学习海量用户通讯系统-显示在线用户列表(1)
144 0
海量用户通讯系统-显示在线用户列表(1)|学习笔记
|
机器学习/深度学习 JSON 网络协议
海量用户通讯系统-显示在线用户列表(7)|学习笔记
快速学习海量用户通讯系统-显示在线用户列表(7)
92 0
|
网络协议 测试技术 Go
海量用户通讯系统-显示在线用户列表(2)|学习笔记
快速学习海量用户通讯系统-显示在线用户列表(2)
58 0
|
机器学习/深度学习 JSON 网络协议
海量用户通讯系统-显示在线用户列表(3)|学习笔记
快速学习海量用户通讯系统-显示在线用户列表(3)
98 0
|
网络协议 测试技术 Go
海量用户通讯系统-显示在线用户列表(5)|学习笔记
快速学习海量用户通讯系统-显示在线用户列表(5)
73 0
|
机器学习/深度学习 JSON 前端开发
海量用户通讯系统-显示在线用户列表(4)|学习笔记
快速学习海量用户通讯系统-显示在线用户列表(4)
78 0
|
JSON 网络协议 测试技术
海量用户通讯系统-显示在线用户列表(6)|学习笔记
快速学习海量用户通讯系统-显示在线用户列表(6)
88 0

热门文章

最新文章