改进 Elastic Stack 中的信息检索：引入 Elastic Learned Sparse Encoder，我们的新检索模型

英文原文请参考：https://www.elastic.co/blog/may-2023-launch-information-retrieval-elasticsearch-ai-model

在本系列的上一篇博客文章中，我们讨论了在零样本情况下应用密集模型进行检索的一些挑战。这是众所周知的，BEIR基准测试将多种检索任务组合在一起，作为模型在未见过数据集上表现的代理。在零样本情况下实现良好的信息检索，即使用预训练模型进行一键式搜索文本字段，正是我们想要实现的目标。

这项新功能适合 Elasticsearch _search端点，就像另一个查询子句，即text_expansion查询。这很有吸引力，因为它允许搜索工程师继续使用 Elasticsearch ®已经提供的所有工具来调整查询。此外，为了真正实现一键式体验，我们将其与新的 Elasticsearch Relevance Engine 集成。然而，本博客并没有重点关注集成，而是深入研究了我们选择的模型架构以及我们为训练它所做的工作。

在这个项目开始时我们还有另一个目标。自然语言处理（NLP）领域正在快速发展，新的架构和训练方法正在迅速引入。虽然我们的一些用户希望掌握最新的发展并完全控制他们部署的模型，但其他用户只想使用高质量的搜索产品。通过开发自己的训练管道，我们拥有了一个用于实施和评估最新想法（例如新的检索相关预训练任务或更有效的蒸馏任务）的平台，并将最好的想法提供给我们的用户。

最后，值得一提的是，我们认为此功能是对 Elastic Stack 中现有模型部署和向量搜索功能的补充（这些能力适用于那些更定制的用例，例如跨模态检索）。

结果

在查看架构的一些细节以及我们如何训练我们的模型（Elastic Learned Sparse Encoder）之前，回顾一下我们得到的结果是很有趣的，因为，实践出真知。

正如我们之前讨论的，我们使用 BEIR 的子集来评估我们的性能。虽然这绝不是完美的，并且不一定代表模型在您自己的数据上的行为方式，但我们至少发现要在此基准上做出重大改进极具挑战性。因此，我们相信我们在这方面取得的改进会转化为模型的真正改进。由于基准测试的绝对性能数据本身并没有特别丰富的信息，因此很高兴能够与其他强大的基准进行比较，我们将在下面进行比较。 

下表显示了 Elastic Learned Sparse Encoder 与带有英文分词器的 Elasticsearch BM25 的性能比较，并按我们评估的 12 个数据集细分。我们取得了 10 胜 1 平 1 负的成绩，NDCG@10 的平均进步为 17%。

NDCG@10 用于 BM25 和 Elastic Learned Sparse Encoder 的 BEIR 数据集（上面称为“ELSER”，注意越高越好）

在下表中，我们将我们的平均表现与其他一些强基线进行了比较。VVespa的结果基于BM25和他们实现的ColBERT的线性组合，如此处报告所述，而Instructor的结果则来自于这篇论文，SPLADEv2 的结果取自本文，OpenAI 结果来自于此报告。请注意，我们已将 OpenAI 结果分开，因为它们使用 BEIR 套件的不同子集。具体来说，他们对 ArguAna、Climate FEVER、DBPedia、FEVER、FiQA、HotpotQA、NFCorpus、QuoraRetrieval、SciFact、TREC COVID 和 Touche 进行平均。如果您查看他们的报告，您会注意到他们还报告了以百分比表示的NDCG@10。我们建议读者查阅上述链接以获取有关这些方法的更多信息。

BEIR 数据集与各种高质量基线的平均 NDCG@10（越高越好）。注意：OpenAI 选择了不同的子集，我们单独报告了该集的结果。

最后，我们注意到一个已被广泛观察到的事实，即在零样本情况下，统计检索（如BM25）和基于模型的检索的集成，即混合搜索，往往比单独使用任一种检索方式效果更好。在 8.8 中，Elastic 已经允许通过线性增强对 text_expansion 执行此操作，如果您校准数据集，则效果很好。我们还在研究 Reciprocal Rank Fusion（RRF）排名融合算法，它在没有校准的情况下表现良好。如果您感兴趣，请继续关注本系列的下一篇博客，其中将讨论混合搜索。

在了解了我们的模型表现之后，接下来我们将讨论它的架构以及一些训练方面的细节。

什么是学习稀疏模型以及它们为什么有吸引力？

我们在之前的博客文章中表明，虽然经过微调非常有效，但密集检索在零样本情况中往往表现不佳。相比之下，交叉编码器架构（cross-encoder architectures）不适合大规模检索，但往往能够学习到强大的查询和文档表示，并在大多数文本上表现良好。有人认为，造成这种差异的部分原因是查询和文档只通过相对较低维度的向量“点积”进行交互的瓶颈。基于这个观察结果，最近提出了几种模型架构，试图减少这种瓶颈，其中包括ColBERT和SPLADE。

从我们的角度来看，SPLADE 还有一些额外的优势：

1. 与 ColBERT 相比，它的存储效率极高。事实上，我们发现文档段落平均扩展到大约 100 个 token ，并且我们看到与正常文本索引的大小大致相同。
2. 在特定限制条件下，这种检索可以利用倒排索引，而我们已经在Lucene中拥有非常成熟的实现。与ANN相比，这些方法非常高效地利用内存。
3. SPLADE在训练过程中提供了自然的控制方式，可以在检索质量和检索延迟之间进行权衡。特别是，我们下面讨论的 FLOPS 正则化器允许为为预期检索成本添加一个项到损失函数中。我们计划在迈向 GA 时利用这一点。

与密集检索相比，最后一个明显的优势是 SPLADE 允许人们通过一种简单且高效的方式来突出显示生成匹配的单词，从而更容易地在长文档中找到相关段落，并帮助用户更好地理解检索器的工作原理。总而言之，我们认为这些优点使得采用SPLADE架构成为发布此功能的一个强有力的理由。

关于这个架构有很多很好的详细描述 —— 如果你有兴趣深入了解，比如说这篇文章是由创建该模型的团队撰写的。简而言之，这个想法是，与其使用分布式表示（例如平均 BERT token 输出嵌入），不如为掩码词预测使用 token logits 或者说是被预测的词汇的 log-odds。

当语言模型用于预测屏蔽词时，它们通过预测词汇表 token 的概率分布来实现这一点。WordPiece 的 BERT 词汇表包含许多常见的真实单词，例如 cat、house 等。它还包含常见的词尾——比如 ##ing（## 只是表示它是延续）。由于单词不能任意交换，因此对于任何给定的掩码位置，预测的 tokens 数量相对较少。SPLADE以掩盖文本中的每个单词并预测最强的 tokens 作为其表示形式的起点。如前所述，这是该文本的自然分离或稀疏表示。

将单词预测的这些 token 概率视为粗略地捕获上下文同义词是合理的。这导致人们将学习到的稀疏表示（例如 SPLADE）视为接近文本自动同义词扩展的东西，我们在该模型的多个在线解释中看到了这一点。 

将SPLADE描述为仅仅基于文本的最大token logits进行微调是过于简单化，甚至会误导人。实际上，SPLADE在微调后会进行一项关键的相关性预测任务。这个任务考虑了查询和文档中所有共享 token 之间的交互作用，从而使得这些 token 在一定程度上重新交织在一起。这些 token 开始表现得更像向量表示的组成部分（尽管是在一个非常高维的向量空间中）。

我们在开展这个项目时对此进行了一些探索。当我们尝试在后期扩展中删除低分和明显不相关的 token 时，我们发现它降低了基准套件中的所有质量指标，包括精度（！）。如果它们更像分布式向量表示，那么这将得到解释，在这种情况下，清零单个组件显然是不合理的。我们还观察到，我们可以随机删除BERT词汇表的大部分内容，并仍然训练高效的模型，如下图所示。在这种情况下，词汇表的某些部分必须被重新用于解释缺失的单词。

最后，我们注意到，与规模确实很重要的生成任务不同，检索并没有明显受益于拥有庞大的模型。我们在结果部分看到，与一些较大的生成模型中的数亿甚至数十亿参数相比，这种方法仅用 100M 参数就能实现近乎最先进的性能。典型的搜索应用程序对查询延迟和吞吐量有相当严格的要求，因此这是一个真正的优势。

我们是如何进行模型训练的？

在我们的第一篇博客中，我们介绍了有关训练密集检索模型的一些想法。实际上，这是一个多阶段过程，通常会选择一个已经经过预训练的模型。此预训练任务对于在特定下游任务上获得最佳结果非常重要。我们不会进一步讨论这个问题，因为迄今为止这还不是我们的重点，但请注意，像许多当前有效的检索模型一样，我们从共 co-condenser pre-trained model 开始。

设计训练管道时，有许多潜在的途径可供探索。我们探索了很多，可以说，我们发现对基准进行持续改进具有挑战性。许多在纸面上看起来很有希望的想法并没有带来令人信服的改进。为了避免这篇博客变得太长，我们首先快速概述训练任务的关键要素，并重点介绍我们引入的一项创新，它提供了最显着的改进。独立于具体因素，我们还对 FLOPS 正则化的作用进行了一些定性和定量观察，我们将在最后讨论。

在训练检索模型时，有两种常见的范式：对比法和蒸馏法。我们采用蒸馏法是因为这在这个论文中，蒸馏法被证明对于训练 SPLADE 非常有效。蒸馏法与常见范式略有不同，后者将大型模型缩小为小型但几乎同样准确的“副本”。相反，这个想法是提取交叉编码器架构中存在的排名信息。这提出了一个小小的技术挑战：由于表示不同，因此目前还不清楚应该如何通过正在训练的模型来模仿交叉编码器的行为。我们使用的标准思想是用以下形式的三元组来呈现两个模型（查询、相关文档、不相关文档）。教师模型用于计算分数差，即score(query, relevant document) − score(query irrelevant document)，而我们训练学生模型使用 MSE 重现这个分数差，以惩罚它所犯的错误。

让我们思考一下这个过程的作用，因为它激发了我们希望讨论的训练细节。如果我们回想起使用SPLADE架构时，查询和文档之间的交互是通过两个稀疏向量的点积来计算的，每个向量对每个词都有一个非负的权重，那么我们可以把这个操作理解为想要增加查询和更高分文档权重向量之间的相似度。这并不是100%准确的，但也不会误导，可以把它想象成类似于在两个文档权重向量张成的平面上“旋转”查询，使其靠近更相关的文档。经过多个批次，这个过程逐渐调整权重向量的初始位置，使得查询和文档之间的距离能够捕捉到教师模型提供的相关性得分。

这就引出了一个关于复现教师得分可行性的观察。在正常的蒸馏中，我们知道只要学生有足够的容量，就能够将训练损失降到零。但是对于交叉编码器的蒸馏，情况并非如此，因为学生的得分受到由点积在权重向量上诱导的度量空间的性质的限制。而交叉编码器没有这样的限制。很有可能对于特定的训练查询q1和q2以及文档d1和d2，我们必须同时安排q1与d1和d2接近，而q2与d1接近但与d2远离。这并不一定是可能的，而且由于我们惩罚了得分的均方误差，一个效果是根据我们能够达到的最小间隔，对与这些查询和文档相关的训练三元组进行任意的重新加权。

在训练模型的过程中，我们有一个观察是教师并不是无懈可击的。我们最初是通过手动检查被分配了异常低分数的查询-相关文档对来发现这一点。在这个过程中，我们发现了客观上评分错误的查询-文档对。除了在评分过程中进行手动干预之外，我们还决定探索引入一个更好的教师。 根据文献，我们使用SBERT 系列的MiniLM L-6作为我们的初始老师。虽然这显示了在多种环境下的强劲表现，但根据他们的排名质量，有更好的教师。一个例子是基于大型生成模型的排名器：monot5 3b。下图中，我们比较了这两个模型的查询-文档得分对分布。monot5 3b 分布显然不太均匀，我们发现当我们尝试使用原始分数训练学生模型时，性能饱和度明显低于使用 MiniLM L-6 作为老师的情况。和以前一样，我们假设这归因于在零附近峰值中的许多重要分数差异，训练担心而不是与长下尾相关的无法解决的问题而迷失。

根据文献，我们最初使用了SBERT家族中的MiniLM L-6作为我们的教师。虽然它在多种情况中表现出强大的性能，但是基于排名质量，我们还是能找到更好的教师模型。一个例子是基于ranker的大型生成式模型：monot5 3b。在下图中，我们比较了这两个模型的查询-文档得分对分布。monot5 3b的分布明显更不均匀，而且我们发现，当我们尝试使用MiniLM L-6的原始分数来训练我们的学生模型时，其性能饱和度明显低于以 MiniLM L-6 为教师的模型。和以前一样，我们推测这是由于零点附近峰值的许多重要分数差异在训练中丢失了，而担心与较长的低尾相关的无法解决的问题。

对于来自 NQ 数据集的查询文档对的随机样本，Monot5 3b 和 MiniLM L-6 分数分布在匹配范围内。注意：X 轴不显示任一模型返回的实际分数

很明显，所有排名者在其分数的单调变换方面都具有相同的质量。具体来说，只要f是单调递增函数，无论我们使用Score(query, document) 还是 f(score(query, document)) 都没有关系；任何排名质量衡量标准都是相同的。然而，并非所有此类函数都是等效的教师函数。我们利用这一事实平滑了 monot5 3b 分数的分布，我们的学生模型突然训练有素，并开始击败之前的最佳模型。最后，我们使用了两位教师的加权合集。

在结束本节之前，我们想简单提一下 FLOPS 正则化器。这是改进的 SPLADE v2 训练过程的关键要素。。它是这篇论文中提出的一种用于惩罚与倒排索引检索计算成本直接相关的指标的方法。特别是，它鼓励根据对倒排索引检索成本的影响，从查询和文档表示中删除那些提供很少排名信息的 token。我们有三个观察结果：

1. 我们的第一个观察结果是，绝大多数 token 实际上都是在正则化器仍在预热时被丢弃的。在我们的训练配方中，正则器在前 50,000 个批次中使用二次预热。这意味着在最初的 10,000 个批次中，正则化器的作用不超过其最终值的 1/25 倍。事实上，我们可以看到，此时分数边际 MSE 对损失的贡献要比正则化损失大几个数量级。不过，在此期间，由训练数据激活的每批查询和文档 token 数分别从平均约 4k 和 14k 下降到约 50 和 300。事实上，99% 的 token 修剪都发生在这一阶段，而且似乎主要是为了删除实际上会损害排名性能的 token。 
2. 我们的第二个观察结果是，我们发现它有助于检索模型的泛化性能。减少正则化的数量并替换导致更多稀疏性的正则化器（例如绝对权重值的总和），都会降低我们基准测试的平均排名性能。 
3. 我们的最终观察结果是，较大批次和多样化批次都会对检索质量产生积极影响；我们尝试将查询聚类与批内否定进行对比。

既然它的主要目的是优化检索成本，那么为什么会这样呢？FLOPS 正则化器定义如下：它首先对所有查询中的每个 token 的权重进行平均，并分别对其包含的文档进行平均，然后将这些平均权重的平方相加。如果我们认为该批次通常包含一组不同的查询和文档，那么这就像一种惩罚，鼓励类似的措施停止单词删除。针对许多不同查询和文档出现的 token 将主导损失，因为很少激活的 token 的贡献除以批量大小的平方。我们假设这实际上有助于模型找到更好的检索表示。从这个角度来看，正则项只能观察批次中查询和文档的 token 权重，这一事实是不可取的。这是我们想重新审视的一个领域。 

结论

我们简要概述了模型选择、其基本原理以及我们在新的text_expansion查询的技术预览中发布的功能背后的训练过程的某些方面，以及与新的 text_expansion 查询的集成Elasticsearch 相关性引擎。迄今为止，我们专注于零样本设置中的检索质量，并在各种强大的基线上展示了良好的结果。随着我们向 GA 迈进，我们计划在该模型的实施方面做更多的工作，特别是围绕提高推理和检索性能。 

请继续关注本系列的下一篇博客文章，我们将在继续探索使用 Elasticsearch 的令人兴奋的新检索方法的同时，研究使用混合检索来组合各种检索方法。