点击上方，选择星标，每天给你送干货！

---

来自：AI部落联盟

如果对开放领域问答（open domain question answering）还不太熟悉的话，建议先阅读上一篇总结哦。总结｜开放领域问答梳理系列(1)介绍了开放领域问答的背景知识、最常用/基本的二阶段系统DrQA及其对应的6个改进方向和相关研究。

这篇文章重点学习的改进/研究的方向是开放领域问答中的：Dense Retriever（直译成稠密检索，但叫向量检索似乎更为恰当）。Dense Retriever（向量检索）直观的作用就是替换Sparse Retriever（稀疏检索，比如TF-IDF或者BM25），所以本文开放领域问答中的所有Dense Retriever的改进和总结（1）的改进基本是不重合的，甚至可以是相辅相成的。

Dense Retriever和Sparse Retriever的区别

无论是Dense还是Sparse Retriever都可以在下面这个简单的框架下进行理解：

1. 假设有一个函数f（比如是BERT/TFIDF），将语料库中的每篇文章（比如维基百科中的所有网页）都映射（也可称为Encoding、编码）成为一个维度为d的向量（vector)。

2. 将一个问题也映射成为一个维度为d的向量，从所有文档向量中找出与问题向量距离最近的向量（比如直接点乘），所对应的文档也就是与问题最相关的文档。

橘个栗子：

语料库包含2个文档：

1. 关 注 AI 部 落 联 盟 。

2. 多 多 在 AI 部 落 联 盟 。

要检索的问题是：多 多 在 哪 里 ？

文档和问题都用空格分开，词库和词ID对应关系也可以叫词典（dictionary）：{关：0，注：1，AI：2，部：3，落：4，联：5，盟：6，多：7，在：8，unk：9}。unk作为unknown word（未登陆词）。

Sparse Retriever举例：

基于TF（为了计算简单暂不引入IDF啦）的Sparse Retriever将2个文档映射成2个维度为10的向量（注意，这里的维度10受到dictionary大小的限制）；映射方式为：位置对应词的ID，位置上的值为词出现的频率：

1. [1，1，1，1，1，1，1，0，0，0]

2. [0，0，1，1，1，1，1，2，1，0]

基于TF的Sparse Retriever则将问题映射为：[0，0，0，0，0，0，0，2，1，2]。那么两个文档的向量点乘得分分别为：0和5分，因此第2个文档和问题距离最近，与问题最相关。

Dense Retriever举例：

基于BERT的Dense Retriever则可以将两个文档映射为2个768维度或者4维的向量（注意这里的维度不受词典大小的限制，这里就以4维举例啦）：

1. [0.13，0.11，0.52，0.55]

2. [0.25，0.35，0.38，0.65]

问题可以被映射为：[0.10，0.10，0.0， 0.20]（偷懒方便计算放个0.0）得到两个文档的得分是0.013+0.011+0.11=0.134和0.025+0.035+0.13=0.19，第2个文档举例最近，最相关。

由此我们来看看看到Dense Retriever和Sparse Retriever的区别：

1. Dense vector对每个文档/问题表示的向量维度灵活，几乎可以使用任意维度的向量进行表示。

   Sparse vecter表示的向量会r受到语料库词典大小的限制。

2. 当词典较大的时候，Sparse vector表示中通常包含大量的0，但Dense vector可以使用较小维度的向量进行表示，几乎不会在包含空闲的0。

3. Sparse vector更倾向表层单词匹配，比如例子中文档2在文档向量的第8、9位包含了单词“多”和“的”，问题向量也在第“8”、“9"位置包含了“多"和“的”; 与之相对的Dense vector便不在有这个特点（既是优势也是劣势，劣势就在于直接匹配的精度有所下降；

   优势在于所包含的语义信息更丰富，更倾向与语义层面的匹配）

更进一步的区别：

1. Dense Vector的表示可以通过训练和学习变得更优秀！

2. 多么难得的品质，个人认为这也是Dense Retriever在未来打败Sparse Retriever的原因！

   上面的例子中对这一点的体现不是很明显，简单理解：

   使用匹配的（文档，问题），来训练映射函数f，使得匹配的文档-问题对儿更加靠近，不匹配的更加远离（这里的匹配既包含了字面单词匹配，也包含语义匹配）。

3. 做过搜索推荐的同学看过来：

   用户A、性别男、足球迷，搜索了问题。

   那么这些所有信息其实都可以通过模型被映射到dense vecter里！

   而Sparse Retriever通常只能映射问题成为向量。

Dense Retriever近期发展特点和难点

既然向量检索这么优秀为什么之前开放问答领域没有火，最近才火起来呢？

个人归纳为：天时地利人和。

• 天时：pretrain模型让及其阅读理解绽放了光芒，而又远不满足于简单的单篇阅读理解，因此open domian qa开始火起来了。

• 地利：faiss为例的向量检索工具不断优化变快。

• 人和：dense vector可训练，语义表征能力强的优点！

火归火，但依旧是个很难的问题，不然也就不会又这么多人来研究她了。为什么难呢？

图1 基于BERT的Dense Retriever示意图

图1展示了一种基于BERT的Dense Retriever，问题和evidence block（一段文章/一个固定长度的文章片段）经过BERT后选择CLS token所对应的向量作为对应encode的dense vector，寻找与问题question向量得分最大的top K个文档作为最相关的文档。这个里面的难点有：

1. 有限的维度，大量的文档，无限的问题：以维基百科为例，有差不多3000万的段落，假设用128维的向量进行编码，那么意味着我们要在这仅有的128维的空间里，将3000万文章的各自的特点进行表示和区分，这很难。

   更难的是，问题是open的（即便问题的词库是固定的，一个问题的描述也是千变万化的）意味着我们将千变万化的问题所表达的信息映射到128维的向量里，也很难。

2. 有限的训练数据集：难点a的一个潜在的解决办法：通过大量的标注，让图1中的双塔模型尽可能见到更多的问题-文档正例对儿，对模型的表达带来更大的帮助。这本身又是一个新问题：标注数据很贵orz。

3. 预训练模型目标和retriver目标的不一致：难点b的一个缓解办法是：无监督（无穷无尽的无标注文本数据）预训练模型可以帮助我们将token的embedding，映射函数（BERT里的一堆transfromer）训练得更好，减少对问题-文档正例对儿得依赖。但对应的难点是：通常的无监督预训练模型都是语言模型，直接用刀图1里其实训练阶段的目标和retriever使用时的目标是有差距的。

4. 检索速度和效率：另外一个难点是向量检索的速度和效率，不过这个难点最近的MIPS工具的更新和发展已经缓解了一部分啦。

5. Dense retriever如何end-to-end有效训练：这一点其实和难点a有关联，由于最终向量表示维度有限，数据也有限，那么如何设计模型/目标函数/模型特征等：既能促使模型在有效的维度信息里表达更丰富，又能让训练阶段和预测/检索阶段一致呢？

由于以上难点仅为个人的一点思考和总结，dense retriever必然还有更多的其他问题，欢迎大家提建议和意见我再补充，所谓发现问题才能解决问题嘛哈哈哈。

改进方向1: 优化预训练模型帮助dense retriever

开放领域问答里的dense retriever最近几年的研究里，首先介绍谷歌ACL2019这一篇文章：Latent Retrieval for Weakly Supervised Open Domain Question Answering。

图2 ORQA示意图

如图2所示，ORQA这篇文章所提的模型应该是最近几年里第1个将dense retriever和阅读理解模型联合在一起end-to-end训练出来的模型了。

简单来说这个文章干了这么一件事情：用第1个BERT编码出问题q的表示向量，用第2个BERT编码出所有文档片段的表示向量，通过问题q的表示向量，找到最相关的top k个文档（问题q和文档片段相比得分最高的k个），并用第3个BERT编码问题q和top k的文档，最终抽取出答案所在的span。训练的时候目标函数是retriever目标函数+阅读理解目标函数。

这篇文章的主要贡献可以归结为：

1. 第1个将dense retriever和machine reading comprehension模型联合并end-to-end训练的模型，并且这个dense retriever搞work了！

2. 尽管训练数据只有question-answer对，也就是只有问题和答案，不用给出所依赖文档的标注，也能训练出一个还不错的dense retriever。

3. 提出了一个预训练模型（对应上一节说的难点c）Inverse cloze Task来帮助训练dense retriever（帮助dense retriever模型的初始化，也对应着上一节的难点a）。

模型的具体训练方法建议读者阅读原文，后续有时间也可专门来写篇论文解读哈哈。如果感兴趣的同学阅读了原文，可以来尝试回答如下几个问题：

问题1: ORQA模型中的dense retriever最开始训练的时候，根据向量得分找到的top k（比如top 10个）相关文档应该是随机的（几千万个文档片段随机选10个，几乎不可能包含问题的答案），这样的话，相当于没有正例了，咋个训？

简单答案：先把top k的k放大，尽可能包含答案，并且先只训练dense retriever，不管reader模型，尽可能让retriever model有监督信号且监督信号先只给dense retriever model。

问题2: Inverse cloze task是咋回事？

简单答案：假设使用一个文档片段A，包含3个句子。从文档A中随机选一个句子当作一个伪伪问题，然后把文档A中的伪问题所对应的句子扔掉，然后这个伪问题和文档A便构成了一个问题q-文档正例对，随机选其他文档作为负例对，进行预训练（预训练的目标：识别正例还是负例对儿即可）。

第2篇值得介绍的文章还是谷歌家的：REALM: Retrieval-Augmented Language Model Pre-Training。

图3 REALM示意图

如图3所示，左边就是预训练过程。思路是：从语料库中随机找一个句子A（伪问题），然后[MASK]掉其中的一个词（伪答案），然后用句子A和retriever model去语料库中retrieve出相关文档，并用reader model去预测答案（也就是红色[MASK]对应的词/entity），最终把retriever和reader model都在预训练中end-to-end训练起来了（牛）。预测的时候只需要在这两个模型上fine-tuning一下即可（把问题和答案替换成真实的问题和答案即可）。????

这个模型的idea真的很厉害了，但这个过程其实并不好训练，为了能让这个过程顺利训练起来，作者做了这些操作：

1. 把ORQA里的invese cloze task当作第一阶段的预训练，帮助模型初始化。

2. MASK的时候仅仅只MASK entites和日期dates。

3. CC-NEWS语料库，比维基百科更大。

4. 训练的时候也更新语料库中文档的BERT表示（基本就是先用BERT得到文档的表示，训练几个epoch再更新文档的BERT表示，ORQA里文档的BERT表示应该是不更新的）

以上两篇文章idea都很棒，效果也很好，可是。。。需要好多好多好多。。GPU????。那么有没有不用那么多资源，也能有一定效果的方法呢？

改进方向2: 训练方法的改进

首先介绍danqi chen再emnlp 2020上的Dense Passage Retrieval for Open-Domain Question Answering简称DPR，一篇简单+实用+效果好的文章。

图4 DPR示意图

如图4所示，DPR结果上就是普通的双塔模型，但论文作者们在训练上（正例、负例的选择）下了很大的功夫，从而节省了预训练所需的大量资源。具体为：

正例的选择：

1. 阅读理解数据集标注好的问题q-文档p的pair。

2. Distant supervision，根据问题q，通过BM25/TF-IDF检索得到相关文档，如果文档包含答案即可作为正例。

负例的选择：

1. 从语料库中随机采样出文档p作为问题q的负例。

2. TFIDF/BM25得分高，但不包含答案的文档（hard negative）

3. 问题q以外的其他问题的正例作为问题q的负例。

图5 in-batch negatives

图5详细介绍了in-batch的负例（第3种负例）如何产生的，从NQ数据集的HIT@top-k效果来看，DPR的top-5 retriever performance随着负例的选择而逐渐变强。

因此DPR的主要贡献可以归纳为：

1. 借助好的负例和训练方法，即便不使用与训练模型，dense retriever也可以达到足够好的检索效果（当然前提是像NQ这样的大数据集，如果数据集本身只有500训练样本还是太难了点）

2. Pipeline的dense retriever+ reader并不比joint训练的差，并且还更模块化和高效，特别是训练的时候，语料库的索引index只需要构建1次即可（REALM训练的时候，如果要更新文档的BERT的表示需要更新index）

3. 仅仅用question-answer的pair作为训练数据即可，使用标注好的问题-文档-答案三元组的帮助并不大太。

那么说到更优的训练方法达到更好的效果，百度的这篇RocketQA: An Optimized Training Approach to Dense Passage Retrieval for Open-Domain Question Answering也从cross-batch sampling、denoise hard negative、data agumentation三个角度进一步证实了其有效性。

既然谈到了更好的负例，那是不是也得提一下Facebook这一篇负例为王：Embedding-based Retrieval in Facebook Search。这篇搜索推荐的文章像我们展示了工业界的dense retrieval（文章里叫embedding retrieval），有许多的细节值得学习！！详情可见知乎相关解读。

Facebook在DPR的研究上还做了进一步的研究：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。如图6所示，虽然看起来有点复杂，其实可以简单理解为：Retriever为DPR+reader为BART和DPR+BERT流程上的的区别不是特别大，感兴趣的读者可以阅读原文进行学习。

图6 RAG框架

以上就是笔者今天想总结的开放领域问答中的Dense Retriever啦，回顾一下主要是：Dense Retriever和Sparse Retriever的区别，Dense Retriever特点和难点、最近2个比较有意思的改进方向、相关论文。

笔者写在最后：

1. 笔者认为开放领域问答中的Dense Retriever应该会越来越流行，至于Dense Retriever单独用就能完全替代TFIDF这种Sparse Retriever呢？

   还是结合两者更好还是需要在对应任务实践一下，无法一概而论的。

2. 一个很有意思的事情是：

   搜索推荐系统、广告/商品推荐系统中的深度召回模型（常说的双塔模型）其实和开放领域问答中的Dense Retriever形式上基本相同，但目前一个很大的不同点在于：

   开放领域问答的Dense retriever在编码问题的时候（由于数据集的原因）只能编码问题的字面描述，没有编码问题的其他信息，比如提问者信息（比如性别、城市、爱好等等），双塔模型中的question这个塔是具备这个能力的。

3. Dense Retriever的向量可以被不断优化，也让question的表示具备“进化性”，也就是说问题+问题搜回来的文档，如果得不到答案，是否可以根据当前已有的信息改进这个问题向量表示，然后重新检索，也就是multi-hop question answering的进一步改进啦！

   将在后续的文章中进一步介绍。

4. Dense Retriever融合上一篇总结的6个改进方向也还有许多未尝试和未解决的问题呢。

说个正事哈

由于微信平台算法改版，公号内容将不再以时间排序展示，如果大家想第一时间看到我们的推送，强烈建议星标我们和给我们多点点【在看】。星标具体步骤为：

（1）点击页面最上方“深度学习自然语言处理”，进入公众号主页。

（2）点击右上角的小点点，在弹出页面点击“设为星标”，就可以啦。

感谢支持，比心。

投稿或交流学习，备注：昵称-学校（公司）-方向，进入DL&NLP交流群。

方向有很多：机器学习、深度学习，python，情感分析、意见挖掘、句法分析、机器翻译、人机对话、知识图谱、语音识别等。

记得备注呦

整理不易，还望给个在看！