- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
作者:京东零售 郑书剑 。
现有的同城购业务围绕京东即时零售能力搭建了到店、到家两种业务场景。同城业务与现有业务进行互补,利用高频,时效性快的特点,可以有效提升主站复访复购频次,是零售的重要战略方向.
LBS:基于位置的服务(Location Based Services).
下文LBS商品代指京东小时购商品;LBS推荐代指京东基于地理位置的推荐能力,需要考虑到附近的供给和履约能力.
B2C:直接面向消费者销售产品和服务商业的零售模式.
下文B2C商品代指京东主站商品,包括自营/pop等非小时购商品;B2C推荐指主站主流推荐能力,不需要考虑当前地理位置的供给,而是面向全国用户的推荐模式.
主要推荐模式集中在一下四种流量场域:
1、附近-商品推feeds推荐; 。
2、附近-纯门店推荐; 。
3、附近-门店-商品列表页推荐; 。
4、主站核心推荐场景lbs商品混排推荐(首页为你推荐、购物车、我的京东等); 。
附近-商品推feeds | 附近-纯门店 | 附近-门店-商品列表页 | 首页为你推荐 |
---|---|---|---|
目前主站核心场景从支持b2c商品推荐,b2c内容素材/聚合素材推荐拓展到更丰富的业务形式,支持lbs业务逻辑推荐,给用户带来更多元化的体验,同时给线下商家和运营提供了更丰富的流量渗透策略.
目前lbs商品推荐架构和b2c商品推荐架构的推荐流程紧密的耦合在一起,上线lbs商品推荐相关策略,都需要考虑到b2c推荐业务的逻辑无diff,效率低,兼容性差,迭代成本高,不利于后续优化策略的快速迭代。通过对lbs商品推荐的整体链路进行升级,与目前的b2c商品推荐链路进行解耦,提升系统的拓展性,更易维护,提高算法策略接入的效率。b2c商品和lbs商品均具备独立quota空间,推荐链路更加清晰,效果优化空间更大.
我们的前端展现形态分为纯商品、纯门店、门店-商品三种形态,且推荐位分布较多,为了减少人力维护成本,同时考虑到LBS推荐模式和传统电商模式的差异,以及流量场域分布和推荐展示形态的区别,我们针对LBS推荐能力进行了单独的设计,抽象出一套推荐模板可以同时解决三种推荐模式,支持跨场景复用.
首先前端请求入参用户当前的经纬度信息,推荐系统从gis系统获取当前可履约的门店信息;推荐系统根据用户个性化信息和门店-商品信息,为用户推荐感兴趣的附近门店-商品.
此时的item粒度为门店+商品粒度,为了同时保证用户对门店和商品兴趣的同时感知,区别于b2c商品的推荐模式,我们将整个系统分为两个阶段。在一阶段对用户感兴趣的门店进行推荐,在二阶段对用户的感兴趣的门店下的商品进行推荐。在两个阶段内完成门店推荐、商品推荐、门店-商品推荐三种模式,三种推荐模式可复用算子达到80+%,覆盖站点从京东主站到小程序,覆盖场景从首页-为你推荐到营销推荐位,总计覆盖核心推荐位30+.
背景:LBS推荐是基于地理位置的推荐场景,和主站b2c推荐模式有所差异;用户对更多维度的因素敏感,如门店质量,配送距离,配送时效等等; 。
所以推荐系统需要在召回的时候就考虑到这些体验因素,所以我们将LBS的召回算法设计成两阶段的模式。一阶段根据用户兴趣(user-store兴趣)和门店质量(ka/销量/距离/时效)等因素召回用户感兴趣的高质量/距离近/配送快的门店。在二阶段进行商品召回用于召回用户感兴趣的商品.
同时我们面临着以下几个问题:
冷启问题:我们是新业务+新场景,新品多,新用户多,相比较成熟的b2c场景,lbs场景交互稀疏问题严重; 。
跨场域兴趣迁移:用户在b2c场景和lbs场景的兴趣表达往往是不一样的,不同场景的兴趣表达往往存在着一定的差异和联系,怎么精准捕捉和表达用户跨场景体现出的兴趣是新场景初期发展的重要工作; 。
兴趣激发周期短:lbs场景用户决策成本低,转化链路短,高转化场景下更要关注物品相关关系的表达; 。
我们初期也对以上几个问题进行了简单的探索,通过跨域兴趣探索和优化i2i关联关系简单的验证了我们的想法.
冷启动召回一般有以下几种方案:
•商圈热门:缺点是和user无关,纯热门item召回,相关性差;这里我们将全局热销/poi热销商品作为兜底召回,用于补充; 。
•cross domain:是一种基于不同场域(如京东b2c场景/lbs场景)共同用户的行为将不同域的用户映射到同一个向量空间,然后借助其他域的丰富行为提升本域冷启动用户的召回效果.
我们这里主要针对cross domain的方式进行了一些简单探索来优化跨场域用户的冷启体验效果.
1)潜客画像召回:根据用户在b2c场景的相关行为(诸如偏好类目是否为lbs转化优势类目)以及是否对lbs相关场景有前置行为的用户(推荐下浏览过附近/搜索内点击过小时购通栏等),来判断当前用户是否为lbs的潜在转化用户,给这些用户推荐其在b2c偏好下的高转化lbs商品; 。
2)跨域类目召回:通过对b2c/lbs共现商品进行挖掘,得到b2c到lbs的类目协同关系,根据用户在b2c场景下的偏好类目推荐对应的lbs类目下的商品; 。
3)跨域i2i召回:结合b2c/lbs的用户的跨场域行为,对lbs商品和b2c商品进行i2i关系挖掘,得到b2c sku到lbs sku的相似相关关系,使用b2c的用户行为为其推荐lbs商品; 。
4)间接召回:基于b2c召回结果,为用户召回相似相关的lbs商品.
基于用户在lbs场景的行为直接召回lbs商品,常见方法有如itemCF,swingCF等.
我们针对lbs场景高转化的特点对i2i召回进行了针对性的优化。我们对lbs场景的用户行为进行了分析,发现用户的点击行为体现了商品的相似性(同品比较等),订单行为体现了商品之间的相关关系(搭配购等),但是用户的订单行为往往非常稀疏,且考虑到lbs商品还含有地域属性,直接使用订单行为构建相关的i2i关系得到的结果非常稀疏,召回的下发占比往往比较低.
于是我们把订单的i2i关系抽象为类目-类目,产品词-产品词的的粗粒度相关关系。然后对全站lbs行为进行i2i关系挖掘,得到的结果使用粗粒度相关关系进行过滤,得到了比直接使用定订单行为构建i2i关系更丰富的结果,召回效率也比相似关系的效率更高.
i2i vs embed:i2i的相似相关关系表现的更加精准,但是覆盖率低;embed方式新颖性好,覆盖率高,但是关系表达相对不这么精准.
为了解决前文中提到的问题,对用户行为进行预处理,对异常用户和异常表现的商品先进行过滤,防止脏数据对整体数据分布造成影响,行为选取时,优先保留订单行为附近的用户行为(高质量行为),同时历史行为序列进行了session划分,保证行为的连续性和相关性,更能体现出用户决策周期内的集中兴趣,优化i-i的关联关系.
模型方面我们采用了随机游走的graph embedding建模方式,和传统方案差异不大:行为序列挖掘 -> 同构图构建 -> 带权重游走序列采样 -> skip-gram+负采样训练,得到物品的item embedding.
同时这里的用户行为序列的选取也可以参考跨域的思路,使用b2c行为进行补充,进一步解决lbs场域召回稀疏的问题。线上即可以使用i2i的方式进行召回,也可以使用u2i的方式进行召回。相比i2i直接召回,曝光占比更高,效率更高.
还有诸如其他的根据品类兴趣和常购行为的兴趣画像召回,复购、常购召回等.
排序准备方面,由于历史遗留原因,目前无论是用户在lbs场域的行为,还是lbs商品画像都有所缺失。于是第一步,我们首先对基础数据进行了维护:1)统一了全站lbs行为接入口径:通过门店pv和商详的pv埋点,捕捉全站lbs行为;2)建立了user-sku和user-store的用户画像和lbs商品画像.
排序特征方面:在复用了b2c商品的部分精排特征的基础上,构建了lbs场景的特有特征,如lbs场景用户行为序列,lbs场景商品/门店反馈特征,以及配送时效,配送费,配送距离等context类特征.
模型优化方面:引入了用户在b2c场景的用户行为,同时引入了b2c训练样本做样本增强.
模型结构方面:在模型输入的方面分为和b2c共享的部分,以及lbs独立特征输入的部分,异构b2c/lbs用户行为序列提取多场域用户兴趣,与B2C场景进行多场景联合优化。上线时进行拆图,仅使用lbs task tower进行打分.
lbs推荐能力作为创新业务,我们通过模板化推荐能力,快速承接推荐位30+,支持三种推荐模式,初期快速的助力了全渠道的业务发展.
后续针对业务理解,经过对LBS推荐链路的独立拆分,以及召回和精排迭代优化。在首页-为你推荐上,lbs商品曝光UV占比相对Q3提升 488% ,CTR相对Q3提升159.52%。同时带动整体大盘指标提升,首页整体浏览深度显著提升0.39%,推荐整体uctr显著提升0.79%,推荐人均三级类目点击数显著提升0.76%,推荐外页uctr显著提升0.37%.
后续我们将继续结合场景特点和业务理解,逐渐完善优化LBS流量分发能力,更好服务商家和用户,提升京东LBS推荐能力.
最后此篇关于京东LBS推荐算法实践的文章就讲到这里了,如果你想了解更多关于京东LBS推荐算法实践的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
本文分享自华为云社区《大模型LLM之分布式训练》,作者: 码上开花_Lancer。 随着语言模型参数量和所需训练数据量的急速增长,单个机器上有限的资源已无法满足大语言模型训练的要求。需要设计分布式训
本文分享自华为云社区《五大基础算法--动态规划法》,作者: 大金(内蒙的)。 一、基本概念 动态规划法,和分治法极其相似。区别就是,在求解子问题时,会保存该子问题的解,后面的子问题求解时,可以直接拿来
pip install scp pip install pexpect 测试代码: import os import stat import paramiko # 用于调用scp命令 def s
我目前正在实现“ token ”REST 服务。 token 只是一个字符串,由一些参数构建而成,然后经过哈希处理并在一定时间后过期。 我想在我的 REST 服务中有一个可以验证 token 的端点,
打开软删除后,我在客户端上添加一条记录,推送,删除添加的记录推送,然后尝试使用与初始记录相同的主键添加新记录(然后推送),我得到一个异常(exception)。 EntityDomainManager
打开软删除后,我在客户端上添加一条记录,推送,删除添加的记录推送,然后尝试使用与初始记录相同的主键添加新记录(然后推送),我得到一个异常(exception)。 EntityDomainManager
我有一个应用程序,每 x 秒接收一次天气信息。我想将此数据保存到 XML 文件中。 我应该为每个天气通知创建一个新的 XML 文件,还是将每个通知附加到同一个 XML 文件中?我不确定 XML 标准的
我猜我们大多数人都必须在某个时候处理这个问题,所以我想我会问这个问题。 当您的 BLL 中有很多集合并且您发现自己一遍又一遍地编写相同的旧内联(匿名)谓词时,显然有必要进行封装,但实现封装的最佳方
我有一些 c# 代码已经运行了一段时间了..我不得不说,虽然我了解 OO 原则的基础知识,但显然有不止一种方法可以给猫剥皮(尽管我讨厌那个短语!)。 因此,我有一个基本抽象类作为基本数据服务类,如下所
我设计了一个 SQL 数据库系统(使用 Postgre),我有一个问题,即创建一个关系/引用的常见做法是什么,这种关系/引用即使在引用的对象被删除时也能持续存在。 比如有一个UserORM,还有Act
我们的目标是搜索用户输入的字符串并计算在其中找到多少元音。不幸的是我被困在这里,有什么帮助吗? def numVowels(s): vowels= "AEIOUaeiou" if s
我有一个适用于我的“items”int 数组的旋转函数。下面的代码完成了它,除了我不必要地传输值。我正在努力实现“就地”轮换。我的意思是 ptrs 会递增或递减,而不是从数组中获取值。我需要通过这种方
我有一个 json 存储在我的应用程序文档文件夹中,我需要在我的所有 View 中使用它。我正在加载 json 并将其添加到每个 View 中的 NSMutableArray。但现在我了解到,我可以将
我用 C++ 开始了一个项目。这种语言的内存管理对我来说是新的。 我过去常常使用 new () 创建对象,然后传递指针,虽然它可以工作,但调试起来很痛苦,人们看到代码时会用有趣的眼神看着我。我为它没有
已结束。 这个问题是 off-topic .它目前不接受答案。 想要改进这个问题? Update the question所以它是on-topic堆栈溢出。 关闭 10 年前。 Improve thi
保持类松散耦合是编写易于理解、修改和调试的代码的一个重要方面——我明白这一点。然而,作为一个新手,几乎任何时候我都会超越我所苦苦挣扎的最简单的例子。 我或多或少地了解如何将字符串、整数和简单数据类型封
我发现我需要编写大量重复代码,因为我无法从其他 Controller 调用函数。例如,这里新闻提要内容在我的代码中重复,我对一个 Controller 做一些特定的事情,然后需要像这样加载我的新闻提要
假设需要一种数字数据类型,其允许值在指定范围内。更具体地说,假设要定义一个整数类型,其最小值为0,最大值为5000。这种情况在很多情况下都会出现,例如在对数据库数据类型,XSD数据类型进行建模时。 在
假设我想循环整个数组来访问每个元素。使用 for 循环、for...in 循环或 for...of 循环是 JavaScript 开发人员的标准做法吗? 例如: var myArray = ["app
我有一个旧的 SL4/ria 应用程序,我希望用 Breeze 取代它。我有一个关于内存使用和缓存的问题。我的应用程序加载工作列表(一个典型的用户可以访问大约 1,000 个这些工作)。此外,还有很多
我是一名优秀的程序员,十分优秀!