Elasticsearch：使用 Quepid 创建评估列表

Elastic 中国社区官方博客

于 2025-05-27 08:00:00 发布

阅读量1.3k

点赞数 39

分类专栏： Elasticsearch Elastic 文章标签： elasticsearch 大数据搜索引擎全文检索数据库

本文为博主原创文章，未经博主允许不得转载。

本文链接：https://blog.csdn.net/UbuntuTouch/article/details/148240947

版权

Elastic 同时被 2 个专栏收录

1872 篇文章

订阅专栏

Elasticsearch

1277 篇文章

订阅专栏

作者：来自 Elastic Daniel Wrigley

在 Quepid 中通过协作式人工评估流程创建评估列表。

Elasticsearch 配备了丰富的新功能，帮助你根据使用场景构建最佳搜索解决方案。浏览我们的示例笔记本以了解更多信息，开始免费云试用，或立即在本地机器上试用 Elastic。

创建判断列表（judgement lists）是在优化搜索结果质量方面至关重要的一步，但这可能是一个复杂而困难的任务。判断列表是一组经过精心整理的搜索查询及其对应结果的相关性评分，也被称为测试集合。使用这个列表计算的指标可以作为衡量搜索引擎性能的基准。为了简化判断列表的创建流程，OpenSource Connections 团队开发了 Quepid。判断可以是显式的，也可以基于用户的隐式反馈。本博客将指导你如何在 Quepid 中建立一个协作环境，从而有效地让人工评审进行显式判断，这是每个判断列表的基础。

Quepid 支持搜索团队进行搜索质量评估的整个过程：

构建查询集
创建判断列表
计算搜索质量指标
基于计算出的搜索质量指标比较不同的搜索算法/排序器

在我们的博客中，我们假设你正在运营一个在线电影租赁商店，并希望提升搜索结果的质量。

先决条件

本博客使用来自 es-tmdb 仓库的数据和映射。数据来源于 The Movie Database。要跟着操作，请创建一个名为 tmdb 的索引，应用映射并将数据写入索引。你可以在本地实例或 Elastic Cloud 部署中设置这个索引 —— 两者都可以正常使用。本文假设你使用的是 Elastic Cloud 部署。关于如何写入数据的说明，请参考 es-tmdb 仓库的 README 文件。

在 title 字段上对 rocky 做一个简单的 match 查询，以确认你已经成功写入了可搜索的数据：

GET tmdb/_search
{
 "query": {
   "match": {
     "title": "rocky"
   }
 }
}

你应该能看到 8 个结果：

{
 "took": 2,
 "timed_out": false,
 "_shards": {
   "total": 1,
   "successful": 1,
   "skipped": 0,
   "failed": 0
 },
 "hits": {
   "total": {
     "value": 8,
     "relation": "eq"
   }
…
}

登录 Quepid

Quepid 是一个工具，可以让用户评估搜索结果质量并运行离线实验来改进它。

你可以通过两种方式使用 Quepid：使用免费公开的托管版本（地址是 https://app.quepid.com），或者在你有权限的机器上自行搭建 Quepid。本篇文章假设你使用的是免费托管版本。如果你想在自己的环境中搭建 Quepid 实例，可以参考安装指南。

无论你选择哪种方式，如果你还没有账号，你都需要创建一个账号。

设置 Quepid Case

Quepid 是围绕 “Case” 组织的。一个 Case 会存储查询、相关性调优设置，以及与你的搜索引擎建立连接的方式。

对于首次使用的用户，选择 Create Your First Relevancy Case。
对于回访用户，可以从顶部菜单中选择 Relevancy Cases，然后点击 + Create a case。

为你的 case 取一个有描述性的名字，例如 “Movie Search Baseline”，因为我们希望开始衡量并改进我们的基线表现。

通过选择 Continue 来确认名称。

接下来，我们需要将 Quepid 与搜索引擎建立连接。Quepid 可以连接多种搜索引擎，包括 Elasticsearch。

配置方式取决于你所使用的 Elasticsearch 和 Quepid 的设置。若要将 Quepid 连接到 Elastic Cloud 部署，我们需要为 Elastic Cloud 启用并配置 CORS，并准备好一个 API 密钥。详细说明请参考Quepid 文档中的相关指南。

输入你的 Elasticsearch 端点信息（例如：https://YOUR_ES_HOST:PORT/tmdb/_search），并在高级配置选项中填写连接所需的其他信息（比如 Elastic Cloud 部署的 API 密钥），点击 ping it 测试连接，然后选择 Continue 进入下一步。

现在我们需要定义在该 Case 中要显示哪些字段。选择所有能帮助我们的人工评审员评估文档对查询是否相关的字段。

将 title 设置为 Title Field，保留 _id 作为 ID Field，并将 overview、tagline、cast、vote_average、thumb:poster_path 添加为 Additional Display Fields。最后一个字段会显示电影的小缩略图，有助于我们和人工评审员进行视觉识别。

点击 Continue 按钮确认显示设置。

最后一步是向该 Case 添加搜索查询。通过输入框逐个添加以下三个查询：star wars、harrison ford 和 best action movie，然后点击 Continue。

理想情况下，一个 Case 应包含能代表真实用户查询并展示不同类型查询的查询。现在我们可以将 star wars 想象为代表所有电影标题类查询的示例，harrison ford 代表演员名称类查询，best action movie 代表按特定类型搜索电影的查询。这通常被称为一个 查询集（query set）。

在生产环境中，我们会通过应用统计技术（如按概率比例抽样 Probability-Proportional-to-Size sampling）从事件跟踪数据中抽取查询样本，并将这些采样的查询导入 Quepid，以包含频率高（head）和频率低（tail）的查询。这意味着我们会偏向更常见的查询，但不会排除罕见的查询。

最后，点击 Finish，你将被跳转到该 Case 的界面，在那里你可以看到刚才定义的三个查询。

查询与信息需求

为了实现我们创建判断列表的总体目标，人工评分员需要针对一个给定的查询对搜索结果（通常是文档）进行判断。这被称为查询/文档对。

有时候，从查询本身看起来很容易理解用户想要什么。例如，查询 harrison ford 背后的意图是找到由演员 Harrison Ford 主演的电影。那么查询 action 呢？我可能会倾向于认为用户是想找属于动作片类型的电影。但是哪一种？最新的？最受欢迎的？根据用户评分最好的？还是用户其实想找所有片名叫做 “Action” 的电影？在 The Movie Database 中，至少有 12 部电影名为 “Action”，它们的片名主要区别在于标题中的感叹号数量。

当查询意图不明确时，不同的人工评分员可能会有不同的理解。这时候就需要引入信息需求：信息需求是对信息的有意识或无意识的渴望。定义信息需求可以帮助人工评分员对查询对应的文档进行判断，因此它在构建判断列表的过程中扮演着重要角色。专家用户或领域专家是定义信息需求的理想人选。按照用户的视角定义信息需求是一种良好的实践，因为搜索结果应当满足他们的需求。

我们 “Movies Search Baseline” 案例中各查询的信息需求如下：

star wars：用户想找到来自星球大战系列的电影或节目。关于星球大战的纪录片也可能相关。
harrison ford：用户想找到由演员 Harrison Ford 主演的电影。Harrison Ford 担任旁白等其他角色的电影也可能相关。
best action movie：用户想找到动作片，最好是用户评分较高的。

在 Quepid 中定义信息需求

要在 Quepid 中定义信息需求，请进入案例界面：

打开一个查询（例如 star wars），然后选择 Toggle Notes。
在第一个字段中输入信息需求，在第二个字段中输入任何附加备注：
点击 Save。

对于少量查询来说，这个流程没有问题。然而，当你将案例从 3 个查询扩展到 100 个查询时（Quepid 的案例通常在 50 到 100 个查询之间），你可能会希望在 Quepid 之外（例如在电子表格中）定义信息需求，然后通过 Import 功能上传并选择 Information Needs。

在 Quepid 创建团队并分享你的案例

协作判断能提升相关性评估的质量。设置团队步骤如下：

在顶级菜单中导航到 Teams。
点击 + Add New，输入团队名称（例如，“Search Relevance Raters”），然后点击 Create。
通过输入成员的电子邮件地址并点击 Add User 添加成员。
在案例界面，选择 Share Case。
选择合适的团队并确认。

创建判断列表册

Quepid 中的判断列表册允许多个评分员系统地评估查询/文档对。创建步骤：

在案例界面进入 Judgements，点击 + Create a Book。
配置判断列表册，填写描述性名称，分配给你的团队，选择评分方法（例如 DCG@10），并设置选择策略（单个或多个评分员）。判断列表册的设置如下：Name: “Movies Search 0-3 Scale”
Teams to Share this Book With: Check the box with the Team you created
Scorer: DCG@10
点击 Create Book.

名称具有描述性，包含了搜索内容（“Movies”）和判断的评分范围（“0-3”）。选定的评分器 DCG@10 定义了搜索指标的计算方式。“DCG” 是 Discounted Cumulative Gain（折扣累计增益）的缩写，“@10” 表示计算指标时考虑的前 10 个结果。

在本例中，我们使用的是一种衡量信息增益并结合位置权重的指标。可能还有其他更适合你用例的搜索指标，选择合适的指标本身就是一个挑战。

向判断列表册中添加查询/文档对

为了添加用于相关性评估的查询/文档对，按以下步骤操作：

在案例界面，导航到 “Judgements”：
选择你创建的判断列表册。
点击“Populate Book”，然后通过选择 “Refresh Query/Doc Pairs for Book” 确认。

此操作会基于每个查询的顶级搜索结果生成查询/文档对，供你的团队进行评估。

让你的人类评审团队进行判断

到目前为止，完成的步骤比较技术性和管理性。现在这些必要的准备工作完成了，我们可以让评审团队开始工作。本质上，评审的工作是为给定查询对特定文档的相关性进行评分。这个过程的结果就是包含所有查询-文档对相关性标签的判断列表。接下来，将更详细地说明这个过程和对应的界面。

人类评分界面概览

Quepid 的人类评分界面设计用于高效评估：

Query：显示搜索词。
Information Need：展示用户意图。
Scoring Guidelines：提供一致评估的说明。
Document Metadata：呈现文档相关细节。
Rating Buttons：允许评审使用相应的键盘快捷键进行判断。

使用人类评分界面

作为人类评审，我通过书籍概览访问界面：

进入案例界面，点击 Judgements。
点击 “More Judgements are Needed!”。系统会展示一个尚未评分且需要额外评分的查询/文档对。具体由判断列表的选择策略决定：

Single Rater:：每个查询/文档对一个评分。
Multiple Raters：每个查询/文档对最多三个评分。

评分查询/文档对

让我们通过几个例子来讲解。当你按照本指南操作时，可能会看到不同的电影，但评分原则是相同的。

第一个例子是针对查询 harrison ford 的电影 “Heroes”：

我们先看查询，然后是信息需求，最后根据给出的元数据判断这部电影。

这部电影是我们查询的相关结果，因为 Harrison Ford 在演员阵容中。主观上我们可能认为更近期的电影更相关，但这不属于我们的信息需求范围。所以我们将这条文档评为 “Perfect”，在我们的分级尺度中是 3。

下一个例子是针对查询 harrison ford 的电影 “Ford v Ferrari”：

按照同样的做法，我们通过查看查询、信息需求，然后判断文档的元数据与信息需求的匹配程度来评估这个查询/文档对。

这是一个较差的结果。可能因为我们的查询词之一 “ford” 出现在标题中，所以出现了这个结果。但 Harrison Ford 在这部电影中没有出演任何角色。所以我们将这条文档评为 “Poor”，在我们的分级尺度中是 0。

第三个例子是针对查询 best action movie 的电影 “Action Jackson”：

这看起来像是一部动作电影，所以信息需求至少部分满足。然而，平均评分是 5.4 分（满分 10 分）。这让这部电影可能不是我们收藏中最好的动作电影。作为评审，我会将这条文档评为“中等”，在我们的分级尺度中是 1。

这些例子说明了使用 Quepid 评估查询/文档对的过程，既是高层次的，也是一般性的。

最佳实践 — 人工评分员

这些例子可能让人觉得做出明确判断很简单。但建立一个可靠的人工评分程序并不容易。这是一个充满挑战的过程，容易影响数据质量：

人工评分员可能因重复任务而疲劳。
个人偏好可能影响判断。
各评分员的领域专业水平不同。
评分员常常同时承担多项任务。
文档的感知相关性可能与其对查询的真实相关性不符。

这些因素可能导致判断不一致、质量低下。但别担心，有经过验证的最佳实践能帮你减少这些问题，建立更稳健可靠的评估流程：

一致评估：按顺序审查查询、信息需求和文档元数据。
参考指南：使用评分指南保持一致。评分指南可包含何时给出哪个评分的示例，帮助理解评分过程。首次评分后与评分员沟通，了解难点和需额外支持的地方，是个好习惯。
利用选项：不确定时，可用 “I Will Judge Later” 或 “I Can’t Tell”，必要时说明原因。
适当休息：定期休息有助于保持评分质量。Quepid 会在评分员完成一批评分时弹出彩带，提醒休息。

遵循这些步骤，你可以在 Quepid 中建立结构化且协作的判断列表创建流程，提升搜索相关性优化的效果。

下一步

接下来怎么办？判断列表只是提升搜索结果质量的基础步骤之一。以下是下一步：

计算指标并开始实验

一旦判断列表可用，利用这些判断并计算搜索质量指标是自然的进展。Quepid 会在有判断数据时自动计算当前案例配置的指标。指标作为“ Scorers ”实现，如果支持的指标不包含你喜欢的，你也可以自己提供！

进入案例界面，导航到 Select Scorer，选择 DCG@10，然后点击 Select Scorer 确认。Quepid 会计算每个查询的 DCG@10 以及所有查询的平均值，以量化案例的搜索结果质量。

既然你的搜索结果质量已经量化，你可以开始进行首次实验。实验从生成假设开始。查看截图中的三个查询，经过一些评分后，很明显这三个查询在搜索质量指标上的表现差异很大：star wars 表现不错，harrison ford 表现一般，但最大潜力在 best action movie。

展开这个查询，我们可以看到它的结果，深入细节，探索为什么文档会匹配以及是什么影响了它们的得分：

点击 “Explain Query” 并进入 “Parsing” 标签页，我们看到该查询是一个 DisjunctionMaxxQuery，在 cast、overview 和 title 三个字段中搜索：

通常，作为搜索工程师，我们会了解一些搜索平台的领域细节。在这个例子中，我们可能知道有一个 genres 字段。让我们把它加到查询中，看看搜索质量是否得到提升。

我们使用在案例界面选择 Tune Relevance 时打开的 Query Sandbox。继续探索，添加你要搜索的 genres 字段：

{
  "query": {
    "multi_match": {
      "query": "#$query##",
      "type": "best_fields",
      "fields": [
        "title^10",
        "overview",
        "cast",
        "genres"
      ]
    }
  }
}

点击 Rerun My Searches! 并查看结果。结果有变化吗？不幸的是，没有。

现在我们有很多选项可以探索，基本上涵盖了 Elasticsearch 提供的所有查询选项：

我们可以增加 genres 字段的权重。
我们可以添加一个根据 vote average 提升文档权重的函数。
我们可以创建一个更复杂的查询，只有当 genres 匹配度高时才根据 vote average 提升文档权重。
…

在 Quepid 中拥有所有这些选项并进行探索的最大好处是，我们可以量化这些调整的效果，不仅针对我们想要改进的单个查询，还能覆盖案例中的所有查询。

这防止我们为了改善一个表现不佳的查询而牺牲其他查询的搜索结果质量。我们可以快速且低成本地迭代，验证假设的价值，没有任何风险，使离线实验成为所有搜索团队的基础能力。

测量评分者间一致性

即使有任务描述、信息需求和像 Quepid 提供的人类评分界面，评分人员之间也可能会产生分歧。

分歧本身并不是坏事，反而有助于发现你可能需要解决的问题。相关性本身具有主观性，查询可能存在歧义，数据也可能不完整或错误。Fleiss’ Kappa 是一种衡量评分者间一致性的统计方法，Quepid 中有一个示例笔记本可以使用。你可以在顶级导航中选择 Notebooks，然后在 examples 文件夹中找到名为 Fleiss Kappa.ipynb 的笔记本。