浅谈 UC 国际信息流推荐

列表页推荐

这是印度语版的推荐列表页,左边跟常见 feed 推荐的产品形态是非常类似的,有不同的异构的卡片:

  • 新闻聚合页,点开以后就是一个聚合页。
  • 视频,点开是一个沉浸式播放的聚合页。
  • 普通的图文,点开是一个落地页、详情页。
  • Memes,印度市场特有的内容 Memes。这种内容主要是一张图片(或者动图),这种内容比较特殊,可以直接在列表页消费,直接看了就曝光、阅读完成,就结束了,如果点开的话就是 Memes 的沉浸式页面。

总结起来,内容消费的路径有:

  • 一种是,列表页里直接消费的内容,如 Memes。
  • 一种是,落地页中消费的内容。
  • 还有就是通过聚合页再次跳到落地页消费的内容。

1. 目标确定

接下来讲下如何确定目标。对于推荐系统来说,最核心的就是如何确定目标,如果目标定不好,可能就会出现标题党的问题。在解释最终求解目标之前,先看下用户的行为路径:

图中圆圈表示的是用户的一种行为,方框表示用户发生这种行为的心里活动。

比如用户看到一篇内容之后,如果这个内容有吸引用户的点,也就是产生了吸引,会发生一次点击,在点击看到详情页的内容之后,如果对这个内容比较满意,用户可能会形成一次有效的阅读,有一次有效阅读之后,如果用户还是觉得这个内容非常好、非常满意,用户可能会有一些互动的行为,比如分享、点赞、评论等。

当然还有种可能:用户在列表页里看到一篇内容之后,用户不是很感兴趣,直接就跳走了或者快速的划过;再就是用户点开了一篇类似标题党的内容,但是内容完全不是用户想要的,这其实是一个强烈的不满意会,一个无效的阅读,然后用户就离开了。如果把所有不满意的行为看作是一种负向的满意度,我们建模的核心目标应该是一个用户累计的所有满意的行为,使满意行为累积量最大化。

这里所有标黄色的路径其实是一个偏正向的路径,标灰色的路径是个偏负向的路径,我们的目标是使正向的路径逐渐的累积,对用户逐渐的产生一个比较正向的影响。

所以求解目标是:

左边为吸引的概率,右边是满意的概率,然后所有看过的内容满意度最大化。

如何衡量有效的阅读?一个传统的方法是用阅读时长来衡量是不是一个满意的阅读,但实际上用户满意的心理和时长不是一个完全线性的关系。比如有一类行为是用户阅读了 5s 或者 10s 以下快速离开(quickback),这种无效阅读,无论是 3s、5s 还是 7s、8s,效果都是用户对内容完全不满意,应该快速离开的。再有,当用户读一篇长文时,大家可能都有这样的体会,长文阅读可能会有一个瓶颈,就是大家花了很长时间在一篇文章阅读上,但是读到一定程度的时候,可能再也读不下去了,能花的时间就存在一个极限了,所以最后满意度和时长关系是类似 sigmoid 的函数关系。因此,我们在对满意度建模时,其实是把回归问题变成了一个分类/二分类/多分类的问题。这里可能会涉及怎么做时长回归的问题(由于不同类型、分类、主题的内容以及内容信息量的不同,其阅读时长总量是会变化的),一种简单的方法是用这些维度,对内容进行统计分析求出分布,然后用分位数来截断,通过人工来排出几个档,也可以做一些人工标注来拟合这样的分类。结合UC国际信息流,稍微特殊的一点是列表页有 Memes 这样的图片内容。这种内容由于强调的是互动性(一般承载的是一些高分享类的内容,如早安、节日问候、搞笑的图片等),在产品设计时,会把这种交互行为做前置,在列表页就放出来,这样就可能存在误点,用户还没看到或看完这篇内容,就产生了点击,需要做一些过滤。

负向满意度,分为:

  • 显式:很多产品在设计时,都会在内容边上有个XX,也就是 dislike,比较直白的显示了负向满意度。
  • 隐式:无点的曝光、无效阅读 ( quickback )、快刷等动作。

说完了总的求解目标之后,这里列举的吸引和满意,满意还可以拆解成更多的步骤,比如刚才说的有效阅读和互动行为,可以再做分解,但无论如何都是一个多目标的任务,针对这样的多目标任务该如何建模呢?

2. 多目标点估计

这里列举了一些方法,都是阿里巴巴集团内部在各个业务线上的一些沉淀:

① ESMM

这是阿里妈妈团队在解决多目标问题的一种解决方案。ESMM 可以解决我们在对多目标问题进行求解时,比如左边是转化率的目标,右边点击率目标,往往是独立进行求解的。使用样本时,该如何表达上文说到的转移概率?常规做法用到的样本,如转化率使用的样本是所有的有点样本,由于在训练时,使用的样本是部分样本,在预测目标时,使用的是全样本,导致样本分布会存在一定的偏差。ESMM 是把样本空间放到全空间,在定义目标,计算 loss 时,计算的都是全样本空间的 loss,一个是点击率,再有一个是把 CVR 作为一个中间节点,最后求解的 loss 目标是 CTR * CVR,然后底层网络参数共享。

② DBMTL

DBMTL 模型是淘宝推荐团队对 ESMM 模型进行的改进。主要的改进点:左边这部分就相当于 ESMM 那张图横过来了,是共享参数层;specific layer 是走的不同目标的分支;最重要的是右边 bayesian layer,表达了概率图中目标之间的贝叶斯转移概率的因果关系。如果转移概率之间的关系,受其他的一些 feature 和因素的影响,也可以把那些 feature 加到网络中一起训练,所以 DBMTL 建模的时候还建模了几个目标之间的因果关系。

③ MMoE

MMoE 类似一个专家系统,有多个子网络,每个子网络使用的特征和网络结构可以有差异,在最终确定多目标的时候进行票选,通过 gate 来赋予不同的权重来做票选。

最后,我们的业务在不同场景上都取得了比较正向的收益,如视频频道和 Push 场景。

多目标这儿写了一个点估计,因为主要用在精排的场景,在做每次的预估时,考虑的都还只是某一条内容的满意度效果。

3. 混排

但是在列表页场景,我们要求解的是一个组合最优的效果,也就是说对上面的问题需要做进一步的扩展。在考虑点击率时,还要考虑上下文,我上下文的信息。

然后我们的求解目标也做了一个转换:

U 转到 page,做了一个独立假设,认为页与页之间是没有关联关系的,但这个假设不一定成立,只是为了把问题简化一下。这样我们的问题就变成了在组合列表页的情况下,如何达到组合最优。比如有 N 条精排的候选集输出,对这 N 条结果输出 M 个槽位的排列,也就是求解排列的最优解。所以搜索空间相当于是 N 的 M 次方,一个非常大的搜索空间,在实际业务中是没法落地的,因为计算复杂度太高了。

所以淘搜这有一个简化版的方法:类似于贪心的一种算法,在每一轮只确定当前这条最优的结果,然后考虑上文,不考虑下文。举个例子,比如现在是第三轮迭代,已经确定了前三个位置的最优组合,现在是求解第四个位置应该选哪一条,预测第四条那个位置最优的一个选项。另外在做贪心搜索时,搜索空间非常受限,受选择顺序的限制。那么 beam search 有一个参数,就是宽度,每次可以把候选集保留 top3,也就是最优组合的 top3 作为候选,再进行下一次的探索,有一定的探索回溯的能力,这样 beamsize 探索的最优空间的大小,可以用来 balance 性能和效果。

还有一点是对上文的建模,怎么表达上文的排列信息,也就是上文内容之间的位置相对关系的信息。这里有一个比较巧妙的方法:用 RNN 的网络结构来表达他们之间的相互关系,然后在计算的过程中(因为是一个贪婪式的计算,每一轮只计算一步),只计算 RNN 的一个 STEP 可以了,所以在时间复杂度上也是可以接受的,这样存储一个 RNN 中间的隐变量就可以了,这就是混排的做法。

内容冷启

内容冷启问题,有朋友问,如果一个推荐系统完全不做内容理解,是不是也是可行的?这里从其中一个角度说下。

左图是我们现在只用 ID 作为 feature,也就是说核心 feature 是内容的 ID,相当于没有内容理解,这是一个新内容收敛的效果,下边横轴是下发的 PV,可以看到点击率的收敛,要基本上要到千次左右的下发才能达到一个接近收敛的程度,而且起步阶段和后面其实 gap 还是非常大的,用 ID 做推荐就会遇到这样冷启的问题,特别是我们的业务场景又涉及到小语种。因此,对于场景,无论是 item 还是流量都做了很多的细分,所以冷启的问题会尤其的严重一些。

解法其实还是内容理解,我们把 ID 的特征映射到文本域。这里有一个 YouTube 15年做的一个工作,怎么去掉时间的 bias,就是 Example age,其含义是在采用这条样本时,这个时间点距离这条内容发布的时间点之间的 time diff 时间差是什么样的。加上 bias 的 feature 之后,对时间敏感的内容在下发时就会考虑到下发时间差,相当于提高了时效性。

我们在召回侧 DM match,把 ID 特征加上文本特征之后,冷启(1000条以下的曝光)内容 AUC 有了不错的提升。

另外,在多语言的体系下,如果能把文本域的表征对齐投影到同一个空间,对冷启应该能起到更好的效果。

总结

简单总结下,结合大家常见的一些问题,本次分享主要介绍了排序中如何确定目标,如何做多目标的点估计以及混排的组合优化,还简单介绍了内容冷启的一些解决思路,主要是特征泛化和语义对齐。本次分享就到这里,谢谢大家。

作者介绍

杰雄,阿里高级算法专家

本文来自 DataFun 社区

原文链接

https://mp.weixin.qq.com/s?__biz=MzU1NTMyOTI4Mw==&mid=2247493952&idx=1&sn=f32e43f0e834d12649a3a6272b85ede0&chksm=fbd75b2ccca0d23a224032d999dd52ca3fa53529abf78c2cf3d4f5e9d52ef3a691bcf76bbdd1&scene=27#wechat_redirect

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/tHwBxFjNrwEFjosocXVl

扫码关注云+社区

领取腾讯云代金券