短视频推荐精排记录

精排记录

Posted by BY on May 21, 2017

特征

User

  1. 基础信息(openId、是否新用户、是否低活用户
  2. 基础画像(60天长期兴趣tag2,ai画像tag,60天长期兴趣tag3)
  3. 短期session(完播up主列表,秒滑up主列表,播放序列,点赞up主序列,点赞item序列, 打开up主列表,分端session,评论序列,左滑进入up列表)

Content

  1. 是否当日首刷,场景id,召回通道id,导流id

Item

  1. 基础信息(视频时长,itemid,清晰度,tag1,颜值标签,tag2)
  2. 统计特征(最近一小时下发量,最近200条播放率,最近200条有效播放,最近7天的下发量)

up主

  1. 基础特征(upid,ocr字幕,关键词)
  2. 统计特征(最近30天完播率,最近30天长播,app按照列表)

特征评估

user_nxd、nxd、覆盖率、独立hash数

特征一致性

样本拼接:

  1. 数据源:下发日志(包含user&场景特征) join 预估服务日志(item ID对应的特征版本号) join 行为埋点 user&场景特征由上有统一获取、下发到各个预估服务,这样user特征只用落一份,并且可以避免多个预估服务取到的user特征不一致、导致的特征一致性问题。
  2. 离线在线共用特征抽取(简称FE,FE版本需要一致;FE的算子只加不改的原则)

不一致的一些典型case

  1. 并发请求多个模型,同一个item 不同的模型是不同FS上取的特征,不同FS item特征版本不一致。这时候一个item对应两个版本。
  2. 离线拼接的时候item特征版本过期
  3. FE算子被人修改

模型

样本

tips

o User 基础画像 行为统计 短期Session,端内、端外;播放、互动 原始数据 item list:曝光、播放、点赞等list分开存储,行为更多 tag list:归集到tag维度统计播放时长、曝光点击率 特征设计 正向反馈、负向反馈拆分为不同特征 统一建模:每个item的属性、行为(播放率等)拆分为两个embedding 长期session Hard search, 同tag的、以及每个tag下取n个item。 因为短期session 受到下发内容分布的影响很大,发什么就有什么,不能全面表达用户兴趣。 用户理解: 兴趣计算 端内兴趣、多场景兴趣、长期兴趣 topN兴趣、兴趣ID join 兴趣排序位次、兴趣ID join 兴趣权重占比 交叉:target item的tag在用户长期兴趣中排第几 负反馈:得分低于自身均值且低于大盘均值的兴趣 兴趣探索 Context 场景、刷次 导流特征:导流ID、导流ID属性、导流交叉tag2/up_id/item_id item ID和属性:tag、kw、来源、地域、上架时间、视频时长 基本统计特征 播放率、有效播放、完播、流失率(join log(show_cnt) 、 duration )、点赞评论等互动 多周期统计特征 分人群统计特征 分性别、年龄、地域 统计项:秒滑、播放率、播放时长 使用时:视频时长分桶、与人群统计、统计项 交叉 特征处理 降低噪音:比如一些率要做置信处理(贝叶斯平均或者wilson区间平滑),或者join 分母的分桶 降低学习难度:item的平均播放率要 join 视频时长分桶 (强的bias要交叉) 信息全面,不丢失、折损重要信息 特征抽取(FE)配置: 特征配置 及其依赖的特征抽取算子库,离线在线共用并且保证一致性。 hash方式为:hash(slot + feat_value), 有的slot可以共享embedding以提高泛化能力、降低模型大小,比如itemID可以同时出现在click_history 和 like_history中,可以共享embedding。 multihot特征 根据需要选择 sum_pooling / avg_pooling 或者自定义的 pooling方式。 相关指标 离线评估 统计: 覆盖率cover_rate 独立特征数 平均值个数(每个样本,multihot) 评估:特征重要度(shuffle单列特征后的auc diff) 在线指标: FE服务监控,各个特征的fea_sign命中率、成功率、覆盖率 特征一致性 样本拼接: 数据源:下发日志(包含user&场景特征) join 预估服务日志(item ID对应的特征版本号) join 行为埋点 user&场景特征由上有统一获取、下发到各个预估服务,这样user特征只用落一份,并且可以避免多个预估服务取到的user特征不一致、导致的特征一致性问题。 离线在线共用特征抽取(简称FE,FE版本需要一致;FE的算子只加不改的原则) 不一致的一些典型case 并发请求多个模型,同一个item 不同的模型是不同FS上取的特征,不同FS item特征版本不一致。这时候一个item对应两个版本。 离线拼接的时候item特征版本过期 FE算子被人修改 精排模型 指标: Nxd, auc; Gnxd, gauc 拆分各个分桶(item属性、user属性)看pcoc和auc 精度问题 各个击破。 最简单的是某个分桶高估或者低估(看分桶pcoc),一般把该属性特征加进去就会好。强bias一定要引入特征,比如是否为导流/首条、场景、新老用户 看哪些维度比较难估准(看分桶auc),比如新用户难估准,那么给新用户找外部特征、拆分模型,等。 auc高但是gauc低:bias强,看下面的debias方式 多目标是否达到帕累托最优 互动目标很稀疏,MMoE网络所有专家都受到主目标(播放完成度)影响很大,关注expert_net权重分布。PLE对于稀疏目标(互动)有收益。主目标无收益甚至微负向。期望通过互动带来留存收益。 debias 现象: 点赞:有视频时长的bias(视频时长越长越容易有点赞),有user的bias。 playrate:有视频时长的bias、也有user的bias。 auc比较高、gauc(按视频时长分桶、按user分桶)都很低:user和视频时长的bias强,user bias比视频时长bias更强。 特征层面处理: label层面处理: label上消除bias: 直接优化gAUC 绝对值信息需要保留: 比如广告 需要估的准:pointwise 比如有效播放、播放率。 rerank中可能用这些打分做门控,那么其实选出来的是高消用户,对高消用户做强插,这时候是需要绝对值信息的。如果不需要这个高低消用户的bias,每个请求都需要同等比例的插入,则用位次。 搜索,是要针对当前query 选出最好的结果,那么可以从label层面消除bias,pairwise 没用的bias,比如场景、user,做pairwise,桶内比较。 拆分label: 自动上滑与非自动上滑模式需要拆分开。 模型层面处理: 如果分发模式也不一样,强bias特征做门控,比如是否首刷、是否新用户。 拆分为两个模型:新老用户模型。 模型训练 优化器&模型大小控制: dense部分使用adam sparse部分使用FTRL,通过FTRL参数lambda1 lambda2控制稀疏化程度。另外添加频次截断(对每个feat_sign在负样本中出现的次数、正样本中出现的次数进行统计,即show/click频次,作为过滤依据)以及unseen_days清除过期特征。 热启动训练: 如果只是增加了模型参数(比如增加特征或者增加一个模块),那么老的参数可以从已有模型加载。 模型更新流程: 小时级训练&推送,需关注以下各个阶段的时效: 原始样本(user action 与 snapshot拼接任务的输出) 模型样本(label计算 & FE 抽取后的输出) 模型训练 模型配送(dense配送到预估服务本地,sparse配送到online PS) 天级校准: 为保证时效性,需要做到小时级训练,但是一些用户行为或者埋点存在滞后,比如播放时长很长的适配、或者关注,滞后行为要么在小时级训练中予以纠正,最简单的办法是天级别模型校准。 粗排 多目标,学后验&精排序(融合公式rank),提升漏斗一致性(时长分布一致性提高)

使用粗级联样本替代曝光样本,目标是学精排序。