业界大盘点！文本相关性在搜广推三大场景中的应用

最新推荐文章于 2024-08-08 16:00:58 发布

李rumor

最新推荐文章于 2024-08-08 16:00:58 发布

阅读量758

点赞数

文章标签：自然语言处理机器学习深度学习推荐系统

本文链接：https://blog.csdn.net/m0_37310036/article/details/116207669

版权

卷友们好，我是rumor。

NLP最赚钱的落地莫属搜索、广告、推荐三大场景了，今天我们就向钱看，来了解下作为NLP算法工程师，怎样在互联网最主要的三个场景里发光发热，同时蹭得一份业绩。

注：欢迎初入NLP领域的小伙伴们加入rumor建立的「NLP卷王养成群」一起学习，添加微信「leerumorrr」备注知乎+NLP即可，群里的讨论氛围非常好～

搜广推这三个场景的架构都差不多，主要就是通过对内容/商品的召回和排序，来优化Query-Doc的匹配结果。可以将这个过程分为三部分：

Doc的理解：现在的候选Doc/Item是各种模态的，比如视频、商品、图片、文本，但不管哪种形式，文本都是其中的重要一种，可以利用阅读理解、信息抽取、文本匹配打标签等技术加深对内容的理解
Query的理解：在搜索、广告中输入都是真实的Query，可以基于NLP进行意图、分词、NER等各种解析，而推荐中则是把User当作Query，这时可以把用户历史消费的内容作为用户兴趣，这件又回归到了Doc理解
Query-Doc相关性：通过用户行为、用户信息、时空信息、上述的Query和Doc理解等海量特征来找出符合用户需求的结果。搜索和广告是命题作文，其中文本层面的Query-Doc很重要，而推荐中内容信息则可以解决用户、物品冷启动问题，也起着不可或缺的作用

本文主要聚焦于Query-Doc文本相关性的应用调研，该相关性分数作为特征，对召回以及排序结果都有很大影响。（不是不想讲别的，光文本相关性我就刷了十几篇业界干货，肝要爆掉了，别的就下次一定吧hhh）

业界解决大赏

之前写过一篇文本匹配的综述，但当真正涉及到应用时跟业务的阶段、流量、资源都有很大关系，简单的字面匹配其实就能满足不少需求。

蘑菇街

蘑菇街在最初的迭代时，通过频率、tfidf、BM25、布尔模型、空间向量模型、语言模型等统计方式抽取了文本的稠密特征，输入到树模型进行相关性打分就能得到不错的效果。同时他们也加入了Q-D的交互特征，也就是对Query、Doc进行同义词扩展后，计算重合ngram term占Query term和Doc term的比例。但字面匹配的可扩展性较差，需要好的同义词表提升泛化性能，因此下一个阶段就是引入词向量。蘑菇街在19年也尝试了用tfidf筛选出核心词，并对Query、Doc的核心词进行Self-Attention计算再融合，得到更好的文本相关性结果，将佣金收入提升了5.56%。

接下来到了深度学习时代，各厂门都开始不满足字面匹配的相关性，因为这个方案需要大量的人工特征工程以及同义词、停用词的挖掘，这时便出现了著名的DSSM模型。

小米移动搜索

小米采用的方案是在人工GBDT的方案基础上融合C-DSSM的结果，利用大规模用户行为数据进行训练，提升了长尾Query的查询效果。

阿里妈妈

阿里妈妈也采用了DSSM进行广告语义匹配，但他们在应用中发现pairwise loss会导致Q-D预测结果偏向正太分布：

这就导致阈值对召回结果有很大影响，不同天的Query召回集合变动很大，给广告效果带来了不确定性。因此他们改为拟合伯努利分布，使预测结果成哑铃的形状，降低阈值对截断的影响。同时为了弥补DSSM缺少交互的缺点，他们在中间加入了Q-D的attention交互计算，最终新的方案在各个指标上都超越了DSSM。

京东电商搜索

当然，文本相关性也可以不单独作为一个特征，而是直接融合到召回中。京东电商搜索则是分别给Query和商品建立了一个encoder，在输入Query文本、商品名称的同时融合其他特征进行计算，比如用户基础信息、历史行为、商品品牌、品类等：

值得注意的是，左侧的Query编码器采用了multi-head机制，用于捕获不同的语义，比如品牌属性、商品属性等，丰富Query的表示。

阿里飞猪

阿里飞猪和京东采取的融合方案相似，不同的是他们更关注Doc的理解，提前对商品的目的地和类目id进行了编码，作为Doc侧的输入：

当然，讲NLP肯定少不了BERT。

知乎搜索

作为重内容的社区，知乎在他们的搜索召回和排序中都有用到BERT，在召回中会分别对Query和Doc编码，通过向量检索的方式召回候选，同时在二轮精排也会用交互式的小BERT进行相关性计算：

数据才是天花板

上面介绍了字面匹配和语义匹配各阶段的模型，但在应用场景中，数据才是真正的天花板，模型只是在不断拟合上线而已。训练数据的构造在文本相关性任务中是十分重要的。

把用户点击的数据当作正例是无可后非的，但一个很常见的错误就是把召回结果中未点击的内容作为负例。腾讯全民K歌的分享中指出，在召回和排序这两个步骤中我们的视角是不一样的，召回阶段的视角是内容全集，同时未点击也不意味着就不是好结果，所以更好的做法是在全局范围内进行随机负采样，实践的效果也证明这样会更好。

但单纯的随机负例也有问题，就是可能会把相关商品变成负例，降低结果与Query的相关性。京东电商搜索采用的方案是按一定比例将随机负例与batch negatives相融合，因为batch内的doc都有对应的batch query作为正例，打散的话更大概率与当前正例不相关，之后再通过控制参数来平衡召回结果的多样性与相关性。

知乎搜索还提出了一种hard负例的挖掘方法，就是将query和doc映射到一个空间中，再对doc进行聚类，这样就可以找到与query相近的类别，从其中采样一些较难的负例。或者也可以参考阿里飞猪的做法，在一个类目或者目的地下随机选择负例，提升训练数据的难度。

当然有资源的话最好还是进行人工标注，而搜广推数据量那么大，都标注肯定是不可能的，需要更高效的问题样本发现机制。阿里文娱基于Q-Learning的思想，对于线上预测较差的样本，再用一层模型进行挖掘，把低置信度的样本、或者高置信度但和线上预测不一致的样本拿去给人工标注，这样就可以快速迭代出问题集并有针对性地优化：

线上怎么用呢

上文终于费劲吧啦地把模型训出来了，然而怎么用还是问题，之所以不是所有厂都用BERT，主要还是因为代价太大。虽然Doc的表示都可以离线预测好存起来，但Query来了真心受不了。

第一种解决方案就是把模型做小。

上文中介绍的知乎搜索直接把BERT用到了二轮精排中，因此他们的做法是基于Roberta-large进行蒸馏，采用Patient-KD方式，将12层蒸馏到了6层。同时他们也对BERT表示模型进行了维度压缩，在不影响线上效果的情况下，将768维压缩到了64维，减少了存储空间占用。

阿里文娱只用到基于表示的方案，因此他们蒸馏了一个非对称的双塔模型，并且在doc端采用multi-head方式来减少指标衰减。

第二种解决方案就是把数据尽可能存起来。

360搜索广告在训练阶段用了16层transformer，因此在应用到线上时选择了离线的方式，先从日志中挖出一部分Q-D对，进行相关性预测，再通过CTR预测进行过滤，把最终结果存储到线上KV系统。

不过这种方案只限于数据量可以承受的场景，也可以把两种方式进行融合，将一些高频Query提前存好，剩下的长尾Query用小模型预测。

我们的业务不一样

上述的介绍主要还是集中在搜索、广告场景下，因为推荐场景没有query，花样会更多一些，也会利用其他很多特征，基本上都是把文本作为一个维度来训练相关性模型。下面再介绍两个我在业界分享中看到的相关性改进方法，一起开开眼。

百度凤巢

对于搜索广告这种命题作文来说，召回阶段最重要的目标就是Q-D相关性，但这个优化目标其实跟最终的ctr是有gap的，尤其是在广告场景中，最终影响收益的指标和ctr有很强的关系。所以百度凤巢团队提出了MOBIUS系统，将ctr预估引入到搜索召回阶段：

最单纯的想法是直接在召回阶段以ctr为目标进行训练，但由于ctr目标本身的问题，很可能将相关性不高的广告预测为正例。MOBIUS提出了一个数据增强模块，先从日志里捞一批Q-D对，再用相关性模型进行打分，找出相关性低的pair作为badcase，让最终的模型预测。这样模型从二分类变成了三分类，就具备了过滤不相关case的能力，将相关性预测与ctr预测较好地融合在了一起。