写点什么

浅谈 UC 国际信息流推荐

2019 年 10 月 03 日

浅谈 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


2019 年 10 月 03 日 08:001643

评论

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

form-data和x-www-form-urlencoded

hasWhere

DeFi从入门到精通

hasWhere

沟通的方法:反向叙述

石云升

读书笔记 沟通 6月日更

区块链场景化应用大有可为

CECBC区块链专委会

一个jvm线程占用多少操作系统内存

hasWhere

华为大佬怒肝1个月源码,贡献出这份Spring Framework使用技巧

java专业爱好者

Java spring Spring Framework

相比买买买,我们更想在618聊一聊云厂商的能力象限价值几何

脑极体

5分钟速读之Rust权威指南(二十三)Cargo

码生笔谈

rust

Tomcat架构的认知

邱学喆

tomcat @WebServlet @WebFilter Manager

这3份在Git上转载超万次的算法文档,让字节很头疼:这该怎么面试啊

互联网架构师小马

Java 字节跳动 数据结构 面试 算法

算法第零期开营仪式总结

IT蜗壳-Tango

6 月日更

django-task1 笔记之python基础

橙橙橙橙汁丶

django #python

MySQL基础之十四:事务

打工人!

MySQL 6 月日更

科普 DeFi 中的闪电贷

hasWhere

Kubernetes手记(13)- 用户认证系统

雪雷

k8s 六月日更

戏说前端 JavaScript 之『防抖节流』基础知识

编程三昧

JavaScript 前端 防抖节流 函数节流 函数防抖

源码级别理解 Redis 持久化

蘑菇睡不着

Java redis Redis 协议

Zookeeper在线迁移

阿骆麦迪

zookeeper 分布式 中间件 6月日更

【21-9】文件和文件夹

耳东

PowerShell 6月日更

从金融街往事到全场景智慧金融未来

脑极体

期权的初步认识

Qien Z.

期权 6月日更

servlet工作原理之tomcat篇

hasWhere

Java中的关键字final

架构精进之路

Java 6 月日更

数据库索引为什么使用B+树

hasWhere

Java中23种设计模式:五大创建型模式的详细解析

攻城狮Chova

设计模式 创建型 6 月日更

内网渗透测试:初探远程桌面的安全问题

代码熬夜敲

Linux 运维 网络安全 信息安全 渗透测试

《原则》(十六)

Changing Lin

6月日更

内推学弟进了腾讯,看看他的标杆简历!

程序员鱼皮

Java 后端 简历 校招 秋招

一个SpringBoot问题就被面试官吊打?不存在的,我有手写版pdf秘籍逆袭!

不秃顶的Java程序员

Java 程序员 架构 微服务 Spring Boot

全国首个“区块链+数字人民币”应用场景在雄安新区落地

CECBC区块链专委会

数字化转型须遵循“战略五原则”和“3-1-1战术”

李洋

数字化转型 信创 战略思考 企业数字化 战略技术

浅谈 UC 国际信息流推荐-InfoQ