分享嘉宾：李晓亮 腾讯 专家算法工程师
编辑整理：张宸宁 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，需要保证主谓宾的结构或语义的完整性。

分享嘉宾：