你可能会问，为什么要使用多图表呢？这是 Lucene 架构选择的副作用：不可变的段。与大多数建筑选择一样，有利也有弊。例如，我们最近对无服务器 Elasticsearch 进行了 GA。在这种情况下，我们从不可变分段中获得了非常显著的优势，包括高效的索引复制以及将索引和查询计算解耦并独立自动扩展的能力。对于矢量量化，分段合并让我们有机会更新参数，使其适应数据特征。按照这种思路，我们认为有机会测量数据特征和重新审视索引选择还有其他好处。

在这篇文章中，我们将讨论我们为大幅降低构建多个 HNSW 图形的开销，尤其是降低合并图形的成本所做的工作。

背景

为了保持可管理的分段数量，Lucene 会定期检查是否应该合并分段。这相当于检查当前分段数是否超过目标分段数，目标分段数由基本分段大小和合并策略决定。如果超过该计数，Lucene 会合并片段组，同时违反约束条件。这一过程在其他地方有详细描述。

Lucene 选择合并大小相似的数据段，因为这样可以实现写入放大的对数增长。就向量索引而言，写入放大是指向量插入图形的次数。Lucene 会尝试以大约 10 个为一组合并数据段。因此，向量插入图的次数大约为 {10}\left (\frac{n}{n_0} \right )次，其中是索引向量数，n 是预期的基本段向量数。由于写入量呈对数增长，即使是庞大的指数，写入放大率也只有个位数。不过，合并图形所花费的总时间与写入放大率成线性比例。

在合并 HNSW 图形时，我们已经进行了小幅优化：保留最大分段的图形，并将其他分段的向量插入其中。这就是上述 9/10 因素的原因。下面，我们将展示如何通过使用我们正在合并的所有图表中的信息来大幅提高性能。

HNSW 图表合并

此前，我们保留了最大的图形，并从其他图形中插入矢量，但忽略了包含这些矢量的图形。我们在下文中利用的关键见解是，我们丢弃的每个 HNSW 图形都包含了有关其所含向量的重要邻近性信息。我们希望利用这些信息来加快插入至少部分载体的速度。

我们重点讨论将较小的图插入较大的图 _l=(V _l, E _l)的问题，因为这是一个原子操作，我们可以用它来构建任何合并策略。

策略是找到的一个顶点子集，将其插入大图中。然后，我们利用这些顶点在小图中的连通性，加速插入剩余的顶点。在下文中，我们用和分别表示小图和大图中顶点的邻居。具体流程如下

MERGE-HNSW

Inputs and

1Find to insert into using COMPUTE-JOIN-SET 2Insert each vertex into 3for do 4 5 6FAST-SEARCH-LAYER 7SELECT-NEIGHBORS-HEURISTIC 8

我们使用下面讨论的程序来计算集合（第 1 行）。然后，我们使用标准的 HNSW 插入程序将中的每个顶点插入大图中（第 2 行）。对于我们尚未插入的每个顶点，我们都要找到已插入的邻接顶点及其在大图中的邻接顶点（第 4 行和第 5 行）。我们使用FAST-SEARCH-LAYER 程序（第 6 行）作为种子程序，从 HNSW论文（第 7 行）中找到SELECT-NEIGHBORS-HEURISTIC 的候选者。实际上，我们在INSERT 方法（论文中的算法 1）中替换了SEARCH-LAYER 来查找候选集，其他方面没有变化。最后，我们将刚刚插入的顶点添加到（第 8 行）。

很明显，要做到这一点，中的每个顶点都必须在至少有一个邻居。事实上，我们要求对于中的每个顶点，|J\capfor some M，即最大层连接性。我们观察到，在真实的 HNSW 图中，顶点度的分布相当广泛。下图显示了 Lucene HNSW 图表底层顶点度的典型累积密度函数。

我们探讨了的固定值以及使其成为顶点度函数的方法。第二种选择会带来更快的速度，而对图形质量的影响却很小，因此采用了以下方案

请注意，根据定义，|N_s| 等于小图中顶点的度数。下限为 2 意味着我们将插入每个度数小于 2 的顶点。

一个简单的计数论证表明，如果我们仔细选择 ，我们只需要在 中直接插入大约具体来说，如果我们将一条图边的一个末端顶点恰好插入到，我们就会给这条图边着色。那么我们知道，对于 中 至少有 个 邻居，我们至少需要给 条边着色。此外，我们预计

这里，_U（left[N_s(U)|\right]）是小图中的平均顶点度。对于每个顶点u\我们最多为 |N_s条边着色。因此，我们期望着色的边的总数最多为 |J|\_U\left[|N_s(U)|\right].我们希望通过仔细选择，使着色的边数接近这一数字，因此，为了覆盖所有顶点，J| 需要满足以下条件

这意味着 {1}{4}|V_s|=\frac{1}{5} |V_s|。

如果SEARCH-LAYER 的运行时间占主导地位，这表明我们可以将合并时间最多提高。考虑到写入放大率的对数增长，这意味着即使对于非常大的索引，我们的构建时间通常也只比构建一个图形多一倍。

这种策略的风险在于会破坏图形质量。我们最初尝试使用无操作程序FAST-SEARCH-LAYER 。我们发现这降低了图表质量，以至于影响了作为延迟函数的召回率，尤其是在合并到单个片段时。然后，我们通过对图形的有限搜索，探索了各种替代方案。最终，最有效的选择是最简单的。使用SEARCH-LAYER ，但ef_construction 要低。通过这种参数设置，我们能够获得质量极佳的图形，同时还能将合并时间平均缩短 30% 多一点。

计算连接集

寻找一个好的连接集可以表述为一个 HNSW 图覆盖问题。贪婪启发式是一种简单有效的近似最优图覆盖的启发式。我们采用的方法是按增益递减的顺序逐个选取顶点添加到。增益定义如下

这里，表示向量在中的邻域数，是指示函数。增益包括我们添加到的顶点计数的变化，即 \max，因为我们添加了一个覆盖范围较小的顶点，从而更接近我们的目标。下图展示了中心橙色顶点的增益计算。

我们为每个顶点 维护以下状态

1. 是否陈旧、

2. 其增益

3. 中相邻顶点的计数，用 表示、

4. 范围为 [0,1] 的随机数，用于打破平局。

计算连接集的伪代码如下。

COMPUTE-JOIN-SET

Inputs

1 2 3for do 4 5 6 7while do 8 maximum gain vertex in 9Remove the state for from 10if is not stale then 11 12 13for do 14mark as stale if 15mark neighbors of stale if 16 17else 18 19if then 20 21return

我们首先在第 1-5 行中初始化状态。

在主循环的每次迭代中，我们首先提取最大增益顶点（第 8 行），然后随机打破平局。在进行任何更改之前，我们需要检查顶点的增益是否过时。特别是，每次我们将一个顶点添加到，都会影响其他顶点的增益：

1. 由于它的所有邻居在中都多了一个邻居，因此它们的收益会发生变化（第 14 行）

2. 如果它的任何一个邻居现在被完全覆盖，其所有邻居的收益都会发生变化（第 14-16 行）

我们以一种懒散的方式重新计算增益，因此只有当我们想要将某个顶点插入，才会重新计算该顶点的增益（第 18-20 行）。由于增益只会减少，我们永远不会错过应该插入的顶点。

请注意，我们只需跟踪我们添加到的顶点的总增益，就能确定何时退出。此外，当 {exit} 时，至少有一个顶点的增益不为零，因此我们总能取得进展。

实施结果

我们在四个数据集上进行了实验，这四个数据集涵盖了我们支持的三种距离度量（欧氏、余弦和内积）：

1. quora-E5-small：522931 个文档，384 个维度，使用余弦相似性、

2. cohere-wikipedia-v2：1M 文档，768 维度，使用余弦相似性、

3. gist：100 万个文档、960 个维度并使用欧氏距离，以及

4. cohere-wikipedia-v3：100 万文档，1024 维度，使用最大内积。

对于每个数据集，我们都会评估两种量化水平：

1. int8 - 每个维度使用一个 1 字节的整数，而

2. BBQ - 每个维度使用一个比特。

最后，在每个实验中，我们在两个检索深度对搜索质量进行了评估，并在建立索引后和强制合并为单一片段后对搜索质量进行了检查。

总之，我们在索引和合并方面实现了持续的大幅提速，同时保持了图的质量，因此在所有情况下都能保持搜索性能。

实验 1：int8 量化

从基线到候选方案（建议的修改）的平均提速为

索引时间加速：1. 次

强制合并加速：1. 次

运行时间细分如下

为完整起见，确切时间为

索引

合并

数据集

底线

候选人

构建

候选人

quora-E5-small

112.41s

81.55s

113.81s

70.87s

wiki-cohere-v2

158.1s

122.95s

425.20s

239.28s

要领

141.82s

119.26s

536.07s

279.05s

wiki-cohere-v3

211.86s

168.22s

654.97s

414.12s

下面我们展示了候选方案（虚线）与基线在两种检索深度下的召回率与延迟对比图：多段索引的召回率@10 和召回率@100（我们的默认合并策略在索引所有矢量后的最终结果），以及强制合并为单段后的召回率与延迟对比图。曲线越高、越靠左越好，这意味着在较低的延迟条件下有更高的记忆率。

正如您所看到的，对于 Cohere v3 数据集来说，候选者的多分段指数更好，而对于所有其他数据集来说，候选者的多分段指数稍差，但几乎不相上下。合并为单一网段后，所有情况下的召回曲线几乎相同。

实验 2：烧烤量化

从基准线到候选方案的平均加速度为

索引时间加速：1. 次

强制合并加速：1. 次

运行时间细分如下

为完整起见，确切时间为

索引

合并

数据集

底线

候选人

构建

候选人

quora-E5-small

70.71s

58.25s

59.38s

40.15s

wiki-cohere-v2

203.08s

142.27s

107.27s

85.68s

要领

110.35s

105.52s

323.66s

202.2s

wiki-cohere-v3

313.43s

190.63s

165.98s

159.95s

对于多分段索引，候选者在几乎所有数据集上都更胜一筹，但 cohere v2 除外，基线略胜一筹。就单段指数而言，所有情况下的召回曲线几乎相同。

结论

本博客中讨论的算法将在即将发布的 Lucene 10.2 以及基于该算法的 Elasticsearch 版本中提供。用户将能利用这些新版本中改进的合并性能和缩短的索引构建时间。这一变更是我们为使 Lucene 和 Elasticsearch 在矢量和混合搜索方面快速高效而不断努力的一部分。

理解搜索相关性评估中的 BEIR 基准测试

要改进任何系统，您需要能够衡量其表现。在搜索领域，BEIR（或等效 MTEB 排行榜的检索部分）被认为是信息检索社区的“圣杯”，这并不令人意外。它是一个结构非常完善的基准测试，涵盖了不同任务的多样化数据集。更具体地说，它涵盖了以下领域：

• 参数检索 (ArguAna, Touche2020)

• 开放领域问答 (HotpotQA, Natural Questions, FiQA)

• 段落检索（MSMARCO）

• 重复问题检索（Quora，CQADupstack）

• 事实核查（FEVER, Climate-FEVER, Scifact）

• 生物医学信息检索（TREC-COVID、NFCorpus、BioASQ）

• 实体检索 (DBPedia)

• 引文预测 (SCIDOCS)

它提供了一个单一的统计信息 nDCG@10，用于衡量系统在其返回的顶部结果中，为每个任务样例匹配最相关文档的程度。对于人机交互的搜索系统来说，顶部结果的相关性至关重要。然而，评估搜索效果有很多细微差别，而单一的汇总统计数据无法涵盖这些差别。

BEIR 数据集的结构

每个基准测试包含三个组成部分：

• 要检索的语料库或文档

• 查询

• 查询的相关性判断（也称为 qrels）。

相关性判断以零或更高的分数表示。非零分数表示文档与查询有一定的相关性。

数据集

语料库大小

#测试集中的查询数量

#qrels 中正向标注的数量

#qrels 等于零

#语料库中的重复项数量

Arguana

8,674

1,406

1,406

0

96

Climate-FEVER

5,416,593

1,535

4,681

0

0

DBPedia

4,635,922

400

15,286

28,229

0

FEVER

5,416,568

6,666

7,937

0

0

FIQA-2018

57,638

648

1,706

0

0

HotpotQA

5,233,329

7,405

14,810

0

0

Natural Questions

2,681,468

3,452

4,021

0

16,781

NFCorpus

3,633

323

12,334

0

80

Quora

522,931

10,000

15,675

0

1,092

SCIDOCS

25,657

1,000

4,928

25,000

2

Scifact

5,183

300

339

0

0

Touche2020

382,545

49

932

1,982

5,357

TREC-COVID

171,332

50

24,763

41,663

0

MSMARCO

8,841,823

6,980

7,437

0

324

CQADupstack (sum)

457,199

13,145

23,703

0

0

表 1：数据集统计信息。这些数字是在数据集的测试部分计算得出的（MSMARCO 的 dev）。

表 1 列出了构成 BEIR 基准的数据集的一些统计数据，如语料库中的文档数量、测试数据集中的查询数量以及 qrels 文件中的正/负（查询、文档）对数量。通过快速查看数据，我们可以立即推断出以下几点：

• 大多数数据集在 qrels 文件中不包含任何负面关系，即零分，这会明确地将文档标记为与给定查询无关。

• 每个查询的平均文档关联数（#qrels/#queries）从 ArguAna 的 1.0 到 493.5（TREC-COVID）不等，但大多数情况下的值为 < 5。

• 一些数据集的语料库中存在重复文档，在某些情况下可能导致评估不准确，例如，当一个文档被认为与查询相关但其重复文档却不相关时。例如，在 ArguAna 中，我们识别出 96 个重复文档对案例，每对中只有一个文档被标记为与查询相关。通过将初始 qrels 列表“扩展”以包含重复文档，我们观察到 nDCG@10 分数平均相对提高了约 1%。

ArguAna 中的重复对示例。在 qrels 文件中，只有第一个文档显示为与查询（“test-economy-epiasghbf-pro02a”）相关（作为反方论点）

在 MTEB 排行榜上比较模型时，人们很容易将重点放在平均检索质量上。这虽然是模型整体质量的一个良好代理指标，但并不一定能说明它在您特定场景下的表现。由于结果按数据集报告，因此值得了解不同数据集与您的搜索任务的关联程度，并仅使用最相关的数据集重新评估模型。如果您想深入研究，还可以检查各数据语料库的主题重叠情况。按主题对质量指标进行分层，可以更精细地评估模型的具体优势与劣势。

这里需要特别注意，当文档未在 qrels 文件中标注时，默认情况下它被视为与查询不相关。我们对此领域进行了更深入的探究，并收集了一些证据，以更清晰地阐明以下问题：“评估者面对没有真实标注信息的（查询，文档）对的频率有多高？”。这一点之所以重要，是因为当只有浅层标注可用时（即并非每个相关文档都被标记），一个信息检索系统可能仅仅因为它“选择”呈现了不同的相关（但未标记）文档，而被判定为比另一个系统更差。这是创建高质量评估集时的常见陷阱，尤其是对于大型数据集。为了可行，人工标注通常会关注当前系统返回的顶部结果，因此可能会遗漏其盲区中的相关文档。因此，通常更可取的做法是将更多资源集中在少数查询的更完整标注上，而不是广泛的浅层标注。

利用 BEIR 基准测试进行搜索相关性评估

为了启动分析，我们实施了以下场景（见笔记本）：

1. 首先，我们将每个数据集的语料库加载到 Elasticsearch 索引中。

2. 对于测试集中的每个查询，我们使用 BM25 检索前 100 个文档。

3. 我们使用多种 SOTA 重排序模型对检索到的文档进行重新排序。

4. 最后，我们报告第 2 步（检索后）和第 3 步（重新排序后）得出的前 10 名文档的 "评判率"。换句话说，我们计算的是 qrels 文件中得分排名前 10 的文档的平均百分比。

我们使用的模型重新排序列表如下：

• Cohere 的 rerank-english-v2.0 和 rerank-english-v3.0

• BGE-base

• mxbai-rerank-xsmall-v1

• MiniLM-L-6-v2

检索

重排序

数据集

BM25（%）

Cohere Rerank v2 (%)

Cohere Rerank v3 (%)

BGE-base (%)

mxbai-rerank-xsmall-v1 (%)

MiniLM-L-6-v2 (%)

Arguana

7.54

4.87

7.87

4.52

4.53

6.84

Climate-FEVER

5.75

6.24

8.15

9.36

7.79

7.58

DBPedia

61.18

60.78

64.15

63.9

63.5

67.62

FEVER

8.89

9.97

10.08

10.19

9.88

9.88

FiQa-2018

7.02

11.02

10.77

8.43

9.1

9.44

HotpotQA

12.59

14.5

14.76

15.1

14.02

14.42

Natural Questions

5.94

8.84

8.71

8.37

8.14

8.34

NFCorpus

31.67

32.9

33.91

30.63

32.77

32.45

Quora

12.2

10.46

13.04

11.26

12.58

12.78

SCIDOCS

8.62

9.41

9.71

8.04

8.79

8.52

Scifact

9.07

9.57

9.77

9.3

9.1

9.17

Touche2020

38.78

30.41

32.24

33.06

37.96

33.67

TREC-COVID

92.4

98.4

98.2

93.8

99.6

97.4

MSMARCO

3.97

6.00

6.03

6.07

5.47

6.11

CQADupstack（平均）

5.47

6.32

6.87

5.89

6.22

6.16

表 2：在检索/重新排序的前 10 个文档上计算的（数据集、重排序器）对的评判率

从 表 2 可以看出，除了 TREC-COVID（覆盖率>90%）、DBPedia（~65%）、Touche2020 和 nfcorpus（~35%）之外，大多数数据集在检索或重新排序后的标注率介于 5% 到略高于 10% 之间。这并不意味着所有这些未标注文档都是相关的，但其中可能有一个子集——特别是那些排在靠前位置的——可能是正例。

随着通用指令调优语言模型的出现，我们拥有了一种新的强大工具，它有可能自动化判断相关性。这些方法的计算成本通常太高，不适合在线搜索，但我们这里关注的是离线评估。在下文中，我们将使用它们来探究一些 BEIR 数据集可能存在浅层标注问题的证据。

为了进一步验证这一假设，我们决定专注于 MSMARCO 数据集，选择 100 个查询及其前 5 个经重排序（使用 Cohere v2）且当前未被标记为相关的文档。我们遵循了两种不同的评估路径：首先，我们使用精心调优的提示（后续文章中将详述）引导最近发布的 Phi-3-mini-4k 模型来预测文档与查询的相关性（或不相关性）。与此同时，这些案例也进行了人工标注，以评估 LLM 输出与人工判断之间的一致性率。总体而言，我们可以得出以下两个结论：

• LLM 响应与人工标注之间的一致性率接近 80%，作为该方向的起点，这似乎足够好。

• 在 57.6% 的情况下（基于人工判断），返回的文档被判定为实际上与查询相关。换一种说法：对于 100 个查询，我们有 107 个文档被判定为相关，但至少还有 0.576 × 5 × 100 = 288 个额外文档实际上是相关的！

以下是一些从 MSMARCO/dev 数据集中提取的示例，其中包含查询、注释的正例文档（来自 qrels）一个由于标注不全导致的假负例文档：

示例 1：

示例 2：

人工评估此类特定查询，是理解搜索质量的一种普遍有用的技术，它是对 nDCG@10 等定量指标的补充。如果您有一组代表性的查询集，在每次修改搜索时都运行它们，这将为您提供关于性能如何变化的重要定性信息，而这些信息在统计数据中是看不见的。例如，它为您提供了更多关于搜索返回的错误结果的见解：它可以帮助您发现检索结果中的明显错误，相关错误类别，如误解特定领域术语等等。

我们的结果与围绕 MSMARCO 评估的相关研究一致。例如，Arabzadeh 等人 遵循类似的流程，他们雇用众包工人进行偏好判断：除其他发现外，他们表明在许多情况下，重新排序模块返回的文档比 MSMARCO qrels 文件中的文档更受青睐。另一项证据来自 RocketQA 重新排序器的作者，他们报告称，经过人工检查，超过 70% 的重排序文档被判定为相关。

更新 - 2023 年 9 月 9 日：在对数据集进行仔细重新评估后，我们识别出另外 15 个相关文档案例，使其总数从 273 个增加到 288 个。

主要要点和后续步骤

• 对更高质量真实标注的追求永无止境，因为它对于基准测试和模型比较至关重要。如果谨慎使用并配以适当的指令调优，LLM 可以在某些评估领域提供协助

• 更普遍地说，鉴于基准测试永远不会完美，从单纯的分数比较转向捕捉统计显著性差异的更稳健技术可能更可取。Arabzadeh 等人等人的工作提供了一个很好的例子，他们基于研究结果构建了 95% 置信区间，以表明不同运行之间是否存在显著（或不显著）差异。在随附的笔记本中，我们提供了使用自助法实现置信区间的方法。

• 从最终用户的角度来看，在阅读基准测试结果时，考虑任务对齐性是有益的。例如，对于构建 RAG 管道的 AI 工程师来说，如果知道最典型的用例涉及从不同来源汇集多条信息，那么在 HotpotQA 等多跳问答数据集上评估其检索模型的性能，会比在整个 BEIR 基准测试的全局平均分更有意义

在下一篇博客文章中，我们将更深入地探讨如何使用 Phi-3 作为 LLM 评判工具，以及调优它以预测相关性的过程。