平台根据业务场景内置多种召回策略,策略规则及参数可根据业务需要进行配置。
目前平台支持5种基础召回类型:高热召回、用户兴趣召回、重定向召回、item_cf召回、模型召回,以及3种相关推荐场景的召回类型:父物品维度高热召回、父物品重定向召回、父物品item_cf召回。每种召回类型均可以创建多个召回策略。每一路召回都可以配置时间、行为以及过滤条件等召回逻辑。
基于推荐内容的行为热度进行统计,并按照热度排序返回召回结果。
例如将时间近1920min
有点击
行为(且满足维度条件设置)的物品,按照“行为发生的频次”由大到小进行召回
如果用户的点击行为如下:【C,C,A,B,D,D,B,C,D,E,D,E,E,B,C,C】,那么召回结果:C>D>E>B>A。
物品 | 行为 | 行为发生时间 |
---|---|---|
itemA | 点击1次 | 100 min before |
itemB | 点击2次 | 200 min before |
itemC | 点击5次 | 300 min before |
itemD | 点击4次 | 400 min before |
itemE | 点击3次 | 500 min before |
基于用户历史行为热度计算用户兴趣偏好,并通过指定兴趣偏好维度返回召回结果。召回结果可以根据兴趣支持多种融合方式,可以根据兴趣等比例融合、根据兴趣所占权重比例进行融合,也可以根据物品/内容得分(按行为频次打分)返回召回结果。
step1:计算用户A的兴趣
用户的兴趣是从他的行为中发现的,首先我们要处理用户的行为数据。
因为配置的行为是点击
,所以我们挑选用户A 最近的点击记录:
物品 | 物品类目 | 行为发生时间 |
---|---|---|
iphone11 | 电子产品 | 100 min before |
thinkpad | 电子产品 | 200 min before |
台球杆 | 体育用品 | 300 min before |
|
|
|
Kindle | 电子产品 | 500 min before |
羽毛球拍 | 体育用品 | 600 min before |
足球 | 体育用品 | 700 min before |
switch | 电子产品 | 800 min before |
|
|
|
根据过滤条件:行为发生在1920min
之内,电动牙刷 和 玛莎拉蒂 以及后面的所有行为都被过滤掉了。
根据配置,我们定义用户“兴趣” 为物品类目
,“喜欢程度” 定义为点击
行为的行为频次。统计结果如下:
物品类目 | 行为频次 |
---|---|
电子产品 | 4 |
体育用品 | 3 |
step2:找到兴趣下的热门物品
我们已经知道用户A的 “兴趣” 了。下面我们就把这两个类目下最 “热门” 的物品召回出来,“热门” 的标准和 第一步中 “喜欢程度” 的定义一样,都是点击
行为的行为频次
,我们挑选出 电子产品 类目下的所有用户的点击行为:
用户 | 物品 | 物品类目 | 行为发生时间 |
---|---|---|---|
uidA | iphone11 | 电子产品 | 100 min before |
uidB | iphone11 | 电子产品 | 100 min before |
uidC | iphone11 | 电子产品 | 100 min before |
uidA | thinkpad | 电子产品 | 200 min before |
uidB | thinkpad | 电子产品 | 200 min before |
uidA | Kindle | 电子产品 | 500 min before |
|
|
|
|
|
|
|
|
uidB | xbox | 电子产品 | 100 min before |
|
|
|
|
|
|
|
|
|
|
|
|
根据过滤条件:行为发生在1920min
之内
将不符合条件的物品过滤掉,统计结果如下
物品 | 行为频率 |
---|---|
iphone11 | 3 |
thinkpad | 2 |
Kindle | 1 |
xbox | 1 |
这四个物品就是 电子产品 这个类目下召回的物品了。
同理,假如 体育用品 这个类目下的召回物品如下:
物品 | 行为频率 |
---|---|
台球杆 | 5 |
棒球杆 | 4 |
旱冰鞋 | 1 |
羽毛球拍 | 1 |
那么最后对于用户A的召回结果,就是这两个类目下的召回结果的合集。
step3:合并结果
目前平台支持三种合并方式:
基于用户发生历史行为,进行二次召回(按照“行为发生的时间”由近到远进行召回)。内容社区无重定向召回。
将在线请求用户在1920min
之内发生点击
行为的物品,按照“行为发生的时间”由近到远进行召回。
例如用户1、2、3在1920min内的点击行为分别如下(例如用户1,先点击itemC,再点击itemB,再点击itemA):
uid1 【itemA,itemB,itemC……】
uid2【itemA,itemB,itemD……】
uid3【itemD,itemE,itemF……】
在线传入uid1,返回结果:A>B>C>……
基于物品的协同过滤召回。对满足条件的用户按照一定比例随机采样进行计算,物品相似度支持两种计算方式:item-common、swing。swing 是一种改良版的相似度计算模型,与 item-common 对比计算资源消耗更多,内存占用更大,但是效果更优。
step1:取用户近期有行为的物品
在线传入uid1,取用户uid1最近发生点击
行为的的20
个物品uid1【itemA,itemB,itemC】
step2:离线计算 i2i 的关系
1)将满足时间近5天
用户的点击
行为筛选出来:
uid1 【itemA,itemB,itemC……】
uid2【itemA,itemB,itemD……】
uid3【itemD,itemE,itemF……】
2)通过item-common
/swing
计算 i2i 的关系:
(itemA , itemB) = (A,B 共现的次数) / itemA * itemB
(itemA , itemC) = (A,C 共现的次数) / itemA * itemC
假设item-common
/swing
计算 i2i 的结果如下:
itemA(itemB 相似度0.8,itemC 相似度0.7 ,itemD 相似度0.6……itemN 相似度0.5)
itemB(itemC 相似度0.9,itemD 相似度0.8,itemE 相似度0.4……itemN 相似度0.3)
……
itemN(itemB相似度0.7,itemC相似度0.6,itemD相似度0.5……itemN-1相似度0.3)
【其他过滤条件】
step3:以上两个结果进行merge
itemC:【itemE,itemF,itemM】
itemB:【itemA,itemC,itemD】
itemA:【itemB,itemE,itemN】
merge结果如下:E>A>B>F>C>N>M>D
通过用户自建的模型进行召回,支持常用的向量化召回算法。自建模型可参考模型开发流程。模型训练使用用户行为数据,在线预测使用 user 侧特征。
说明
新建的模型召回需要 1 小时生效,生效期间建议不要用于在线服务或AB实验。
基于父物品的行为热度进行统计,并按照热度排序返回召回结果。
将时间近1920min
有点击
行为的物品,且与在线请求父物品维度一致(且满足维度条件设置)的物品,按照行为频率进行排序。假设所选维度为视频类型
,在线请求的父物品视频类型为电影。
例如用户对物品的点击行为如下:【C,C,A,B,D,D,B,C,D,E,D,E,E,B,C,C】。
物品 | 行为 | 行为发生时间 | 物品维度 |
---|---|---|---|
itemA | 点击1次 | 100 min before | 电影 |
itemB | 点击2次 | 200 min before | 电影 |
itemC | 点击5次 | 300 min before | 电影 |
itemD | 点击4次 | 400 min before | 电影 |
|
| 500 min before |
|
其中E与在线请求的父物品维度不一致,不被召回。
召回结果:C>D>B>A
基于父物品下发生的历史行为进行召回(按照“行为发生的时间”由近到远进行召回)。内容社区无父物品重定向召回。
和在线请求的父物品相同,并且在1920min
之内发生点击
行为的物品,按照**“行为发生的时间”由近到远**进行召回。
例如用户当前请求的父物品为 itemP。最近发生过点击行为的item如下:
物品 | 父物品 | 行为发生时间 |
---|---|---|
itemA | itemP | 100 min before |
itemB | itemP | 200 min before |
|
|
|
itemD | itemP | 400 min before |
|
|
|
itemF | itemP | 600 min before |
itemC 和 itemE 的父物品为 itemQ,与当前请求的父物品 itemP 不一样,需要排除掉,剩下的按照时间排序。
返回结果: A>B>D>F
基于父物品的协同过滤召回。对满足条件的用户按照一定比例随机采样进行计算,物品相似度支持两种计算方式:item-common、swing。swing 是一种改良版的相似度计算模型,与 item-common 对比计算资源消耗更多,内存占用更大,但是效果更优。
step1:取在线请求的父物品 pid(即parent_item_id,下同)
有两种方式,一种是直接取父物品 pidA,一种是取父物品 pid 下发生点击行为的20个物品 item_id【itemA,itemB,itemC……】。
step2:离线计算 i2i 的关系
有两种方式计算 i2i 关系:
1)将满足时间近5天
用户的点击
行为筛选出来:
pid1 【itemA,itemB,itemC……】
pid2【itemA,itemB,itemD……】
pid3【itemD,itemE,itemF……】
2)通过item-common
/swing
计算 i2i 的关系:
(itemA , itemB) = (A,B 共现的次数) / itemA * itemB
(itemA , itemC) = (A,C 共现的次数) / itemA * itemC
假设item-common
/swing
计算 i2i 的结果如下:
itemA(itemB 相似度0.8,itemC 相似度0.7,itemD 相似度0.6……itemN 相似度0.5)
itemB(itemC 相似度0.9,itemD 相似度0.8,itemE 相似度0.4……itemN 相似度0.3)
……
itemN(itemB 相似度0.7,itemC 相似度0.6,itemD 相似度0.5……itemN-1 相似度0.3)
【其他过滤条件】
step3:以上两个结果进行merge
使用step1 的【方案一】,即直接取父物品 pidA:在线传入 pidA,将 pidA 作为 itemA,取相似物品列表 itemA(itemB 相似度0.8,itemC 相似度0.7 ,itemD 相似度0.6……itemN 相似度0.5)
结果如下:B>C>D>……>N
使用step1 的【方案二】,即取父物品 pid 下发生点击行为的20个物品 item_id:pid1 【itemA,itemB,itemC……】,取20个 item 的相似 item 进行 merge:
itemA:【itemB,itemE,itemN】
itemB:【itemA,itemC,itemD】
itemC:【itemE,itemF,itemM】
merge 结果如下:B>A>E>N>C>F>D>M
批式召回任务:每日定时计算,当天提交的任务从第二天开始生效。对资源消耗较小,适合对时效性要求不高且时间窗口比较大的召回场景。
流式召回任务:流式任务需要传入行为数据的增量实时数据才能启动。流式任务启动后任务常驻,对资源消耗较多,适合对时效性要求高且时间窗口比较小的召回场景。
不同字段类型对应的运算符号如下:
物品表字段 | 运算符 |
---|---|
string、array<string>、 | 属于(in)、不属于(not in) |
int32、int64 | 等于(=)、不等于(!=)、大于(>)、大于等于(>=)、小于(<)、小于等于(<=)、在区间(between) |
float、double | 大于(>)、小于(<)、在区间(between) |
注意
当选择的维度条件涉及 $##$ 拼接时(如选择物品类目、内容分类、spm 等),按照如下逻辑:
若只想保留二级类目为2的行为数据构建召回,按照下图配置即可。
另外,item_id为null的数据会被过滤掉,不会用于召回任务的计算。
召回规则完成配置发布后就可以使用,可以在在线服务和ab实验中绑定召回使用。一次只能发布一个召回,当存在“发布中”的召回时,不可再发布其他召回。
召回规则下线时关联的在线服务会重启生成一个新的版本,如果召回规则关联了上线中的ab实验则不可下线。
在使用自定义召回/自定义规则模块前,如果还未开通过编译服务,则需要先发起“开启自定义策略”流程。
单击左下角开启自定义策略的【一键开启】按钮,在弹出的确认界面单击【启用】。开通成功后,即可使用自定义召回策略和自定义业务规则,且自定义模型模块也无需再次开通。
在平台内置的召回策略之外,支持“添加召回”,即新增用户自定义的召回结果数据,与平台召回进行融合。
说明
目前支持在私有化环境下使用。
代码文件:进入编辑页面,可看到“添加召回”的代码文件,版本为 c++14。提供默认的示例代码,用户可在此基础上根据业务需求进行代码编辑。可在 readme 文件中查看示例代码的详细说明。
参数文件:params 文件夹下,提供默认的参数文件 params_default.json,同时支持新建参数文件。每个自定义召回的代码文件可以有多份参数文件,不同在线服务使用同一个自定义召回时,可灵活选择使用不同的参数文件。
在完成代码和参数编辑后,正式发布前,可通过测试功能验证代码逻辑的正确性。
在自定义召回代码编辑页,可以直接发布。也可以在召回列表操作栏点击“发布”。
所有“已发布”状态的自定义召回,均可以在在线服务配置召回策略时选择使用。选择使用自定义召回时,可选择对应的参数文件。不同在线服务支持使用同一份自定义召回时,灵活选择不同的参数文件。