教你评估搜索相关性(第1部分)

2024-07-31 07:42:11 浏览数 (1)

评估搜索相关性 - 第1部分

这是一个系列博客的第一篇，讨论如何在更好地理解 BEIR 基准的背景下评估自己的搜索系统。我们将介绍一些具体的技巧和方法，以改善您的搜索评估过程，并介绍一些常见的问题，这些问题会使评估变得不那么可靠。最后，我们指出 LLMs 提供了一个强大的新工具，可以帮助搜索工程师评估搜索效果，并通过示例展示如何使用它们来帮助评估搜索。

引言

要改进任何系统，您需要能够衡量其表现。在搜索领域，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 到 TREC-COVID 的 493.5 不等，但大多数情况下小于 5。
  • 一些数据集在语料库中存在重复的文档，这在某些情况下可能会导致错误的评估。例如，在 ArguAna 中，我们发现了 96 对重复文档对，每对中只有一个文档被标记为与查询相关。通过“扩展”初始 qrels 列表以包括重复项，我们观察到 nDCG@10 分数平均相对提高了约 1%。
代码语言：javascript复制
{
  "_id": "test-economy-epiasghbf-pro02b",
  "title": "economic policy international africa society gender house believes feminisation",
  "text": "Again employment needs to be contextualised with …",
  "metadata": {}
}
{
  "_id": "test-society-epiasghbf-pro02b",
  "title": "economic policy international africa society gender house believes feminisation",
  "text": "Again employment needs to be contextualised with …",
  "metadata": {}
}

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

在比较 MTEB 排行榜上的模型时，专注于平均检索质量是很诱人的。这是衡量模型整体质量的一个很好的代理，但它并不一定能告诉您它对您的特定任务的表现。由于结果是按数据集报告的，值得理解不同数据集与您的搜索任务的相关性，并仅使用最相关的数据集对模型进行重新评分。如果您想深入了解，还可以检查各种数据集语料库的主题重叠。按主题分层的质量度量可以更精细地评估它们的具体优劣。

这里需要注意的一点是，当文档未在 qrels 文件中标记时，默认情况下它被认为与查询无关。我们深入探讨这一领域，收集一些证据，以便更好地了解以下问题：“评估者多频繁地遇到没有真实信息的（查询，文档）对？”。这是重要的，因为当只有浅层标记可用（因此并非所有相关文档都被标记为相关）时，一个信息检索系统可能仅因为它“选择”展示了不同的相关（但未标记的）文档，而被评判为比另一个系统差。这是在创建高质量评估集时的一个常见问题，尤其是对于大型数据集。为了实际可行，手动标记通常会集中在当前系统返回的顶部结果，因此可能会错过其盲点中的相关文档。因此，通常更倾向于将更多资源集中在对较少查询进行更全面的标记，而不是广泛的浅层标记。

为了开始我们的分析，我们实现了以下场景（请参见笔记本）：

  1. 首先，我们将每个数据集的语料库加载到 Elasticsearch 索引中。
  2. 对于测试集中的每个查询，我们使用 BM25 检索前 100 个文档。
  3. 使用各种最先进的重排序模型对检索到的文档进行重新排序。
  4. 最后，我们报告从步骤 2（检索后）和步骤 3（重新排序后）得到的前 10 个文档的“判决率”。换句话说，我们计算在 qrels 文件中有分数的前 10 个文档的平均百分比。

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

  • Cohere's 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 (avg.)

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 个查询以及 Cohere v2 重新排序后未标记为相关的前 5 个文档。我们采用了两种不同的评估路径：首先，我们使用一个精心调优的提示（在稍后的文章中详细介绍）来引导最近发布的 Phi-3-mini-4k 模型预测文档与查询的相关性。同时，这些案例也被手动标记，以评估 LLM 输出与人工判断的一致性。总体而言，我们可以得出以下两个结论：

  • LLM 响应与人工判断的一致率略高于 80%，作为一个起点，这似乎足够好了。
  • 在 54.5% 的情况下（基于人工判断），返回的文档实际上被发现与查询相关。换句话说：对于 100 个查询，我们有 107 个被判定为相关的文档，但至少还有 0.545 x 5 x 100 = 273 个实际上相关的额外文档！

以下是一些来自 MSMARCO/dev 数据集的示例，其中包含查询、标注的正向文档（来自 qrels）和由于标记不完全而导致的误判负向文档：

示例1：

代码语言：javascript复制
{
  "query":
    {
        "_id": 155234,
        "text": "do bigger tires affect gas mileage"
    },
  "positive_doc":
    {
        "_id": 502713,
        "text": "Tire Width versus Gas Mileage. Tire width is one of the only tire size factors that can influence gas mileage in a positive way. For example, a narrow tire will have less wind resistance, rolling resistance, and weight; thus increasing gas mileage.",
    },
    "negative_doc":
    {
        "_id": 7073658,
        "text": "Tire Size and Width Influences Gas Mileage. There are two things to consider when thinking about tires and their effect on gas mileage; one is wind resistance, and the other is rolling resistance. When a car is driving at higher speeds, it experiences higher wind resistance; this means lower fuel economy."
    }
}

示例2：

代码语言：javascript复制
{
  "query":
    {
        "_id": 300674,
        "text": "how many years did william bradford serve as governor of plymouth colony?"
    },
  "positive_doc":
    {
        "_id": 7067032,
        "text": "http://en.wikipedia.org/wiki/William_Bradford_(Plymouth_Colony_governor) William Bradford (c.1590 u00e2u0080u0093 1657) was an English Separatist leader in Leiden, Holland and in Plymouth Colony was a signatory to the Mayflower Compact. He served as Plymouth Colony Governor five times covering about thirty years between 1621 and 1657."
    },
    "negative_doc":
    {
        "_id": 2495763,
        "text": "William Bradford was the governor of Plymouth Colony for 30 years. The colony was founded by people called Puritans. They were some of the first people from England to settle in what is now the United States. Bradford helped make Plymouth the first lasting colony in New England."
    }
}

手动评估特定查询是一种通常有用的技术，用于理解搜索质量，补充如 nDCG@10 之类的定量度量。如果您有一组代表性查询，在进行搜索变化时总是运行这些查询，它可以为您提供关于性能变化的重要定性信息，这在统计数据中是不可见的。例如，它可以帮助您更深入了解搜索返回的错误结果：它可以帮助您发现检索结果中的明显错误、相关错误类别（如误解特定领域术语）等。

我们的结果与 MSMARCO 评估的相关研究一致。例如，Arabzadeh 等人 采用了类似的程序，他们雇用众包工人做偏好判断：他们展示了在许多情况下，重排序模块返回的文档比 MSMARCO qrels 文件中的文档更受欢迎。另一个证据来自 RocketQA 重排序器的作者，他们报告说，经过手动检查，发现超过 70% 的重排序文档是相关的。

主要收获及下一步

  • 对更好的地面真相的追求是永无止境的，因为它对于基准测试和模型比较非常关键。如果谨慎使用并通过适当的指令进行调优，LLMs 可以在一些评估领域提供帮助。
  • 总的来说，鉴于基准永远不会完美，可能更倾向于从纯分数比较转向捕获统计显著性差异的更稳健的技术。Arabzadeh 等人 的工作提供了一个很好的例子，他们根据自己的发现建立了 95% 的置信区间，表明各个运行之间存在显著（或不显著）差异。在随附的笔记本中，我们提供了使用bootstrapping实现的置信区间。
  • 从最终用户的角度来看，在阅读基准测试结果时考虑任务对齐是很有用的。例如，对于构建 RAG 管道并知道最典型的用例涉及从不同来源收集多条信息的 AI 工程师来说，评估其检索模型在多跳 QA 数据集（如 HotpotQA）上的性能会比评估整个 BEIR 基准测试的全局平均值更有意义

在下一篇博文中，我们将深入探讨使用 Phi-3 作为 LLM 评判员的过程以及对其进行调整以预测相关性的过程。

elasticsearch

0 人点赞