搜索场景下的智能推荐演变之路

摘要：传统的推荐手段主要还是深度挖掘用户行为和内容本身相似性的价值，包括但不限于协同过滤，内容表征 + 向量召回，以及各式各样的点击率预估模型，然后这样的推荐行为缺乏内在的逻辑性和可解释性，有一种知其然，不知所以然的体感。本文中，阿里巴巴高级算法专家 王悦 就为大家分享了搜索场景下的智能推荐演变之路。

以下内容根据演讲视频以及 PPT 整理而成。

点击查看阿里巴巴 AI 智能专场直播

演讲嘉宾简介：王跃（跃神），阿里巴巴高级算法专家。浙江大学硕士毕业，阿里巴巴高级算法专家，加入阿里巴巴以来一直致力于研究搜索推荐相关技术，相关工作包括自然语言处理，查询词分析技术研究，知识图谱数据构建，实体推荐等多个不同方向。当前是夸克浏览器智能推荐业务业务负责人，致力于推动推荐从传统的用户行为推荐向知识化推荐的升级，从而提升用户信息获取信息的边界，加快信息决策的效率。

本次分享将首先介绍神马搜索在推荐领域有哪些应用场景，之后为大家分享在神马搜索的推荐系统中所做的召回和排序相关的工作。

一、概览

场景介绍

首先为大家介绍神马搜索的推荐场景有哪些，比如大家在向搜索框输入内容之前，搜索框就会提供一些预置的搜索词，这属于没有搜索 Query 的推荐。其次，如果大家点击网页之后返回结果，神马搜索会在 URL 下面提供一些相关的 Query，这是与 URL 本身相关的推荐。再次，还有 Query 推荐和相关搜索，这中推荐的主要目的是引流，国内的搜索引擎基本上都是商业化的产品，因此通过这样的推荐方法就能够很好地吸引一些流量进来。此外，还有体感比较好的实体推荐，以及在内容消费页面所做的相关推荐。

推荐大致可以分为三个阶段，首先在输入之前，神马搜索引擎会基于用户画像以及其他的一些相关推荐技术将一些内容推荐给用户；第二个阶段就是在搜索的结果页进行推荐；最后一个阶段就是在内容页面上做一些相关推荐。从另外一个维度上来看，推荐也可以分为三个部分，分别为没有 Query 的推荐、有 Query 的推荐以及基于 URL 的推荐。

技术大图

正如下图所展示的，推荐的业务应用场景非常多，因此无论是从横向还是纵向上进行划分，都可以将推荐划分为多个视角。而如果对于每种推荐都从头到尾搭建一套系统，那么成本将会非常高，而 UC 团队有一套比较通用的技术体系来支撑如下图所示的推荐相关业务。搜索场景下智能推荐的技术大图可以大致分为三个部分，最底层是数据以及数据相关的梳理；其上层就是通过召回以及排序等手段对于数据进行一定的处理；最上面一层就是使用处理好的数据来支撑业务。

对于上层大部分的推荐场景而言，所采用的召回方法基本都是相同的，而所采用的排序方法往往不同。比如对于预置词这种业务而言，它是没有 Query 的，因此在做模型设计的时候就无法利用这些信息。

二、召回

接下来为大家整体地介绍一下推荐系统中的召回体系，在本次分享中只会涉及其中比较通用的 4 种召回方法，但实际上召回体系远远不止这 4 种，一些比较通用的召回方法没有在本文中列出。

用户行为召回

在召回部分介绍的第一种方法就是用户行为召回，也就是去深挖用户行为的价值。用户行为的挖掘是搜索引擎推荐的重要环节，这部分会针对于用户行为做两件事情。第一件事情就是从 Session 的角度来分析哪些 Query 经常会出现在一起，这样分析也会遇到一些问题，比如首先要去区分 Session 里面不同的 Query 类型，在搜索引擎里面可以自己主动地发起一次搜索，也可以自己去点击一些推荐结果。但是这两种行为存在一定的区别，比如主动搜索和被动通过推荐来搜索是不同的，主动搜索行为往往会获得较高的分数，如果在比较靠后的位置点击了推荐结果和在相对比较靠前的位置点击了推荐结果的行为也是不同的。因此，在这里需要对于不同类型的行为做一些权重计算，同时做一些比较机器化的规则，比如在某一个 Session 里面，某一个 Query 是用户最后一次搜索，此时就需要去考虑这个 Query 是不是已经满足了用户需求，因此会对于这些 Query 加一定的权重。

第二个问题就是时效性优化问题，对于一些头部的 Query 而言，可能一天之内就能达到几万甚至十万的量级。对于这样的 Query，通常的做法就是拉一个时间窗口去看所有 Session 里面 Query 的情况如何。但实际上对于这些头部的 Query 没有任何意义，因为其一天的数据就足够分析了，因此在这种情况下会做一些采样；对于一些长尾的 Query 则会做一些时间窗口的拉长操作。第三个问题是稀疏优化，对于前面所提到的基于 URL 的推荐而言，通常的做法就是收集用户点击了 URL 之后又搜索了哪些 Query 的行为，但是这种情况下点击的 URL 往往是很稀疏的，因此会使用 URL 下面本身的一些与 Title 相似的 Doc 共享推荐的 List 实现基于文本的泛化，或者通过相似 Query 共享推荐 List 实现基于行为的泛化，这样一来推荐的效果和覆盖率都会有极大的提升。

行为分析

下图展示的是协同过滤算法，但是经典的协同过滤算法往往存在一些问题，比如同一个 Item 权重的分配而言，在行为非常丰富的用户和行为较少的用户之间，可能更加倾向于前者。

但是这样的做法并不一定合理，因此我们复用了集团的一些成果，做了两点主要的改进，第一个就是尽量地降低行为特别丰富的用户的比重，使得其相对比较平滑。第二个就是构建如上图所示的菱形结构，进而达到闭环的效果，使得推荐的理由更加强烈一些。综上所述，可以从入度出度、行为丰富度不同等闭环的结构上面做优化，来提升整体协同过滤类算法的效果。

标签召回

基于标签的召回与基于用户画像的召回非常类似，对于用户画像而言，现在业界比较传统的做法就是在用户身上打上各种各样的标签，比如性别、年龄以及爱好等。因此，这里将基于标签的召回和基于用户画像的召回合在一起讲解。这里列举了一个例子就是在做 APP 推荐时如何去分析偏长尾的标签，比如搜索“什么软件拍照带耳朵？”时能够发现非常丰富的问答数据，并且发现 Faceu 这款 APP 在答案里面。而如果其他的问答网站里面反馈出了其他的 APP，就能计算出 Faceu 和其他拍照 APP 之间存在非常强大的相关性，这样一来可以做一些关联的推荐，并且可以标注出其推荐者。

标签召回主要包括两个步骤，第一步就是建立比较完整的标签体系，将标签归纳到比较稀疏的链路下面去。在定义好这些链路体系之后，第二步就可以分门别类地去进行挖掘，这里的挖掘相对而言还是比较传统的，比如先分取一些 Query，然后去判断有哪些数据，并对于已有的数据进行一些标注，做一些标签的识别，之后进一步扩大。当我们累积到一定量之后，就可以尝试借助有监督的方法实现进一步的泛化。

知识图谱召回

基于知识图谱的召回是最近一段时间内在学术界比较火的方法。UC 团队在基于知识图谱的召回方面也做了大量的尝试，大致分析了一下有这样几类算法，比如文本建模算法 DLA 和 Doc2vec，知识表示算法 tranE、transH、transD 以及 transR，网络关系算法 DeepWalk、Node2Vec 以及 SNDE 等。文本建模算法基本上都是无监督学习，因此没有办法很好地利用关系网络，主要是利用文本信息；知识表示算法对于关系的稠密度要求非常高，如果关系稠密度没有达到要求，那么采样效果就会非常差；基于深度学习的网络关系算法即可以结合文本信息也可以融合关系网络。综上所述，基于深度学习的网络关系算法相对而言比较中庸一点，能够同时利用文本和网络信息，整体效果也会相对好一些。

UC 团队主要针对 Node2vec 的基础版本做了一些优化。之所以优化 Node2vec 是因为其具有深度优先和广度优先的机制，能够使得其整个训练过程和方向变得可控。Node2vec 的过程主要可以分为 3 部分，主要就是以知识图谱这个图关系网络为基础做随机游走，并且控制随机游走需要深度优先还是广度优先，深度优先会更加关注全局信息，而广度优先则会更加关注 Doc 信息。UC 团队在 Node2vec 上面主要做了两方面优化，一个是数据增广，也就是增加了用户行为数据以及百科数据和超链接数据，将这些数据抽取出来实现层级化，这样就能够在一定程度上解决网络稀疏的问题。第二个优化点就是利用深度学习中一个比较好的方法，也就是利用文本信息做 embedding，比如在知识图谱里面某一个人物有相应的描述，可以对于这些描述信息进行切词并 embedding 到网络中来。

向量召回

基于向量的召回也是最近几年在学术界和工业界中比较热门的方法。向量召回的出发点就是分析输入的 Query 或者用户与候选的推荐 Query 之间的文本语义匹配问题。这个模型是 YouTube 在 2016 年发的一篇论文中提出的，UC 团队在此基础上进行了改进，比如对于 Query 以不同的粒度进行切词。此外，Query 还会有一些文本特征，比如检索切词、语义切词等，还会将用户画像的特征以及实时信息特征一起训练来提升模型的性能。

下图所展示的是向量召回的效果图，左边的第一列是训练的特征，第二列是召回的数据，第三列是真实的搜索 Query。对于向量召回方法而言，有一些优化的方法，比如线上存在真实的排序情况，那么可以将线上真实情况和线下召回的情况做一个比较，从而大致了解向量召回的优势情况以及准确率如何。

三、排序

基础相关性

在排序部分首先介绍基础相关性。下图中展示了一个 Query 例子“泰勒级数展开公式”。在线上首先会对于这个 Query 做切词，切词完成之后，每个 Token 都会召回一系列的候选 Doc，此时会出现一系列的问题，因为已经将 Query 切成 Token 了，所以极有可能产生的 Doc 结果和原始的 Query 是不相关的，因为切分之后无法得到足够的 Query 信息。此时，需要借助相关性模型大致地控制所获取的文本与原始 Query 的相关性，将相关性特别低的候选 Doc 在这一步过滤掉。在模型设计时也会考虑一些应用的场景，比如在做实体推荐时就会将 Query 里面实体的信息引入进来，进而实现共享网络。

如果将 Query 分类信息引入进来就能很好地解决一些歧义的问题。

CTR 预估

UC 团队在两年前做了 CTR 预估的相关工作，那个时候其他的一些方法还没有成熟，因此这部分做的相对比较简单，主要的工作集中在样本的选择以及特征的选择上面。对于样本选择而言，通常会在一个推荐序列里面将点击过的结果作为正样本，将没有被点击过的结果作为负样本。在模型设计方面，比较重要的是 CTR 类特征，如果这个特征不佳就会使得整个模型的特征打一个比较大的折扣。而 UC 团队所实现的 CTR 预估模型能够达到小时级更新，保证线上的效果。

MAB

MAB 的意思就是“多臂老虎机”，比如一个老虎机有多种可以玩的方法，我们一开始不知道哪种方法才能获胜，因此需要逐个实验每种玩法获胜的几率是多少，最终去确定应该以什么顺序来玩。这和排序是非常相关的，因为在推荐时如果直接使用 CTR 排序可能导致一些比较好的潜在的推荐 Item 因为刚刚出来，没有被很多用户点击过，就会导致其永远无法排在前面。此时就需要借助一个探索机制来缓解这样的问题，也就是当使用 CTR 排序完成之后，并不完全按照 CTR 去提供排序结果，而是使得所有的推荐候选项都有一定的概率被选中。如果经常性地进行探测，那么推荐结果也会逐渐地收敛。

小结

这里简单做一个总结，在本文中已经介绍了大部分的推荐算法。对于召回而言，从精准到泛化基本上可以分为基于检索的召回、基于标签的召回、协同过滤、基于知识图谱的召回以及基于向量的召回。对于排序而言，也介绍了基础相关性、语义相关性以及 CTR 预估和 MAB。

本文作者：游客 be77vkb76molw

阅读原文

本文为云栖社区原创内容，未经允许不得转载。