作者：来自 Elastic Thanos Papaoikonomou, Thomas Veasey
这是一系列博客文章中的第一篇，讨论如何在更好地理解 BEIR 基准的背景下考虑评估你自己的搜索系统。我们将介绍具体的技巧和技术，以便在更好地理解 BEIR 的背景下改进你的搜索评估流程。我们还将介绍导致评估可靠性降低的常见陷阱。最后，我们注意到 LLM 为搜索工程师提供了一个强大的新工具，我们将通过示例展示如何使用它们来帮助评估搜索。
介绍
要改进任何系统，你需要能够衡量其运行情况。在搜索环境中，BEIR（Benchmarking-InformationRetrieval - 或相当于 MTEB 排行榜的检索部分）被认为是信息检索社区的 “holy grail - 圣杯”，这一点并不奇怪。这是一个结构良好的基准，包含不同任务的各种数据集。更具体地说，涵盖以下领域：
- 论证检索（ArguAna、Touche2020）
- 开放域问答（HotpotQA、Natural Questions、FiQA）
- 段落检索（MSMARCO）
- 重复问题检索（Quora、CQADupstack）
- 事实核查（FEVER、Climate-FEVER、Scifact）
- 生物医学信息检索（TREC-COVID、NFCorpus、BioASQ）
- 实体检索（DBPedia）
- 引文预测（SCIDOCS）
它提供了一个单一统计数据 nDCG@10，该统计数据与系统在返回的顶级结果中与每个任务示例最相关的文档的匹配程度有关。对于搜索系统来说，人类与顶级结果（top results）的相关性互动至关重要。然而，评估搜索有许多细微差别，而单一的汇总统计数据会忽略这些细微差别。
BEIR 数据集的结构
每个基准都有三个工件：
- 要检索的语料库或文档
- 查询
- 查询的相关性判断（又名 qrels）。
相关性判断以零或更大的分数提供。非零分数表示文档与查询有某种关联。
| Dataset | Corpus size | #Queries in the test set | #qrels positively labeled | #qrels equal to zero | #duplicates in the corpus |
|---|---|---|---|---|---|
| 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 |
表 1 列出了构成 BEIR 基准的数据集的一些统计数据，例如语料库中的文档数量、测试数据集中的查询数量以及 qrels 文件中的正/负（查询、文档）对数量。快速浏览数据后，我们可以立即推断出以下内容：
- 大多数数据集在 qrels 文件中不包含任何负面关系，即零分数，这明确表示文档与给定查询无关。
- 每个查询的平均文档关系数（#qrels/#queries）从 ArguAna 的 1.0 到 TREC-COVID 的 493.5 不等，但大多数情况下的值小于 5。
- 一些数据集的语料库中存在重复文档，在某些情况下可能会导致错误的评估，即当文档被认为与查询相关但其重复项不相关时。例如，在 ArguAna 中，我们已识别出 96 个重复文档对案例，其中每个文档对只有一个文档被标记为与查询相关。通过 “expanding - 扩展” 初始 qrels 列表以包括重复项，我们观察到 nDCG@10 得分平均相对增加约 1%。
{
"_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 文件中标记，则默认情况下它被视为与查询无关。我们深入研究这个领域，并收集一些证据来进一步阐明以下问题：“How often is an evaluator presented with (query, document) pairs for which there is no ground truth information? - 评估者多久会遇到一次没有基本事实信息的（查询、文档）对？”。这很重要的原因是，当只有浅层标记可用时（因此并非每个相关文档都标记为浅层标记），一个信息检索系统可能会被判定为比另一个更差，因为它 “选择” 显示不同的相关（但未标记）文档。这是创建高质量评估集时常见的问题，尤其是对于大型数据集。为了切实可行，手动标记通常侧重于当前系统返回的最佳结果，因此可能会错过盲点中的相关文档。因此，通常最好将更多资源集中在更少查询的更完整标记上，而不是广泛的浅层标记。
为了开始我们的分析，我们实施以下场景（参见 notebook）：
- 首先，我们将每个数据集的语料库加载到 Elasticsearch 索引中。
- 对于测试集中的每个查询，我们使用 BM25 检索前 100 个文档。
- 我们使用各种 SOTA 重新排序模型对检索到的文档进行重新排序。
- 最后，我们报告来自步骤 2（检索后）和步骤 3（重新排序后）的前 10 个文档的 “判断率”。换句话说，我们计算 qrels 文件中具有分数的前 10 个文档的平均百分比。
我们使用的重新排序模型列表如下：
- Cohere's
rerank-english-v2.0andrerank-english-v3.0 - BGE-base
- mxbai-rerank-xsmall-v1
- MiniLM-L-6-v2
| Retrieval | Reranking | |||||
|---|---|---|---|---|---|---|
| Dataset | 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 |
从表 2 中，除了 TREC-COVID（覆盖率 > 90%）、DBPedia（~65%）、Touche2020 和 nfcorpus（~35%）之外，我们发现大多数数据集在检索或重新排序后的标记率在 5% 到 10% 多一点之间。这并不意味着所有这些未标记的文档都是相关的，但其中可能有一个子集（尤其是那些位于顶部位置的文档）可能是正面的。
随着通用指令调整语言模型的出现，我们有了一个强大的新工具，可以自动判断相关性。这些方法通常计算成本太高，无法在线用于搜索，但在这里我们关注的是离线评估。在下文中，我们将使用它们来探索一些 BEIR 数据集存在浅层标记的证据。
为了进一步研究这一假设，我们决定专注于 MSMARCO，并选择 100 个查询的子集以及当前未标记为相关的前 5 个重新排序的文档（使用 Cohere v2）。我们遵循了两种不同的评估路径：首先，我们使用精心调整的提示（稍后将详细介绍）来启动最近发布的 Phi-3-mini-4k 模型，以预测文档与查询的相关性（或不相关性）。同时，这些案例也被手动标记，以便评估 LLM 输出和人类判断之间的一致率。总体而言，我们可以得出以下两个结论：
- LLM 响应和人类判断之间的一致率略高于 80%，这似乎足以作为该方向的起点。
- 在 54.5% 的案例中（基于人类判断），返回的文档被发现与查询实际上相关。换一种说法：对于 100 个查询，我们有 107 个文档被判定为相关，但至少有 0.545 x 5 x 100 = 273 个额外的文档实际上是相关的！
以下是从 MSMARCO/dev 数据集中提取的一些示例，其中包含查询、带注释的真（positive）文档（来自 qrels）和由于标记不完整而导致的假（negative）文档：
示例 1：
{
"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：
{
"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 \u00e2\u0080\u0093 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% 的置信区间，表明各个运行之间存在显着（或不显着）差异。在随附的 notebook 中，我们使用引导程序提供了置信区间的实现。
- 从最终用户的角度来看，在阅读基准测试结果时考虑任务对齐很有用。例如，对于构建 RAG 管道并知道最典型的用例涉及从不同来源收集多条信息的 AI 工程师来说，评估其检索模型在 multi-hop QA 数据集（如 HotpotQA）上的性能比评估整个 BEIR 基准的全局平均值更有意义
在下一篇博文中，我们将深入探讨使用 Phi-3 作为 LLM 评判员以及对其进行调整以预测相关性的过程。
准备好自己尝试了吗？开始免费试用。
希望将 RAG 构建到你的应用程序中？想要使用矢量数据库尝试不同的 LLM？
在 Github 上查看我们针对 LangChain、Cohere 等的示例笔记本，并立即加入 Elasticsearch Relevance Engine 培训。
原文：Elasticsearch search relevance: Evaluating using the BEIR benchmark — Search Labs
