Press "Enter" to skip to content

李晓亮:腾讯搜索词推荐算法探索实践

 

 

分享嘉宾:李晓亮 腾讯 专家算法工程师

 

编辑整理:张宸宁 Boss直聘

 

出品平台:DataFunTalk

 

导读: 今天很高兴在这里为大家介绍我们团队在搜索词推荐上面的思考,希望能够给大家提供一些启发。主要内容包括以下几大方面:

 

搜索词推荐场景介绍

 

推荐物品

 

推荐算法设计

 

未来展望

 

01

 

搜索词推荐场景介绍

 

下图是我们负责的QQ浏览器中几个主要的搜索词推荐场景。

 

 

左边第一个图是个性化词推荐,基于用户的兴趣偏好推荐感兴趣的搜索词。

 

第二个是query自动补全场景,用户点击搜索框开始输入后,会展示自动补全的相关搜索词。

 

第三、第四个是基于用户当前浏览的短视频或者正在阅读的文章,推荐和短视频、文章相关的搜索词。

 

最后一个是根据用户输入的搜索词,在搜索结果页中,展示与当前输入搜索词相关的其他搜索词。

 

搜索词推荐与传统新闻推荐、短视频推荐,有哪些差异呢?传统新闻推荐是基于用户兴趣偏好推荐感兴趣的文章或者短视频,用户与最终消费物品只有一层连接,但搜索词推荐至少包含三层连接。

 

第一层是context和推荐query的连接 :context包括用户兴趣偏好,输入的搜索词,或者用户当前在看的内容。需要建立用户上下文以及推荐query之间的一个匹配关系。该匹配关系有多种目标,但最核心的目标是query点击率。

 

第二层是query和搜索结果的连接 :就是要做好query和搜索结果的匹配,即搜索结果的满足度。

 

第三层是搜索结果页与最终消费内容的连接 :用户在结果页上浏览内容,找到可能感兴趣的文章,最终点击某篇文章进行消费,此时才到了用户最终的内容呈现和消费的环节。

 

 

因此区别于传统推荐只考虑一层关系,搜索词场景需要考虑以上三层的匹配关系,增加了技术难度。至少会有以下三个挑战:

 

推荐可评估性

 

传统的推荐是千人千面的,很难有一个专家知识去评估给用户推荐的物品是好是坏,是否符合用户兴趣;并且在推荐时既要保持关联性,又要让用户有一定的惊喜感。然而搜索是有比较强的专家知识的,能够评估搜索结果是否满足用户输入Query。在搜索结果的丰富程度以及内容的时效性、权威性上,我们有一整套评估机制。所以搜索词推荐需要权衡传统推荐的千人千面不可评估,又要融入搜索的可评估性。

 

内容生态

 

传统新闻或者短视频推荐的物品是内容,这些内容有很强的作者生态,包含作者运营,粉丝增长诉求以及规则约束等,去保证系统尽可能持续产出更好更优质的内容。但是在搜索词推荐中,由于推荐物品——Query是数十亿UGC短文本,没有良好的生态保障质量,需要我们做更多的Query理解工作。

 

物品属性易变

 

对于信息流推荐来讲,作者生产出文章后,它的属性是基本不变的,只有部分后验的特征会更新,比如文章的点击率、转发数、评论数、点赞数;其他如title、创建时间以及文本的内容是不变的。但在搜索词推荐中,搜索结果是否满足,它是一个持续变化的过程,而且在不同的时间点,推荐质量可能会差别很大,用户的关注度差别也很大。所以要做好搜索词推荐,就要考虑属性易变的问题。

 

02

 

搜索词推荐场景介绍

 

推荐系统本质是解决内容过载情况下,用户对有价值内容的消费问题。推荐物品是一个核心要素。

 

 

对于推荐词场景来说,推荐物品主要包含两部分。一个是搜索词,涉及到Query意图、核心词抽取、语义完整性等NLP技术,或者Query相关的信息流消费pv、索引网页的数量、信息流的分类、不同时间窗口的趋势,还有安全相关的质量控制。另一个是搜索结果页的呈现,包括文章样式,搜索结果基础相关性、语义相关性、权威性、时效性,文章的意图、url点击分布。

 

1. 词(query)库系统架构

 

 

Query词库包括以下几类词:

 

第一类也是最主要的是 主动搜索词 ,通常是亿级别甚至数十亿级别。由于每个人对同一需求的表述不同,导致长尾效应非常明显。用户在搜索时通常不会输入一个完整的句子,而是输入几个关键字,有的会用空格间隔。因此主动搜索词的质量相对较差,直接给用户推荐,会带来很多的体验问题。

 

第二类是 生成式query ,有模板式和抽取式两种。模板式就是基于模板做元素替换,一个原始的query“c罗十大精彩进球”,通过核心元素以及非核心元素的抽取,做同位词替换,扩展出“梅西十大精彩进球”或者“c罗十大绝杀”。抽取式就是从信息流的文章title里面抽取可以作为搜索词的片段。抽取式主要通过序列标注或者基于标点符号的片段切分,例如下面的例子,我们从“NBA历史三分之王!库里距雷阿伦纪录仅差1记三分”,分别抽取了“库里仅差一记三分”、“NBA历史三分之王”这两个Query。

 

第三类是 知识图谱生成Query ,结合腾讯内部的知识图谱体系去构造推荐词,比如“周华健代表作品”、“曹云金相声全集”等。

 

第四类是 热搜榜人工运营的搜索词 。

 

词库系统会有不同的机器学习算子,做词质量的判断,接入安全系统、人审复审机制。

 

2. 搜索结果页满足度

 

 

我们会从四个维度评估一个query的搜索结果满足度。

 

第一个是 相关性 ,搜索结果是不是满足了用户的需求,是不是同一件事情,有没有抓住主需。

 

第二个是 丰富性 ,搜索结果不能只呈现单一的内容载体,是不是有图文、短视频、小程序等比较丰富的形态。或者在用户搜索连续剧时,给出全集的播放地址,而不只呈现单集内容。

 

第三个是 时效性 ,通常股价、天气、彩票等类别的需求要给用户呈现最新的搜索结果。

 

最后是 内容质量 ,包括文本质量、图片质量、视频质量这些多媒体属性,也是搜索结果满足度的一个重要评估维度。

 

03

 

推荐算法设计

 

 

上图是推荐算法的技术栈,与传统的推荐差别不大。底层是query库,往上是索引层、召回层,接下来是粗排层、精排层、混排层,以及顶层的业务接入。

 

在此主要结合我们场景的特点,介绍在粗排层、精排层的优化中遇到的问题和解决方案。

 

1. 【个性化词推荐场景】粗排-数据稀疏性

 

 

粗排模型的主要问题是数据稀疏性。以个性化词推荐场景举例,左二是粗排模型,它是一个经典双塔的网络结构,基于我们公司内部的粗排中台实现。红色框是用户塔,通过对用户离散特征的处理,得到一个embedding向量;蓝色框是query塔,通过对离散值跟连续值特征的处理,得到一个Query embedding;此外还包括个别交叉类特征。离线Query建库时,Query embedding计算后通过query id hash到不同机器,在本地进行缓存。在线预估时,用户塔每个请求只计算一次,得到的user embedding和召回的万级别的item id一起分发到下游各个节点。下游的预估节点,通过收到的user embedding、本地查询的query embedding以及用户交叉的特征,实时计算得到最终的预估点击率。

 

在这个粗排框架下,我们遇到最大的问题是数据的稀疏性。

 

 

由 于我们产品样式以及搜索需求分布的特点,导致我们在个性化词推荐中,收集不 到类似信息流场景那幺丰富的反馈行为信息。

 

粗排模型如果按照传统的做法直接采用线上的真实曝光、点击样本去做训练,会存在很严重的样本偏差问题。我们粗排的候选集合是一万条,排序后筛选头部800条给精排模型,精排取头部40条给前端,前端逐个轮播40条Query。通过数据分析我们发现精排的pctr和粗排的pctr的偏差非常大。因此实践中,我们的模型会计算精排模型的得分与粗排模型的得分偏差,通过teacher-student的框架让粗排模型学得更好。但这样只解决了对精排的800条候选中被粗排模型高估的部分物品,不能解决被粗排模型低估的问题。于是我们线上从候选集剩余的9000多条里随机挑选了50条,放到精排模型中一起去预估,这样做能够让精排模型对被粗排低估的那一部分物品进行校正。

 

 

由于物品库规模很大,我们借鉴了业界在embedding table的压缩算法来节省成本。将我们1000万的embedding空间分成两个500万,一个query用两个500万的哈希值去表示(可能会带来一定的哈希冲突)。

 

同时为了更好的做交叉特征学习,我们在塔内部引入了fm或者pnn结构;user塔与item塔之间的交叉也做了一些尝试,比如每个user的embedding增加一个id embedding,这个id embedding用来学习item侧的最顶层学到的语义向量。

 

2. 【文章相关搜索】精排-多任务学习

 

 

Query推荐场景的多任务学习方案设计。图中abcde抽象了用户在浏览信息过程中的可能交互,这些交互抽象成几个任务。第1个任务是词的点击率预估,第2、3个任务是预估这个词点击后在结果页的有点率、消费数。第4个任务刻画的是相同的Query在结果页总的消费数。第5个任务是文章与query的相关性约束。

 

CTR目标和结果页有点率目标存在依赖关系,适合ESMM建模,同时ESMM也能够缓解直接预估有点率的样本偏差问题。

 

结果页有点率、不同场景的消费数、点击率、相关性等目标存在一定的相关性,适合MMoE建模。

 

 

精排模型是一个比较经典的多塔结构。底层是文章、用户、query以及交叉特征。左右两边的绿色门网络对上层的目标进行筛选,最顶层是CTCVR目标。

 

 

在这个框架下我们借鉴业界思路,类似PLE,对专家网络分成多层学习;对于不同的用户群体,做目标的分离跟组合,比如新老用户的不同网络拆分;不同目标下的embedding是要独立的还是共享的,以及不同目标的参数要如何调整等。

 

3. 【query自动补全】精排-TopN满足

 

 

query自动补全场景,例如用户输入搜索词“梅西”时,会展示出10个搜索建议词。 假设用户点击第4个“梅西现在在哪个球队”,我们会构造几个逆序pair对样本。 query自动补全作为用户搜索的主路径,主要的目标是帮助用户提升输入效率。 相比其他词推荐场景,我们会更关注理想体验以及top n的满足率。 在基于pointwise预估的基础上加了pairwise-loss,针对这些逆序的pair对进行loss的学习,提升top的满足率。

 

 

简单的逆序没有区分<1,4>、<2,4>的pair对的差异性,所以我们引入了lambda-loss,进而考虑具体逆序位置之间的差别到底有多大,需要给予什幺样的权重去做打压。

 

我们有3个评估指标:

 

分位置的top n的点击占比

 

分位置的top n的点击率

 

在不同位置上的ndcg

 

 

我们还基于人工标注数据的LTR模型来提升搜索词的推荐体验。比如query词质量初筛的LTR模型,基于用户当前的搜索词以及推荐的候选词,去做理想体验标注,0到4分共5档,4分是可以正常满足用户需求。搜索结果页也有四个维度的标注:相关性、丰富度、时效性、内容质量,并用LTR模型去学习结果页top n的文档打分。在自动补全场景里面,候选词会过词质量和结果页满足度的LTR模型,推荐词在满足基础的体验时,才进入到精排队列中。

 

04

 

未来展望

 

1. Multi-Task + Session/Sequence

 

 

我们当前做的事情更多是在针对业务特点优化搜索词推荐算法。但未来需要结合multi-task或者multi-view,做很多场景融合,去满足用户在不同场景下的诉求。QQ浏览器app是一个综合的工具平台,集成新闻、小说、影视、音乐等消费行为,如何通过类似transformer的结构学习用户的多种不同的消费行为序列,也是我们在持续探索的方向。

 

2. 推荐词用户满意度

 

 

我们的场景对搜索结果的满意度有比较强的依赖,搜索词本身是一个桥梁,是用户 需求和最终消费内容之间的关联。 搜索结果也会不断引入更丰富的内容来提升搜索体验,在这个过程中我们需要引入更实时、更全面的搜索信号。 另外需要持续 提升对query的理解能力,从数十亿的query中筛选出优质词。

 

05

 

精彩问答

 

Q1:id的embedding它是通过预训练的方式还是端到端的方式来得到的?

 

A1:我们当前各个场景的id embedding是通过端到端的学习得到的。同时也在尝试做一个基于所有词推荐、主动搜索行为的预训练模型。

 

Q2:搜索的时效性,一般是以什幺时间单位级别来更新,还有网络其实每个时段都产生了很大的信息,那我们如何在确保信息及时性的同时,能够尽可能保障好搜索推送结果的质量,规避信息的虚假还有不相关这一块的问题。

 

A2:时效性是我们一直在持续迭代的技术方向。搜索大团队有一个时效性组,也有内容质量相关的技术、运营团队,专门负责解决时效性内容更新和内容质量相关问题,包括query突发检测、突发信号的识别,基于不同的时间窗口去检测出爆发点。我们小组主要负责基于已有的时效性内容、Query做好推荐算法,建立各种各样的机制,保障我们的数据能够实时回流,比如机器算子做并行化,与其他团队合作探索最优化的工程解决方案,将相关的特征引入到排序模型中,设计对应的排序目标,提升时效性推荐体验。

 

Q3:候选词query是生成多种方式,在query库里边它的配比是怎幺来处理的?因为title生成的量它预期会非常高,那幺量级大会不会导致最终推荐的query多数来源于这个路径。

 

A3:词库中占比最高的是主动搜索query,它的量级是数亿级别的。生成词没有那幺多,会有标题党的问题,并且词的完整性需要做严格的模型筛选。生成的query,需要保证主谓宾的结构或语义的完整性。

 

Be First to Comment

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注