写点什么

阿里飞猪主题与交互式推荐技术实践

  • 2021-03-11
  • 本文字数:6039 字

    阅读完需:约 20 分钟

阿里飞猪主题与交互式推荐技术实践

今天要分享的主题包括两个子主题,一个是交互式推荐的应用实践,另外一个是旅行主题场景里的深度学习算法的实践。


在飞猪推荐场景中,除了对单一商品的推荐外,还包括对以主题形式组织的商品集合的推荐。飞猪旅行主题是一款兼具个性化和发现性心智的产品,在信息流中不但承担着精确匹配用户需求的作用,还扮演着挖掘用户潜在需求、提升用户体感的角色。本次分享介绍飞猪在商品集合推荐的算法应用。

相比于 feeds 场景的自然下滑无感推荐模式,交互式推荐通过”提问-反馈”的显式交互模式,一方面可以增加用户在 App 使用中的参与感,另一方面也有助于系统更实时地捕获到用户即时偏好,从而进一步提升推荐效果。我们在飞猪 App 瀑布流场景中,基于端智能推荐框架,也进行了一些交互式推荐的实践。

飞猪场景交互式推荐背景介绍

交互式推荐的概念最早在 2018 年 Youtube 的一篇论文《Q&R: A Two-Stage Approach toward Interactive Recommendation》中提出来,它是一种采用和 QA 系统类似的推荐方式,系统针对不同的用户生成问题来探测(询问)用户偏好,然后根据用户的行为反馈(比如点击或选择项)进行视频推荐,循环往复。


在飞猪 App 推荐瀑布流场景中,这种显式地反馈交互也提供了一种实时捕获用户意图的方式。

上图是飞猪首页瀑布流场景中交互式推荐的示意,例如用户 A 点击了“丽江自由行“商品,点击位置下方会推荐出包含“丽江”目的地攻略聚合卡片;用户 B 点击了”重庆 4 天 3 晚自由行”,点击位置附近会推荐重庆酒店和玩乐项目相关的 query 聚合卡片进一步探索用户兴趣;用户 C 点击了阿坝自由行,下方可能会推荐出包含该商品的榜单供用户参考。


飞猪 app 作为一种偏工具化的产品,用户的行为是比较稀疏的,大多数用户只有在有出行需求的情况下,才会来到我们的 app,用户购买交通类的商品(机票/火车票)比较多,度假玩乐商品相对较少,而飞猪瀑布流主要是以度假玩乐商品的推荐为主,稀疏的行为数据通常不太能准确地学习到用户意图。例如用户的前一次访问可能是半年前,我们基于这种稀疏久远的历史记录来刻画用户当前的意图,可能是不够准确的。在当前的这种双列的分页批量推荐的瀑布流场景下,用户在当前瀑布流产生点击行为之后,如果我们不能及时地捕获到用户的实时意图并进行相应的承接,用户很可能在浏览了第一页后就流失掉,这也是我们需要解决的问题。交互式推荐可以通过实时的操作方式去承接用户需求,另外也可以将用户的意图通过 query 的方式去进行探索和细化。


交互式推荐 VS 瀑布流常规推荐对于常规 Top-N 推荐来说的话,一般我们是会基于用户的各种维度的行为数据进行意图建模。在实际环境中,客户端用户产生点击行为,通过常规的日志链路(通常是批量上报)进行数据上报,通过日志服务器采集下来,然后给到服务端计算用户偏好,这里的链路的耗时通常是分钟级的。在实际场景下用户在往下滑的过程中,例如从第一页下滑到第二页,第二页的推荐结果返回到客户端时,可能第一页的行为还没有同步到用户偏好计算模块,这里就存在实时的兴趣偏好捕捉不到的情况。

而在实时交互式推荐中,我们会将用户点击数据通过一个高速通路的方式传给服务器,包括可以通过参数的方式直接传给服务器,行为数据随请求实时传回用户偏好模块进行计算。整个来讲,对比瀑布流推荐 Top-N 的全局最优的方式来说,这是一种轻量级的局部最优的推荐。另外,相对来说这是一种主动的对话式推荐,可以显示告诉用户我们推荐瀑布流的内容,给用户一种比较好的互动性体验。

用户需求分类及承接


交互式推荐场景下,我们对各种基础物料(比如度假商品/酒店/景点/目的地/query 词等)进行重新组织,用以承接处于不同旅行状态周期的用户的需求。


① 决策期用户:兴趣比较集中,用户知道自己要找什么商品,这类用户一般是会选择一些相似的商品进行比价。对于这种场景,比如用户点击了一个酒店套餐,会给他推荐同目的地下的酒店套餐。点击酒店之后会给他推荐同地域同级别的类似酒店等。


② 冲刺期用户:对于冲刺期用户来说,已经有相关的订单或者一些很明确的交通信息。这种情况下,如用户买了自由行商品之后,去到目的地后可能会需要一些门票,一些需要逛的景点;或者他并没有买机票,那我们可能就会给他推荐特价票务信息等。


③ 种草期用户:这里旨在探索用户需求,通过返回一些关键词,包括类目、目的地、主题这种卡片形式让用户去选择,从而判断确定用户的需求是什么。

用户实时兴趣捕捉和细化

这里通过图示的方式展现交互式推荐如何实时更新用户偏好。T-1 时刻用户有一些长短期行为计算得到的偏好目的地、类目、主题、玩法等维度用户画像数据。然后,我们会给他推荐一个目的地的探索卡片,比如包含成都/重庆/上海的卡片,因为这里是动画操作效果,大部分情况下用户是可以感知到这些实时插入瀑布流的卡片的存在的,如果用户对于卡片里的目的地都没有点击反馈,那么可以视作用户对这里的目的地是不感兴趣的,那么下一时刻,我们会把这些数据给融合进用户画像中,作为一个负反馈的数据放进去,如果用户在此前的画像偏好中是有成都的,那么可能会削减之前的权重。反之,如果有点击行为,则会强化对应 trigger 的权重。

1. 找相似召回

对于决策期用户来讲的话,用户实际上是更多地是一种找相似的需求,对应的召回主要是基于高相关召回的方式进行的。在前一期的分享里,我们有些环节也提到了 CF 和 Swing,或者是基于 Session based Swing 的方式的召回方式,这种计算访问相关性的方式,可以保证商品的高相关性。在 Session based 这种相似计算的方式里面,我们增加一些限定条件,比如在找相似的情况下,实际上用户的需求大部分情况下是找同目的地的相关商品,我们会加上目的地的条件进行相关性约束,这种情况下基于协同过滤的召回结果里面,可以很好地避免目的地不一致这种 badcase 的存在,用户体验会好很多。

2. 搭配相关性召回

对于相关性召回来说,这里主要考虑搭配性召回。例如用户点击了自由行商品(通常部分或全部包含交通/酒店/玩乐等元素),我们推荐的酒店,机票,当地玩乐商品实际上是需要跟这个自由行去搭配的。对于搭配召回来说的话,目前也是基于用户的行为数据来计算搭配类目。比如给定自由行的 trigger,然后在指定目的地相同的情况下,进行相关性的计算,得到不同类目下的相关性召回结果。

3. 探索性召回


在探索性召回方面,目前主要通过 query 和目的地卡片的方式进行推荐。其中 query 主要是来自于用户在飞猪的搜索栏等场景里输入的查询词。整体上来说,仅使用用户搜索 query 后进行点击的宝贝作关联获取的样本量是比较小的,对此,我们进行了一些扩充,将 query2item2item 这类二跳关联的商品 query 对加入候选,提高召回覆盖。


举个例子,湖州和千岛湖的自由行都是在江浙地区,我们计算出它们间有很高的相关性,如果用户之前有过湖州相关的行为,那么会给用户推荐千岛湖这样的 query 去探索其兴趣。同样地,还会基于人群用户偏好的方式产生一些 query 给用户以进行探索,比如在杭州很多人会去搜索迪斯尼这样的一个 query 关键词,假如这个用户是杭州人,那么我们也会把迪斯尼这样的一个搜索热词推荐给用户进行探索发现,目的地词的推荐也是类似的计算逻辑。

4. 推荐理由生成


交互形态上,除了前面介绍的多种形态的卡片外,我们还会在推荐的卡片上固定的坑位给用户显式地提示出推荐理由的,一般会如下几种方式生成:


1)基于用户行为,如浏览/加购/收藏等;

2)基于用户所属人群:同好人群相关信息;如“xxx 海岛控也在逛”;

3)被点击商品所属的主题榜单排名等。

5. 交互卡片选择


如前所述,我们有丰富的卡片类型(9 种)去满足不同用户的需求,在底层的物料选择上,我们会基于通用的 Match/Rank 模块得到各类基础物料的点击率 top50,然后基于基础物料候选池,组装生成待推荐的卡片的候选池(部分卡片为聚合类卡片),在此基础上通过卡片选择模型预估 ctr 得到 top1。这里主要是使用了一个三层的全连接网络,使用的主要特征如下:


  • 用户侧特征,User Profile 特征,长期/短期目的地/类目/主题等偏好。

  • 实时 Trigger 特征,Trigger 类型,类目、目的地、关联 POI、tag 等。

  • 卡片相关特征,Card 类型,Card 关联商品/酒店/POI;Card 关联主目的地、类目等。飞猪的实时交互的方式对比自然瀑布流推荐是有明显的优势的,在有点击行为的 session 下,实时推荐卡片的坑位 ctr 明显高于自然瀑布流的坑位平均 ctr。


旅行主题推荐介绍

接下来,给大家介绍一下旅行主题是如何在我们飞猪的信息流中进行个性化推荐的。

1. 背景介绍


主题是具有一定共性的度假商品组成的集合,是基于用户兴趣点为中心的一种更为复杂的商品组织形式,旅行主题在我们的信息流中不但承担着精确匹配用户需求的作用,还扮演着挖掘用户的潜在需求、提升用户体感的一个角色。比如,对于一个有交通类订单并且有明确度假意图的用户,我们可以给他推荐一些目的地玩乐的主题清单;对于没有任何行为或者度假意图不明确的用户,我们可以基于用户的 LBS 定位或者根据当前的时令节假日等维度给用户推荐一些当季的周边游主题,所以旅行主题在我们的飞猪信息流中是一款兼具个性化性质和发现性性质的产品。


主题入口通过个性化引流引导用户进入到主题承接页,主题承接页的样式是多种多样的,根据承接页的商品排序方式大致可以把旅行主题分为两类:一类是千人千面的主题清单,一类是千人一面的主题榜单。

2. 旅行主题推荐的特性

我们的主题有两个特性:

  • 所见即所得,即用户在主题入口看到的图片是用户进入承接页看到的第一个商品的图片

  • 商品和主题之间是多对多的关系,一个主题下面会有很多的商品,同时一个商品也会归属于多个主题

3. 旅行主题的组织方式


如上图所示,旅行主题的组织方式是多种多样的,以此来满足用户不同层次和粒度的需求,这些旅行主题是算法基于商品的标签和用户的行为自动聚合出来的,也有一些是运营同学人工整合的。


在飞猪的各个推荐场景中,我们几乎都可以看到旅行主题卡片的身影,最典型的两个场景:一个是双十一等大促场景中的榜单会场入口,另一个是飞猪首页猜你喜欢信息流中与其他商品或者酒店进行混排的卡片。无论是主题入口的个性化推荐还是主题承接页的排序、甚至到主题的生产都离不开算法的参与。接下来我们会着重介绍一下主题入口的个性化排序算法。

主题推荐算法

1. 主题推荐流程


主题推荐的流程和单个商品的类似,大致也是分为召回和排序两个阶段,在召回之后和排序之前,我们会加入很多人群属性和时空属性做一些规则性的过滤,比如:对于非亲子类的人群,我们会把亲子类主题过滤掉。最后的业务逻辑部分,我们会做一些简单的业务加权之类的操作。下面我们会详细介绍主题的召回和排序这两部分。

2. 主题召回

主题召回的个性化包含首图个性化和文案个性化


首图个性化:

HOW:将商品的图片直接曝光给用户,来实现主题首图的个性化

WHY:

① 通过商品的图片吸引用户进入承接页(商品相关性)

② 降低过度曝光对用户造成的视觉疲劳度(商品新颖性)


文案个性化:

HOW: 主题本身的个性化



由于我们的主题入口是由商品和主题本身共同决定的,商品的个性化实现了主题首图的个性化,而主题本身的个性化则实现了包装这个商品的主题卡片的个性化。所以,在我们做主题召回的时候,天然的就会分为两层,一层是商品的召回,一层是主题的召回。我们既可以先召回商品再召回商品所归属的主题,也可以直接召回主题,然后召回主题下挂载的商品。针对不同的用户状态,我们会有不同的召回通道。


静默用户:

对于长期无任何行为的静默用户,我们可以基于用户的 LBS 定位信息和当前的时令节假日等客观因素,然后关联主题的标签,直接召回相关的主题,再召回主题下的商品。


种草期用户:

对于有行为的种草期用户,我们可以基于用户的机票、火车票、酒店、度假商品等行为,分析出用户偏好的目的地、类目、玩法等,然后基于 X2I、I2I 等通道去召回商品,同时召回商品所归属的主题。


决策期用户:

对于有行程的决策期用户,我们会做一些搭配性召回。例如,对于有机票订单的用户,会给他召回一些机场的接送清单。


行中用户:

对于行程中的用户,我们会根据用户的 LBS 定位召回当前目的地附近的一些玩乐、景点类的清单。

3. 主题排序


在召回商品和主题之后,因为一个商品是可以挂载多个主题的,在对商品进行排序后,我们就要给每个商品选择一个主题,一个最简单的方式就是给每个商品保留一个最热门的主题。但是,这种方式没有考虑用户对主题本身的偏好,另外,这种方式会导致我们的推荐结果越来越趋于头部热门的现象。所以,我们增加了一个用户对主题本身的偏好的预估,最后,主题卡片的排序就由商品和主题来共同决定。两个决策因子的权重通过人工调参的方式找到一个局部的最优解,线上 AB test 验证这个方式的点击率较之前只考虑热门的方式有一个较大的提升,此外,这种方式也能明显的减缓主题推荐的马太效应。


在前面的那种方式里,商品的 CTR 预估和主题的 CTR 预估是独立建模的,也就是说,我们分别训练了两个独立的模型对商品和主题进行打分。考虑到我们的主题是基于商品的目的地、类目、玩法等维度聚合而来的,所以主题下挂载的商品的特征也能对主题进行一定的表达。另外,主题的入口是由商品和主题本身所共同决定的,所以主题排序和商品排序实际上是两个相关的任务。


因此,我们借鉴了多任务学习的思想,联合学习商品的 CTR 预估和主题的 CTR 预估。上图就是我们的模型结构图,两个子任务共享中间的隐藏层,同时在上层保留各自的网络结构。我们之所以没有让两个子任务在网络的底层就参数共享,是因为这两个子任务输入的样本的特征和特征的维度是不一样的。所以,我们通过加入一层全连接层,将两个任务输入的特征映射到相同的维度,最后模型训练的损失函数就由两部分组成,分别对应商品的 CTR 预估和主题的 CTR 预估。离线评测显示多任务学习可以同时提升两个子任务的 AUC,线上的 AB test 也能带来一定的点击率提升。


在实际线上使用的过程中,我们还是通过将两部分分数进行融合的方式来决定最终的主题卡片的排序,这种人工调整融合方式和权重的做法是很低效的,而且很难找到最优解,所以我们尝试将主题和商品这样一个 pair 进行建模,也就是对商品和主题这样一个整体进行点击率预估,最终线上 AB test 表明这种简单直观的建模方式,相对于基线而言也是有所提升的。

4. 工程 Trick 分享

最后,给大家分享一个小 trick,如果用户点击了主题入口,很可能是主题卡片和附近的商品在样式上有所差别,也可能是主题卡片真正命中了用户的兴趣点或需求点。但是如果用户点击了主题入口,进入到主题承接页,并且在承接页内点击了其他的商品,这种行为显然要比用户直接跳出承接页表现出了更强烈的兴趣,所以我们把用户在承接页的点击正反馈考虑在内,调整了主题排序的样本,即对主题承接页有点击的入口正样本进行上采样。离线评测和线上 AB test 都显示有一个明显且稳定的提升。


嘉宾介绍:

羲农,负责飞猪 App 实时交互推荐场景的效果优化,飞猪个性化场景可解释性推荐。

里熙,2018 年 7 月毕业于西安电子科技大学。目前主要负责飞猪旅行主题的生产和投放。


本文转载自:DataFunTalk(ID:dataFunTalk)

原文链接:阿里飞猪主题与交互式推荐技术实践

2021-03-11 13:002251

评论

发布
暂无评论
发现更多内容

这才是大数据的正确打开方式

华为云开发者联盟

大数据 数据仓库 云原生 数据治理 灾备

阿里P8重磅总结:看完别说不会了哦,SpringBoot「完结篇」

比伯

Java 编程 程序人生 计算机 架构】

MySQL 索引概要

小方

MySQL 索引

openLooKeng如何应对“野蛮零散”的大数据

openLooKeng

大数据 开源 openLooKeng

史上最强的:京东北极星商业系统权限管控实践

Java架构师迁哥

Impala架构详解

五分钟学大数据

4月日更 impala

关于ReentrantReadWriteLock,首个获取读锁的线程单独记录问题讨论(firstReader和firstReaderHoldCount)

徐同学呀

AQS Java源码 JUC

CopyOnWriteArrayList源码解读之CopyOnWrite思想的利与弊

徐同学呀

Java源码 JUC CopyOnWriteArrayList

边缘计算是流行词还是风口?开发者怎样选开源项目?

华为云开发者联盟

开源 开发者 5G 边缘计算 EdgeGallery 社区

架构实战营 模块二作业

fazinter

架构实战营

MySQL存储过程的异常处理

Sakura

4月日更

还有人搞不懂数据仓库与数据库的区别?

大数据技术指南

数据仓库 4月日更

堪称神作!阿里数位专家联合写的“大厂高频Java面试手册”

码农之家

Java 编程 程序员 互联网 面试

Github霸榜数月!原来是阿里大牛最新的Java性能优化实战笔记

钟奕礼

Java 编程 程序员 架构 面试

架构师实战营 模块二总结

代廉洁

架构实战营

Spring Bean创建过程的Hook

邱学喆

BeanPostProcessor @Autowired注入原理 @Resource注入原理 @Value注入原理

第 0 期架构训练营模块 2 作业

架构实战营

阿里高工熬夜14天码出这份Java10w字的面试手册!却遭GitHub封杀

Java架构之路

Java 程序员 架构 面试 编程语言

程序员3年CRUD从8K涨到20K,这4个月我到底经历了什么?

码农之家

编程 程序员 互联网 面试 职场

2021互联网大厂高频面试专题500道:并发编程/Spring/MyBatis(附答案解析)

比伯

Java 编程 架构 程序人生 计算机

聪明人的训练(十七)

Changing Lin

4月日更

为极客时间增加自动提醒功能,督促用户回来上课

克比

ThreadPoolExecutor源码解读(一)重新认识ThreadPoolExecutor(核心参数、生命周期、位运算、ThreadFactory、拒接策略)

徐同学呀

线程池 Java源码 JUC ThreadPoolExecutor

架构师实战营 模块二作业(微信朋友圈高性能复杂度架构分析)

代廉洁

架构实战营

Anolis OS 8.2 RC2 发行,支持飞腾、海光、兆芯、鲲鹏等芯片

阿里云基础软件团队

阿里P8整理出SQL笔记:收获不止SOL优化抓住SQL的本质

Java架构之路

Java 程序员 架构 面试 编程语言

阿里高工熬夜18天码出Java150K字面试宝典,却遭Github全面封杀

Java架构之路

Java 程序员 架构 面试 编程语言

技术实践丨列存表并发更新时的锁等待问题原理

华为云开发者联盟

事务 update 元组 列存表

计算机原理学习笔记 Day8

穿过生命散发芬芳

计算机原理 4月日更

探索区块链Baas平台的奥秘,源中瑞公共服务平台开发技术

源中瑞-龙先生

区块链 源中瑞 Baas

FutureTask源码解读,阻塞获取异步计算结果(阻塞、取消、装饰器、适配器、Callable)

徐同学呀

Java源码 JUC Future

阿里飞猪主题与交互式推荐技术实践_AI&大模型_DataFunTalk_InfoQ精选文章