GTLC全球技术领导力峰会·上海站,首批讲师正式上线! 了解详情
写点什么

有赞推荐系统关键技术

2019 年 11 月 06 日

有赞推荐系统关键技术

个性化推荐是随着移动互联网发展不断发展起来的,它是建立在海量数据挖掘基础上的一种高级商务智能平台,以帮助电子商务网站为其顾客购物提供完全个性化的决策支持和信息服务。有赞微商城使用个性化推荐系统,尤其是在关键节点增加推荐入口,进行场景化推荐,帮助商家进一步提高用户的付款转化率,最大化流量变现。


一、场景介绍

目前接入个性化推荐的入口有微商城商详页、购物车、订单列表、物流信息等 7 个系统固定页面,除此之外,我们也封装了插件用于店铺装修接入个性化推荐,如微页面、个人中心、日历签到,也用于店铺活动页面,如砍价、秒杀、好评有礼等,如下图部分示例:



二、整体架构

有赞个性化推荐系统可以分为数据、存储、服务和应用四个层级,如下图所示。其中数据层又分为离线和实时两部分,离线会根据三个维度生成召回商品集合,离线也会对接 DMP 画像数据用于模型构建,同时根据用户的实时行为进行实时推荐;存储层用于存储数据层的数据,离线召回主要是用 hbase 存储,实时用 druid ,另外也设置了 redis 缓存,来解决部分线上性能问题;服务层是对外提供接口的部分,根据不同场景配置的召回策略,依次进行召回、排序,实时过滤三部分操作;应用层直接对接服务层,发起请求得到推荐反馈,进行商品展示。后面章节介绍该推荐系统的关键技术点。



三、召回

主要在数据层产出,是对用户的浏览、加购、购买、搜索、咨询等多维度行为进行分析,产出不同召回源,用于实时召回、离线召回和冷启动召回。


3.1 实时召回

根据实时浏览和咨询的商品从离线相似度表获取相似商品后,对所有相似商品计算分值进行排序,根据得分做推荐。目前一些用于实时召回的其他模型也正在研发中,另外针对用户的实时行为分析更多的维度,如收藏、加购等行为,结合对用户实时意图的分析进行推荐,应该效果会更好些。


3.2 离线召回

3.2.1 CF(基于协同过滤)

协同过滤是比较经典也是使用最广泛的召回算法,其中 Item-CF 其原理是根据两个商品被同时浏览/加购/购买的频率来分别计算两个商品之间的相似度分,得到三个商品相似度表;然后通过用户的请求触发去分别查询商品相似度表,扩展用户感兴趣的商品。User-CF 是根据用户浏览/加购/购买商品的共现情况,计算两个用户之间的相似度;假设 A 是与用户 a 最相似的 topK 个用户集合,就可以将相似用户浏览/加购/购买的商品推荐给用户 a。协同过滤的基本算法虽然简单,但是要获得更好的效果,往往需要根据实际的业务场景进行调优。合理选择计算商品之间相似度的数据的时间窗口,引入时间衰减,归一化、打散等策略对优化 Item-CF 的效果都有很大的帮助。


3.2.2 ClassPrefrence(基于类目偏好)

基于类目偏好的召回,利用全网数据分析用户的类目喜好,同时结合类目热销商品,召回商品集合,这个算法原理比较简单,实现上难度也不是很大。


3.2.3 FPgrowth(基于频繁项挖掘)

利用 FPGrowth 算法挖掘商品之间的频繁项,频繁项挖掘的一个典型例子是购物篮分析。频繁项研究有助于发现交易数据库中不同商品之间的联系,找出顾客购买行为模式,分析哪些商品会被一同购买,还有一同购买的频次是多少,经常被一同购买的商品就可以放到一起做推荐了。我们实际使用过程中,扩展到了浏览和加购行为,即总是在同一个会话中被浏览或者总是被同时加购,也作为了可推荐候选集的一部分。


3.2.4 Produce&Word2Vec(基于产品词的 Word2Vec)

这个算法结合了产品词和语义分析,首先基于 Word2Vec 召回候选集,利用商品标题信息进行 embedding,然后计算余弦相似度,这一步召回的候选集量往往很大,所以引入产品词目的是将相似度计算范围缩小,因为只有产品相似的商品才有计算的必要。


3.2.5 QueryWords(基于查询词)

这个算法比较直接的获取用户喜欢的商品,首先需要根据搜索词和搜索后点击的商品建立搜索词及商品的联系,结合用户对搜索词的喜好,进行相关商品推荐。简单说就是通过搜索词将商品和用户联系起来,进行个性化推荐。不过需要考虑实效问题,用户对商品的需求一段时间内可能有一定兴趣,才会进行搜索,达到购买需求后一般都会进行其他需求的搜寻,这样当建立用户与搜索词的偏好联系时,分析的搜索行为数据时间窗口不宜过长。


3.2.6 Seq&Word2Vec(基于用户行为序列的 Word2Vec)

计算所有用户一定时间窗口范围内对每个商品的浏览次数,同时考虑浏览顺序,挖掘得到商品直接的关联模式,如商品 A 和商品 B 在 M 个用户浏览行为中都有先后的浏览顺序,则模式商品 A -> B 的权重是 M ,挖掘更多这样的模式可以得到一个有向图,然后用随机游走在有向图上采集到商品序列,作为 Word2Vec 的输入样本,embedding 后得到商品的向量,从而可以进一步计算商品相似度用于推荐。除了浏览行为外,也可以从点击、购买等行为中挖掘这样的序列模式,可以使用 Word2Vec 生成商品向量,也可以根据用户序列预测用户的下一步行动,如下一个浏览、点击或购买等的商品,最终实现个性化推荐。


3.2.7 其他

除了考虑用户的浏览、点击、购买、搜索、咨询等行为生成了对应的召回算法外,也考虑了地域、年龄、性别等维度的信息,在对这些维度深入分析的基础上,设计了相应的召回算法。


3.3 冷启动召回

3.3.1 shopHot(基于店铺热销)

跟店铺销量相关的推荐源分别有根据店铺热销和店铺内不同类目热销,后者还做了类目的打散,考虑到只根据整体销量的话,每天推出的商品多样性会较差,加入类目打散,可以缓解这个问题。


3.3.2 linUCB(基于 linUCB 算法)

linUCB 算法是 UCB 算法( Upper Confidence Bounds 的首字母缩写)的扩展,对于 UCB 主要是为了解决 Multi-armed bandit 这个问题,思路就是使用置信区间,即不确定程度,区间越宽越不确定。每个商品的回报均值都有个置信区间,随着实验次数增加,置信区间会变窄,每次选择前都根据已经试验的结果重新估计每个商品的均值和置信区间,选择置信区间上限最大的那个商品。不过在推荐领域,一个选择的回报是由用户和商品共同决定的,完全可以用特征来刻画两者,选择前如果能使用特征预估每个商品的期望回报即置信区间会更合理些,这也是 UCB 需要解决的一个问题,所以 linUCB 就诞生了。linUCB 算法做了一个假设,一个商品被选择推荐给一个用户,其回报和相关特征成线性关系,用用户和商品特征预估回报和置信区间,选择置信区间上界最大的商品推荐,观察回报后更新线性关系的参数,从而进行迭代学习。之前的冷启动只有店铺销量相关的召回算法,且在推荐曝光商品中占比较高,没有做商品和用户的个性化,对于新品流量也很少,对于实时上架的新品也是无法及时推荐的。linUCB 就是针对新品的冷启动方案,新品给予一定机会进行曝光展示来验证商品的效果,逐渐迭代参数,使得效果好的商品曝光越多,效果差的商品曝光越少。


四、排序

排序模块已经做了一些工作且还在不断持续优化中。线上已经运行的主要是基准版本和 Wide&Deep 版本。基准版本是简单的融合策略,根据召回策略将同一商品来自不同召回源的打分直接加和,类似于投票法,虽然简单粗暴但是有一定效果。基于 Wide&Deep 的排序也是经验验证有效果的,所以优先使用此算法来优化效果。Wide&Deep 由两部分组成,分别是 Wide 和 Deep,如下图所示。传统的 Wide 类型的特征可以对确定性的推荐很好的建模, 如果考虑到多样性,就需要对稀疏数据和”没有直接观测到”的行为数据建模,Deep 部分可以对多阶的行为传导更好的表达。



上图参考论文《Wide & Deep Learning for Recommender Systems》


Wide&Deep 最后一层中 Deep 和 Wide 部分是合并到一起的,将 Wide 部分的特征和 Deep 部分的最后一层的特征对齐,然后统一送入到一个逻辑回归模型中,模型公式如下:



五、存储表设计

离线召回是基于 HBase 存储,对于三类离线召回源用户-商品、商品-商品、店铺-商品分别设计了三类存储 RowKey,这样便于管理不同召回算法产出的结果,同时只需要个位数的存储表就可以满足大部分的常规接入场景。另外,这三个表上层的不同召回算法是并行导入的,而不是所有结果汇总后一起导表,是为了避免一个算法的结果导入失败时还得全部结果重导的悲剧。


六、场景策略配置

不同场景接入推荐时,会有实时、离线、冷启动三部分召回策略,即对于每个场景,都会有针对实时、离线、冷启动三部分的配置,便于线上服务读取解析。配置的策略内容是经实验验证效果较好的召回源,如商详页场景,实时需要兼顾考虑时效性和当前推荐的场景性质,配置商品相似度相关的召回源是可以满足场景需求的;离线如果推荐与主商品有关联的商品效果不错,就会配置频繁项挖掘这个召回源;冷启动作为兜底方案,使用店铺热销方案也是可以满足需求的,于是配置店铺热销相关的召回源。


上述举例对应配置格式如下(仅供参考): {   实时:      商详页:Item-CF   离线:      商详页:FPGrowth   冷启动:      商详页:ShopHot  }
复制代码


另外,我们也配置了分流策略,当前策略是根据用户唯一标识进行配置,并且不同场景均可配置;还有排序算法的相关参数,如使用特征名称、算法版本、对应场景、对应场景的分流等均可配置。


七、现状及展望

  1. 分流测试策略还有待优化,随着业务的增长,越来越多的推荐场景接入,需要设计更为复杂的分流测试实验,只基于用户唯一标识的方式肯定不能满足需求;

  2. 排序阶段需要进一步优化,尝试更多的主流前沿算法,并结合业务实际情况进行相应调整;

  3. 当前接入个推系统最多的是有赞微商城业务,未来我们期望可以接入更多的推荐场景,包括微商城其他场景、有赞其他业务如零售、精选、分销等;

  4. 从各个环节提高推荐系统的性能,更快速的离线召回产出,更大规模的召回商品参与到重序模块,更及时的排序后结果返回及展示。


本文转载自公众号有赞 coder(ID:youzan_coder)


原文链接


https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA==&mid=2455760129&idx=1&sn=87030af248251c18519186df4af86e68&chksm=8c686b24bb1fe232b6c44d50e1e4d2683e136339ba49c6f0f4137b529780bf5b20d7950ec4c1&scene=27#wechat_redirect


2019 年 11 月 06 日 08:001795

评论

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

为什么软件交付要快?因为要有赢的感觉!

刘华Kenneth

DevOps 敏捷 MVP 最小可用产品 持续交付

大话设计模式 | 2. 策略模式

Puran

C# 设计模式

编程基础

南山

ARTS打卡计划_第二周

叫不醒装睡的人

ARTS 打卡计划

硬核!30 张图解 HTTP 常见面试题

小林coding

https 计算机网络 计算机基础 HTTP

ARTS Week4

丽子

使用 Docker 镜像 | Docker 系列

AlwaysBeta

Docker 容器 虚拟私有云

你了解 SpringBoot java -jar 的启动原理吗?

猴哥一一 cium

Spring Boot Java 面试 Fat-JAR JAR URL Java 25 周年

【在云端 001】欢迎来到云原生

Bora.Don

云计算 云原生

ARTS Week 3

时之虫

ARTS 打卡计划

架构师训练营作业1-食堂就餐卡系统设计

索隆

架构师训练营第一讲-学习总结

索隆

B端产品经理养成记(4):敏捷项目

涛哥

敏捷 产品经理

架构训练营作业-20200614

caibird1984

GoF 23种设计模式

无心水

设计模式 GoF 23种设计模式

原创 | TDD工具集:JUnit、AssertJ和Mockito (二十一)编写测试-动态测试

编程道与术

Java 编程 TDD 单元测试 JUnit

Flink 源码分析之写给大忙人看的 Flink Window原理

shengjk1

flink flink源码 flink window

官方源、镜像源汇总

JackTian

镜像源 官网源

阿里架构师用心整理JVM与性能优化核心知识分享

周老师

Java 程序员 JVM Java 面试 计算机

利用工作日志提高效率

Janenesome

思考 工作方式

愚蠢写作术(4):怎么让写作从开始到放弃

史方远

读书笔记 个人成长 写作 随笔杂谈

国内首个区块链电子档案平台上线

CECBC区块链专委会

区块链技术 防伪 溯源 电子档案

仓储控制系统(WCS)软件可靠性设计

阿喜伯

仓储控制系统 WCS 可靠性设计 容错性 易恢复性

软件设计原则作业

qihuajun

JVM学习笔记——JVM类加载机制

王海

Java JVM Java 面试

推荐几款有意思的小众 App(06.13)

静陌

产品 App

OFD 版式技术解析系列(二):OFD的颜色显示

华宇法律科技

Shell的技巧小总结(MIT Missing Semester)

AndersonKim

Shell MIT 计算机 Computer Science 计算机工具

个人编程技能全景图

南山

1. 版本管理工具及 Ruby 工具链环境

Edmond

rubygems CocoaPods VersionControl PackageManager Git Submodule

小师妹学JavaIO之:用Selector来发好人卡

程序那些事

io nio 「Java 25周年」 小师妹 selector

DNSPod与开源应用专场

DNSPod与开源应用专场

有赞推荐系统关键技术-InfoQ