前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >谷歌 ICLR 2020 | 向量化召回也需要『预训练』

谷歌 ICLR 2020 | 向量化召回也需要『预训练』

作者头像
NewBeeNLP
发布2021-04-26 10:16:58
1.1K0
发布2021-04-26 10:16:58
举报
文章被收录于专栏:NewBeeNLP

作者 | 黄挂 编辑 | NewBeeNLP

今天分享的paper是来自谷歌的:PRE-TRAINING TASKS FOR EMBEDDING-BASED LARGE-SCALE RETRIEVAL

ICLR 2020的paper,是作者在google实习的工作。这篇paper关注的是向量化召回的事情,想来公司搜索第一版双塔向量化召回当时是我去试的,后来同事做了很多奇淫技巧发扬光大。模型结构因为召回这个任务的特性所以其实都很简单,这篇文章主要探索的是怎么做预训练能够让召回更牛皮。

Take away

因为我之前也经常在知乎看别人的论文阅读笔记,其实不喜欢那种整篇顺一遍几乎没有翻译或提炼的笔记。但会议通货膨胀,很容易遇到水文,我想每篇阅读笔记最前面都写一些take away,大家可以最方便快捷的了解到自己需不需要继续了解这篇文章。

不过我总是建议大家多读读paper,比较作者能把实验思想写成paper发表,再水也总是有可取之处的。

下面是这篇文章的take away:

  1. 水文指数(满分5):⭐️⭐️⭐️
  2. 作者其实没有提出(我想象的)适合召回模型的“bert-style”预训练任务,因为作者一个很关键的trick是pretrain形式和downstream形式是一样的,就很难说清楚是预训练任务设计的好还是模型更加well-trained了。
  3. 当然至少这也说明了,向量化召回的模型如果更加well-trained的话,效果会好很多。这一点其实我们在做模型的时候也体会到了。
  4. 当然如果看作作者提出来了三种低成本构造“海量弱标签双塔召回模型训练数据”,也是有价值的。
  5. 作者讲故事能力还是挺强的,文章写的挺好。

先简单说说什么是向量化召回

如果你有过互联网公司的经历,大概率你知道什么是召回,可以跳过这一段。但如果不知道没关系。

想象一个搜索引擎,你输入了一个query,背后的引擎如何在海量的文章视频网页里通过query找到你想看的内容呢?绝大部分系统都会分成“召回”和“精排”两部分。我们先通过“召回”从海量网页库里快速圈出一批可能相关的候选,然后再用“精排”对这批候选重新精细的排序,最后找到和你的query最相关的内容。

其实推荐引擎、淘宝的商品引擎等背后几乎也都是这样的两步走(或者三步走,有些中间会有粗排)的过程。召回步骤我们的要求是就两个:“高召回”,“快”。他不用太准,只要不要把真正相关的漏掉就行;但他一定要快,因为背后的文章库是海量的且会一直增加。

因为这些特性,所以大部分召回的模型都喜欢用“双塔”结构,顾名思义,就是query和doc都分别单独做一个塔,分别算到他们的embedding,最后点积或cosine表示他们的相关性。如下图左。

不像bert style的模型(如上图右),需要query和doc拼接一起进入encoder。双塔模型可以预先将doc端的文档全部都提前算好,做好索引,然后query来的时候,用ANN(approximate nearest neighbor )的算法就可以做到超快速度检索。当然双塔结构因为交互不够cross-attention深入(现在主流的NLI和QA任务基本上都是用这种结构),所以效果会相对差一些,但天下武功唯快不破。

上面讲的其实是向量化召回的流程,传统召回也有很多很有意思的东西,譬如倒排索引什么的,之后有计划可以专门写写。

模型结构

模型结构其实在上图左已经一目了然了。tower用的是transformer的。

loss用的是极大似然,想法简单来说就是希望一个query下真正相关的doc的分数要比其他的doc更大。一个query下的doc的条件概率用softmax来表示(如下公式):

p_\theta(d|q) = \frac{exp(f_\theta(q, d))}{\sum_{d'\in D} exp(f_\theta(q,d'))}

D是所有文档,因为所有文档太多了,所以一般会用一个sampled softmax来优化。「具体怎么sample其实对效果影响感觉是很大的,作者没有细说,只说是同一个batch下的一个子集,这样就类似于是随机负例了」

这里再多嘴一句,其实数据选择、包括如何采样负例、这些都是在工业界看来更加crucial,对效果影响更大的奇淫技巧。

预训练

作者看来,预训练重要的点有两个:

  1. 要和下游任务有联系,像召回,我们希望设计一些任务,让模型学习编码q或d的整体语义,这样对我们孱弱的交互(只是点积)会有帮助
  2. 数据要可以无监督获取。

作者基于Wikipedia的数据设计了3种phrase-level的任务:

  1. Inverse Cloze Task (ICT)
  2. Body First Selection (BFS)
  3. Wiki Link Prediction (WLP)
  4. Masked LM (MLM) (这个就不说了,看过bert的都明白)

Inverse Cloze Task (ICT)

ICT是想学习一句话,以及这句话周围的话的关系。这个任务其实不是作者提出来的,是refer到另一篇文章了。而且其实他和当年word2vec的升级版doc2vec,还是Skip-Thought什么的是一样的思想。就是有一个doc,然后从中间挖出一句话。然后希望他们二者的embedding表示更加接近。

Body First Selection (BFS) 和 Wiki Link Prediction (WLP)

这两个任务放在一起因为是一样的,他假设了「每篇wiki的第一段是可以表达整篇文章整体含义的」。BFS就是在同一篇wiki中随机找一段话,希望让他和表示整体主旨的第一段话的embedding更加相近。WLP就是希望这段话和他超链接里的wiki的第一段话的embedding更加相近(「这里又假设了wiki的超链接之间的文章还是有某种语义关联的」)。

一开始我以为是根据上面的形式采样了很多pair,然后像NSP(next sentence prediction)任务一样,拼接起来然后分类,可能会有随机负例。但我发现作者似乎不是这个意思,作者似乎是想说,他的「预训练形式其实也是双塔结构,而不是bert的那种拼接预测的形式」

看到这里就大概明白为啥表现会这么好了,其实我觉得「关键点是作者构造了海量弱标签数据让双塔模型更好的学习」了。本质上其实是召回模型在downstream数据上是under-trained的,然后作者通过wiki构造了一批数据,让模型更加well-trained了。

「作者的意思不是说“经过上面三种任务预训练的transformer参数用来初始化双塔召回模型会更好”,而是说“双塔召回模型经过上面三种弱标签数据训练一下再跑下游任务会更好”。」

「所以其实他没有给出更好的召回模型的预训练方式,只是给出了三种无监督获取召回模型训练数据的方法嘛。」

看结果也是,纯MLM的效果从1%->80%涨了很多。说不定还没收敛呢?除非作者再补充下面几个实验,才能说服我。

  1. 用上面三个预训练任务,拼接pretrain,而不是two-tower pretrain,能带来提升。(否则我可以怀疑其实是two-tower pretrain让模型更加适应点击算分的形式)
  2. 把模型训练的拟合曲线分析一下,证明模型在down-stream已经是well-trained了,加预训练可以让他更上一层楼。
  3. 我怀疑,先MLM训练,然后再做上面的3个双塔pretrain,效果会更好。因为MLM会mask一些词,如果mask掉了关键词,对双塔encode的效果会影响很大(这是我之前验证过的)

ABLATION STUDY

生气归生气,我们还是看看缺省实验。

有下面几点:

  1. 三个构造数据的方式中:ICT > BFS > WLP
  2. BFS,WLP看起来确实没啥用,单ICT就基本逼近ICT + BFS + WLP了。然而ICT又不是作者最早提出的...
  3. 如果将维度从256换成512,提升相对微弱。

总结:

整体来说其实感觉相对有点水,感觉作者只是提出了三种构造双塔召回模型预训练数据的方式而已。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-04-14,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 NewBeeNLP 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • Take away
  • 先简单说说什么是向量化召回
  • 模型结构
  • 预训练
  • Inverse Cloze Task (ICT)
  • Body First Selection (BFS) 和 Wiki Link Prediction (WLP)
  • ABLATION STUDY
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档