GMTC 全球大前端技术大会(北京站)门票 9 折特惠中,点击立减 ¥480 了解详情
写点什么

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

评论

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

技术团队内部管理思考

6:00 am

技术管理

架构实战营模块二命题作业

Geek_993581

架构实战营

Kafka源码阅读笔记(1)

InfoQ_Springup

kafka

视图

在即

四月日更

翻译:《实用的Python编程》09_01_Packages

codists

Python

合约跟单交易系统开发量化策略

薇電13242772558

数字货币

跨省通办,海淀在全国率先推出“区块链+”服务新模式

CECBC区块链专委会

美国指责俄罗斯SVR发动网络攻击并对其进行制裁 俄方表示必将回击

Machine Gun

网络安全 信息安全 美国

微擎的日志文件保存在哪里?如何查看。

微擎应用商城

从能耗大户“变身”智能绿色办公,只需一步到位!

IoT云工坊

物联网 API sdk 办公空间 智能转型

IPFS矿机可以挖多少年?IPFS矿机一年大约挖多少FIL?

投资矿机v:IPFS1234

IPFS矿机一年挖多少FIL IPFS矿机可以挖多少年

用APICloud开发仿微信聊天App制作经验分享

APICloud

小程序云开发 前端开发 web开发 APP开发 APICloud

「前端初学者、硬件爱好者、编程自学者」微信小程序开发很简单!

智能物联实验室

前端 前端开发 前端进阶 硬件设计 硬件研发

跨链技术如何破解区块链的可扩展性难题?

CECBC区块链专委会

区块链

streamlit:算法工程师快速编写demo的利器

行者AI

算法

浪潮云说丨打造网络安全“铜墙铁壁”

浪潮云

云计算

架构实战业命题二学习总结

Geek_993581

架构实战营

如何避免团队里出现搭便车现象

石云升

团队建设 28天写作 职场经验 管理经验 4月日更

浅谈BSS3.0产品“守成”之策上 • 架构提升篇

鲸品堂

运维 性能 架构·

重磅:Filecoin官方博客发布文章,星际联盟投资13亿美元建设中国最大的Filecoin分布式存储产业园

投资矿机v:IPFS1234

马丁量化策略系统搭建,量化交易软件开发

13823153121

牛客网官推!3天访问量直接破20W的Java高频面试汇总笔记太香了!

程序员小毕

Java 程序员 架构 面试 分布式

腾讯司晓:区块链如何在数字世界中重塑所有权?

CECBC区块链专委会

让孩子爱上阅读(一)

箭上有毒

读书笔记 4月日更

【得物技术】得物前端性能监控实践

得物技术

前端 体验 监控 用户体验 实践

混沌工程缓存实战系列一Redis

心远

缓存 混沌工程

微服务中台技术解析之sso登录实践

小江

Java 架构设计 后端开发 SSO

数字货币自动交易机器人APP开发|数字货币自动交易机器人软件系统开发

开發I852946OIIO

系统开发

【详解文件IO系列】讲讲 MQ 消息中间件 (Kafka,RocketMQ等)与 MMAP、PageCache 的故事

Linux服务器开发

网络编程 Linux服务器开发 底层实现原理 网络io C++后端开发

lakin跟投社区APP开发|lakin跟投社区软件系统开发

开發I852946OIIO

系统开发

人生向前

shun123456789

DIY 的 Kubernetes 集群的稳定性保障实践

DIY 的 Kubernetes 集群的稳定性保障实践

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