本文将介绍如何使用最低得分参数来提高语义搜索结果的精确度。如想测试本博客文章中提供的示例，请访问 相关 Jupyter 笔记本。

背景：精确率和召回率

在搜索相关性中，精确率和召回率是关键概念。强烈建议尚不熟悉这些内容的读者查阅相关资料。以下是摘要。

• 精确率：返回的搜索结果中与用户相关的比例。

• 召回率：搜索结果集中包含的语料库中所有相关文档的百分比。

或者换句话说，精确率只返回相关结果，而召回率则返回所有相关结果。可以想象，这些需求经常相互冲突。语义搜索往往具有很高的召回率，但在精确率方面可能会不理想。继续阅读，了解如何避免这种情况。

推出最低得分参数

min_score参数通过设定最低得分阈值提升检索精度，系统将自动过滤得分低于该阈值的匹配结果，从而精简结果集。以下是一个简单的示例：

得分归一化

设置最低得分阈值固然可行，但并非所有语义模型都能返回适用于静态阈值的分值。以 ELSER 为例，它所返回的分值是无界得分。有些密集模型得分是密集聚类的，只有在特定查询的背景下才有意义。

对于大多数语义搜索情况，我们建议在应用“min_score”之前使用归一化方法。归一化确保文档得分在规定区间内。Elasticsearch 检索器提供了两种此类归一化器，即“l2_norm”和“minmax”。最常用的是“minmax”，因为它简单易懂，在很多情况下都很有效。“minmax”的主要属性包括：

• 文档分数分布在 0 到 1 之间。

• 得分最高的文件总是记为 1 分。

• 得分最低的文件总是记为 0 分。

  • 这可能会使其不太适合关键字搜索。更多讨论请参见“混合搜索”部分。

以下是一个包含min_score规范化语义查询的示例。排名窗口参数已增加到 500，使系统能够返回从第 100 条开始的更长结果列表。

当前参数已设置为高于生产环境的常规值，以便我们全面检验搜索结果质量并针对性优化输出。

使用线性检索器的混合搜索

对于混合搜索，最简单的方法是归一化所有分数，分配权重，并应用最低得分。请注意，通过选择总和为 1 的权重，可以将总分控制在 0-1 的范围内。这样使得最终得分易于解读，且便于调整 min_score。以下是一个示例：

使用 RRF 的混合搜索

使用 BM25 时，我们通常通过其他方式控制精度，例如使用AND 操作符或minimum_should_match 。此外，由单个、精确和罕见术语组成的查询自然会导致搜索结果较少，而且往往都是高度相关的结果。这就可能导致：

• 在 BM25 检索器中，排名靠后的结果即使绝对 BM25 分值接近头部结果，仍会被赋予较低的归一化分数。

• 将极低的 BM25 分值与语义分值相加，总分即可近似为语义分值。

• 缺少 BM25 分值参考可能导致 min_score threshold 丢弃该文档。

作为解决方案，我们可以改用倒数排序融合 (RRF) 来结合 BM25 和语义结果。该方法通过关注各结果集中的文档位置而非原始分值，巧妙规避了不同检索算法评分体系难以直接比较的技术难题。在这种情况下，min_score 仅应用于语义检索器。

结论

通过采用 min_score，我们已验证可有效降低语义检索算法因高召回率导致的结果集中误报数量。要了解有关检索器的更多信息，请参阅本博文和Elasticsearch 文档。

然而，当你解决这一问题时，却可能因无法手动测试所有情况而不经意间破坏其他查询的功能。但你或你的 QA 团队该如何测试，以确认某一项查询的改动是否会对其他查询产生连锁反应呢？或者更关键的是，你们要如何确保所作的改动确实优化了某项查询呢？

转向系统性评估

这个时候，判断列表就可以派上用场。与其在每次更改时依赖手动和主观测试，不如定义一组与业务案例相关的固定查询及其相关结果。

这一组（测试用例或数据）将成为基准参照。每次实施改动时，你都用它来评估搜索效果是否确实得到了提升。

这种方法的价值在于：

• 消除不确定性：无需再费心猜测所做的更改是否会影响其他查询；数据会直接告诉你答案。

• 停止人工测试：一旦判定集被记录下来，测试便会自动执行。

• 佐证更改：你可以展示出明确的指标，以佐证某项更改所带来的益处。

如何开始建立判断列表

最简单的开始方式之一是获取具有代表性的查询，并手动选择相关文件。有两种方法可以列出此列表：

• 二元判断：与查询关联的每一份文档都会被赋予一个简单标签：相关（通常标注分数为“1”）和不相关（标注分数为“0”）。

• 分级判断：在此情境下，每份文档会依据不同等级获得相应分数。例如：采用 0 至 4 分的评分量表，类似于李克特量表，其中 0 分表示“完全不相关”，4 分表示“完全相关”，中间还设有“相关”“有点相关”等不同程度表述。

当搜索意图具有明确界限时，二元判断（是/否）十分奏效，即判断该文档是否应出现在搜索结果中？

当存在模糊地带时，分级判断更为实用：某些结果相较于其他结果更优，因此你可以将结果划分为“优秀”“良好”和“毫无价值”等不同等级，并运用能体现结果排序权重及用户反馈的评估指标。然而，分级量表也存在弊端：不同评审者对评分等级的使用方式可能存在差异，这会导致判断结果的一致性降低。并且，由于分级指标对高分赋予了更大的权重，即便是一个微小的改动（比如将某项评分从 4 分改为 3 分），也可能在指标上引发远超评审者预期的巨大波动。这种额外引入的主观性使得分级判断结果更具干扰性，且随时间推移愈发难以把控。

我需要自己对文件分类吗？

不一定，因为有多种不同方法创建判定列表，且每种方法各有其优缺点：

• 明确判断：在这种情况下，领域专家会逐一审阅每个查询/文档，并手动判定其相关性（或相关程度）。尽管此方法能确保质量并实现把控，但其可扩展性较差。

• 隐式判断：采用这种方法时，你会依据真实用户行为（如点击量、跳出率、购买行为等）来推断相关文档。此方法可实现数据的自动收集，但可能存在偏差。例如，用户往往更倾向于点击排名靠前的结果，即便这些结果并不相关。

• AI 生成的判断：最后这种方法是借助模型（如 LLM）自动评估查询和文档，人们通常称之为LLM 陪审团。其优势在于速度快且易于扩展，不过数据质量取决于所用模型的性能，以及大语言模型训练数据与您业务需求的契合程度。与人工评分一样，LLM 评审团也可能引入自身偏见或出现前后不一致的情况，因此，必须对照一小部分可信判断结果来验证其输出结果。LLM 模型本质上具有概率性，所以即便将温度参数设置为 0，也常见同一结果被 LLM 模型给出不同评分的情况。

以下是一些选择最佳方法来构建判断集的建议：

• 明确界定哪些仅用户能恰当判断的要素对你而言至关重要（例如价格、品牌、语言、风格以及产品细节等）。如果这些要素至关重要，则至少需针对判断列表中的部分内容获取明确的判断结果。

• 当你的搜索引擎已有足够流量时，可运用隐式判断，即借助点击量、转化率以及停留时长等指标来洞察使用趋势。不过，你仍需谨慎解读这些数据，将其与显式判断结果进行对比，以规避潜在偏差（例如用户往往更倾向于点击排名靠前的结果，即便排名靠后的结果更具相关性）。

为解决这一问题，位置偏差消除技术会对点击数据进行调整或重新加权，以更准确地反映用户的真实兴趣。以下是一些方法：

• 结果随机排序：针对部分用户调整搜索结果的排序，以此估算结果位置对点击量的影响。

• 点击模型包括动态贝叶斯网络 DBN 和用户浏览模型 UBM。这些统计模型会借助滚动行为、停留时长、点击顺序以及返回结果页等模式，来估算用户点击行为反映真实兴趣（而非仅受结果位置影响）的概率。

示例：电影评分应用

准备工作

要运行此示例，需要一个正在运行的本地或部署在 Elastic Cloud 上（托管或无服务器）的 Elasticsearch 8.x 集群，以及访问 REST API 或 Kibana 的权限。

想象有一款应用程序，用户可以在其中上传自己对电影的看法，还可以搜索要观看的电影。由于文本由用户自己撰写，因此可能存在拼写错误和表达方式上的多种差异。因此，搜索引擎必须能够解读这种多样性，并为用户提供有用的结果。

为能在不影响整体搜索行为的前提下对查询进行迭代优化，贵公司业务团队基于最常执行的搜索查询，创建了以下二元判断集：

查询

DocID

文本

迪卡普里奥的表演

doc1

迪卡普里奥在《荒野猎人》中的表演令人惊叹。

迪卡普里奥的表演

doc2

《盗梦空间》中，莱昂纳多·迪卡普里奥饰演了他最具标志性的角色之一。

迪卡普里奥的表演

doc3

布拉德·皮特在这部犯罪惊悚片中表现出色。

迪卡普里奥的表演

doc4

一部充满惊险动作、视觉效果惊艳的冒险大片。

让人热泪盈眶的悲伤电影

doc5

这是一个令人心碎的关于爱与失去的故事，让我哭了好几个小时。

让人热泪盈眶的悲伤电影

doc6

有史以来最催泪的电影之一，记得带上纸巾！

让人热泪盈眶的悲伤电影

doc7

让你捧腹大笑的轻松喜剧

让人热泪盈眶的悲伤电影

doc8

一部充满动作与激情的科幻史诗巨作。

正在创建索引：

批量请求：

以下是该应用程序正在使用的 Elasticsearch 查询：

从判断到指标

就其本身而言，判断列表并不提供太多信息；它们只是我们查询结果的期望。它们真正的优势在于，当我们使用它们来计算客观指标以衡量我们的搜索性能时。

如今，大多数常用指标包含

• 精度：衡量所有搜索结果中真正相关的结果比例。

• 召回率：衡量搜索引擎在检索出的 x 个结果中，找到的相关结果所占的比例。

• 折损累积增益（DCG）：用于衡量结果排序的质量，该指标基于最相关的结果应排在前列这一原则进行评估。

• 平均倒数排名（MRR）：用于衡量首个相关结果所处的排名位置情况 。在列表中越靠前，其分数就越高。

以同样的电影评分应用程序为例，我们将计算召回率指标，看看我们的查询是否遗漏了任何信息。

在 Elasticsearch 中，我们可以通过排名评估 API，使用判断列表来计算指标。该 API 将判断列表、查询以及想要评估的指标作为输入，并返回一个数值，该数值是对查询结果与判断列表进行对比后得出的结果。

让我们针对已提出的这两个查询运行判定列表：

我们将向 rank_eval 发送两个请求：一个针对莱昂纳多·迪卡普里奥查询，另一个针对悲伤电影查询每个请求均包含一个查询及其对应的判定列表（评分）。我们无需对所有文档进行评分，因为未纳入评分范围的文档将被视为未作判定。在进行计算时，召回率仅考虑“相关文档集”，即那些在评分中被认定为相关的文档。

在此情形下，针对莱昂纳多·迪卡普里奥的查询召回率为 1，而悲伤电影查询的召回率为 0。这意味着对于第一个查询，我们能够获取到所有相关结果，而第二个查询则未获取到任何相关结果。因此，平均召回率为 0.5。

或许我们对 minimum_should_match 参数设置得过于严苛了，因为要求查询中的所有词汇都必须在文档中出现，这很可能会导致我们遗漏掉一些相关结果。不妨去掉 minimum_should_match 参数，这样只要文档中包含查询语句里的任意一个词汇，该文档就会被视为相关结果。

如你所见，通过在两个查询中的其中一个里移除 minimum_should_match 参数，现在两个查询的平均召回率都达到了 1。

总而言之，移除 minimum_should_match: 100% 这一条件后，我们得以使两个查询均实现完美召回率。

我们做到了！对不对？

没那么快！

通过提升召回率，我们能够获取到更广泛的结果范围。然而，每一次调整都意味着需要权衡取舍。这正是为何要定义完整的测试用例，并运用不同指标来评估各项更改的原因。

使用判断列表和指标可以防止您在进行更改时盲目行事，因为现在您有数据可以支持这些更改。验证不再是手动和重复的，您可以在多个用例中测试您的更改。此外，A/B 测试允许您实时测试哪种配置最适合您的用户和业务案例，从而实现从技术指标到实际指标的完整循环。

使用判断列表的最终建议

运用判定列表开展工作，不仅关乎评估测量，更在于构建一个能让你自信迭代优化的框架。为实现这一目标，可遵循以下建议：

1. 从小处着手，但一定要开始行动。你无需准备 10000 个查询，且每个查询都配有 50 个判断列表。你只需找出 5 到 10 个对业务场景最为关键的查询，并明确你期望在结果顶部看到的文档即可。这已经能为你提供一个基础。通常，你应优先从热门查询以及无结果的查询入手开展工作。你也可以先使用像精确率这样易于配置的指标进行测试，然后再逐步尝试更复杂的指标。

2. 与用户核实。在生产环境中通过 A/B 测试对数据指标进行补充验证。如此一来，你便能知晓那些在指标上表现良好的更改是否也切实产生了实际影响。

3. 保持列表有效性。你的商业案例会不断变化，关键问题也会随之变化。定期更新判断以反映新的需求。

4. 使其成为流程的一部分。将判断列表整合到开发管道之中。确保每次配置更改、同义词添加或文本分析操作，都能自动对照基础列表进行验证。

5. 将技术知识与战略相结合。不要仅仅满足于衡量精确率或召回率等技术指标。要利用评估结果为业务成果提供决策依据。

分数范围问题

首先，让我们回顾一下混合搜索困难的主要原因之一：不同的分数范围。我们的老朋友BM25会产生无限制的分数。换句话说，BM25 可以生成从接近 0 到（理论上）无穷大的分数。与此相反，针对dense_vector 字段的查询会产生介于 0 和 1 之间的分数。由于semantic_text 混淆了用于索引嵌入的字段类型，因此除非您对索引和推理端点配置有详细了解，否则很难说清查询的分数范围。这在试图交错使用词汇和语义搜索结果时会带来问题，因为即使语义结果更相关，词汇结果也可能优先于语义结果。对于这个问题，普遍接受的解决方案是在交织结果之前对分数进行归一化处理。Elasticsearch 为此提供了两种工具：线性检索器和RRF检索器。

RRF检索器采用RRF 算法，将文档排名作为衡量相关性的标准，并舍弃分数。由于不考虑分数，因此分数范围不匹配不是问题。

线性检索器使用线性组合来确定文档的最终得分。这包括获取文档中每个组件查询的得分，对其进行归一化处理，然后求和生成总分。在数学上，这一操作可以表示为

其中N 是归一化函数，SX 是查询 X 的得分。归一化功能在这里非常关键，因为它将每个查询的得分转换为使用相同的范围。您可以在这里了解有关线性寻回猎犬的更多信息。

分解

用户可以利用这些工具实现有效的混合搜索，但需要对索引有一定的了解。让我们看一个使用线性检索器的示例，在这个示例中，我们将查询一个包含两个字段的索引：

1.semantic_text_field 是一个semantic_text 字段，使用文本嵌入模型E5

text_field 是一个标准的text 字段

1.我们在 字段上使用 查询，我们 在 Elasticsearch 8.18/9.0 中添加了对match 该查询的 支持semantic_text

在构建查询时，我们需要牢记semantic_text_field 使用的是文本嵌入模型，因此对它的任何查询都会产生 0 到 1 之间的分数。我们还需要知道text_field 是一个标准的text 字段，因此对它的查询将产生一个无限制的分数。为了创建具有适当相关性的结果集，我们需要使用一种检索器，在合并查询得分之前将其归一化。在本例中，我们使用了minmax 归一化的线性检索器，它将每个查询的得分归一化为介于 0 和 1 之间的值。

本例中的查询结构相当简单，因为只涉及两个字段。然而，随着字段的增加和类型的变化，它很快就会变得复杂。这表明，要编写有效的混合搜索查询，往往需要对所查询的索引有更深入的了解，这样才能在组合之前对组件查询得分进行适当的归一化处理。这对混合搜索的广泛应用构成了障碍。

查询分组

让我们扩展一下示例：如果我们想查询一个text 字段和两个semantic_text 字段，该怎么办？我们可以构建这样一个查询：

这表面上看起来不错，但也有潜在的问题。现在，semantic_text 场比赛占总分的⅔：

这可能不是你想要的结果，因为这会造成分数不平衡。在只有 3 个字段的示例中，这种影响可能并不明显，但如果查询的字段较多，就会出现问题。例如，大多数索引包含的词法字段远远多于语义字段（即dense_vector,sparse_vector, 或semantic_text) 。如果我们使用上述模式查询一个包含 9 个词法字段和 1 个语义字段的索引呢？词性匹配将占得分的 90% ，从而削弱语义搜索的有效性。

解决这一问题的常用方法是将查询分为词汇和语义两个类别，并对两者进行平均加权。这就避免了任一类别在总分中占主导地位。

让我们付诸实践。在使用线性检索器时，本例中的分组查询方法会是怎样的？

哇，真是啰嗦！您甚至可能需要上下滚动多次才能查看整个查询！在这里，我们使用两级标准化来创建查询组。数学上可以表示为

这第二级规范化可确保semantic_text 字段和text 字段的查询权重均匀。请注意，在本例中，我们省略了text_field 的二级规范化，因为只有一个词法字段，这样可以避免更多的繁琐。

这种查询结构已经很笨重了，而且我们只查询三个字段。随着查询字段的增多，即使是经验丰富的搜索从业人员也越来越难以驾驭。

多字段查询格式

我们在 Elasticsearch 8.19、9.1 和 无服务器 中为线性和 RRF 检索器添加了 多字段查询格式 ，以简化所有这些操作。现在，您只需使用"...... "即可执行与上述相同的查询：

这将查询从 55 行缩减到 9 行！Elasticsearch 自动将索引映射用于

• 确定每个查询字段的类型

• 将每个字段归入一个词汇或语义类别

• 在最终得分中平均分配每个类别的权重

这样，任何人都可以执行有效的混合搜索查询，而无需了解有关索引或所用推理端点的详细信息。

使用 RRF 时，可以省略normalizer ，因为排名是相关性的代表：

每场增强

在使用线性检索器时，您可以应用每个字段增强功能来调整某些字段中匹配的重要性。例如，假设您要查询四个字段：两个semantic_text 字段和两个text 字段：

默认情况下，每个字段在其组（词法或语义）中的权重相同。比分细目如下

换句话说，每个字段占总分的 25% 。

我们可以使用field^boost 语法为任何字段添加每个字段的提升。让我们将semantic_text_field_1 和text_field_1 提升 2：

现在的比分是这样的

每个查询组的权重仍然相同，但组内字段的权重发生了变化：

• semantic_text_field_1 是语义查询组得分的 66% ，是总分的 33%

• text_field_1 是词法查询组得分的 66% ，是总分的 33%

ℹ️ 请注意，在按字段提升时，总分范围不会改变。这是分数标准化的预期副作用，可确保词法和语义查询分数保持直接可比性。

ℹ️ 在 Elasticsearch 9.2+ 中，每个字段的提升也可与 RRF 检索器一起使用

通配符分辨率

您可以在fields 参数中使用* 通配符来匹配多个字段。继续上面的例子，这个查询在功能上等同于明确查询emantic_text_field_1,semantic_text_field_2, 和text_field_1 ：

值得注意的是，*_field_1 模式同时匹配text_field_1 和semantic_text_field_1 。查询将自动执行，就像明确查询每个字段一样。semantic_text_field_1 同时匹配两种模式也没有问题；在执行查询之前，所有匹配的字段名称都会被去除重复。

您可以通过多种方式使用通配符：

• 前缀匹配（例如：*_text_field)

• 内联匹配 (ex:semantic_*_field)

• 后缀匹配（例如：semantic_text_field_*)

您还可以使用多个通配符来应用上述组合，例如*_text_field_* 。

默认查询字段

多字段查询格式还允许您查询您一无所知的索引。如果省略fields 参数，它将查询由index.query.default_field 索引设置指定的所有字段：

默认情况下，index.query.default_field 设置为* 。该通配符将解析索引中支持术语查询的所有字段类型，其中大多数字段类型都支持术语查询。例外情况是

• dense_vector 领域

• rank_vector 领域

• 几何领域：geo_point, shape

当你想在第三方提供的索引上执行混合搜索查询时，该功能尤其有用。多字段查询格式可让您以简单的方式执行适当的查询。只需排除fields 参数，就能查询所有适用字段。

结论

分数范围问题会让有效的混合搜索实施起来很头疼，尤其是在对所查询的索引或所使用的推理端点了解有限的情况下。线性和 RRF 检索器的多字段查询格式将基于查询分组的自动混合搜索方法打包到简单易用的应用程序接口中，从而减轻了这种痛苦。附加功能（如按字段增强、通配符解析和默认查询字段）扩展了功能，涵盖了多种使用情况。

立即试用多字段查询格式

您可以通过 免费试用 ，在完全托管的 Elasticsearch Serverless 项目中使用多字段查询格式检查线性检索器和 RRF 检索器。它还提供从 8.19& 9.1 开始的堆栈版本。

只需一条命令，几分钟即可在本地环境中开始使用：

和我们许多人一样，我发现自己对人工智能能力的发展速度既目瞪口呆又惊叹不已。我们首先看到大型语言模型（LLMs）和矢量搜索将我们带入语义革命，在这场革命中，我们不再需要用关键字来寻找事物。随后，法学硕士们向我们展示了与数据交互的新方法，他们使用聊天界面将自然语言请求转化为回复，将庞大的知识库提炼为易于使用的摘要。我们现在（已经）以 "代理人工智能"（agentic AI）工作流的形式出现的自动 LLM 驱动逻辑已经初具雏形，它可以从语义上理解接收到的请求，推理出需要采取的步骤，然后从可用的工具中选择迭代执行的行动来实现这些目标。

人工智能代理的前景正迫使我们从主要使用 "提示工程 "来塑造我们的人工智能生成交互，发展到关注我们如何帮助代理工具获得最相关、最有效的额外信息，以便 LLM 在生成其响应时加以考虑--"情境工程 "是下一个前沿领域。混合搜索是迄今为止最强大、最灵活的浮现相关上下文的手段，Elastic 的搜索人工智能平台开辟了一种全新的方式来利用数据为上下文工程服务。在本文中，我们将从两个角度讨论法律硕士如何改变了信息检索的世界，然后再讨论如何将它们结合起来以取得更大的成果。有相当多的地方需要覆盖...

第 I 部分：法律硕士如何改变搜索方式

让我们从法律硕士如何改变了我们获取和检索信息的方式这个角度出发。

我们的词汇遗产

长期以来，我们一直生活在有限的词库搜索世界中（尽我们所能，相当不错）。搜索是我们在研究或开始一个新项目时最先使用的工具，直到最近，我们还需要以词法搜索引擎能够理解的方式来描述我们的查询。词法搜索依赖于将某种形式的查询术语与文档语料库中的关键字进行匹配，无论内容是非结构化的还是结构化的。词法搜索要返回命中的文档，必须与该关键词相匹配（或者有同义词列表或词典等受控词汇来为我们建立概念联系）。

词法 多匹配 查询示例

至少搜索引擎有能力返回相关性得分的点击率。搜索引擎提供丰富的查询语法选项，可有效定位索引数据，并提供内置相关性算法，根据用户查询语法的意图对结果进行评分。几十年来，搜索引擎在相关性排序算法方面取得了长足的进步，这使搜索引擎成为一个高效的数据检索平台，可以根据查询结果的相关性对结果进行评分和排序。使用 SQL 作为主要数据检索方法的数据库和其他系统在这方面处于劣势：数据库查询中没有相关性的概念；它们能做的最好的事情就是按字母或数字对结果进行排序。好消息是，您将获得这些关键词的所有点击率（召回率），但相对于您询问这些关键词的原因（精确度）而言，它们的顺序不一定有帮助。这一点很重要，我们很快就会看到...

进入（语义）龙

信息矢量表示法作为关键字搜索的替代方法，其潜力已被研究了很长时间。矢量让我们摆脱了只用关键词匹配内容的模式，因此前景十分广阔--由于矢量是术语和权重的数字表示，因此可以根据语言模型对术语在训练领域中相互关系的理解，在数学上接近概念。通用矢量搜索之所以拖延了很长时间，是因为模型大多局限于特定领域，它们根本不足以充分理解一个术语在不同语境中可能代表的许多不同概念。

直到几年前出现了大型语言模型（LLM），它们能够在更大的数据量上进行训练（使用转换器和注意力），矢量搜索才变得实用起来--LLM 的大小和深度最终使矢量能够存储足够的细微差别，从而真正捕捉语义。理解深度的骤然增加使得 LLM 现在可以实现大量以前无法实现的自然语言处理（NLP）功能，其中影响最大的可能是根据序列中迄今为止的上下文推断序列中最有可能出现的下一个术语。推理过程赋予了生成式人工智能近乎人类的文本生成能力。人工智能生成的文本参考了 LLM 对训练数据中术语相关性的理解，并利用请求的措辞来区分术语可能出现的不同语境。

尽管生成式人工智能非常神奇，但 LLM 也有其局限性，会导致质量和准确性方面的误差，也就是通常所说的幻觉。当 LLM 无法获得信息（或没有正确的上下文引导）来根据事实回答问题时，就会产生幻觉，因此，为了帮助 LLM，它会产生一个自信满满、听起来似是而非的回答。部分原因在于，虽然 LLM 可以在包含各种信息的大型领域中学习语言的用法，但它们必须在某个时间点停止训练，因此它们的理解存在时效性因素--也就是说，模型只能知道在停止训练之前的准确性。造成幻觉的另一个因素是，模型通常不知道私人持有的数据（不能在公共互联网上获取的数据），当这些数据包含特定术语和名词时，这一点尤为重要。

矢量数据库

LLM 使用一种称为文本嵌入的技术将内容矢量化到其模型空间中，这种技术是指根据所接受的训练，将内容的语义嵌入或映射到模型的世界观中。准备和处理嵌入内容需要几个步骤，包括分块和标记化（以及子词标记化）。其结果通常是一组密集的向量，代表了模型在其向量空间内对该内容块含义的理解。分块是一个不精确的过程，目的是使内容符合模型生成嵌入的处理限制，同时还尝试使用语义结构（如句子和段落指示符）将相关文本归入一个分块。

由于单个分块与同一文档中的其他分块并不完全关联，因此分块的需要可能会在嵌入文档中造成一些语义损失。神经网络固有的不透明性会使这种损失变得更加严重--LLM 是一个真正的 "黑盒子"，训练过程中术语和概念之间的联系是非确定的，人类无法解释。这就导致了可解释性、可重复性、无意识偏见等问题，并可能失去信任和准确性。不过，从语义上将想法联系起来的能力，以及在查询时不受特定关键词束缚的能力还是非常强大的：

语义 查询 示例

矢量数据库还有一个问题需要考虑：它们不是搜索引擎，而是数据库！在进行矢量相似性搜索时，会对查询词进行编码，以便在模型的矢量空间中找到一组（嵌入）坐标。然后将这些坐标作为靶心，找出与靶心 "近邻 "的文档--这意味着文档的排名（或在结果中的位置）是由计算出的文档坐标与查询坐标的相似度距离决定的。在可能的上下文中，哪个最接近用户的意图？我将其比喻为电影《星际之门》中的一个场景，我们有六个相交的坐标点来告诉我们目的地（靶心），但如果不知道 "第七个符号"--代表用户主观意图的起点坐标，我们就无法到达目的地。因此，通过表达式语法和相关性评分来考虑查询的主观意图，我们就能得到类似于主观相关性分级的圆柱体，而不是根据不断扩大和无差别的相似性来对向量进行相对排序。

LLM 的推理能力可能有助于确定它对查询所掌握的最有可能的上下文，但问题是，在没有帮助的情况下，输入查询的坐标只能根据模型最初的训练方式来确定。

在某些方面，你可以说矢量相似性走向了与严格的关键词匹配相反的极端--它的优势在于能够克服术语不匹配的问题，但几乎可以说是无懈可击：LLM 倾向于统一相关概念，而不是区分它们。矢量相似性提高了我们从语义上匹配内容的能力，但并不能保证精确度，因为它可能会忽略精确的关键字和特定的细节，而这些细节在模型中并没有得到足够的消歧。矢量相似性搜索本身就很强大，但我们需要将从矢量数据库中获取的结果与其他检索方法的结果关联起来。

重新排名技术

现在是提及一种名为 "重排 "的通用技术的好时机。"重排 "是对结果集进行重新评分或归一化，使其达到统一的排名顺序。需要重新排序的原因可能是来自多个来源或检索方法的结果具有不同的排序/评分机制（或者根本没有，SQL！），或者重新排序可能是为了使来自非语义来源的结果与用户的查询在语义上保持一致。重新排序是第二阶段的操作，是指通过某种初始检索方法收集到的一组结果（即SQL、词法搜索、向量搜索），然后用不同的评分方法重新排序。

有几种可用的方法，包括学习排名（Learning-To-Rank，LTR）和互惠排名融合（Reciprocal Rank Fusion，RRF）--LTR 适用于捕捉搜索结果特征（喜欢、评分、点击等），并利用这些特征对搜索结果进行评分、提升或倾斜。RRF 非常适合合并不同查询模式返回的结果（如词法搜索和矢量数据库搜索）合并为一个结果列表。Elastic 还提供了使用线性重排方法调整分数的灵活性。

不过，最有效的重排技术之一是语义重排，它利用 LLM 的语义理解能力来分析查询和结果的向量嵌入，然后应用相关性评分/重评分来确定最终顺序。当然，语义重排需要与重排模型建立连接，Elasticsearch提供了推理API，让您可以创建重排端点，利用内置模型（Elastic Rerank）、导入的第三方模型或外部托管服务（如Cohere或Google Vertex AI）。然后就可以通过检索器查询抽象语法执行重新排序：

多级检索器重排操作示例

听起来不错吧？我们可以对来自不同来源的结果进行重新排序，从而接近对所有类型内容的语义理解......语义重新排序的计算成本和处理时间都很高，正因为如此，语义重新排序只能在数量有限的结果上进行，这意味着如何检索这些初始结果非常重要。

语境检索方法很重要

主观意图是确定结果准确性和评分相关性的一个重要因素。由于无法考虑用户执行查询的意图（如通过灵活的语法或第二阶段重排所表达的意图），我们只能从模型空间中已编码的现有上下文中进行选择。我们通常通过检索增强生成（RAG）等技术来解决这种缺乏上下文的问题。RAG 的工作原理是，它可以有效地转移查询的坐标，包括通过预查询返回的其他相关术语，以获取与上下文相关的数据。这就使得提供额外上下文的引擎及其执行检索的初始方法对上下文的准确性更加重要！

让我们回顾一下不同的上下文检索方法，以及它们对 RAG 操作的帮助或伤害：

• 没有搜索引擎的混合搜索检索仍然缺乏主观相关性。如果提供 RAG 的平台主要基于下面的 SQL（包括大多数 "数据湖 "平台），那么在初始检索阶段就缺乏相关性评分。许多数据湖平台提供自己版本的混合检索（而非搜索），通常在基于 SQL 的检索和矢量数据库结果上结合语义重排和 RRF 等重排技术。简单的排序显然不足以进行主观排序，但即使作为第二阶段语义重排操作的基础，SQL 作为第一阶段检索，在只对 "前 k 个 "点击进行语义重排时也会出现问题--如果不在检索时对结果进行某种评分，我们又如何保证最好的结果确实在最前面的结果中呢？

• 对于 RAG 来说，仅有矢量相似性是不够的。这实际上是由一系列复杂问题造成的--这是嵌入的损失性，还有天真的分块方法、相似性的计算方法，以及主观意图这一至关重要的缺失部分。RAG 的主要目标之一是将生成式人工智能交互建立在客观事实的基础上，既能防止产生幻觉，又能让 LLM 了解它在训练过程中不知道的私人信息。我们可以利用 RAG 提供的额外语境来约束和引导 LLM，使其考虑我们所知道的对回答当前问题最重要的关联和细节。为此，我们需要同时使用语义和词汇方法。

• 基于文件的 grep/regex RAG。在人工智能代理领域，有一些人指出，应使用大幅放大的上下文窗口，通过 grep 和 regex 访问本地文件，以实现 RAG，而不是使用外部检索平台。我们的想法是，有了更大的上下文窗口，法律硕士就能在自己的思维空间内建立概念联系，而不是依赖分块的碎片和多种检索方法/平台来收集相关信息。虽然从理论上讲，拥有整个文档比拥有文档片段能提供更全面的信息，但这只适用于小数据域（或者，例如，在提供用于振动编码的文件时），即使在这种情况下，初始检索方法也是扫描所有仅有关键字匹配的文档。

搜索不仅仅是检索

搜索引擎的设计目的是使查询尽可能快速和灵活。在内部，它们利用专门的数据结构来存储和检索不同类型的数据，以满足这些数据类型的需要。Elasticsearch 可优化所有类型数据的存储和查询，包括非结构化/全文词法搜索（匹配、短语、近似、多重匹配）、快速关键字（精确匹配）匹配和过滤、数字范围、日期、IP 地址，而且存储文档结构的方式也非常灵活（例如，可通过"...嵌套或扁平化文档）。Elasticsearch 还是一个原生矢量数据库，可以存储和查询稀疏和密集矢量类型。我们将继续探索创新方法（例如，更好的二进制量化 (BBQ) & DiskBBQ），以保持搜索保真度，同时提高速度、可扩展性以及与矢量化内容相关的成本。Elasticsearch 平台还提供内置的数据弹性和高可用性，并包含数据生命周期管理功能，如可搜索快照，让您可以在经济高效的对象存储上保留不常访问或长期保留的数据，但仍可完全搜索。

混合搜索是最好的选择

混合搜索（不仅仅是混合检索）将传统词汇搜索的优势与 LLM 的语义理解和向量相似性搜索相结合。这种协同作用允许在检索阶段通过搜索引擎提供的任何灵活的查询语法选项：意图驱动语法选项和相关性评分、多模态数据检索、过滤、聚合和偏置来定位高度相关的结果。利用ES|QL等搜索语法和多级检索器，我们可以在一个请求中灵活地将传统搜索与语义搜索、过滤器和多种重排技术结合起来。

混合搜索的最大优势之一是，您的查询可以同时针对多种不同的数据类型使用专门的语法。这些不同的查询语法不仅可用于查找结果，还可用作结果的筛选器或聚合器。例如，最常见的查询类型之一是地理空间分析，它经常与其他语法相结合。您可以查询地理坐标在某一点指定距离内的结果，或要求按地区对结果进行汇总，或进行汇总以跟踪进入/离开某个区域的移动情况并发出警报。使用混合搜索，您可以灵活地组合语法，以最准确的方式定位搜索结果，检索最贴近您的上下文的内容。

中场休息

第一部分讲述了矢量搜索如何改变了我们检索数据的方式，并为 LLM 给我们用来与数据交互的查询机制带来的变化做了铺垫。我们将假装不得不把这部分内容分成多个部分，以便 LLM 能够在不丢失上下文的情况下理解......;-)让我们在第二部分 "代理人工智能和上下文工程的必要性"中进一步了解 这一点的重要性 ，在第三部分中，我们将继续讨论混合搜索。

直线型寻回犬

在本篇文章中，我们将介绍linear retriever，它是我们支持混合搜索的最新成员！与rrf 不同，linear retriever 计算的是与文档匹配的所有查询的加权总和。这种方法既能保留结果集中每个文档的相对重要性，又能精确控制每个查询对最终得分的影响。因此，它为微调混合搜索提供了一种更直观、更灵活的方式。

定义一个线性检索器，其最终得分的计算公式为

就这么简单：

注意到它有多简单直观了吗？(与rrf 非常相似！）这种配置允许您精确控制每种查询类型对最终排名的贡献程度，这与rrf 不同，后者仅依赖于相对排名。

需要注意的是：knn 分数可能有严格的界限，这取决于所使用的相似性指标。例如，使用余弦相似度或单位归一化向量的点积，得分总是在[0, 1] 范围内。相比之下，bm25 分数的可预测性较差，而且没有明确的界限。

评分缩放：KNN vs BM25

混合搜索面临的一个挑战是，不同的检索器会产生不同的分数。例如，请考虑以下情况：

查询 A 得分：

doc1

doc2

doc3

文档4

knn

0.347

0.35

0.348

0.346

bm25

100

1.5

1

0.5

查询 B 得分：

doc1

doc2

doc3

文档4

knn

0.347

0.35

0.348

0.346

bm25

0.63

0.01

0.3

0.4

您可以从上面看到这种差异：kNN 分数介于 0 和 1 之间，而bm25 分数可能相差悬殊。这种差异使得设置静态最佳权重以合并结果变得非常棘手。

归一化拯救：MinMax 归一化器

为了解决这个问题，我们引入了一个可选的minmax 归一化器，该归一化器使用以下公式将每个查询的分数独立缩放至[0, 1] 范围：

这就保留了每个文档在查询结果集中的相对重要性，从而更容易合并来自不同检索器的得分。正常化后，分数变为

查询 A 得分：

doc1

doc2

doc3

文档4

knn

0.347

0.35

0.348

0.346

bm25

1.00

0.01

0.005

0.000

查询 B 得分：

doc1

doc2

doc3

文档4

knn

0.347

0.35

0.348

0.346

bm25

1.00

0.000

0.465

0.645

现在，所有得分都在[0, 1] 范围内，加权总和的优化也更加简单明了，因为我们现在捕捉的是结果的重要性（相对于查询而言），而不是绝对得分，并能在不同查询中保持一致。

线性寻回器示例

现在，让我们通过一个例子来展示上述内容，以及linear Retriever 如何解决rrf 的一些不足之处。RRF 仅依靠相对排名，不考虑实际分数差异。例如，给出这些分数：

doc1

doc2

doc3

文档4

knn

0.347

0.35

0.348

0.346

bm25

100

1.5

1

0.5

rrf 分数

0.03226

0.03252

0.03200

0.03125

rrf 会将文件排序为

但是，doc1 的bm25 得分明显高于其他文件，而rrf 只查看相对排名，因此未能捕捉到这一点。linear Retriever 结合归一化处理，可以正确地考虑分数及其差异，从而得出更有意义的排名：

doc1

doc2

doc3

文档4

knn

0.347

0.35

0.348

0.346

bm25

1

0.01

0.005

0

如上图所示，doc1 的优秀排名和score 的bm25 都得到了适当的考虑，并反映在最终得分上。此外，所有分数现在都在[0, 1] 范围内，这样我们就能以更直观的方式对它们进行比较和组合（甚至建立离线优化流程）。

将所有内容整合在一起

要充分利用linear 检索器的正常化功能，搜索请求应如下所示：

这种方法结合了两方面的优点：既保留了linear Retriever 的灵活性和直观评分，又通过 MinMax 归一化确保了一致的评分缩放。

与我们所有的检索工具一样，linear 检索工具可以集成到分层检索树的任何层级中，并支持可解释性、匹配高亮、字段折叠等功能。

何时选择线性寻回犬，为什么会有区别

linear 猎犬：

• 通过利用实际得分，而不仅仅是排名，来保留相对重要性。

• 允许利用不同查询的加权贡献进行微调。

• 利用规范化增强一致性，使混合搜索更稳健、更可预测。

结论

linear retriever 已经在 Elasticsearch Serverless 以及 8.18 和 9.0 版本中可用！更多示例和配置参数可参阅我们的文档。试用一下，看看它如何改善您的混合搜索体验--我们期待您的反馈。搜索愉快

Quepid 在搜索质量评估过程中为搜索团队提供支持：

• 建立查询集

• 创建判断列表

• 计算搜索质量指标

• 根据计算得出的搜索质量指标，比较不同的搜索算法/排名器

在我们的博客中，假设我们经营一家电影租赁店，目标是提高搜索结果的质量。

准备工作

本博客使用es-tmdb 资源库中的数据和映射。数据来自电影数据库。接下来，使用映射建立名为 tmdb 的索引，并为数据建立索引。不管是建立本地实例还是使用弹性云部署，都可以正常工作。我们假设本博客使用的是弹性云部署。你可以在es-tmdb 软件仓库的 README 中找到有关如何为数据建立索引的信息。

对rocky 的标题字段进行简单的匹配查询，以确认有数据可供搜索：

您将看到 8 项结果。

登录 Quepid

Quepid是一款能让用户衡量搜索结果质量并进行离线实验以提高质量的工具。

您可以通过两种方式使用 Quepid：一种是使用https://app.quepid.com 上的免费公开托管版本、或在你可以访问的机器上设置 Quepid。本帖假设您使用的是免费托管版本。如果您想在自己的环境中建立一个 Quepid 实例，请遵循《安装指南》。

无论您选择哪种设置，如果还没有账户，您都需要创建一个账户。

如何设置 Quepid 案例

Quepid 的组织结构围绕"案例展开。"案例可存储查询、相关性调整设置以及如何与搜索引擎建立连接。

• 对于首次使用的用户，请选择创建第一个相关性案例。

• 老用户可以从顶层菜单中选择相关性案例，然后点击+ 创建案例。

请描述性地命名您的案例，例如"电影搜索基线，" ，因为我们希望开始测量和改进我们的基线搜索。

选择继续，确认名称。

接下来，我们建立 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测试连接，然后选择继续进入下一步。

现在，我们定义要在案例中显示的字段。选择所有有助于我们的人工评判员稍后评估文档与给定查询相关性的内容。

将title 设置为标题字段，将_id 保留为ID 字段，将overview, tagline, cast, vote_average, thumb:poster_path 添加为附加显示字段。最后一个条目显示了结果中电影的小缩略图，为我们和人类评分员提供视觉指导。

选择继续按钮确认显示设置。

最后一步是在案例中添加搜索查询。通过输入框逐一添加 "星球大战"、"哈里森-福特"和 "最佳动作片"三个查询，然后继续。

理想情况下，案例包含的查询能代表真实的用户查询，并能说明不同类型的查询。现在，我们可以把《星球大战》想象成一个查询，代表所有关于电影名称的查询；把哈里森-福特想象成一个查询，代表所有关于演员的查询；把最佳动作片想象成一个查询，代表所有搜索特定类型电影的查询。这通常称为查询集。

在生产场景中，我们将通过应用概率比例大小采样等统计技术，从事件跟踪数据中抽取查询样本，并将这些采样查询导入 Quepid，以根据查询频率包含头部（频繁查询）和尾部（不频繁查询）的查询，这意味着我们会偏向于更频繁的查询，而不会排除罕见的查询。

最后，选择 "完成"，您将转到案例界面，看到三个已定义的查询。

查询和信息需求

为了实现我们的总体目标--评判列表，人类评判者需要对给定查询的搜索结果（通常是文档）进行评判。这就是所谓的查询/文档对。

有时，在查看查询时似乎很容易知道用户想要什么。查询harrison ford 的目的是查找演员哈里森-福特主演的电影。查询action 如何？我知道我很想说用户的意图是寻找动作类型的电影。但是是哪些呢？最新的、最受欢迎的、用户评价最好的？或者，用户是否想找到所有名为 "动作 "的电影？在电影数据库中，至少有 12 部（！）电影被称为 "动作片"，它们的名称主要区别在于片名中感叹号的数量。

如果查询的意图不明确，两名人工评分员对查询的解释可能会有所不同。输入信息需求：信息需求是一种有意识或无意识的信息渴望。定义信息需求有助于人类评判员判断查询的文档，因此他们在建立判断列表的过程中发挥着重要作用。专家用户或主题专家是明确信息需求的最佳人选。从用户的角度来定义信息需求是一种很好的做法，因为搜索结果应该满足用户的需求。

电影搜索基线 "案例查询的信息需求：

1. 星球大战用户希望查找《星球大战》系列电影或节目。有可能相关的是关于《星球大战》的纪录片。

2. 哈里森-福特用户希望查找演员 Harrison Ford 主演的电影。哈里森-福特扮演不同角色的电影也可能与此相关，比如旁白。

3. 最佳动作片：用户希望找到动作片，最好是用户平均票数高的动作片。

如何在 Quepid 中定义信息需求

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

1.打开一个查询（例如星际大战）并选择切换备注。

2.在第一个字段中输入信息需求，并在第二个字段中输入任何附加说明：

3.单击保存。

对于少数几个查询，这个过程没有问题。但是，当您将案例从 3 个查询扩展到 100 个查询时（Quepid 案例通常在 50 到 100 个查询之间），您可能希望在 Quepid 之外定义信息需求（例如，在电子表格中），然后通过导入并选择信息需求来上传。

在 Quepid 中创建团队并共享案例

合作判断可提高相关性评估的质量。组建团队：

1.在顶层菜单中导航至团队。

2.单击+ 添加新成员，输入团队名称（例如"Search Relevance Raters" ），然后单击创建。

3.输入成员的电子邮件地址并单击 "添加用户"，添加成员。

4.在个案界面，选择共享个案。

5.选择合适的团队并确认。

在 Quepid 中创建评估手册

Quepid 中的一本书允许多个评分者对查询/文档对进行系统评估。创建一个

1.转到案件界面中的 判决书 ，点击 + 创建一本书 。

2.为图书配置一个描述性的名称，将其分配给您的团队，选择一种评分方法（例如 DCG@10），并设置选择策略（单个或多个评分者）。图书使用以下设置：

• 名称："电影搜索 0-3 刻度"

• 要与之分享此书的团队：勾选您创建的团队

• 得分者DCG@10

3.单击创建图书。

名称具有描述性，包含搜索内容（"电影"）和评判标准（"0-3"）的信息。所选的 Scorer DCG@10 定义了搜索指标的计算方式。DCG "是 "贴现累积收益"的缩写，"@10 "是在计算该指标时，从顶部开始考虑的结果数量。

在这种情况下，我们使用一种衡量信息增益的指标，并将其与位置加权相结合。可能还有其他搜索指标更适合您的使用情况， 选择合适的 指标 本身就是一项挑战 。

用查询/文档对填充评估手册

要添加查询/文档对进行相关性评估，请按照以下步骤操作：

1.在案件界面中，导航至"判决。"

2.选择您创建的图书。

3.单击"Populate Book" ，然后选择"Refresh Query/Doc Pairs for Book 进行确认。"

该操作根据每个查询的热门搜索结果生成配对，供团队评估。

让您的人工评分团队进行评估

到目前为止，已完成的步骤都是相当技术性和行政性的。现在，这些必要的准备工作已经完成，我们可以让我们的评委团队开展工作了。从本质上讲，法官的工作就是评定特定文档与给定查询的相关性。这一过程的结果就是判断列表，其中包含了被判断的查询文档对的所有相关性标签。接下来，我们将进一步详细解释这一过程及其界面。

人工评分界面概览

Quepid 的人工评分界面专为高效评估设计：

• 查询：显示搜索词。

• 信息需求：显示用户的意图。

• 评分指南：提供一致评价的说明。

• 文件元数据：介绍文件的相关详细信息。

• 评级按钮：允许评定者使用相应的键盘快捷键指定评定结果。

使用人工评分界面

作为一名人工评审员，我通过图书概览进入界面：

1.导航至案件界面并单击判决。

2.点击 "需要更多判决！"。

系统会显示一个尚未评级的查询/文件对，该查询/文件对需要额外的判断。这是由图书的选择策略决定的：

• 单一评判者：每个查询/文档对只有一个评判。

• 多个评分者：每个查询/文档对最多可有三个评判。

评估查询/文档对

让我们举几个例子。当您按照本指南进行操作时，很可能会看到不同的电影。不过，评级原则保持不变。

第一个例子是电影 "英雄 "中的查询 "哈里森-福特"：

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

这部电影与我们的查询结果相关，因为演员中有哈里森-福特（Harridson Ford）。我们可能会主观地认为近期的电影更具相关性，但这并不是我们信息需求的一部分。因此，我们给这份文件的评分是 "完美"，在我们的评分标准中是 3 分。

下一个例子是电影 "福特诉法拉利"，查询条件是哈里森-福特：

按照同样的做法，我们通过查看查询、信息需求以及文档元数据与信息需求的匹配程度来判断该查询/文档。

这是一个糟糕的结果。我们可能会看到这个结果，因为我们的查询词之一 "福特 "在标题中匹配。但哈里森-福特在这部电影中没有扮演任何角色，也没有扮演任何其他角色。因此，我们将这份文件评为 "差"，在我们的评分标准中是 0 分。

第三个例子是电影 "动作杰克逊 "的最佳动作片查询：

这看起来像是一部动作片，因此至少满足了部分信息需求。不过，投票的平均值为 5.4（满分 10 分）。因此，这部电影可能不是我们收藏的最好的动作片。因此，作为评委，我给这份文件的评分是 "尚可"，在我们的评分标准中是 1 分。

这些示例特别说明了使用 Quepid 对查询/文档进行评级的过程，既有高层次的，也有一般的。

人工评分员最佳实践

所展示的示例可能会让人觉得可以直接得出明确的判断。但是，建立一个可靠的人工评级程序并非易事。这是一个充满挑战的过程，很容易影响数据质量：

• 人类评分员可能会因重复性工作而感到疲劳。

• 个人喜好可能会影响判断。

• 不同法官的领域专业知识水平各不相同。

• 评级员往往身兼数职。

• 文档的感知相关性可能与查询的真实相关性不一致。

这些因素可能导致判决不一致、质量不高。不过不用担心，有一些经过验证的最佳实践可以帮助你最大限度地减少这些问题，并建立一个更强大、更可靠的评估流程：

• 一致的评估：依次审查查询、信息需求和文件元数据。

• 参考指南：使用评分指南以保持一致性。评分指南可以举例说明何时采用哪种等级，从而说明评审过程。事实证明，在第一批评判结束后与人工评判员进行核对是一种很好的做法，可以了解具有挑战性的边缘案例以及在哪些方面需要额外的支持。

• 利用选项：如果不确定，可使用"I Will Judge Later" 或"I Can't Tell," ，必要时提供解释。

• 休息：定期休息有助于保持判断质量。每当人工评判员完成一批评判时，Quepid 都会弹出彩纸，帮助用户定期休息。

按照这些步骤，您就可以在 Quepid 中建立一个结构化的协作方法来创建判断列表，从而提高搜索相关性优化工作的效率。

后续步骤

何去何从？判断列表只是提高搜索结果质量的一个基础步骤。下面是接下来的步骤：

计算指标并开始实验

一旦有了判断列表，利用判断和计算搜索质量指标就水到渠成了。当有判决书时，Quepid 会自动计算当前案件的配置指标。指标以 "计分器 "的形式实现，如果支持的指标不包括您最喜欢的指标，您可以提供自己的指标！

进入案例界面，导航至 "选择评分员"，选择DCG@10，点击 "选择评分员"确认。现在，Quepid 将计算每次查询的 DCG@10，并计算总体查询的平均值，以量化搜索结果的质量。

既然已经量化了搜索结果的质量，那么就可以进行第一次实验了。实验从提出假设开始。在对截图中的三个查询进行评级后，可以明显看出这三个查询在搜索质量指标方面的表现截然不同：《星球大战》表现不错，《哈里森-福特》看起来还行，但《最佳动作片》的潜力最大。

扩大查询范围后，我们就能看到查询结果，并能深入研究细节，探索文档匹配的原因以及影响其得分的因素：

点击 "Explain Query（解释查询）"并进入 "Parsing（解析）"选项卡，我们可以看到该查询是一个 DisjunctionMaxxQuery，搜索三个字段：演员、概述和标题：

通常情况下，作为搜索工程师，我们对搜索平台的一些特定领域了如指掌。在这种情况下，我们可能知道我们有一个基因字段。让我们将其添加到查询中，看看搜索质量是否有所提高。

我们使用在案例界面选择 "调整相关性"时打开的 " 查询沙盒"。请添加您搜索的流派字段，继续探索：

单击重新运行我的搜索！并查看结果。他们变了吗？遗憾的是没有。我们现在有很多选项可以探索，基本上是 Elasticsearch 提供的所有查询选项：

• 我们可以增加基因字段的字段权重。

• 我们可以添加一个功能，根据文件的平均得票率来提升文件。

• 我们可以创建一个更复杂的查询，只在有强基因匹配的情况下，才按投票平均值提升文档。

• …

在 Quepid 中拥有所有这些选项并对其进行探索的最大好处是，我们不仅可以量化我们试图改进的查询的效果，还可以量化我们的所有查询的效果。这就避免了我们通过牺牲其他搜索结果的质量来改善一个表现不佳的查询。我们可以快速、低成本地迭代，并在没有任何风险的情况下验证我们假设的价值，这使得离线实验成为所有搜索团队的基本能力。

评估评分员间信度

即使有任务说明、信息需求和类似 Quepid 提供的人工评定界面，人工评定者也会出现分歧。

意见分歧本身并不是坏事，恰恰相反：衡量意见分歧可以让你发现你可能想要解决的问题。相关性可能是主观的，查询可能是模糊的，数据可能是不完整或不正确的。弗莱斯卡帕（Fleiss' Kappa）是衡量评分者之间一致性的一种统计方法，Quepid 中有一个示例笔记本可供使用。要找到它，请在顶层导航中选择 笔记本 ，然后在 示例 文件夹中选择笔记本 Fleiss Kappa.ipynb 。

结论

Quepid 使您能够应对最复杂的搜索相关性挑战，并将继续发展：从第 8 版开始，Quepid 支持人工智能生成判断，这对希望扩展判断生成流程的团队特别有用。

Quepid工作流程使您能够高效地创建可扩展的判断列表，最终产生真正满足用户需求的搜索结果。有了判断列表，您就有了衡量搜索相关性、迭代改进和改善用户体验的坚实基础。

在前进的过程中，请记住相关性调整是一个持续的过程。判断列表可以让你系统地评估自己的进步，但如果能与实验、指标分析和迭代改进相结合，判断列表的作用会更加强大。

延展阅读

• Quepid docs：

  • 相关性是一项团队运动

  • 人类评级员的 Quepid

  • 如何将 Quepid 连接到弹性云

• Quepid Github 存储库

• 认识皮特，关于改进电子商务搜索的系列博客

• 相关性 Slack：加入 #quepid 频道

与 Open Source Connections 合作 ，改造您的搜索和人工智能能力，并使您的团队能够不断发展这些能力。我们的业绩记录遍布全球，客户在搜索质量、团队能力和业务绩效方面不断取得显著提高。现在就联系我们，了解更多信息。

筛选器与分面

在开始之前，我们先来定义一下什么是过滤器和切面。过滤器是用于限制结果集的预定义属性。例如，在市场中，甚至在进行搜索之前就可以使用筛选器。用户可以先选择一个类别，如"Video games" ，然后再搜索"PS5" ，将搜索范围缩小到更具体的子集，而不是整个数据库。这大大增加了获得更多相关结果的机会。

面板的工作原理与筛选器类似，但只有在执行搜索后才可用。换句话说，搜索会返回结果，并根据这些结果生成新的细化选项列表。例如，在搜索 PS5 游戏机时，可以显示存储容量、运输成本和颜色等信息，帮助用户选择理想的产品。

既然我们已经定义了过滤器和切面，下面我们就来讨论经典方法和基于机器学习 (ML) 的方法对其实施和使用的影响。每种方法都有影响搜索效率的优势和挑战。

过滤器和分面的经典方法

在这种方法中，过滤器和切面是根据预定义规则手动定义的。这意味着，考虑到目录结构和用户需求，可用于细化搜索的属性是固定的，并事先进行了规划。

例如，在市场中，"Electronics" 或"Fashion" 等类别可能有特定的筛选条件，如品牌、格式和价格范围。这些规则是静态创建的，可确保搜索体验的一致性，但每当出现新的产品或类别时，就需要进行手动调整。

虽然这种方法提供了对所显示过滤器和面的可预测性和控制，但当出现需要动态改进的新趋势时，这种方法就会受到限制。

优点

• 可预测性和控制：由于筛选器和切面是手动定义的，因此管理变得更加容易。

• 低复杂性：无需训练模型。

• 易于维护：由于规则是预定义的，因此可以快速进行调整和修正。

缺点

• 新过滤器需要重新索引：每当需要使用新属性作为筛选器时，就必须对整个数据集重新索引，以确保文档包含该信息。

• 缺乏动态适应性：过滤器是静态的，不能根据用户行为的变化自动调整。

滤波器/滤面的实现 - 经典方法

在开发工具 Kibana 中，我们将使用经典方法创建过滤器/面板演示。

首先，我们定义映射来构建索引：

品牌和存储 字段被设置为关键字，可直接用于聚合（面）。价格字段为浮动类型，可以创建价格范围。

下一步，将对产品数据编制索引：

现在，让我们按照品牌、存储空间和价格范围对结果进行分组，从而检索出经典的面孔。在查询中，定义了 size:0。在这种情况下，目标是只检索聚合结果，而不包括与查询相对应的文档。

回复将包括品牌、存储和价格的计数，有助于创建筛选器和面。

基于机器学习/人工智能的筛选器和分面方法

在这种方法中，机器学习（ML）模型（包括人工智能（AI）技术）分析数据属性，生成相关的过滤器和面。ML/AI 不依赖预定义规则，而是利用索引数据特征。这样就能动态发现新的切面和过滤器。

优点

• 自动更新：自动生成新的过滤器和切面，无需手动调整。

• 发现新属性：它可以将以前未考虑过的 数据特征识别为过滤器，从而丰富搜索体验。

• 减少人工操作：当人工智能从可用数据中学习时，团队无需不断定义和更新过滤规则。

缺点

• 维护复杂性：使用模型可能需要预先验证，以确保生成的过滤器的一致性。

• 需要 ML 和 AI 专业知识：该解决方案需要合格的专业人员来微调和监控模型性能。

• 无关过滤器的风险：如果模型没有得到很好的校准，可能会生成对用户无用的切面。

• 成本：使用 ML 和 AI 可能需要第三方服务，从而增加运营成本。

值得注意的是，即使有了校准良好的模型和精心制作的提示，生成的切面仍应经过审查步骤。这种验证可以是手动的，也可以基于审核规则，以确保内容的适当性和安全性。虽然这不一定是一个缺点，但这是一个重要的考虑因素，以确保在提供给用户之前，面的质量和适用性。

实施过滤器/面板--人工智能方法

在本演示中，我们将使用一个人工智能模型来自动分析产品特性并提出相关属性建议。有了结构良好的提示，我们就能从目录中提取信息，并将其转化为过滤器和切面。下面，我们将介绍这一过程的每个步骤。

最初，我们将使用推理 API注册一个端点，以便与 ML 服务集成。以下是与OpenAI 服务集成的示例。

现在，我们定义一个管道来执行提示并获取模型生成的新过滤器。

为"PlayStation 5" 产品运行该流水线的模拟，说明如下：

令人惊叹的游戏：惊叹于令人惊叹的画面，体验全新 PS5 的功能。

令人惊叹的沉浸感：支持触觉反馈、自适应触发器和 3D 音频技术，探索更深层次的游戏体验。

超薄设计：通过 PS5 数字版，玩家可以在时尚、紧凑的设计中获得强大的游戏技术。

1TB 存储空间：内置 1TB SSD 存储空间，让您随时随地畅玩最喜爱的游戏。

向后兼容和游戏提升：PS5 游戏机可播放 4,000 多款 PS4 游戏。有了 Game Boost，您甚至可以在一些最好的 PS4 游戏机游戏中享受更快、更流畅的帧率。

让我们观察一下这次模拟产生的提示输出。

现在，新索引中将添加一个新字段dynamic_facets，用于存储人工智能生成的面。

我们将使用Reindex API 将videogames索引重新编入videogames_1，并在此过程中应用generate_filter_ai管道。该管道将在索引编制过程中自动生成动态切面。

现在，我们将运行搜索并获得新的筛选器：

结果

下面是一个简单的前端，以表示面的实现：

这里提供了用户界面代码。

结论

这两种创建过滤器和切面的方法各有利弊。基于手动规则的传统方法可提供控制并降低成本，但需要不断更新，且无法动态适应新产品或新功能。

另一方面，基于人工智能和机器学习的方法可以自动提取切面，使搜索更加灵活，并且无需人工干预即可发现新的属性。不过，这种方法的实施和维护可能更为复杂，需要进行校准以确保结果的一致性。

在传统方法和基于人工智能的方法之间做出选择，取决于企业的需求和复杂程度。对于数据属性稳定且可预测的简单场景，传统方法可以更高效、更易于维护，从而避免基础设施和人工智能模型的不必要成本。另一方面，使用 ML/AI 提取切面可以大大增加价值，改善搜索体验，使过滤更加智能。

重要的是要评估自动化是否值得投资，或者更传统的解决方案是否已能有效满足业务需求。

本博客将探讨如何使用大型语言模型 (LLM) 自动识别和生成同义词，并允许以编程方式将这些术语加载到 Elasticsearch 的同义词 API 中。

何时使用同义词？

与矢量搜索相比，使用同义词是一种更快、更具成本效益的解决方案。它的实现较为简单，因为它不需要深厚的嵌入知识，也不需要复杂的矢量摄取过程。

此外，由于矢量搜索需要更大的存储容量和内存来嵌入索引和检索，因此资源消耗较低。

另一个重要方面是搜索区域化。有了同义词，就可以根据当地语言和习俗调整术语。这在嵌入式可能无法匹配区域表达或特定国家术语的情况下非常有用。例如，有些单词或缩略语在不同地区可能有不同的含义，但当地用户自然会将其视为同义词。在巴西，这种情况非常普遍。"Abacaxi" 和"ananás" 是同一种水果（菠萝），但在东北部的一些地区，第二个术语更常用。同样，东南部著名的"pão francês" 在东北部可能被称为"pão careca" 。

如何使用 LLM 生成同义词？

为了自动获取同义词，我们可以使用 LLM，它可以分析术语的上下文，并建议适当的变体。这种方法可以动态扩展同义词，确保搜索范围更广、更准确，而无需依赖固定词典。

在本演示中，我们将使用 LLM 生成电子商务产品的同义词。由于查询词的变化，许多搜索结果很少或没有结果。有了同义词，我们就可以解决这个问题。例如，搜索"智能手机" 可以涵盖不同型号的手机，确保用户找到所需的产品。

准备工作

在开始之前，我们需要设置环境并定义所需的依赖关系。我们将使用 Elastic 提供的解决方案，在 Docker 中本地运行 Elasticsearch 和 Kibana。代码将使用 Python 3.9.6 版本编写，依赖关系如下：

创建产品索引

最初，我们将创建一个不支持同义词的产品索引。这样我们就可以验证查询，然后将其与包含同义词的索引进行比较。

为了创建索引，我们在 Kibana DevTools 中使用以下命令批量加载产品数据集：

用 LLM 生成同义词

在这一步中，我们将使用 LLM 来动态生成同义词。为此，我们将整合 OpenAI 应用程序接口，定义适当的模型和提示。LLM 将接收产品类别和名称，确保同义词与上下文相关。

从创建的产品索引中，我们将检索"Electronics" 类别中的所有项目，并将其名称发送到 LLM。预期输出结果如下

有了生成的同义词，我们就可以使用同义词 API 将其注册到 Elasticsearch 中。

使用同义词 API 管理同义词

同义词 API 提供了在系统内直接管理同义词集的有效方法。每个同义词集都由同义词规则组成，其中一组词在搜索中被视为等同词。

创建同义词集示例

这样就创建了一个名为"my-synonyms-set," 的集合，其中"hello" 和"hi" 被视为等同词，"bye" 和"goodbye 也被视为等同词。"

为产品目录创建同义词

下面是建立同义词集并将其插入 Elasticsearch 的方法。同义词规则是根据 LLM 建议的同义词映射生成的。每条规则都有一个 ID（与 slug 格式的产品名称相对应）和 LLM 计算出的同义词列表。

下面是创建同义词集的请求有效载荷：

在集群中创建同义词集后，我们就可以进行下一步，即使用定义的同义词集创建支持同义词的新索引。

下面是完整的 Python 代码，其中包含 LLM 生成的同义词和同义词 API 定义的同义词集创建：

创建支持同义词的索引

将创建一个新索引，对products 索引中的所有数据进行重新索引。该索引将使用synonyms_filter ，它应用了之前创建的products-synonyms-set 。

以下是配置为使用同义词的索引映射：

重新索引products 索引

现在，我们将使用Reindex API将products 索引中的数据迁移到包含同义词支持的新products_02 索引中。在 Kibana DevTools 中执行了以下代码：

迁移后，products_02 索引将被填充，并可使用配置的同义词集验证搜索。

使用同义词验证搜索

让我们比较一下两个索引的搜索结果。我们将在两个索引上执行相同的查询，并验证是否使用同义词来检索结果。

在products 索引中搜索（不含同义词）

我们将使用 Kibana 执行搜索并分析结果。在分析> 发现菜单中，我们将创建一个数据视图，以可视化我们创建的索引中的数据。

在 Discovery 中，单击数据视图并定义名称和索引模式。对于"产品" 索引，我们将使用"产品"模式。然后，我们将重复该过程，使用"products_02"模式为"products_02" 索引创建一个新的数据视图。

配置好数据视图后，我们就可以返回 Analytics> Discovery 并开始验证。

在这里，选择 DataView 产品并对"tablet" 一词进行搜索后，我们没有得到任何结果，尽管我们知道有"Kindle Paperwhite" 和"Apple iPad Air" 这样的产品。

在products_02 索引中搜索（支持同义词）

在支持同义词的"products_synonyms" 数据视图上执行相同查询时，产品被成功检索。这表明配置的同义词集工作正常，确保搜索词的不同变体都能返回预期结果。

我们可以直接在 Kibana DevTools 中运行相同的查询来获得相同的结果。只需使用 Elasticsearch Search API 搜索 products_02 索引即可：

结论

在 Elasticsearch 中使用同义词提高了产品目录搜索的准确性和覆盖范围。与众不同的关键在于使用了LLM，它可以根据上下文自动生成同义词，无需预定义清单。该模型分析了产品名称和类别，确保与电子商务相关的同义词。

此外，同义词 API简化了词典管理，允许动态修改同义词集。有了这种方法，搜索变得更加灵活，更能适应不同的用户查询模式。

这一过程可以通过新数据和模型调整不断改进，确保提供越来越高效的研究体验。

参考资料

在本地运行 Elasticsearch

https://www.elastic.co/guide/en/elasticsearch/reference/current/run-elasticsearch-locally.html

同义词应用程序接口

https://www.elastic.co/guide/en/elasticsearch/reference/current/synonyms-apis.html

基于第 1 部分的示例，本文将探讨如何运用多种技术及 Elasticsearch 强大的向量搜索工具集，使后期交互向量能够胜任大规模生产工作负载。

如需获取完整代码示例，请访问 GitHub。

后期交互模型的挑战

ColPali 会为我们索引中的每个文档页面生成超过 1000 个向量。

这导致在处理后期交互向量时面临两大挑战：

1. 磁盘空间：将所有向量存储到磁盘会占用大量存储空间，在大规模使用时成本高昂。

2. 计算开销：使用 maxSimDotProduct() 比较函数对文档排序时，需要将每个文档的所有向量与查询的 N 个向量逐一对比。

接下来，我们看看解决这些问题的一些技巧。

优化后期交互模型的技术

位向量

为了减少磁盘占用，我们可以将向量压缩为二值（比特）向量。我们可以使用一个简单的 Python 函数将多向量转换为二值向量：

函数的核心思想很简单：大于 0 的值量化为 1，小于 0 的值量化为 0。这样会得到一个由 0 和 1 组成的数组，随后我们将其转换为代表二值向量的十六进制字符串。

对于我们的索引映射，我们将element_type参数设置为bit：

将所有新的二值向量写入索引后，我们可以使用以下代码对其进行排序：

这以牺牲少量精度为代价，使我们能够利用汉明距离 (maxSimInvHamming(...)) 进行比较，而汉明距离可以利用位掩码、SIMD 等技术进行优化。如需了解更多信息，请阅读我们这篇关于二值向量与汉明距离的博文。

或者，我们可以不将查询向量转换为位向量，而是使用全保真度的后期交互向量进行搜索：

这将使用一种非对称相似度函数来比较我们的向量。

让我们来考虑两个比特向量之间的标准汉明距离。假设有一个文档向量 D：

和一个查询向量 Q：

简单的二值量化会将向量 D 转换为 10101101，将 Q 转换为 11111011。计算汉明距离需要直接的位运算，速度极快。本例中，汉明距离为 01010110，其中 1 的个数为 4。因此，评分即为汉明距离的倒数。请记住，更相似的向量汉明距离更小，取倒数后能让更相似的向量得分更高。具体到这里，得分将是 1/4 = 0.25。

然而，请注意我们丢失了每个维度的幅度信息。一个 1 就只是一个 1。因此，对于 Q 向量，0.01 和 0.79 之间的差异就消失了。由于我们只是根据 >0 进行量化，这里可以用一个小技巧：不量化查询向量 Q。虽然这无法利用极快的位运算，但由于文档向量 D 仍是量化的，因此仍能保持较低的存储成本。

简而言之，这保留了 Q 向量中的信息，从而提高了距离估计的质量，同时保持了低存储开销。

使用二值向量可以为我们显著节省磁盘空间并降低查询时的计算负载。但我们还能做得更多。

平均向量

要在数十万甚至更多文档中扩展搜索，仅靠二值向量带来的性能提升可能还不够。为了支撑这类规模的工作负载，我们需要利用 Elasticsearch 为向量搜索设计的 HNSW 索引结构。

ColPali 为每个文档生成约一千个向量，数量过多，无法全部加入 HNSW 图。因此，我们需要减少向量数量。为此，我们可以对 ColPali 为图像生成的所有文档向量取平均值，从而创建代表文档含义的单一向量表示。

目前，这无法在 Elasticsearch 内部直接完成，我们需要在将数据摄入 Elasticsearch 之前对向量进行预处理。

这可以通过 Logstash 或 Ingest 管道实现，但这里我们将使用一个简单的 Python 函数：

我们同时对向量进行归一化，以便使用点积相似度。

将所有 ColPali 向量转换为平均向量后，即可将其索引到 dense_vector 字段中：

需要注意的是，这可能会增加总磁盘使用量，因为我们在保存后期交互向量之外还存储了额外信息。同时，我们需要额外的内存来存放 HNSW 图，但这使得我们能够在数十亿向量规模上进行搜索。为了降低内存占用，我们可以利用备受欢迎的 BBQ 特性。如此一来，我们便能在原本无法处理的海量数据集上获得快速的搜索结果。

现在，只需使用 kNN 查询即可搜索到最相关的文档。

遗憾的是，原先的最佳匹配项排名跌落至第 3 位。

为了解决这个问题，我们可以采用多阶段检索策略。在第一阶段，使用 kNN 查询在数百万文档中为查询筛选出最佳候选集。在第二阶段，仅使用精度更高的 ColPali 后期交互向量对前 k 个（例如：10 个）候选进行重排序。

这里，我们使用 8.18 版本引入的重打分检索器来对结果进行重排序。重打分后，可以看到最佳匹配项又回到了第一位。

注意：在实际生产应用中，可以设置比 10 大得多的 k 值，因为 maxSim 函数相对而言仍有不错的性能。

令牌池化

令牌池化通过聚合冗余信息（例如白色背景的图像块）来减少多向量嵌入的序列长度。该技术在减少嵌入数量的同时，保留了文档页面的绝大部分信息。

令牌池化的工作原理是，使用聚类算法将文档内相似的令牌嵌入分组到聚类中。然后，计算每个聚类中所有向量的均值，以生成一个聚合的向量表示。这个聚合向量将取代该组中原始的多个令牌向量，从而在不显著损失文档信息的前提下减少向量总数。

ColPali 论文建议对大多数数据集使用初始池化因子 3，这可以在保持 97.8% 原始性能的同时，将向量总数减少 66.7%。

但需要注意：对于包含文本密集、空白极少的“Shift”数据集，随着池化因子增大，其性能会迅速下降。

要生成池化后的向量，我们可以使用 colpali_engine 库：

现在我们得到了一个维度减少约 66.7% 的向量。我们可以照常对其进行索引，并使用 maxSimDotProduct() 函数进行搜索。

我们能够获得良好的搜索结果，代价是结果精度有轻微损失。

提示：使用更高的 pool_factor（如 100-200），可以在平均向量方案和此处讨论的方案之间取得折中。当每个文档仅有 5-10 个向量时，将它们索引到嵌套字段中并利用 HNSW 索引就变得可行。

交叉编码器 vs. 后期交互模型 vs. 双编码器

根据我们目前的了解，与其他 AI 检索技术相比，如 ColPali 或 ColBERT 这类后期交互模型定位如何？

虽然 maxSim 函数相比交叉编码器计算成本更低，但仍比使用双编码器的向量搜索需要多得多的比较和计算（后者每个查询-文档对仅比较两个向量）。

因此，对于后期交互模型，我们通常建议仅将其用于对前 k 个搜索结果进行重排序。这也体现在其字段类型的名称上：rank_vectors。

那么交叉编码器呢？后期交互模型是否因为查询时执行成本更低而更优？和往常一样，答案是：视情况而定。交叉编码器通常能产生更高质量的搜索结果，但它们需要大量的计算，因为查询-文档对需要完整地通过 Transformer 模型。它们的优势在于无需对向量进行索引，可以无状态运行。这带来以下特点：

• 使用更少的磁盘空间

• 更简单的系统

• 搜索结果质量更高

• 延迟更高，因此无法进行深层重排序

另一方面，后期交互模型可以将部分计算转移到索引阶段，从而降低查询成本。我们付出的代价是必须索引向量，这使得索引流水线更复杂，并且需要更多磁盘空间来存储这些向量。

具体到 ColPali，由于图像包含大量数据，从中分析信息的成本非常高。在这种情况下，权衡的天平倾向于使用 ColPali 这类后期交互模型，因为在查询时评估这些信息将过于消耗资源且速度太慢。

对于像 ColBERT 这样处理文本数据（与大多数交叉编码器，如 elastic-rerank-v1，类似）的后期交互模型，决策可能更倾向于使用交叉编码器，以受益于其节省磁盘和架构简单的特点。

我们鼓励您根据自身的使用场景权衡这些利弊，并尝试 Elasticsearch 提供的各种工具，以构建最佳的搜索应用。

结论

在本博客中，我们探讨了多种优化后期交互模型（如 ColPali）的技术，以支持在 Elasticsearch 中进行大规模向量搜索。虽然后期交互模型在检索效率和排序质量之间提供了良好的平衡，但也带来了存储和计算方面的挑战。

为了应对这些挑战，我们研究了以下技术：

• 二值向量：可显著减少磁盘空间，同时利用汉明距离或非对称最大相似度等高效相似度计算。

• 平均向量：将多个嵌入压缩为单一的稠密表示，从而实现利用 HNSW 索引的高效检索。

• 令牌池化：智能合并冗余的嵌入，同时保持语义完整性，降低查询时的计算开销。

Elasticsearch 提供了一套强大的工具集，让您可以根据需求定制和优化搜索应用。无论您优先考虑检索速度、排序质量还是存储效率，这些工具和技术都能帮助您在实际应用中平衡性能与质量。