对于新用户而言，这是运行高质量向量搜索的最快方式。如果您已在使用 Elasticsearch，这款新产品能够在您的数据所在平台上实现向量搜索，您无需引入任何新系统。Elasticsearch 向量数据库支持多种应用场景，例如为大型语言模型 (LLM) 提供事实依据，为 AI 智能体赋予检索与记忆能力，以及处理数千亿个向量等。立即创建新项目，只需几分钟即可开始使用。

一个引擎，满足所有向量应用场景

Elasticsearch 向量数据库专为使用向量构建应用程序的用户而设计：

• RAG：通过密集和稀疏向量检索为您的 LLM 检索适当的上下文，或者采用结合向量检索和词汇检索的混合搜索。您的生成质量会随着检索质量的提升而提高。

• AI 智能体：为智能体提供针对文档和对话记忆的快速筛选检索，满足多步智能体循环所需的低延迟要求。

• 语义搜索：根据含义而非关键字进行匹配，只需一种字段类型且无需任何管道代码。

• 推荐和相似度：针对产品、图像或任何内容大规模查找最近邻。

您的向量工作负载所需的一切，开箱即用且经过优化

构建基于向量的应用程序意味着将多个独立部分连接起来：设置并托管嵌入模型，通过这些模型为您的文档编制索引，高效存储向量，将嵌入模型应用于每个查询，与向量存储进行匹配，以及最后检索匹配项背后的文档。Elasticsearch 向量数据库可为您处理所有这些操作，无需进行额外配置或设置。

使用 vectordb_document 索引模式进行向量索引

vectordb_document 索引模式是一种专为向量优先型工作负载构建的新索引配置，默认启用，因此您可以获得专家会选择的设置。以下是它会启用的功能：

• 默认使用 bfloat16：向量的存储大小仅为 float32 的一半，对召回率的影响可忽略不计，甚至在考虑量化之前，就能将您的磁盘占用空间大致减半。

• 排除源向量：在 Elasticsearch 中，您的嵌入向量已存在于用于搜索的索引结构中；在 _source 中保留第二份原始副本只会增加存储占用并降低获取结果的速度。我们排除了重复项，以便更快获得响应并减少存储空间。

• 将正确的文件预加载到缓存中：向量查询最先访问的数据结构会提前预热到内存中，从而确保无论是第一次查询还是第一千次查询，速度都快如闪电。

• 并行合并：合并可将分段整合为组织更有序的向量结构，从而同时提升召回率并改善延迟，而以多线程方式运行这些合并则可以更快达成这一目标。

向量存储、压缩和自动调优

• 您的向量会自动压缩。更好的二进制量化 (BBQ) 可在保持召回率的同时将向量的内存占用最多减少 32 倍，而 DiskBBQ 则能针对大规模工作负载进一步降低内存需求。 

• 选择启用自动校准，该功能会根据您的数据调整每个分段的量化参数，并在数据发生漂移时在每次合并时重新调整。在 18 个数据集上的测试结果显示，每秒查询数 (QPS) 平均提升了 16.7%，且大多数数据集的召回率也有所提高。

托管 GPU 推理上的嵌入

• 通过原生 Jina AI 嵌入和重排序模型生成嵌入向量，或引入第三方模型；所有模型均在 Elastic Inference Service (EIS) 提供的托管 GPU 上运行，无需运维模型服务器。如果您愿意，您也可以选择自行托管。

• semantic_text 字段类型可自动处理分块和嵌入以及查询，这是市面上实现语义搜索的最简单途径。 

混合搜索和过滤向量搜索

• 混合搜索是内置功能，可在单个查询中结合全文检索和向量检索。您可以使用倒数排序融合 (RRF) 或您所需的任何其他融合机制来融合结果。在混合搜索中，向量搜索部分的配置往往最具挑战性；而借助 Elasticsearch 向量数据库，这一难题迎刃而解，您的整个混合技术栈也会变得更加出色。 

• 借助带过滤功能的向量搜索，将元数据过滤作为向量检索过程本身的一部分来实施，而不是将其作为事后补救措施，从而避免损害召回率。

从第一天起即面向企业

您还可以获得基于角色的访问控制 (RBAC)、审计日志，以及纯向量数据库通常缺乏的合规性认证。

扩展时经济实惠且具有可预测性

Elasticsearch 向量数据库旨在让您随着业务增长仍可负担：BBQ 和 DiskBBQ 压缩可使存储线性增长并保持较低内存占用，这意味着即使扩展到数千亿个向量，费用也不会大幅攀升。您实际支付的费用由您已知的数字决定：存储的数据量、索引的数据量，以及所需的搜索容量。估算您的文档数量、向量维度和查询负载，您便可在创建项目之前算出所需费用。您还可以在月底逐项了解账单明细。没有不透明的计算单元，也不会因后台操作产生意外费用。

如何开始使用 Elasticsearch 向量数据库

创建无服务器向量数据库项目

创建新的 Elastic Cloud 无服务器向量数据库项目。将数据指向终端，即可开始编入索引。

使用 semantic_text 创建索引

向量索引模式负责处理向量配置。使用 semantic_text 意味着系统会在托管 GPU 推理上为您管理嵌入和分块设置以及索引设置，无需构建嵌入管道。

采集文档

索引文本，系统便会为您生成嵌入。

运行语义搜索查询

查询您刚刚创建的相同语义字段：

然后您会获得返回的结果：

语义搜索只是开始。运行纯文本查询，或将两者结合为混合查询。您甚至可以构建自己的向量查询，实现完全控制。请参阅文档中的语义搜索快速入门，获取完整说明。

Elasticsearch 中向量搜索的未来展望

我们已经在着手进行后续改进：

• 更出色的多租户处理：如果您的数据需要按租户保持隔离，我们将为您提供一种速度更快、代码量更少的方法来实现这一目标。

• 自动索引优化：从“全新索引”到“完全优化”，无需过多人工干预。

• 持续的基础架构改进：对向量数据库的设置和基础架构进行持续调优，确保您始终获得最佳吞吐量和最快响应。

在 Elastic Cloud Serverless 上试用 Elasticsearch 向量数据库

仅需数分钟，您即可从零开始构建支持混合检索与过滤功能的向量查询应用，并利用生产级默认配置自动完成性能调优。您可以构建快速、可扩展的 AI 应用，无需构建基础架构。

开始使用 Elastic Cloud Serverless，或深入了解完整文档和 API 参考。

什么是召回？

召回率 以 0 到 1 的范围来衡量用户真正想要的文档有多少出现在搜索结果中。如果某个查询应显示三个产品，而您的搜索结果仅有两个进入前 10 名，则该查询的得分为 recall@10 = 0.67。这是一个基于集合的指标：它并不关心相关文档在这 k 个结果中的位置。位置 10 的相关文档与位置 1 的相关文档具有同等效力。高召回率意味着您不会丢失相关结果。

该图表显示了两组文档：所有相关文档（左侧）和 BM25 实际检索到的文档（前 10 个，右侧）。只有交集部分才计入召回率，找到了 prod_1 和 prod_2，而 prod_3、prod_4 和 prod_6 则完全遗漏。结果：Recall@10 = 2/5 = 0.40。

准备工作

让我们言归正传，更好地了解召回的工作原理。本演示使用 Python。您可以在配套笔记本 (notebook.ipynb) 中跟着操作，其中每个代码块都是一个可直接运行的单元。

提供的代码使用以下内容：

• Elasticsearch 9.3+

• Python 3.10+

• 包含 Elasticsearch 凭据的 .env 文件

该数据集

我们将使用包含 1,000 种产品的产品目录，涵盖鞋类、电子产品、工具等多个类别。

每份文档有四个字段：

字段

类型

“标题”

文本

“描述”

文本

“品牌”

关键字

`类别`

关键字

该数据集加载自 dataset.csv。

词汇搜索的支持和局限性

BM25 是 Elasticsearch 和大多数搜索引擎的默认排名算法。它根据查询词在文档中的出现频率对其进行评分，并根据文档长度和这些词在整个索引中的出现频率进行调整。在此基础上，您还可以获得分析器：小写规范化、词干提取和停用词消除。查询“跑步鞋”将匹配“跑步鞋”，也可能匹配“跑步”。

这对很多查询都很有效：

• “跑鞋”会立即匹配标题中包含这些确切标记的产品。

• “蓝牙扬声器”会显示便携式音频产品，因为这些词语是逐字匹配的。

搜索结果具有确定性和可解释性：文档排名靠前，是因为查询词出现在其中。调试相关性很简单。

出现问题的地方

现在，让我们针对同一目录尝试这些查询：

• “护肤流程”：在任何产品标题中都没有出现“流程”这个词。BM25 能够部分匹配“护肤”这一词，但面部精华液、身体精油和保湿霜等产品是用“维生素 C”、“视黄醇”或“提亮”等术语来描述的，这些术语与查询词都没有重叠。构成完整护肤流程的产品分散在索引中，没有任何共同的令牌将其关联起来。

• “宠物旅行配件”：这是一个用例分组，而非产品类别。宠物狗背带、宠物汽车座椅和旅行笼都与此相关，但它们的描述侧重于便携性、安全性和舒适性，而非“旅行配件”。BM25 与“宠物”大致匹配，但无法区分旅行专用产品与宠物目录中的其他产品。

这是一个召回问题。相关文档已存在于您的索引中。BM25 无法找到它们，因为用户的用词和文档中的词语匹配度不够高。

添加同义词有助于处理已知情况。但您无法枚举用户表达某种意图的所有方式。这就是向量发挥作用的地方。

为何要测量召回率

在解决问题之前，需要先对问题进行量化。

Recall@k 衡量有多少用户真正想要的文档出现在搜索结果中。正式来说：

Precision@k 衡量前 k 个结果，以及其中有多少是实际相关的：

高精度意味着您返回的结果质量较高。在电子商务领域，缺少相关产品（召回率低）通常比显示稍有瑕疵的结果（精度较低）更糟糕，因为隐藏的产品意味着销售损失。

Elasticsearch 的 rank_eval API 允许您系统地测量两者。您提供一系列查询，每个查询都有一组已评分的文档，Elasticsearch 会为您计算所有查询的指标。

设置评估

rank_eval API 需要一个评级数据集：查询与每个查询相关的文档之间的映射，以及相关性等级（0＝不相关，1＝相关，2＝高度相关）。

在笔记本中，这是判断列表：

这种混合是有意为之：q1 是 BM25 可以很好处理的查询（产品标题中的精确标记），而 q2、q3 和 q4 是基于意图的查询，用户的意图是以概念而非具体产品关键词来表达的。

测量 BM25 基线召回率

首先，设置 Elasticsearch 客户端，并对原始文本数据建立索引：

现在为 BM25 构建 rank_eval 请求。列表中的每个请求都将会查询及其评分结合起来：

结果：

0.43 这意味着在所有四个查询中，BM25 只找到了它应该找到的文档的 43%。这种不足集中体现在基于意图的查询中：“护肤流程”漏掉了面部精华液和身体精油，因为“流程”一词从未出现在产品标题中；而“宠物旅行配件”则检索出了一些不相关的宠物产品，却遗漏了那些以便携性和安全性而非“旅行配件”来描述的宠物笼和宠物箱。

这就是我们的基准。现在我们有了一个要超越的数字。

使用 Jina 嵌入添加向量搜索

Vector search 将文档和查询编码为高维向量，这是一种由数百甚至数千个数值组成的向量，每个数值都对它所代表的数据的特定特征进行编码。意义相似的文档最终会在向量空间中靠近，即使它们没有共同的词汇。“健身器材”和“哑铃套装”会放在一起，因为这两个概念是相关的。我选择 Elasticsearch 作为我的向量数据库，是因为它支持混合搜索，让我既能理解语义，又能精确查找关键字。

EIS 包括通过其推理 API 嵌入模型的开箱即用支持。

步骤 1：使用 Jina 嵌入 v5 作为推理终端

如果您的集群具有 GPU 资源（在 Elastic Cloud 和 Elasticsearch 9.3+ 中可用），嵌入将在 GPU 上生成，这比 CPU 推理快得多，并消除了历史上使向量在扩展时变得昂贵的性能权衡。

为什么要特别选用 Jina 嵌入？jina-embeddings-v5-text 是一种多语言模型（支持 119 种以上语言），具有 32,000 个标记的上下文窗口，并支持特定任务的低秩自适应 (LoRA) 适配器。它适用于开箱即用的简短产品描述。点击此处了解有关 jina-embeddings-v5-text 模型的更多信息。

步骤 2：创建具有语义字段的索引

这里的关键在于 semantic_text 字段类型。这是对 dense_vector 的更高级别的抽象：您将其指向一个推理终端，Elasticsearch 会自动生成嵌入。

title 和description 上的 copy_to 属性意味着这两个字段的内容都会流入 semantic_field 进行嵌入，因此单个向量就能捕获完整的产品表示。

步骤 3：为产品编制索引

索引时，Elasticsearch 会调用每个文档的推理端点，并将生成的嵌入存储在 semantic_field 中。您无需编写任何额外代码。

混合搜索：将 BM25 与向量结合并采用 RRF

添加向量可以提高召回率，但仅使用向量可能会在精确匹配查询中失去精度；“跑鞋”仍应将逐字匹配的结果排在首位。混合搜索则保留词汇成分，以保持这种精确性。

使用倒数排序融合 (RRF) 的混合搜索可以保持两者的优点：

• BM25 可以高精度处理精确和近似精确的查询。

• 语义搜索能以高召回率处理基于意图和多语言的查询。

• RRF 将两份排名表合并为一份排名表。

RRF 公式根据每个文档在每个结果列表中的排名，为每个文档分配分数：

在两个列表中均排名靠前的文档将获得更高的综合得分。rank_constant用于控制排名较低的文档获得的权重大小。

结果：

混合搜索在 BM25 (0.43) 的基础上有了显著提升，并为“跑鞋”等精确匹配查询保留了精确度。

结果：前后结果对比

以下是所有三种方法的完整对比：

结果：

方法

Recall@10

BM25（词法）

0.43

混合型（BM25 + 向量）

0.75

按查询细分：

结论

在这篇文章中，我们看到，当用户键入精确的查询时，BM25 词汇搜索是可靠的，但当他们根据意图而非关键词进行搜索时，其召回率就会下降。借助 rank_eval，我们建立了一个可重复的基线，用真实数据来衡量这一差距。在此基础上，我们添加了一个由 Jina 嵌入提供支持的 semantic_text 字段，并再次运行了评估。结果：混合搜索将召回率从 0.43 提高到 0.75，同时保留了精确匹配查询的精确度，但实际幅度取决于您的查询组合。

该模式可扩展至本示例之外：从用户的实际查询中收集判断，以 rank_eval 作为基准运行，添加 semantic_text，然后再次进行测量。您将确切了解改进了哪些方面以及改进了多少。

后续步骤

• 深入了解召回与向量搜索：《召回与向量搜索量化》，作者：Jeff Vestal

• 添加重排序功能，以进一步提升前几条结果的精准度

• 探索 Elasticsearch 混合搜索文档

• 阅读有关 rank_eval API 的更多信息

我们如何构建 Elasticsearch simdvec

Elasticsearch 中的每一次向量搜索查询，无论是分层导航小世界 (HNSW) 遍历、倒排文件 (IVF) 扫描，还是重排序阶段，最终都会归结为同一个问题：在一次查询中，数百万次计算向量之间的距离。Elasticsearch 支持广泛的数据类型和量化策略，从 float32 到 int8、bfloat16、binary 以及 Better Binary Quantization (BBQ)。每种类型都在内存、吞吐量和召回率之间形成不同取舍。而这一切背后都有一个统一的引擎：simdvec。

我们打造 simdvec，是为了让每一次距离计算都尽可能逼近硬件允许的性能上限。在本文中，我们将介绍为何要打造它、它的内部构成，以及它在哪些场景中影响最大。

设计得如同一辆赛车

作为一级方程式赛车 (F1) 爱好者（我们其中一人曾效力于法拉利 F1 车队），我们看到了一个清晰的相似之处。F1 赛车的设计只有一个目标：取得最佳单圈成绩。发动机功率、空气动力学和底盘设计之所以重要，是因为它们都服务于这一结果。向量数据库也是如此：索引吞吐量、查询延迟和召回率决定了成功与否。

最终结果固然重要，但要达到最高性能水平，就需要每个组件都做到极致。它不能只是“足够好”，而必须是同类中的“最佳”。simdvec 正是以这种思路打造的，聚焦于系统中的一个关键部分：引擎。它是一个专门构建、针对单指令多数据 (SIMD) 优化的内核库，提供手动调优的原生 C++ 距离函数，并通过 Panama 外部函数接口 (FFI) 从 Java 调用这些函数。它支持批量评分、缓存行预取，以及 Elasticsearch 中使用的所有向量类型和布局。

这就是每个查询背后的引擎。

为什么我们要自研

我们在 2023 年从 Apache Lucene 中的 Panama Vector API 起步。它在处理 float32 点积时表现良好，但 Elasticsearch 的需求很快就超出了它的能力范围。Elasticsearch 需要支持一系列量化向量类型：int8、int4、bfloat16、单比特以及非对称 BBQ。每种类型都有不同的 SIMD 策略、打包布局和累加器要求。除了类型覆盖范围之外，Elasticsearch 的评分路径还需要的不只是单对向量吞吐量：HNSW 需要在一次过程中为多个图邻居评分，IVF 需要对数千个候选项进行带预取的批量评分，而基于磁盘的评分需要直接在 mmap 映射内存上工作，实现零拷贝。我们考察了现有方案，发现没有一个能完全满足这些要求。

于是，我们打造了 simdvec：通过 FFI 从 Java 调用手动调优的原生 C++ 内核，具备批量评分和预取能力，并支持 Elasticsearch 使用的每一种向量类型。通过自有这个库，我们可以控制完整技术栈。当我们添加 BBQ 这样的新量化类型时，它会获得经过调优的 SIMD 内核，并完整接入整个系统。我们无需等待上游库支持它，也无需在任何类型的性能上做出妥协。Elasticsearch 中的每一次向量查询——无论是 HNSW、IVF、重排序还是混合检索——都运行在这个引擎之上。这个引擎正是围绕我们实际使用的操作和类型量身打造的。

simdvec 针对 x86 和 ARM 分别提供原生库，每种库都有多个指令集架构 (ISA) 层级，并在启动时选择。通过 FFI 从 Java 调用的开销非常低，仅为个位数纳秒级。

技术格局

我们并不是唯一在打造 SIMD 优化向量距离内核的团队。这个生态系统非常丰富，我们希望了解 simdvec 的表现。这并非为了给项目排名，而是为了提供上下文，说明 Elasticsearch 的引擎处在什么位置。我们选择了三个项目作为参考点，每个代表一种不同的技术路径：

• jvector：一个 Java 近似最近邻 (ANN) 库，使用 Panama Vector API 进行向量化距离计算，并在 x86 上提供可选的原生 C 加速。

• FAISS：一个广泛部署的开源矢量搜索框架，带有手动调整的 AVX2/AVX-512 内核。

• NumKong（原 SimSIMD）：一个包含 2,000 多个手动调优 SIMD 内核的综合库，覆盖距离函数、矩阵运算和地理空间计算。

每个项目服务于不同的目标，有着不同的取舍。我们引用它们的参考数据，是为了给 simdvec 在 Elasticsearch 所需特定操作上的性能提供参照。

我们如何衡量

simdvec 和 jvector 基准测试使用 Java 编写，并采用 JMH（标准 JVM 微基准测试框架），测试中包含 FFI 开销。对于 NumKong 基准测试和 FAISS 基准测试，我们使用 Google Benchmark（标准 C++ 微基准测试框架）编写了小型 C/C++ 测试程序。两个框架都会在预热和迭代校准后报告每次操作所需的纳秒数。我们通过硬件性能计数器验证了所有库在两个平台上都确实使用了 SIMD。所有基准测试代码均已公开在链接的 GitHub 存储库中；对于 simdvec，代码位于 elasticsearch 存储库中。

软件：JDK 25.0.2、JMH 1.37、GCC 14、Google Benchmark（最新版）。

一次处理一个向量

向量搜索中最基础的操作是计算两个向量之间的距离。每一次 HNSW 邻居评估、每一次 IVF 候选项评分、每一次重排序比较，都会归结为这个内层循环。

我们在两个平台上测量了 1024 维下的单对向量吞吐量，首先从 float32 开始。这是基准类型，也是生态系统中竞争最激烈的类型。我们将 simdvec 与 FAISS 和 jvector 进行了对比；我们排除了 NumKong，因为它在 float32 上使用 float64 累加器，速度慢 3.2 到 5.3 倍（取决于平台），这是以吞吐量换取数值精度。为了保持同类对比，我们改为在 int8 上测试 NumKong，因为此时它采用的累加器策略与 simdvec 相同。

在 x86 上，FAISS AVX-512 是最快的单对内核，耗时 23 ns。simdvec AVX-512 紧随其后，为 28 ns，这一差距反映了 FFI 调用开销。两者都使用 512 位 FMA，并采用多累加器展开。在 AVX2 层级，两者更接近，分别为 36 ns 和 39 ns，都受限于 256 位寄存器和内存加载宽度。jvector 使用 Java Panama Vector API，耗时 44 ns。Panama 能生成良好的 SIMD 代码，但手动调优的 C++ 内部函数仍然具有优势。

在 ARM 上，simdvec 以 70 ns 领先，明显快于 110 ns 的 jvector 和 156 ns 的 FAISS。simdvec 针对 aarch64 提供手动调优的 NEON 内核。jvector 没有 ARM 原生代码，依赖 Panama。FAISS 依赖编译器自动向量化，而非显式的 NEON 内部函数，这也解释了更大的性能差距。这体现了拥有自有内核库的一个实际优势：当 Elasticsearch 扩展到 Graviton 时，我们添加了专门构建的 NEON 内核。而 jvector 和 FAISS 尚未以同等程度优先投入 ARM 原生代码。

但 Elasticsearch 评分的远不止 float32。int8 量化可将内存占用降至原来的四分之一，bfloat16 降至原来的一半，BBQ 降至原来的三十二分之一。每种类型都需要自己的 SIMD 策略，而 simdvec 为所有这些类型都提供手动调优的原生内核。

在我们比较的库中，只有 NumKong 拥有可用于 int8 对比的内核。我们测量了 1024 维度下的 int8 点积、平方欧几里得距离和余弦计算。

Int8 单对评分（1024 维，ns/vec op – 越低越好）

在两种架构上，NumKong 在中小维度下持平或更快，差异主要来自更低的调用开销（直接 C 调用 vs Java FFI）。在更高维度下，simdvec 迎头赶上，因为更高效的内核实现（使用级联展开）摊薄了调用成本：随着维度增加，这一差距会缩小并最终反转。交叉点出现在 768 到 1536 维之间，具体取决于函数和架构。

尽管 Java FFI 存在略高的开销，simdvec 的表现仍足以媲美高度优化的 C/C++ 库。它不仅是唯一一个同时为 float32 和 int8 提供优化内核的库，而且在 ARM 上保持领先，在 x86 上的 float32 方面也仅略逊于 FAISS，在 int8 上与 NumKong 在两个架构上都非常接近。对于 bfloat16、int4、binary 和 BBQ，虽然存在其他替代方案，但 simdvec 的优势在于，它能够针对每种类型的数据布局进行手动 SIMD 调优。

然而，生产环境下的搜索引擎不会一次只为一个向量评分，而是会在每次查询中为数千个向量评分。接下来的问题是：在如此规模下性能表现如何？

一次处理数千个向量

单对向量性能只是整体图景的一部分。在实践中，真正重要的是系统在负载下的行为。一次 HNSW 查询可能会为数百个图邻居评分。一次 IVF 扫描可能会为数千个倒排列表条目评分。一次重排序阶段可能会为数万个候选项评分。单对吞吐量固然重要，但更关键的是评分大量向量时的速度，以及当工作集超出 CPU 缓存时性能下降是否平缓。

simdvec 为每一种数据类型都提供了批量评分功能。这绝非简单的单对内核循环，而是使用了多累加器内层循环：在每个维度步长 (stride) 中仅加载一次查询向量，并让多个文档向量共享该向量，同时针对下一批次执行显式的缓存行预取。在本文撰写之时，jvector 和 FAISS 都没有提供等效功能。jvector 没有批量 API，调用者只能在循环中逐对评分。FAISS 暴露了 fvec_inner_products_ny，但在撰写本文时，其实现方式仍是循环调用单对向量距离函数，没有查询向量摊销，也没有预取。

Float32。为了在内核层面衡量影响，我们使用随机访问模式来模拟类似 HNSW 的分散式图邻居查找，并让单个查询对数量不断增加的 1024 维 float32 文档向量进行评分。我们选择了 32、625 和 32,500 个向量这三种数据集规模，使工作集分别超出 L1、L2 和 L3 缓存。

当数据能放入缓存时，simdvec 在两个平台上都是最快的，但优势不大，因为此时内核算术运算占主导。真正的差距出现在工作集超出 L3 缓存之后。在 x86 上，simdvec 每个向量 95 ns，而 FAISS 需要 165 ns，jvector 需要 412 ns。在 ARM 上，模式相同：simdvec 保持在 162 ns，而 FAISS 攀升到 347 ns，jvector 到 476 ns。simdvec 中的预取和查询向量摊销能够以简单循环调用单对向量内核无法匹敌的方式掩盖内存延迟；而在真实搜索工作负载所处的大量访问主内存的场景中，这种优势会进一步扩大。

Int8。同样的模式在量化类型上也成立。我们测量了 1024 维 int8 点积的批量评分，数据集大小同样选择为超出 L1、L2、L3 缓存边界，将 simdvec 的批量评分与 NumKong 循环调用的单对评分进行了对比。

在 x86 上，simdvec 快 1.2 倍到 1.9 倍，这得益于显式预取和批处理的结合。在 ARM 上，simdvec 再次胜出，在所有数据集大小下快 1.7 倍到 1.9 倍。优势来自每次批处理四个向量，通过交错访问模式提供内存级并行性。在这两种情况下，最引人注目的结果都出现在最大数据集规模上，而这也正是最关键的场景。

平方距离和余弦计算的结果也呈现类似模式：ARM 上加速 1.4 倍到 1.8 倍，x86 上加速 1.3 倍到 3.0 倍（详见此处）。

当内存成为瓶颈

生产环境中的向量索引通常无法放入 CPU 缓存。一个包含 1,000 万个 1024 维 int8 向量的索引大小为 10 GB。为候选项评分意味着需要从 DRAM 流式读取数据，而这正是批量评分架构发挥作用的地方。

我们使用硬件性能计数器来测量批量评分过程中 CPU 内部的实际运行情况，结果发现，隐藏内存延迟需要两种截然不同的策略，每种架构各对应一种。

在 x86 上，显式预取大幅减少了缓存未命中。批量内核会按顺序处理向量，先完整计算一个向量，再处理下一个，同时为下一批数据发出预取指令。未来所需的数据在 CPU 需要之前就被拉入 L1 缓存。

在 ARM 上，即使使用预取，顺序处理方法也表现不佳。取而代之的是，批量内核采用交错加载策略：在每个步幅位置交错加载四个向量的数据，为乱序执行引擎提供四个独立的内存流。CPU 并没有加快取数速度，而是在内存请求在途时，通过始终保持有计算任务可做来减少等待时间。详细分析可参阅此 GitHub issue。

这些数字讲述了两个不同的故事：

1. 在 x86 上，预取将缓存未命中从 13.9 万次降低到 1.9 万次，每周期指令数 (IPC) 提升了一倍以上。批量处理的优势会随着数据集规模增长而扩大：当工作集位于 L2 时为 1.2 倍，超出 L3 后则达到 2.8 倍，因为预取能够掩盖越来越高的 DRAM 往返访问开销。

2. 在 ARM 上，缓存未命中几乎没有变化。真正变化的是利用率：后端停顿减少 40%，因为交错访问模式让流水线持续有任务可执行。这一优势在不同数据集规模下稳定保持在 1.8 倍，因为内存级并行性无论数据来自缓存还是 DRAM 都同样适用。

两种架构，两种策略，一个结果：在生产规模下，即使向量散落在主内存各处，simdvec 也能让 CPU 流水线保持忙碌。

这对 Elasticsearch 用户意味着什么

这些内核层面的能力会不断叠加。一次向量搜索查询可能会执行数百万次距离操作：HNSW 图遍历、候选项评分、重排序。在数千个并发查询下，每次操作的纳秒级差异都会直接影响查询延迟和集群吞吐量。无论您使用 float32、int8、bfloat16 还是 BBQ，无论您的索引在内存中还是磁盘上，simdvec 都是底层的引擎，而每一次操作都运行在这个引擎上，并经过了哪怕一纳秒都不放过的极致精细调优。

关键结论是，在生产规模下，向量搜索性能并不主要由原始 SIMD 吞吐量决定，而是取决于系统能否在持续处理数百万次小型操作的同时，高效掩盖内存延迟。

simdvec 内核几乎会随每个 Elasticsearch 版本持续改进。当新的量化类型和硬件平台出现时，它们从第一天起就能获得经过调优的内核。而现有类型也会随着我们不断优化已发布的实现而持续变快。

组织往往会积累大量文档，例如支持工单、法律文件、新闻资讯和研究论文；在提出正确的问题之前，首先需要了解这些文档里都包含哪些内容。没有标签或训练数据，手动审查数千份文档是不切实际的。当您不知道要搜索什么时，传统搜索无济于事。

本文将介绍一种 Elasticsearch 原生方法，用于无监督文档集群和时序故事追踪，帮助解决这一发现难题。读完本文后，您就可以像这样跨天追踪故事脉络：

您将发现：

• 为什么当您希望在没有查询的情况下进行主题发现时，集群嵌入（而非检索嵌入）至关重要。

• 如何借助 Elasticsearch 的 k 近邻 (kNN) 和批量 msearch，通过密度探测质心分类按主题对文档进行分组。

• significant_text 如何自动为集群添加标签，让主题在无需训练模型的情况下也能清晰呈现。

• 时间故事链如何将每日集群联系起来，展示主题如何逐日演变。

该管道以来自 BBC News 和 The Guardian 的约 8,500 篇 2025 年 2 月文章作为测试语料库。新闻之所以适合作为示例，是因为它具有清晰的时间演化特征；而在任何文档发现至关重要的场景中，这种模式同样适用，例如法律审查、合规监控、研究整合和客户支持分流。

技术栈：

• Jina v5 集群嵌入：用于主题分组的任务专用低秩自适应 (LoRA) 适配器。Jina 已加入 Elastic，其模型可通过 Elastic Inference Service (EIS) 原生调用。

• Elasticsearch：可扩展的 kNN、significant_text 标签生成和向量存储。

• DiskBBQ：一种基于磁盘的向量索引格式，结合了 Better Binary Quantization (BBQ) 与分层 k-means 分区，以加速近似最近邻 (ANN)。这种索引分区是向量搜索的内部机制，与本文使用的密度探测集群算法相互独立。与 bbq_hnsw 相比，bbq_disk 将量化向量存储在磁盘上，并仅在堆内存中保留分区元数据，在保持高召回率的同时，大幅降低了资源需求。

• 全局集群 + 每日时间链接：发现与故事演变。

您需要：

• Elasticsearch 部署（Elastic Cloud、Elasticsearch Serverless 或 Elastic 自托管 8.18+/9.0+）：bbq_disk 需要 8.18 或更高版本。可选的 diversify retriever 部分需要 9.3+ 或 serverless。

• Jina API 密钥：免费层级包含 1,000 万个 token，足以覆盖核心集群管道的需求（约 425 万个 token）。可选的 retrieval-versus-clustering 对比需要进行第二轮嵌入计算。

• Guardian API 密钥（免费）。

设置

安装所需软件包：

可选（仅当您从此仓库运行抓取帮助程序时）：

然后在项目根目录的 .env 文件中配置 API 密钥：

此笔记本调用 load_dotenv(override=True)，因此本地 .env 值优先。

第 1 部分：发现式集群 —— 为什么要使用集群嵌入？

大多数向量搜索都会使用经过训练的检索嵌入来将查询与相关文档进行匹配。这对于搜索非常合适，但并不适合用于发现。当您希望在没有任何查询的情况下找到语料库中的主题时，您需要使用能将相似文档组合在一起的嵌入。

Jina v5 通过面向特定任务的低秩适配 (LoRA) 适配器解决了这个问题。LoRA 在保持大部分基础模型权重冻结的同时，对目标内部层添加小幅低秩更新，使模型行为转向特定任务，而无需完全重新训练。同一基模型根据 task 参数产生不同的嵌入：

任务

训练用于

用例

检索.段落

查询-文档匹配

搜索，检索增强生成 (RAG)

聚类

主题分组（针对紧密集群进行优化）

发现与分类

集群适配器经过训练，使相同主题的文档在嵌入空间中更接近，而不同主题的文档则更远离。下面的可视化对比会更直观地呈现这种差异。

检索与集群：可视化对比

为了展示这种差异，我们分别使用两种任务类型对文档样本进行嵌入。集群在原始 1024 维嵌入空间中执行；Uniform Manifold Approximation and Projection (UMAP) 仅用于将这些嵌入投影到 2D 进行可视化。UMAP 保留局部邻域结构，因此可用于比较集群的分离程度。

下图展示了同一组 480 篇文档样本分别采用两种任务类型进行嵌入后，再通过 UMAP 投影到 2D 的结果。请观察集群面板中那些更紧密、彼此分离更明显的颜色分组。

检索嵌入（左）会更分散地铺开各个主题；集群嵌入（右）则会基于相同文档形成更紧密、彼此分离更明显的分组。

集群嵌入能够形成更紧密、视觉上也更清晰的分组。检索嵌入会更均匀地分布各个主题，因此非常适合搜索（细粒度相似度）；但对发现来说，更关键的是紧密的主题集群。

这就是为什么在本演练的其余部分中使用 task="clustering" 的原因。

加载数据集

该语料库结合了 2025 年 2 月的两个新闻来源：

• BBC News通过RealTimeData/bbc_news_alltimeHuggingFace 数据集。

• The Guardian 通过 Guardian Open Platform API。

纳入多个来源，有助于验证集群识别出的是真正的主题，而不是某个来源特有的写作风格。

使用集群任务进行嵌入

在调用 Jina v5 API 处理所有文档时均会传入 task="clustering"。嵌入会缓存到磁盘，因此后续运行会完全跳过 API。

API 调用很简单。task 参数是与典型嵌入使用的关键区别：

以下时间反映的是缓存命中情况。第一次对 API 运行时间更长，具体取决于语料库大小。

索引到单个 Elasticsearch 索引

对于发现式集群，整个月的数据都会写入同一个索引 (docs-clustering-all)。每日分区会在后续阶段进行，用于实现时间故事链接。

索引映射对向量字段使用 bbq_disk：

1024 维 float32 向量大小为 4 KB。 bbq_disk 使用分层 k-means 将向量划分为小集群，对其进行二进制量化，并将全精度向量存储在磁盘上以便进行二次评分。只有分区元数据保留在堆内存中，因此即使面对大型语料库，内存需求仍然较低。对于能够承受更多堆内存的工作负载，bbq_hnsw 构建分层可导航小世界 (HNSW) 图，以实现更快的查找，但资源消耗更高。

dense_vector 字段类型支持多种量化策略：bbq_disk 和 bbq_hnsw 最适合高维嵌入，例如此处使用的 1,024 维向量。

集群：基于密度探测的质心分类

传统的集群算法（如 HDBSCAN）假设您可以将完整的 N×d 向量矩阵保存在内存中，并运行重复的完整遍历更新。对于 8,495 篇 1024 维文档而言，这一规模尚可管理（约 35 MB）；但如果没有额外基础设施，这种方法就无法扩展到数百万篇文档。

从概念上看，该算法类似于采用 Voronoi 分配和噪声底限的 KMeans++ 初始化；但它将 Elasticsearch kNN 搜索作为计算原语，因此几乎所有工作都在服务器端完成。

1. 抽取 5% 的文件 作为密度探针（随机抽样，至少 50 个）。

2. 通过批量 msearch kNN 查询探测密度。每个探针发出 kNN 查询，并记录其邻居的平均相似度。高平均相似度 = 嵌入空间中的稠密区域。msearch 在单个 HTTP 调用中发送多个搜索请求，这一点至关重要：密度探测生成数百个 kNN 查询，批量处理可避免每个请求的开销。

3. 通过多样化策略选择高密度种子：将密度高于中位数的候选种子按密度从高到低排序，只有当它与每个现有种子的余弦相似度都低于分离阈值时，才按贪婪策略予以接受。这是唯一的客户端计算（8k 文档约 0.01 秒）。

4. 通过 msearch kNN 按质心对所有文档进行分类：每个种子都作为一个质心，kNN 搜索会检索相似度高于阈值的邻近文档。每个文档都会被分配给返回该文档且得分最高的质心。小集群被归为噪声。

Elasticsearch 负责处理核心计算：使用 msearch 进行密度探测和分类，并使用 significant_text 生成标签。对于该语料库（8,495 个文档），5% 的密度探针样本会发起 425 个 kNN 探针查询，msearch 会将其批量处理为 9 次 HTTP 调用（批大小为 50），从而避免每个探针单独发起一次请求的开销。再结合 bbq_disk ANN 查找，整个集群阶段便能兼顾速度与可扩展性。在集群过程中，kNN 查询会使用尽可能小的 num_candidates 值来提升速度；而在生产环境的搜索查询中，则应使用更高的 num_candidates 值，以牺牲一定延迟为代价换取更高的召回率。

集群的自然大小由每个质心周围的嵌入空间密度决定，而非硬性的 k 上限。主题越密集的区域，形成的集群就越大；而越小众的主题，则会形成更小的集群。

为什么不选择 KMeans 或 HDBSCAN？

KMeans 假设集群为球形，并需要将完整的 N×d 矩阵加载到内存中。对于适合内存的语料库，HDBSCAN 是一个强有力的替代方案。它既可以处理任意形状的集群，也具备更易理解的密度语义。

密度探测质心方法面向的是另一类场景：您希望在同一系统中完成存储、检索和集群，或者数据规模已经大到使客户端矩阵运算变得不切实际。它使用 Elasticsearch kNN 作为计算原语，处理任意大小的集群，并将几乎所有计算保留在服务器端。

理解噪声率

约 28% 的噪声率是有意为之，并不意味着系统出现了故障。在配置的 similarity_threshold 下，不属于任何密集集群的文档将保持未分配状态，而不是被强制匹配到不合适的集群中。这相当于一道质量门槛：评论专栏、短文和一次性报道往往难以形成集群，因为它们缺乏构成连贯分组所需的主题密度。

阈值可调：降低 similarity_threshold 会产生更激进的集群（分配更多文档，但集群更松散），提高则会收紧集群并增加噪声比例。对于这种包含混合新闻内容的语料库，约 30% 的噪声比例是一个合理的平衡点。生产部署应根据特定领域的质量标准调整阈值。

使用 significant_text 自动添加标签

现在，每个集群都需要一个便于人工理解的标签。Elasticsearch 的 significant_text 聚合会找出在前景集（集群）中出现异常频繁、而在背景集（完整语料库）中不常见的词项。

其底层采用统计启发式方法（默认为 JLH 分数），平衡了绝对频率与相对频率的变化，无需机器学习，也无需调用大语言模型 (LLM)。例如，一个关于英国政治的集群，可能会浮现出 starmer、labour、downing 等词项，因为与整体新闻语料库相比，这些词项在该集群中出现得异常频繁。

在这一全局处理阶段，标签直接基于 docs-clustering-all 计算，因此前景集和背景集都取自整个月的数据。在第 2 部分中，标签会使用每日索引模式 (docs-clustering-*)。这是一个通配符，可让查询同时覆盖所有匹配的索引，从而为 significant_text 提供更广泛的背景，以获得更好的对比效果。

一个最小查询形状如下所示：

significant_text significant_text 也可作为一道质量门槛：未产生任何显著词项的集群，说明其缺乏可区分的词汇特征。这类分组本身并不连贯，因此应归为噪声，而不应赋予带有误导性的标签。

一个轻量级的确定性清理步骤会移除噪声较大的标签词项（如数字 token 和通用词），并在必要时回退到代表性标题。这样既保留了 Elasticsearch 原生标签的特点，也提升了可读性。

集群可视化

下方的可视化结果展示了全局集群阶段的发现，包括按日期划分的集群文档与噪声文档分布、整个月的 UMAP 投影，以及用于验证集群反映的是主题而非来源的来源构成图。

2025 年 2 月期间，集群文档与噪声文档的每日分布情况。

UMAP 中的每个彩色岛屿都代表一个集群：一组关于同一主题的文章，纯粹是通过嵌入相似性而发现的。灰色噪声点则是未能明确归入任何集群的文章（通常是短篇文章、观点文章或一次性报道）。

来源细分图表确认，集群中的文章同时来自 BBC News 和 The Guardian。集群找到的是主题，而非来源，这正是无监督发现应该产生的结果。

使用 diversify retriever 探索集群的广度

普通 kNN 返回与集群质心（密集核心）最相似的文档。但真实的集群往往还会涵盖多个子主题。diversify retriever 使用最大边际相关性 (MMR)，呈现既与质心相关、彼此之间又有所差异的文档。

关键参数是λ（lambda）：

• λ = 1.0 → 纯相关性（与普通 kNN 相同）。

• λ = 0.0 → 纯多样性（结果最大程度分散）。

• λ = 0.5 → 均衡：既与主题保持相关，又能覆盖不同角度。

最简 retriever 请求结构如下：

在 diversify 层级，type、field 和 query_vector 参数均为必需：field 用于告知 MMR 应使用哪个 dense_vector 字段来计算结果之间的相似度，而 query_vector 则提供相关性评分的参考向量。

这可以让您回答：“这个集群到底涵盖了什么？”而不仅仅是“它的中心是什么？”

普通 kNN 的结果往往集中在主题的某一个侧面，也就是那些与质心最相似、彼此之间也最相似的文档。diversify retriever 则会展示同一集群的不同侧面，包括子主题、不同来源和多样化视角。

多样性指标定量证实了这一点：diversify retriever 结果的平均两两相似度较低，意味着返回的文档覆盖范围更广。

这适用于：

• 理解一个集群实际涵盖的范围，不仅要关注其中心，还要关注其边缘。

• 生成摘要。多样化且有代表性的文档为 LLM 提供了更好的素材。

• 寻找代表性示例，用于人工审核或下游标签生成。

• 质量检查。如果多样化结果看起来不够连贯，就说明这个集群可能需要进一步拆分。

第 2 部分：时间故事链

跨天追踪故事

第 1 部分对整个月的数据进行了全局集群，以发现其中的主题。为了呈现时间演化，同样的密度探测质心分类会按天在每日索引上独立运行，再将相邻日期的集群连接起来。请注意，每日集群与第 1 部分中的全局集群相互独立；每天都会生成自己的集群分配和标签，并根据当天的内容进行调整。

链接方法：采样与查询

对于第 A 天的每个集群：

1. 采样几个代表性文档。

2. 对 B 天的索引运行 kNN。

3. 统计落入 B 天每个集群的命中数量。

4. 如果命中比例超过阈值（kNN 比例 ≥ 0.4），则记录一条链接。

这速度很快（每个集群只查询少量文档，不是全部），并且使用 Elasticsearch 的原生 kNN，无需外部工具。

kNN 比例达到 100% 表示源集群中的所有采样文档都落入同一个目标集群，也就是强度最高的跨日关 流水以上大多数关联都与足球相关，这很合理：英超联赛的报道每天都有，且主题一致性很高。

score | operator | gedling → league | striker | season 链接是一个小众本地足球集群（Gedling 是一家非联赛俱乐部）在第二天被吸收到更广泛的英超联赛集群中的一个例子，这是每日以不同粒度重新集群的自然效果。

构建故事链

故事链是由连续多天的关联集群组成的序列。

单个配对链接可以显示周一与周二“英国政治”集群之间的关联。故事链则能揭示完整的发展脉络：一个故事从周一开始，在一周内持续发展，并在周五逐渐淡出。

链通过贪婪策略构建，所依据的是 kNN 比例 ≥ 0.4 的关联；这意味着源集群中至少有 40% 的采样文档会落入同一个目标集群。算法从最早出现的集群开始，并始终沿着最强的出向关联继续延伸。

最长的链条连续 19 天追踪乌克兰–俄罗斯相关报道。考虑到 2025 年 2 月持续紧张的地缘政治局势，这并不令人意外。其次是贯穿当月 19 天的英超足球报道。更短的链条则对应于颁奖季（电影/颁奖，6 天）、六国橄榄球赛（10 天）以及英国政治领导层相关报道（7 天）。每条链都代表一条故事轨迹，这些轨迹完全是基于每日索引之间的嵌入相似性自动发现的。

Sankey：可视化故事流

Sankey 图是一种流向可视化图表，其中连线宽度表示连接强度。在这里，每个垂直条带代表一天，每个节点代表一个每日集群（大小由文档数量决定），每条彩色路径则描绘出一条跨时间延展的故事链。链接宽度表示 kNN 重叠强度：更粗的链接意味着更多采样文档落入目标集群。每条链都使用统一颜色，因此从左到右的一条同色路径就代表一个故事的发展过程。

例如，乌克兰－俄罗斯链（作为较长路径之一清晰可见）从 2 月初一直延续到第三周；其链接始终较粗，表明该主题在不同日期之间具有很强的连续性。

时间故事链贯穿 2025 年 2 月。每条彩色路径都代表一个跨天延续的故事；连线宽度表示 kNN 重叠强度。

这种方法的成果

本文完整介绍了基于 Elasticsearch 构建的无监督文档集群管道：

1. 集群嵌入：Jina v5 的任务专用适配器可生成针对主题分组优化的嵌入，而不仅仅是用于查询-文档匹配。

2. 全局发现式集群：在一个索引中对整个月的数据进行集群，可最大限度地发掘跨日主题。

3. 密度探测质心分类：取样 5%，通过 msearch kNN 探测密度，选择不同的高密度种子，再根据这些质心对所有文档进行分类。Elasticsearch 负责处理大部分计算任务；客户端仅负责耗时极短（约 0.01 秒）的种子选择工作。

4. significant_text标签生成：无需借助 ML 模型或人工标注，显著性检验就能生成有意义的集群标签。无法产生任何显著词项的集群，说明其内部缺乏连贯性，因此会被降为噪声——这也是一种内置的质量控制机制。

5. 时间故事链接：借助每日索引以及跨索引的采样与查询 kNN，追踪故事如何随时间演变。

关键要点：

• 嵌入任务类型至关重要：集群嵌入能够形成明显更紧密的主题分组。

• 借助 kNN 搜索，Elasticsearch 既可以充当存储层，也可以充当集群引擎。

• 密度探测质心分类几乎将所有计算保留在服务器端，并生成由嵌入空间密度决定的自然大小的集群。

• significant_text 该方法速度快、可解释性强，在自动标注和质量门控方面同样十分有效。

这种方法适用的场景：

• 您拥有带有时间戳的文本，且希望在无标注训练数据的情况下进行主题发现。

• 您希望使用同一套技术栈完成存储、向量搜索、标注和时间关联。

还可以进一步探索的扩展方向：

• 多周期集群（如按周、按月汇总）

• 通过增量集群分配进行实时摄取。

• 以 significant_text 词项为种子生成 LLM 集群摘要。

• 在更大规模下，采样得到的 KMeans 质心可以作为基于密度的集群算法的热启动种子，从而降低探测阶段的成本。

亲自试用

您可以将其替换为自己的带时间戳文档语料库；任何包含日期信息的文本集合都适用于这一管道。完整的笔记本和支持代码可在 配套仓库中找到。

• 开始免费试用 Elastic Cloud：几分钟内即可启动一个支持 bbq_disk 的托管集群。

• 试用 Elasticsearch Serverless：无需管理集群，可自动扩展，并支持本演练涵盖的全部内容。

Elasticsearch 拒绝了延迟到达的指标。这些拒绝导致管道滞后，导致更多的延迟数据，从而引发了更多的拒绝。最终，该管道彻底停滞了。

我们不得不从快照中恢复数据，重新索引数据，并重新设计摄取管道以恢复数据。

根本原因并非索引生命周期管理 (ILM) 本身。而是时序数据流 (TSDS) 以及它们如何执行有时间限制的后备索引。

TSDS 可以将指标的存储需求减少 40——70%，但使 TSDS 高效的架构更改也改变了索引随时间推移的行为方式。这些变化在设计 ILM 策略或数据摄取管道可能会产生延迟到达的数据时非常重要。

简要说明

使用 TSDS 时：

• 后备索引仅接受特定时间窗口内的文档。

• 如果在索引移动到冷冻或冻结状态后有延迟的数据到达，Elasticsearch 将拒绝接受这些文档，或将其路由到故障存储（如果已配置）。

设计规则：

什么是时序数据流？

时序数据流 (TSDS) 是针对指标数据进行了优化的专用数据流。对数据进行路由，使相关文档位于同一分片内，从而优化它们以进行查询和检索。下面介绍 Elasticsearch 如何实现这一操作：

每个文档包含：

• 时间戳。

• 用于识别时间序列的维度字段。

• 表示测量值的度量字段。

示例包括：

• 每台主机的 CPU 使用率。

• 每项服务的请求延迟。

• 每个传感器的温度读数。

维度 确定了我们要测量的内容，而度量 则代表了随时间变化的值。

尺寸

维度描述被测量的实体。

示例:

我们在映射中按以下方式定义它们：

指标

指标代表数值，并使用以下方式定义：

常用指标类型：

• 计量：数值会上升和下降。

• 计数器：数值不断增加，直至重置。

Elastic Agent 主要收集指标和日志数据，因此，即使您没有手动启用任何 TSDS 索引，集群中仍可能包含这些索引。

_tsid 字段

Elasticsearch 内部会根据维度字段生成 _tsid 值。这样，具有相同尺寸的文档就可以路由到相同的分区，从而改进：

• 压缩。

• 查询位置。

• 聚合性能。

关键区别：有时间限制的后备索引

传统数据流始终写入最新的支持索引，称为 写索引，但 TSDS 的行为有所不同。

每个 TSDS 后备索引都有一个定义的时间窗口，并且仅接受 @timestamp 值在该窗口内的文档：

为文档编制索引时，Elasticsearch 会将其路由到负责该时间戳的后备索引，这意味着与传统索引不同，TSDS 可以同时写入多个后备索引。

例如：

• 实时数据 → 最新索引。

• 较晚的数据 → 覆盖该时间范围的较早索引。

为延迟到达的数据进行设计

真正的摄取管道很少能完美地按时提供指标。指标可能会由于网络中断、传输过程中的积压、批量摄取以及边缘设备的丢失而延迟，这些设备重新连接后会开始追赶进度。

传统索引会悄然吸收这些延迟。TSDS 不会。

如果文档的时间戳超出了可写后备索引的范围，Elasticsearch 将拒绝该文档，这意味着您的 ILM 策略必须考虑延迟数据。

关键制约因素

后备索引必须保持足够长的可写时间，以接受延迟数据。

实际上：

由于 ILM 衡量的是从滚动更新开始算起的年限，因此操作规则变为：

例如，如果指标最多可能延迟六小时到达，则索引在滚动更新后必须保持至少六小时的可写状态。

正是由于没有考虑到这一限制，才导致了前面所述的摄取失败。延迟到达的数据被定向到一个早期索引，该索引已经处于冷层并因此被写入阻塞。

处理被拒绝的文档

当 TSDS 拒绝文档时，Elasticsearch 返回一个错误，表明时间戳不在可写索引的范围内。您的摄取管道如何处理该错误，决定了是丢失数据还是停止摄取。

处理被拒绝文档的主要机制是故障存储。

故障存储（在 Elasticsearch 9.1+ 中推荐）

Elasticsearch 9.1 引入了失败存储，它能自动捕获被拒绝的文档。Elasticsearch 不会将错误返回给客户端，而是将失败的文档写入数据流中的专用失败索引。

您可以使用以下方法检查故障：

使用故障存储可防止摄取管道因拒绝错误而阻塞，同时保留失败的数据以供分析或重新索引。

监测拒绝问题

延迟到达问题通常首先表现为摄取异常。您可能会先注意到它们：

• 索引速率突然下降。

• 拒绝的文档激增。

• 越来越多的故障存储条目。

• 管道输入和输出计数不匹配。

通过对这些信号发出警报，操作人员可以在管道停滞之前检测问题。工作流、机器学习作业和其他机制可用于自动检测和通知。

TSDS + ILM 迁移检查清单

如果要将指标集群迁移到 TSDS、引入 ILM 分层，或升级到指标默认为 TSDS 的 Elasticsearch 版本，请先查看这些项目。

1. 测量摄取延迟

在更改 ILM 策略之前，请确定：

• 正常摄取延迟。

• 事件期间的最坏延迟情况。

• 批量管道造成的延迟。

您的 ILM 设计必须适应最大实际延迟。

2. 验证索引时间窗口

检查您的 TSDS 支持索引：

寻找：

• time_series.start_time

• time_series.end_time

这些界限决定了哪些索引可以接受文档。了解这些时间窗口有助于您确定数据最多可以延迟多久才不会被拒绝。

3. 为延迟到达的数据调整热层的大小

确保后备索引保持可写状态的时间足够长，以便写入延迟到达的数据。

操作规则：

• warm_min_age > rollover_max_age + maximum_expected_lateness

请记住，如果指标可能晚到六个小时，那么索引必须至少在六个小时内保持可写状态。

4. 决定如何处理被拒绝的文档

在启用 TSDS 之前选择策略：

• 故障存储（在 Elasticsearch 9.1+ 中推荐）。

• Logstash 死信队列。

• 为延迟到达的数据提供后备索引。

• 接受有限的数据丢失。

5. 监测摄取健康状况

为以下内容添加警报：

• 索引速率下降。

• 已拒绝的文档。

• 故障存储增长。

• 管道输入/输出不匹配。

数据延迟问题通常首先表现为摄取异常。

总结

时序数据流为指标工作负载提供重大的存储和性能改进，但它们引入了重要的架构变更：后备索引是时间绑定的，这影响了 ILM 的行为。

使用 TSDS 时：

• 索引必须保持足够长的可写时间，以接受延迟数据。

• 摄取管道应安全处理被拒绝的文档。

要记住的关键规则是：

如果围绕这一约束条件设计 ILM 策略，TSDS 就能很好地处理指标工作负载。

但若忽视这一限制，您的摄取管道可能会很难发现这些时间界限。

您的第一个查询

首先定义一个映射到 Elasticsearch 索引的普通旧 CLR 对象 (POCO)。属性名称通过标准System.Text.Json 属性（如[JsonPropertyName]）或配置的JsonNamingPolicy 解析为 ES|QL 列名。适用于客户端其他部分的源序列化规则在这里也同样适用。

类型设置完成后，查询语句如下所示：

该提供程序将此转换为以下 ES|QL：

需要注意的一些细节：

• 属性名称解析：由于 [JsonPropertyName] 属性，p.Price 变成了 price_usd，根据默认 camelCase 命名策略，p.Brand 变成 brand。

• 参数捕获：C# 变量 minPrice 和 brand 被捕获为命名参数 (?minPrice，?brand)。它们与 JSON 有效负载中的查询字符串分开发送，这样可以防止注入，并实现服务器端查询计划缓存。

• 流式传输：QueryAsync<T> 返回 IAsyncEnumerable<T>。从 Elasticsearch 返回数据时，数据会逐行具体化。

您还可以在不执行的情况下检查生成的查询及其参数：

这如何运作？快速回顾一下 LINQ

使 LINQ 提供程序成为可能的机制是 IEnumerable<T> 和 IQueryable<T> 之间的区别。

在 IEnumerable<T> 上调用 .Where(p => p.Price > 100) 时，lambda 会编译为 Func<Product, bool>，即一个由运行时在进程内执行的常规委托。这就是 LINQ-to-Objects。

当您在IQueryable<T> 上调用相同的方法时，C# 编译器会将 lambda 封装在Expression<Func<Product, bool>> 中。这是一种数据结构，表示代码的结构，而不是代码的可执行形式。在运行时，该表达式树可被检查、分析，并转换为另一种语言。

IQueryProvider 接口是扩展点。任何提供程序均可通过实现 CreateQuery<T> 和 Execute<T>，将这些表达式树转换为目标语言。实体框架就是利用此机制生成 SQL 语句。LINQ to ES|QL 提供程序使用它来生成 ES|QL 查询。

上述查询的表达式树如下所示：

示例查询的表达式树。

此表达式树由内而外嵌套：Take 包裹着 OrderByDescending，它又包裹着 Where，而后者再包裹着 From，而最内层是根节点 EsqlQueryable<Product> 常量。对于 &&、>= 和 == 这几种操作符而言，Where 谓词本身是一个由 BinaryExpression 个节点构成的子树，其中包含 MemberExpression 个叶子节点，这些叶子节点用于属性访问，以及对 minPrice 和 brand 变量的闭包捕获。提供程序会遍历这一数据结构，从而生成最终的 ES|QL 查询。

深入了解：转换管道

从 LINQ 表达式到查询结果的路径遵循六阶段管道：

转换管道概述。

1. 表达式树捕获

当在一个 IQueryable<T> 对象上串联使用 .Where()、.OrderBy()、.Take() 及其他操作符时，标准的 LINQ 基础架构会构建一个表达式树。EsqlQueryable<T> 实现了 IQueryable<T> 接口，并将处理委托给 EsqlQueryProvider。

2. 翻译

当查询被执行 (通过枚举、调用 ToList()，或使用 await foreach) 时)，EsqlExpressionVisitor自内而外遍历表达式树。它会将每个 LINQ 方法调用分派给一个专门的访问器进行处理：

访客

翻译

进入

WhereClauseVisitor

.Where(predicate)

WHERE 条件

SelectProjectionVisitor

.Select(selector)

评估 + 保留 + 重命名

GroupByVisitor

.GroupBy().Select()

统计信息 ... 依据

OrderByVisitor

.OrderBy() / .ThenBy()

SORT 字段 [ASC\|DESC]

EsqlFunctionTranslator

EsqlFunctions.*、Math.*、字符串方法

80+ ES|QL 函数

在翻译过程中，表达式中引用的 C# 变量被捕获为命名参数。

3. 查询模型

访问器不会直接生成字符串。相反，它们会产生 QueryCommand 对象，一个不可变的中间表征。一个 FromCommand、一个 WhereCommand、一个 SortCommand 和一个 LimitCommand，各代表一条 ES|QL 处理命令。这些数据被收集到EsqlQuery 模型中。

查询模型和命令模式。

该中间模型与表达式树和输出格式均解耦。它可以被检查、拦截（通过 IEsqlQueryInterceptor）或在格式化前进行修改。

4. 格式化

EsqlFormatter 依次访问每个QueryCommand ，并生成最终的 ES|QL 字符串。每条命令占一行，通过 ES|QL 中用于串联处理命令的管道 (|) 运算符分隔。若标识符包含特殊字符，系统会自动用反引号进行转义处理。

5. 执行

格式化后的 ES|QL 查询字符串及捕获的参数会以 JSON 数据载荷的形式发送至 Elasticsearch 的 /_query 终端。而 IEsqlQueryExecutor 接口则对传输层进行了抽象封装，这正是分层包架构发挥作用的关键环节。

6. 实现

EsqlResponseReader 流式传输JSON响应，但不会将整个结果集缓冲到内存中。以流式方式传输 JSON 响应数据，无需将整个结果集缓存至内存。针对每次查询预先计算生成的 ColumnLayout 树结构，会将扁平化的 ES|QL 列名（如 address.street、address.city）映射到嵌套的 POCO 属性。每行数据会被组装为 T 实例，并通过 IEnumerable<T> 或 IAsyncEnumerable<T> 逐个返回。

分层架构

LINQ to ES|QL 功能分为三个软件包：

软件包架构。Elastic.Esql 是纯转换引擎。该组件完全不依赖 HTTP 协议栈，集成了表达式访问器、查询模型、格式化器及响应解析器等核心模块。您可独立使用它来构建和检查 ES|QL 查询（无需连接 Elasticsearch），这在测试验证、查询日志记录或自定义执行层开发等场景中极具实用价值。翻译要点解析：

Elastic.Clients.Esql 是一款轻量级的独立 ES|QL 客户端。该组件通过 Elastic.Transport 在 Elastic.Esql 之上扩展了 HTTP 协议执行能力。如果您的应用程序仅需使用 ES|QL 而无需其他 Elasticsearch API，此方案可实现最小化依赖集成。

Elastic.Clients.Elasticsearch 是完整的 Elasticsearch.NET 客户端。它还建立在Elastic.Esql 的基础上，并通过client.Esql 命名空间公开 LINQ 提供程序接口。这是大多数应用程序的推荐入口点。

两个执行层组件包均提供了针对 IEsqlQueryExecutor 接口的独立实现。该策略接口作为转换与传输层的桥梁。

当与源码生成的 JsonSerializerContext 配合使用时，这三个组件包均支持原生 AOT 编译。如需完整客户端集成方案，请参阅原生 AOT 文档。

不只使用基础功能

上面的例子涵盖了筛选、排序和分页。该提供程序支持更广泛的操作范围。

聚合

GroupBy结合 Select 中的聚合函数，转换为 ES|QL STATS ... BY：

投影

Select，使用匿名类型生成 EVAL、KEEP 和 RENAME 命令：

丰富的函数库

通过 EsqlFunctions 类，可以使用超过 80 个 ES|QL 函数，涵盖日期/时间、字符串、数学、IP、模式匹配和评分。标准 Math.* 和 string.* 方法也已转换：

查找连接

跨索引查找转换为 ES|QL LOOKUP JOIN：

原生 ES|QL 直通接口

对于 LINQ 提供程序尚未涵盖的 ES|QL 功能，您可以添加原始片段：

服务器端异步查询

对于长时间运行的查询，可将其提交给服务器进行后台处理：

服务器端异步查询对于长时间运行的分析型查询/大规模数据集处理尤其有用，这类操作可能会超出常规的超时阈值；在存在负载均衡器、API 网关或代理（这些组件会强制执行严格的 HTTP 超时设置）的超时敏感环境中，异步查询同样优势显著。异步查询通过将查询提交与结果获取解耦，避免了连接中断的情况。

开始使用

LINQ to ES|QL 自以下版本起可用：

• Elastic.Clients.Elasticsearch v9.3.4（9.x 分支）

• Elastic.Clients.Elasticsearch v8.19.18（8.x 分支）

从 NuGet 安装：

dotnet add package Elastic.Clients.Elasticsearch

入口点位于client.Esql上：

方法

返回值

用例

查询<T>(...)

IEnumerable<T>

同步执行

QueryAsync<T>(...)

IAsyncEnumerable<T>

异步流式处理

CreateQuery<T>()

IEsqlQueryable<T>

高级结构分析和检测

SubmitAsyncQueryAsync<T>(...)

EsqlAsyncQuery<T>

长时间运行的服务器端查询

有关完整的功能参考，包括查询选项、多字段访问、嵌套对象和多值字段处理，请参阅LINQ to ES|QL 文档。

结论

LINQ 转 ES|QL 将 C# LINQ 的强大表达能力引入到 Elasticsearch 的 ES|QL 查询语言中，让您无需手工编写查询字符串，就能生成强类型、可组合的查询。它具备自动参数捕获、流式物化功能，还拥有分层式的软件包架构，既能满足独立转换需求，也能适配完整的 Elasticsearch 客户端，可自然融入任意规模的 .NET 应用程序。安装最新客户端，将 LINQ 表达式指向索引，剩下的就交给该提供程序来处理。

为了解决这个问题，像 Elasticsearch 这样的搜索引擎使用了两种主要的优化策略：

1. 近似搜索（分层可导航小世界 [HNSW]）：我们不需要扫描每一份文档，而是建立一个导航图，以便快速跳转到答案的可能邻域。

2. 量化：我们对向量进行压缩（例如，从 32 位浮点数压缩为 8 位整数，甚至 1 位二进制值），以减少内存使用量并加快计算速度。

但优化往往会使准确性下降。

这种担忧是有道理的：“如果我在搜索过程中压缩数据并使用快捷方式，我会错过最佳结果吗？”“这种优化是否会降低搜索引擎的相关性？”

为了证明 Elastic 的量化不会降低结果，我们使用DBPedia-14 数据集构建了一个可重复的测试工具，以精确计算在使用 Elasticsearch 的默认优化时，准确率下降了多少（特别是召回率）才能提高速度。

总结：可能比您想象的要少得多。点击此处查看笔记本，亲自试试

定义（面向非专业人士）

在了解代码之前，让我们先明确一些术语。

• 相关性与召回率：相关性具有主观性（我找到的是优质内容吗？），而召回率则是基于数学计算。如果数据库中有 10 份文档与查询在数学层面完美匹配，而搜索引擎找到了其中 9 份，那么召回率就是 90%（或 0.9）。

• 精确搜索（扁平式）：有时也被称为“暴力搜索”法。搜索引擎会扫描索引中的每一份文档并计算距离。

  • 优点：召回率达到 100%。

  • 缺点：计算量大且大规模扩展缓慢。

• 近似搜索 (HNSW)：“捷径”方法。搜索引擎生成 HNSW 图表。它遍历图表以找到最近邻。

  • 优点：速度极快且可扩展。

  • 缺点：如果图表遍历过早停止，可能会错过近邻。

实验：精准与近似

为了测试召回率，我们使用了 DBPedia-14 数据集，这是一个包含 14 个本体类别的大型标题和摘要数据集，通常用于训练和评估文本分类模型。具体而言，我们将重点关注“电影”类别。我们希望将优化的生产设置与数学上完美的基准真值进行比较。

在此次实验中，我们采用 jina-embeddings-v5-text-small 模型。这是一款处于行业领先水平的多语言模型，在文本表征方面树立了行业基准。我们选择该模型，是因为它确立了当下高性能嵌入的标杆标准。通过将 Jina v5 卓越的精准度与Elasticsearch原生量化技术相结合，我们能够展示一种既具备高效计算能力，又在检索质量上毫不妥协的搜索架构。

我们设置了一个具有双重映射的索引。我们同时将相同的文本导入两个不同的字段：

1. content.raw类型：flat。这会使 Elasticsearch 对全部 Float32 向量执行暴力扫描。通过这种扫描，系统会返回完全匹配的结果，并将用于我们的基线。

2. content类型为semantic_text。默认情况下使用 HNSW + 更好的二进制量化 (BBQ)。这是用于近似匹配的标准、优化生产设置。

Recall@10 测试

在我们的评估指标中，我们使用了 Recall@10。

我们随机挑选了 50 部电影，并对这两个字段运行了相同的查询。

• 如果精确（扁平式）搜索显示前 10 个近邻是 ID [1, 2, 3……10]，

• 而近似 (HNSW) 搜索结果显示的是 ID [1，2，3... 9，99]。

• 我们正确地找到了前 10 个中的 9 个。得分为 0.9。

这是我们使用的映射：

结果：成功的“平直线”

我们进行了一次规模测试，重新加载了整个数据集，并对 1,000 到 40,000 个文档的索引规模进行了测试。

召回率得分情况如下：

文档

Recall@10得分

1,000

1.000 (100%)

5,000

0.998 (100%)

10,000

0.992 (99.4%)

20,000

0.999 (99.0%)

40,000

0.992 (98.8%)

结果非常稳定。即使我们扩大了搜索范围，近似搜索也能在 99% 的情况下与暴力精确搜索相匹配。

为什么它如此有效？

您可能会认为将向量压缩成二进制值会对准确性的影响更大。不这样做的原因在于 Elasticsearch 处理检索的方式。

目前大多数嵌入模型输出的是 Float32 向量，这些向量很大。为了提高搜索效率，Elasticsearch 对高维向量使用量化技术。具体来说，自 9.2 版起，它默认使用BBQ。

BBQ 采用重新打分机制：

1. 遍历：搜索引擎使用压缩（量化）向量来快速遍历 HNSW 图表。由于向量较小，它可以高效地进行过度采样，收集更大的候选文档列表（例如，前 100 个大致相似的文档），而不会影响性能。

2. 重新评分：一旦有了这些候选文件，它就会只检索这几份文件的全精度值，以计算出最终的精确排名。

这样就能两全其美，既能以量化的速度完成繁重的工作，又能以浮点运算的精度完成最终排序。

我们能做得更好吗？

值得注意的是，我们在这里看到的结果是使用默认设置和随机抽样数据得出的。可以将其视为高性能的起点。尽管 Jina v5 性能卓越，但这些召回率分数并非适用于所有数据集的“万能保障”。每个数据集都有其独特之处，虽然您肯定可以进一步调整优化以挖掘出更多性能潜力，但您始终应基于自身特定数据进行基准测试，以明确性能上限所在。

结论

这是一次规模非常小的测试。不过，本次测试的重点并非专门评估嵌入模型或 BBQ 的性能，而是要展示如何通过极简的设置轻松衡量数据集的召回率。

如果您想用自己的数据运行此测试，可以点击此处查看笔记本，亲自试试。

在 HNSW 中，搜索过程是通过在图中迭代扩展候选节点来推进的，同时维护一个迄今为止已发现的、规模受限的最近邻节点集合。每次扩展都会带来一定的影响（包括向量运算、磁盘随机寻址等操作），并且随着搜索的推进，这种影响所带来的边际效益往往会逐渐降低。

优化 HNSW 图遍历的一种方法是，当发现新真实邻近节点的边际概率不再提升时，立即停止搜索。因此，在 Elasticsearch 9.2 中，我们引入了新提前终止机制。当连续访问图节点的次数达到固定数量，但仍无法提供足够的新最近邻节点时，搜索过程就会停止。

本文将指导您了解我们如何改进 HNSW 中提到的提前终止机制，使其更适合不同的数据集和数据分布。

HNSW 中的提前终止

在 HNSW 中，搜索过程是通过在近邻图中迭代扩展候选节点来推进的，同时持续维护一个迄今已发现、规模受限的最近邻节点集合，直至搜索遍历完整个图，或者满足某些提前终止条件为止。

因此，提前终止不一定总是性能优化，它本身就是搜索算法不可或缺的组成部分。决定终止搜索的时机，直接决定了效率与召回率之间的权衡关系。在 Elasticsearch 中，针对 HNSW 图的查询已内置多种提前终止机制：

• 访问节点的最大数量固定不变。

• 已达到固定的超时时间。

这些规则虽然简单且可预测，但在很大程度上与搜索的实际操作无关。此外，它们主要用于确保最终用户在合理的时间内完成查询。

在上一篇博文中，我们介绍了 HNSW 冗余的概念。简而言之，当 HNSW 持续评估那些无法带来更多最近邻节点的新候选节点时，就会产生冗余计算。

耐心：衡量进展而非过程

“耐心”这一概念将提前终止的判定标准重新定义为“衡量进展而非过程”。

而不是问：

“我们走了多少步？”

新的问题变成了：

"在我们彻底丧失希望之前，我们能够接受浪费多少计算量？"

在 HNSW 搜索过程中，早期探索阶段通常能显著提升前 k 个候选结果集的质量。在 HNSW 图探索的初始阶段，随着算法不断发现与查询向量距离更近的邻近节点，邻近节点集会持续更新。随着搜索逐步收敛，这类质量提升会逐渐减少。基于“耐心”机制的终止策略会监测这一变化模式，当持续一段时间内未再出现显著改进时，即终止搜索过程。

在实际操作中，我们在遍历 HNSW 图的过程中，每跳转到一个候选节点时，都会计算队列饱和度。该指标用于衡量在访问最近一个图节点期间，未发生变化的最近邻节点所占的百分比（或者说，是上一轮迭代中引入的新邻节点数量的倒数）。若连续多次迭代中，这一比率持续过高，我们便会停止对图的遍历。

从概念层面来看，“耐心”机制将HNSW搜索视为一个收益递减的过程。当搜索收益趋于平稳时，继续遍历图结构所带来的增益将微乎其微。

这种框架之所以强大，是因为它将终止与可观察到的结果直接联系起来，而不是与任意的固定限制联系起来。

采用这种智能提前终止技术的优势在于，HNSW 图探索过程在保持近乎完美的相对召回率的同时，往往会访问更少数量的图节点。

为了直观地说明这一点，我们可以在几个数据集（FinancialQA 和 Quora）和模型（JinaV3 和 E5-small）上绘制基于耐心的提前终止（标注为 et=static）与默认 HNSW 行为（标注为 et=no）的对比图。

静态阈值和 HNSW 动态

实际上，Elasticsearch 使用静态阈值来实现这一点。其中一个阈值指的是饱和阈值，即我们认为次优的饱和度比率。另一个阈值指的是，在队列达到次优饱和度的情况下，我们允许访问的连续图节点数，即耐心阈值。

当我们在 Elasticsearch 9.2 中引入这种提前终止策略时，我们决定选择保守的默认设置，以便在延迟和内存消耗方面仍能达到效果的同时，尽可能多地让系统召回。因此，我们将饱和阈值设为 100%，耐心阈值设为 KNN 查询中 num_candidates 的（有界）30%。

在很多情况中，这些设置能取得不错的效果；然而，对于请求相同数量邻节点的两个查询而言，它们的收敛行为可能存在极大差异。有些查询会遇到密集的局部邻域，能迅速达到饱和状态；而有些查询则必须遍历漫长且稀疏的路径，才能找到具有竞争力的候选节点。事实证明，后一种情况最难以有效处理。

因此，我们有时会发现：

• 简单查询的过度探索。

• 复杂查询的过早终止。

因此，我们认为固定阈值编码了关于收敛的全局假设，而我们可以使 HNSW 更好地适应不同的动态。

实现 HNSW 的提前终止自适应

自适应提前终止从另一个角度解决了这个问题。该算法不是强制执行预定义的停止阈值，而是从搜索动态本身推断何时停止。

因此，我们不再比较连续两个候选节点间的队列饱和度比率，而是决定引入即时平滑发现率 （即最近一次访问 i 中，针对查询 q 新发现的邻近节点数量），同时结合图遍历过程中该发现率的滑动均值 和标准差（采用韦尔福德算法计算）。这些关于发现率的统计量按每个查询独立计算，从而可根据不同查询的特性动态调整其“耐心”阈值。

先前静态设定的阈值将根据发现率统计数据实现自适应调整：饱和阈值调整为滚动均值加上标准差；同时，我们将耐心值设为与标准差呈反比变化的动态参数。

提前退出的规则保持不变；当瞬时发现率低于自适应饱和阈值时，即判定达到饱和状态。如果在连续访问的候选节点数量超过自适应耐心值所设定的次数后，饱和状态仍持续存在，则停止对图的遍历。

如此一来，我们实现了搜索行为不再依赖于 KNN 查询中的 num_candidates 参数（该参数可能始终被设定为固定值或保留默认值，而与提前终止机制无关），同时能够根据每个查询和向量分布进行动态适配。

在 FinancialQA 和 Quora 数据集上，采用自适应策略（标记为 et=adaptive）时，每个访问节点的召回率相较于静态策略（ et=static）和默认 HNSW 行为（et=no）均有显著提升。

在 Elasticsearch 9.3 中，HNSW 密集向量字段的自适应提前终止默认处于启用状态（最终可以通过相同的索引级别设置将其关闭）。

我们在 2000 万文档语料库上进行的基准测试显示，Elasticsearch 在过滤向量搜索方面的吞吐量比 OpenSearch 高达 8 倍，同时在我们测试的配置中也实现了更高的 Recall@100。上下文工程不仅仅依赖快速的向量检索。随着工作流的迭代，团队还需要强大的相关性控制（如混合搜索和过滤）、操作简便性和可预测的性能。但是，由于智能体通常会在每个请求中多次运行检索、推理、检索循环，因此检索延迟会成倍增加，所以这方面的改进会直接转化为更好的端到端响应能力和更低的成本。

对于上下文工程来说，检索不是一次性的步骤。智能体和应用程序会反复运行循环，例如检索→推理→检索，以完善查询、验证事实、组合基础上下文并完成任务。这种模式在智能体工作流和迭代检索增强生成 (RAG) 中很常见。由于每个用户请求可能会多次调用检索，这会增加响应延迟和/或增加基础设施成本。

为什么向量搜索性能至关重要？

想象一个购物助手回答以下问题：“我需要一个价格在 60 美元以下的随身背包，它可以容纳一台 15 英寸的笔记本电脑、防水，并且可以在周五之前送达。”

在生产环境中，助手很少只发出一个向量查询然后停止。它会运行一个检索循环以构建正确的上下文，并且每一步通常会受到过滤条件的限制，如可用性、地区、发货承诺、品牌规则和政策资格。

第 1 步：解读意图，并转化为约束条件。

智能体可将请求转化为结构化的过滤条件和语义查询，例如：

• 过滤条件：有现货，可配送至用户邮编，可在周五前送达，价格低于 60 美元，有效上架

• 向量查询：“随身背包15英寸笔记本电脑防水”

步骤 2：检索候选对象，然后进行细化。

它通常会重复检索，但会有所变化，以避免遗漏好的匹配结果：

• “旅行背包随身便携笔记本电脑保护套”

• “15 英寸防水通勤背包”

• “轻型机舱背包”

每个查询都使用相同的资格过滤条件，因为检索无关或不可用的项目会造成上下文的浪费。

步骤 3：展开以确认详细信息并降低风险。

代理随后再次检索以验证影响最终答案的关键属性：

• 材料与防水性表述

• 尺寸和笔记本隔层都适合

• 退货政策或保修限制

• 库存不足时的替代方案

这就是多步上下文工程：检索、推理、检索、组合。

延迟与召回为何对上下文工程至关重要

这些交互可能涉及每个用户会话中数十次过滤的检索调用。这使得每次调用的延迟成为端到端响应时间的直接倍增因素，而低召回率则迫使进行额外的重试或导致智能体错过符合条件的项目，导致答案质量下降。

要点：在上下文工程系统中，过滤近似最近邻 (ANN) 并非一次单一查找。由于这是在约束条件下的重复操作，因此即使大型语言模型 (LLM) 是最明显的组件，向量搜索性能也会立即体现在延迟、吞吐量和成本上。

基准测试

成果度

在图表 2 中，每个点代表一个测试配置。最佳结果出现在左上方，这意味着更高的召回率和更低的延迟。Elasticsearch 的结果始终比 OpenSearch 更接近左上角，表明在相同的工作负载配置下，Elasticsearch 具有更好的速度和准确率。

一些关键见解

• s_n_r_value: size_numCandidates_rescoreOversample 的简写（在这些测试中，k 和 numCandidates 设置为等于 numCandidates），例如，100_500_1 表示 size=100、numCandidates=500 和 k=500，重新评分过采样=1。

• 召回率：该配置的测量召回率@100

• 平均延迟（毫秒）：每次查询的平均端到端延迟

• 吞吐量：每秒查询次数

• 召回率 (%)：Elasticsearch 相较于 OpenSearch 的相对召回率提升 (Elasticsearch - OpenSearch) / OpenSearch

• 延迟 Xs：OpenSearch 平均延迟除以 Elasticsearch 平均延迟

• 吞吐量 Xs：Elasticsearch 吞吐量除以 OpenSearch 吞吐量

引擎

`s_n_r_value`

召回

平均延迟（ms）

吞吐量

召回率%

延迟 Xs

吞吐量 Xs

Elasticsearch

100_250_1

0.7704

25

534.75

9.70%

2.28

1.91

OpenSearch

100_250_1

0.7023

57.08

279.58

Elasticsearch

100_500_1

0.8577

25.42

524.14

7.20%

2.4

2

OpenSearch

100_500_1

0.8001

60.9

262.12

Elasticsearch

100_750_1

0.8947

29.67

528.09

5.72%

2.25

2.21

OpenSearch

100_750_1

0.8463

66.76

239.11

Elasticsearch

100_1000_1

0.9156

29.65

534.5

4.66%

2.46

2.44

OpenSearch

100_1000_1

0.8748

72.88

219.01

Elasticsearch

100_1500_1

0.9386

31.84

497.3

3.38%

2.71

2.68

OpenSearch

100_1500_1

0.9079

86.16

185.4

Elasticsearch

100_2000_1

0.9507

34.69

457.2

2.57%

2.98

2.96

OpenSearch

100_2000_1

0.9269

103.36

154.55

Elasticsearch

100_2500_1

0.9582

37.9

418.43

1.99%

3.28

3.26

OpenSearch

100_2500_1

0.9395

124.29

128.53

Elasticsearch

100_3000_1

0.9636

41.86

379.4

1.62%

3.46

3.44

OpenSearch

100_3000_1

0.9482

144.67

110.34

Elasticsearch

100_4000_1

0.9705

50.28

316.21

1.06%

3.87

3.85

OpenSearch

100_4000_1

0.9603

194.36

82.22

Elasticsearch

100_5000_1

0.9749

58.77

270.91

0.73%

4.43

4.41

OpenSearch

100_5000_1

0.9678

260.33

61.38

Elasticsearch

100_6000_1

0.9781

66.75

238.59

0.52%

4.91

4.89

OpenSearch

100_6000_1

0.973

327.44

48.81

Elasticsearch

100_7000_1

0.9804

74.64

213.49

0.38%

5.28

5.27

OpenSearch

100_7000_1

0.9767

394.24

40.53

Elasticsearch

100_8000_1

0.9823

82.28

193.59

0.27%

6.86

6.83

OpenSearch

100_8000_1

0.9797

564.14

28.33

Elasticsearch

100_9000_1

0.9837

90.08

176.96

0.16%

7.63

7.61

OpenSearch

100_9000_1

0.9821

687.25

23.25

Elasticsearch

100_10000_1

0.9848

97.64

163.31

0.08%

8.38

8.36

OpenSearch

100_10000_1

0.984

818.64

19.53

例如，在 100_9000_1 处，OpenSearch 每次检索平均为 687 毫秒， Elasticsearch 为 90 毫秒，而在 10 步检索循环中，等待时间约为 10 x (687 - 90) = 6 秒。

查看完整结果。

方法

我们使用 Python 发送查询并跟踪响应时间及其他统计数据，向引擎发送了以下查询。请记住，任何向量搜索引擎的性能取决于您如何调整其核心参数：考虑多少个候选项，重新评分的程度，以及返回多少上下文。这些设置直接影响召回率（找到正确答案的可能性）和延迟（获得结果的速度）。

在我们的基准测试中，我们使用了通常在智能体检索循环中调整的候选对象、重新评分和结果大小设置，并测量了 Elasticsearch 在该工作负载下的表现。然后我们以相同的设置运行了 OpenSearch 作为参考。

OpenSearch

• "size": <RESULT_SIZE>：返回给客户端的命中次数。在这个基准测试中，计算 Recall@100 的结果大小为 100。

• "k": <NUMBER_OF_CANDIDATES>：最近邻候选对象的数量。

• "ef_search": <NUMBER_OF_CANDIDATES>：要检查的向量数量。

• "oversample_factor": <OVERSAMPLE>：在重新评分之前检索了多少个候选向量。

Elasticsearch

• "size": <RESULT_SIZE>：返回给客户端的命中次数。在这个基准测试中，计算 Recall@100 的结果大小为 100。

• "k": <NUMBER_OF_CANDIDATES>：从每个分片返回的最近邻数量。

• "num_candidates": <NUMBER_OF_CANDIDATES>：进行 knn 搜索时每个分片要考虑的最近邻候选数目。

• "oversample": <OVERSAMPLE>：在重新评分之前检索了多少个候选向量。

示例

Knn 查询, (100_500_1)，将如下所示：

OpenSearch

Elasticsearch

完整配置、Terraform 脚本、Kubernetes 清单和基准测试代码均可在此存储库的 es-9.3-vs-os-3.5-vector-search 文件夹中找到。

集群设置

我们在六台 e2-standard-16 云服务器上运行了测试，每台服务器配备 16 个 vCPU 和 64 GB 内存。在每台服务器上，我们为每个运行搜索引擎节点的 Kubernetes pod 分配了 15 个 vCPU 和 56 GB RAM，其中 28 GB 保留给 JVM 堆。

这些集群运行 Elasticsearch 9.3.0 和 OpenSearch 3.5.0 (Lucene 10.3.2)。由于在此基准测试中两个系统使用相同的 Lucene 版本，我们观察到的吞吐量和延迟差异不能单独归因于 Lucene，而是反映了每个引擎如何集成和执行过滤后的 k 最近邻 (kNN) 检索和重新评分的差异。我们使用了一个单一索引，包含三个主分片和一个副本（因此总共 6 个分片，每个节点 1 个分片）。

我们还在同一区域使用了一台独立服务器运行基准客户端，并收集时序统计数据。

该数据集

对于这个基准测试，我们使用了一个大规模电子商务风格的目录嵌入数据集，包含 2000 万份文档，旨在反映实际的大规模筛选后向量检索的扩展能力。

每份文件代表一个目录项目，包括：

• 一种用于近似 kNN 检索的 128 维稠密向量嵌入。

• 结构化元数据字段用于筛选（例如，项目有效性和可用性，以及其他目录限制条件），从而支持常见的生产环境模式，即仅在符合条件的子集内检索最近邻。

我们之所以选择这个数据集，是因为它捕捉到了我们在生产中看到的智能体和 RAG 型系统所面临的核心性能挑战：仅有矢量相似性是不够的，检索经常受到筛选条件的限制，系统必须在这些限制条件下保持较高的召回率和较低的延迟。与较小的 QA 风格数据集相比，2000 万文档的语料库更能反映筛选后 ANN 系统在实践中面临的扩展和候选压力。

结论

在现代 AI 架构中，尤其是在那些围绕上下文工程构建的架构中，向量搜索速度并非一个微不足道的实现细节。它是一个倍增因素。当智能体和工作流迭代检索→推理→检索时，检索性能直接影响端到端延迟、吞吐量以及输入到模型中的上下文质量。

在我们的基准测试中，与 OpenSearch 相比，当 Elasticsearch 在正确性取决于检索正确文档而不仅仅是相似向量的情况下，始终能以更低的延迟提供更高的召回率。在受控数据集上，差异是显而易见的，而在生产中，这些收益会在大量检索调用中累积，从而提高响应速度、增加容量裕度并降低基础设施成本。

延展阅读

1. 什么是上下文工程？

2. 混合搜索和上下文工程的演进

3. 相关性在 AI 智能体的上下文工程中的影响

回顾

先简单回顾一下最新动态。Elasticsearch 现已确立其作为强大向量数据库的地位，在大规模相似性搜索方面提供了丰富的功能和强劲的性能。凭借标量量化、Better Binary Quantization (BBQ)、SIMD 向量运算以及 DiskBBQ 等在磁盘利用方面更高效的算法，Elasticsearch 已经为管理向量工作负载提供了高效而灵活的多种选项。

通过将 NVIDIA cuVS 集成为可调用的向量搜索模块，我们希望大幅提升向量索引的性能和效率，从而更好地支撑大规模向量工作负载。

挑战

构建高性能向量数据库的最大挑战之一，就是构建向量索引，即 HNSW 图。随着每个向量都要与大量其他向量进行比对，索引构建很快就会被数以百万乃至数十亿次的算术运算所主导。此外，压缩、合并等索引生命周期操作还会进一步增加索引的整体计算开销。随着数据量和相关向量嵌入呈指数级增长，专为大规模并行和高吞吐量数值运算而设计的加速计算 GPU 非常适合处理这些工作负载。

进入 Elasticsearch-GPU 插件

NVIDIA cuVS是一个开源的 CUDA-X 库，用于 GPU 加速的向量搜索和数据集群，能够为 AI 和推荐工作负载快速构建索引和嵌入检索。

Elasticsearch 通过 cuvs-java 使用 cuVS，这是一个由社区开发并由 NVIDIA 维护的开源库。cuvs-java 库十分轻量，基于 cuVS C API 构建，并借助 Panama 外部函数接口，以符合 Java 习惯用法的方式暴露 cuVS 功能，同时兼具现代性和高性能。

cuvs-java 库被集成到一个新的 Elasticsearch 插件中；因此，GPU 上的向量索引可在同一 Elasticsearch 节点和同一进程内完成，无需部署任何外部组件或额外硬件。在索引构建过程中，如果已安装 cuVS 库且存在已正确配置的 GPU，Elasticsearch 会利用 GPU 加速向量索引过程。向量会被传递给 GPU，由 GPU 构建 CAGRA 图。随后将该图转换为 HNSW 格式，使其能够立即在 CPU 上用于向量搜索。构建完成的图，其最终格式与在 CPU 上构建的图完全一致；这使得在底层硬件支持的情况下，Elasticsearch 可以利用 GPU 实现高吞吐量的向量索引，同时释放 CPU 算力，用于并发搜索、数据处理等其他任务。

索引构建加速

作为将 GPU 加速集成到 Elasticsearch 的一部分，对 cuvs-java 进行了多项增强，重点是高效的数据输入/输出和函数调用。一项关键增强是使用 cuVSMatrix 对向量进行透明建模，无论它们位于 Java 堆中、堆外还是 GPU 内存中。这使数据可以在内存与 GPU 之间高效传输，避免对可能多达数十亿个向量进行不必要的复制。

由于这种底层的零拷贝抽象，数据传输到 GPU 内存以及从中检索图时都可以直接完成。在索引过程中，向量首先缓存在 Java 堆内存中，然后发送到 GPU，以构建 CAGRA 图。随后，从 GPU 中取回该图，将其转换为 HNSW 格式，并持久化到磁盘。

在合并时，向量已经存储在磁盘上，完全绕过了 Java 堆。索引文件采用内存映射，数据直接传输到 GPU 内存中。该设计还能轻松适应不同的位宽，如 float32 或 int8，并自然扩展到其他量化方案。

话不多说，那它的实际表现如何呢？

在我们探讨数字之前，了解一些背景信息会有所帮助。在索引期间，Elasticsearch 中的分段合并通常在后台自动运行，这会导致在隔离环境中进行基准测试变得十分困难。为了获得可重复的结果，我们使用了强制合并来在受控实验中明确触发分段合并。由于强制合并与后台合并执行相同的底层合并操作，因此其性能可作为预期改进的有用指标，尽管在实际索引工作负载中，具体收获可能会有所不同。

现在让我们来探讨数字。

我们的初步基准测试结果非常令人鼓舞。我们在 AWS g6.4xlarge 实例上运行了基准测试，该实例具有本地连接的 NVMe 存储。我们将单个 Elasticsearch 节点配置为使用默认的最佳索引线程数（8 个，每个物理核心一个），并关闭合并限速功能（在使用快速 NVMe 磁盘时，这一功能的适用性较低）。

对于数据集，我们使用了 OpenAI Rally 向量赛道中的 260 万个、每个具有 1,536 维的向量，将其编码为 base64 字符串，并以 float32 hnsw 结构进行索引。在所有场景中，构建的图都能达到最高约 95% 的召回率。以下是我们的发现：

• 索引吞吐量：通过在内存缓冲区刷新期间将图构建移交给 GPU 处理，我们将吞吐量提高了约 12 倍。

• 强制合并：索引完成后，GPU 继续加速分段合并，将强制合并阶段加快约 7 倍。

• CPU 使用率：将图构建任务分流到 GPU，可显著降低 CPU 的平均和峰值利用率。以下图表展示了索引和合并期间的 CPU 使用情况，凸显了在 GPU 上运行这些操作时 CPU 使用率的显著降低。GPU 索引期间降低 CPU 使用率，可释放 CPU 周期并重新分配，从而提升搜索性能。

• 召回率：在 CPU 与 GPU 的运行结果中，准确性几乎一致，而 GPU 所构建的图在召回率方面略胜一筹。

再从价格这个维度来进行比较

前面的对比特意选用了相同的硬件配置，唯一的区别只是索引时是否启用 GPU。这种设置有助于单独考察计算性能的影响，不过也可以从成本角度来进行对比。

在与 GPU 加速配置大致相同的按小时费用下，可以搭建一套仅使用 CPU 的环境，其 CPU 和内存资源大约是前者的两倍：32 个 vCPU（AMD EPYC）和 64 GB RAM，因而可将索引线程数量增加到 16

为了保持比较的公平和一致性，我们在 AWS g6.8xlarge 实例上运行了这个仅 CPU 的实验，并且明确禁用了 GPU。这使我们能够在评估 GPU 加速与仅 CPU 索引的成本-性能权衡时，保持所有其他硬件特性不变。

正如您所预期的那样，更强大的 CPU 实例与上述部分的基准测试相比，性能确实有所提高。然而，将这一性能更强的 CPU 实例与最初的 GPU 加速结果进行对比后可以看到，GPU 依然带来显著性能提升：索引吞吐量提高约 5 倍，强制合并阶段加速约 6 倍，同时构建的图其召回率最高可达 95%。

结论

在端到端场景中，使用 NVIDIA cuVS 进行的 GPU 加速使索引吞吐量提高了近 12 倍，将强制合并延迟降低到原来的 1/7，同时显著降低了 CPU 利用率。这表明向量索引和合并工作负载从 GPU 加速中受益显著。在成本调整后的对比中，GPU 加速依然带来显著的性能提升：索引吞吐量约提升 5 倍，强制合并操作的速度提升约 6 倍。

GPU 加速的向量索引目前计划在 Elasticsearch 9.3 的技术预览版中推出，该版本计划于 2026 年初发布。

敬请关注更多内容。

为此，我们使用谷歌的 SigLIP-2 为图像和文本生成矢量嵌入，并将其存储在 Elasticsearch 矢量数据库中。在查询时，我们将搜索输入（文本或图像）转换为嵌入，并运行快速的 kNN 向量搜索来检索结果。这种设置可实现高效的文本到图像和图像到图像搜索。Streamlit 用户界面为我们提供了一个前端，不仅可以进行基于文本的搜索，从相册中查找并查看匹配的照片，还可以从上传的图片中识别山峰，并查看相册中该山峰的其他照片，从而使该项目栩栩如生。我们还介绍了为提高搜索准确性而采取的措施，以及实用技巧和窍门。为便于进一步探索，我们提供了GitHub 存储库和Colab 笔记本。

如何开始

这篇博文的灵感来自于一个 10 岁的孩子，他让我给他们看我在珠峰大本营徒步旅行时拍摄的阿玛达布拉姆山的所有照片。在翻阅相册时，我还被要求辨认其他几座山峰，其中一些我还叫不出名字。

这让我想到，这可以成为一个有趣的计算机视觉项目。我们的目标

• 按名称查找山峰图片

• 从图片中猜测山峰名称，并在相册中找到类似的山峰

• 让概念查询发挥作用（人、河流、祈祷旗 等）

组建梦之队：SigLIP-2、Elasticsearch& Streamlit

很快我们就发现，要想实现这一目标，我们需要将文字（"阿玛达布拉姆"）和图像（我相册中的照片）都转化为可以进行有意义比较的矢量，即在同一个矢量空间中。一旦我们做到了这一点，搜索就只是 "寻找最近的邻居"。

为了生成图像嵌入，我们使用了多语言 视觉语言编码器，因此山峰的照片和 "Ama Dablam "这样的短语会出现在同一个向量空间中。

谷歌最近发布的SigLIP-2 在这方面非常适合。它可以在没有特定任务训练的情况下生成嵌入式（零镜头设置），并能很好地适用于我们的使用案例：未标记的照片和具有不同名称和语言的山峰。由于它是针对文本与图像匹配进行训练的，因此即使查询语言或拼写不同，徒步旅行中的山峰图片和简短的文字提示最终也能接近嵌入。

SigLIP-2 在质量与速度之间实现了很好的平衡，支持多种输入分辨率，并可在 CPU 和 GPU 上运行。SigLIP-2 在设计上比以前的型号（如最初的 CLIP）更适合户外拍摄。在我们的测试中，SigLIP-2 始终能生成可靠的结果。此外，它还得到了很好的支持，因此是本项目的不二之选。

接下来，我们需要一个向量数据库来存储嵌入和强力搜索。它不仅应支持对图像嵌入进行余弦 kNN 搜索，还应在单个查询中应用地理围栏和文本过滤器。Elasticsearch 在这方面非常适合：它能很好地处理向量（在 dense_vector 字段上使用 HNSW kNN），支持结合文本、向量和地理查询的混合搜索，并提供开箱即用的过滤和排序功能。它还可以横向扩展，因此很容易从少量照片扩展到数千张照片。最后，我们需要一个轻量级前端，以便输入搜索查询并查看结果。对于基于 Python 的快速演示，Streamlit 非常适合。它提供了我们所需的基本功能--文件上传、响应式图像网格以及用于排序和地理围栏的下拉菜单。它很容易克隆并在本地运行，也可以在 Colab 笔记本中使用。

实施

Elasticsearch 索引设计和索引策略

我们将在这个项目中使用两个索引：peaks_catalog 和photos 。

峰值_目录索引

该索引是珠峰大本营徒步旅行期间可看到的著名山峰的简明目录。该索引中的每份文件都对应一座山峰，如珠穆朗玛峰。对于每个山峰文档，我们都会存储名称/别名、可选的经纬度坐标以及由 SigLIP-2 文本提示（+ 可选的参考图片）混合而成的单一原型向量。

索引映射：

现场

类型

示例

目的/说明

矢量/索引

本我

关键词

阿玛-达布拉姆

稳定的弹头/ID

-

姓名

文本 + 关键字子字段

["Ama Dablam","Amadablam"]

别名/多语言名称；names.raw 用于精确筛选

-

纬纶

地理点

{"lat":27.8617,"lon":86.8614}

以经纬度组合形式显示的山顶 GPS 坐标（可选）

-

海拔_m

整数

6812

海拔（可选）

-

嵌入文本

dense_vector

768

该山峰的混合原型（提示和可选的 1-3 幅参考图片

index:true, similarity:"cosine", index_options：{type:"hnsw", m:16, ef_construction:128}

该索引主要用于图像到图像的搜索，例如从图像中识别山峰。我们还使用该索引来增强文本到图片的搜索结果。

总之，peaks_catalog 将问题""这是什么山？" "转化为一个重点突出的 "最近邻问题"，有效地将概念理解与图像数据的复杂性分离开来。

peaks_catalog 索引的索引策略： 首先，我们创建了一份在 EBC 徒步旅行中可见的最突出山峰的列表。对于每个山峰，我们都会在yaml 文件中存储其地理位置、名称、同义词和海拔高度。下一步是 生成 每个峰值的 嵌入 值，并将其存储在text_embed 字段中。为了生成稳健的嵌入，我们使用了以下技术：

• 创建文本原型：

  • 山峰名称

  • 提示组合（使用多个不同的提示来尝试回答同一个问题），例如

    • "尼泊尔喜马拉雅山脉山峰的自然照片{name} "

    • "{name} 昆布地区的地标性山峰，高山景观"

    • "{name} 山顶，积雪，岩石山脊线"

  • 可选的反概念（告诉 SigLIP-2 什么不能匹配）：为 "绘画、插图、海报、地图、徽标 "减去一个小矢量，这样我们就偏向于真实照片。

• 如果提供了峰值的参考图像，可选择创建图像原型。

然后，我们混合文本和图像原型，生成最终的嵌入。最后，文件将被索引到所有必填字段：

peaks_catalog 索引中的文件样本：

照片索引

该主索引存储相册中所有照片的详细信息。每份文档代表一张照片，包含以下信息：

• 相册中照片的相对路径。可用于查看匹配图像或在搜索用户界面中加载图像。

• 图片的 GPS 和时间信息。

• SigLIP-2 生成的图像编码密集矢量。

• predicted_peaks 可让我们根据峰名进行筛选。索引映射

现场

类型

示例

目的/说明

矢量/索引

路径

关键词

data/images/IMG_1234.HEIC

用户界面如何打开缩略图/全图

-

剪贴图片

dense_vector

768

SigLIP-2 图像嵌入

index:true, similarity:"cosine", index_options：{type:"hnsw", m:16, ef_construction:128}

预测峰值

关键词

["ama-dablam","pumori"]

索引时的 Top-K 猜想（廉价用户体验过滤器/面）

-

全球定位系统

地理点

{"lat":27.96,"lon":86.83}

启用地理筛选器

-

拍摄时间

date

2023-10-18T09:41:00Z

捕捉时间：排序/过滤

-

照片索引的索引策略： 对于相册中的每张照片，我们会采取以下措施： 从图像元数据中提取图像shot_time 和gps 信息。

• SigLIP-2 图像嵌入：通过模型传递图像并对向量进行 L2 归一化。将嵌入内容存储在clip_image 字段中。

• 预测峰值并将其存储在predicted_peaks 字段中。为此，我们首先获取上一步生成的照片图像向量，然后针对peaks_catalog 索引中的 text_embed 字段快速运行 kNN 搜索。我们保留顶部的 3-4 个山峰，忽略其余的。

• 我们通过对图片名称和路径进行散列计算_id 字段。这可以确保我们在多次运行后不会出现重复。

一旦我们确定了照片的所有字段，就会使用 批量 索引对照片文件进行 批量 索引：

照片索引中的样本文件：

总之，照片索引是相册中所有照片的快速、可过滤、kNN 就绪存储。它的映射结构非常简单，只需足够的结构就能快速检索、清晰显示，并按空间和时间对结果进行切分。该索引可同时满足这两种搜索用途。创建这两个索引的 Python 脚本可在此处找到。

下面的 Kibana 地图可视化将相册中的文档显示为绿色圆点，将peaks_catalog 索引中的山峰显示为红色三角形，其中绿色圆点与珠峰大本营徒步路线非常吻合。

搜索用例

按名称搜索（文本到图像）：该功能可让用户使用文本查询查找山峰照片（甚至是 "祈祷旗 "等抽象概念）。为此，使用 SigLIP-2 将文本输入转换为文本向量。为了生成稳健的文本向量，我们采用了与在peaks_catalog 索引中创建文本嵌入相同的策略： 将 文本输入与小型 提示集合 相结合 ，减去次要的 反概念向量 ，并应用 L2 归一化 生成最终的查询向量。然后在photos.clip_image 字段上执行 kNN查询，根据余弦相似度检索匹配度最高的峰值，从而找到最接近的图像。作为查询的一部分，还可选择应用地理和日期筛选器和/或photos.predicted_peaks 术语筛选器来提高搜索结果的相关性（见下文查询示例）。这有助于排除在徒步过程中看不到的相似山峰。

带有地理过滤器的 Elasticsearch 查询：

按图像搜索（图像到图像）：通过该功能，我们可以识别照片中的某座山，并在相册中查找该座山的其他图像。图像上传后，将由 SigLIP-2 图像编码器处理，生成图像矢量。然后在peaks_catalog.text_embed 字段上进行kNN 搜索，以确定最匹配的峰值名称。随后，根据这些匹配的山峰名称 生成 一个 文本向量 ，并在照片索引中进行另一次 kNN 搜索 ，以找到相应的照片。

Elasticsearch 查询：

第 1 步：找到匹配的山峰名称

第 2 步：在photos 索引上进行搜索，找到匹配的图片（与文本到图片搜索用例中的查询相同）：

流光 UI

为了将所有功能整合在一起，我们创建了一个简单的 Streamlit 用户界面，让我们可以同时执行两种搜索用例。左侧栏显示可滚动的峰值列表（从photos.predicted_peaks 中汇总），并带有复选框和小地图/地理过滤器。顶部有一个按姓名搜索框和一个从照片上传识别按钮。中心窗格采用响应式缩略图网格，显示 kNN 分数、预测峰值徽章和捕获时间。每张图片都有一个查看图片按钮，用于全分辨率预览。

通过上传图片进行搜索：我们会预测峰值，并从相册中找到匹配的峰值。

文本搜索从文本中查找相册中匹配的峰值

结论

我们能看看 阿玛-达布拉姆 的照片吗？变成了一个可运行的小型多模态搜索系统。我们采集了原始的徒步旅行照片，将其转化为SigLIP-2 嵌入，并使用Elasticsearch对向量进行快速的kNN处理，再加上简单的地理/时间过滤器，根据意义浮现出正确的图像。在此过程中，我们将两个索引的关注点分开：一个是混合原型的小peaks_catalog （用于识别），另一个是图像向量和 EXIF 的可扩展photos 索引（用于检索）。它实用、可复制、易扩展。

如果您想对其进行调整，有几项设置可供使用：

• 查询时间设置： k （您希望返回多少个邻居）和num_candidates （最终评分前的搜索范围）。这些设置将在此处的博客中讨论。

• 索引时间设置： m （图形连接性）和ef_construction （构建时间精度与内存）。对于查询，也可以尝试使用ef_search --更高通常意味着更高的召回率，但需要权衡一定的延迟。有关这些设置的更多详情，请参阅本博客。

展望未来，用于多模态和多语言搜索的本地模型/路由器即将登陆 Elastic生态系统，这将使图像/文本检索和混合排名功能更加强大。

如果你想亲自尝试一下：

• GitHub 代码库 ： https://github.com/navneet83/multimodal-mountain-peak-search

• Colab 快速入门 ：https://github.com/navneet83/multimodal-mountain-peak-search/blob/main/notebooks/multimodal_mountain_peak_search.ipynb

我们的旅程就此结束，是时候飞回去了。希望这对你有帮助，如果你改动（或改进）了它，我很乐意听听你的改动。

在本系列的最后一部分，我们介绍了如何部署 Elastic 预训练的 E5 模型（以及 Hugging Face 提供的其他多语言文本嵌入模型），并深入探讨了如何使用 Elasticsearch 和 Kibana 从文本数据中生成密集向量嵌入。在本博客中，我们将研究这些嵌入的结果，并强调利用多语言模型的显著优势。

现在我们已经有了索引coco_multilingual ，执行搜索时将会得到多种语言的文档，其中的 "en "字段可供我们参考：

用英语进行搜索

让我们尝试用英语进行搜索，看看效果如何：

在这里，尽管查询看起来非常简单，但我们要搜索的是 "kitty "一词在所有语言的所有文档中的数字嵌入。由于我们执行的是矢量搜索，因此可以从语义上搜索所有可能与 "kitty "相关的词：猫"、"小猫"、"猫科动物"、"gatto"（意大利语）、"mèo"（越南语）、고양이（韩语）、猫（汉语）等。因此，即使我的查询是以英语进行的，我们也可以搜索到所有其他语言的内容。例如，搜索 kitty lying on something ，也会出现意大利语、荷兰语或越南语的文档。谈效率

搜索其他语言的内容

同样，用韩语（"고양이"）搜索关键词 "猫 "也会得到有意义的结果。令人惊叹的是，在这份索引中，我们甚至没有任何韩文文件！

这是因为嵌入模型在共享语义空间中表示意义，即使查询语言与索引标题不同，也能检索到相关图像。

利用混合搜索和重新排序增加相关搜索结果

我们很高兴相关结果如期出现。但是，在现实世界中，比如在电子商务或 RAG 应用程序中，需要缩小到前 5-10 个最适用的结果，我们可以使用 rerank 模型来优先处理最相关的结果。

在这里，用越南语查询 "猫是什么颜色的？"会得到很多结果，但前 1 或前 2 个结果可能不是最相关的。

结果都提到了猫或某种颜色：

因此，让我们来改进这一点！让我们结合Cohere的多语言 rerank 模型来改进与我们的问题相对应的推理。

现在，有了最重要的结果，我们的应用程序就可以肯定地回答，这只小猫的颜色是黑色或带条纹的棕色。更有趣的是，我们的矢量搜索实际上发现了原始数据集中英文标题的遗漏。尽管参考英译本忽略了这一细节，但它还是能找到那只棕色条纹的猫。这就是矢量搜索的威力。

结论

在这篇博客中，我们介绍了多语言嵌入模型的实用性，以及如何利用 Elasticsearch 来集成模型以生成嵌入，并通过混合搜索和重新分词器来有效提高相关性和准确性。您可以 创建一个 自己的 云集群 ， 使用我们开箱即用的 E5 模型 在您选择的语言和数据集上尝试 多语言语义搜索 。

在用户遍布全球的世界里，跨语言信息检索（CLIR）至关重要。CLIR 可让您以任何语言查找信息，而不是将搜索局限于单一语言，从而增强用户体验并简化操作。想象一下，在全球市场上，电子商务客户可以用自己的语言搜索商品，正确的结果就会出现，而无需提前对数据进行本地化。或者，学术研究人员可以用自己的母语搜索论文，即使资料来源是另一种语言，也会有细微差别和复杂性。

多语言文本嵌入模型让我们能够做到这一点。嵌入是一种用数字向量表示文本含义的方法。设计这些向量的目的是让含义相似的文本在高维空间中彼此靠近。多语言文本嵌入模型专门用于将不同语言中具有相同含义的单词和短语映射到相似的向量空间中。

开源的多语言 E5 等模型是在海量文本数据的基础上进行训练的，通常使用对比学习等技术。在这种方法中，模型学会区分意义相似的文本对（正对）和意义不同的文本对（负对）。对模型进行训练，以调整其产生的向量，从而使正向配对之间的相似性最大化，反向配对之间的相似性最小化。对于多语言模型，这些训练数据包括不同语言的文本对，这些文本对互为翻译，从而使模型能够学习多种语言的共享表示空间。由此产生的嵌入结果可用于各种 NLP 任务，包括跨语言搜索，在跨语言搜索中，文本嵌入之间的相似性可用于查找相关文档，而不受查询语言的限制。

多语言矢量搜索的优势

• 细致入微：矢量搜索擅长捕捉语义，超越关键词匹配。这对于需要理解语境和语言微妙之处的任务至关重要。

• 跨语言理解：即使查询和文档使用不同的词汇，也能跨语言进行有效的信息检索。

• 相关性：通过关注查询和文档之间的概念相似性，提供更相关的结果。

例如，一位学术研究人员正在研究"社交媒体对不同国家政治话语的影响" 。通过矢量搜索，他们可以输入"l'impatto dei social media sul discorso politico" (意大利文) 或"ảnh hưởng của mạng xã hội đối với diễn ngôn chính trị" (越南文) 等查询，并找到相关的英文论文、西班牙语或任何其他索引语言的相关论文。这是因为矢量搜索可以识别讨论社交媒体对政治影响这一概念的论文，而不仅仅是包含确切关键词的论文。这大大提高了他们研究的广度和深度。

开始使用

下面介绍如何使用 Elasticsearch（开箱即用的 E5 模型）设置 CLIR。我们将使用开源的多语言 COCO 数据集（其中包含多种语言的图片说明）来帮助我们可视化两种类型的搜索：

1. 一个英语数据集上的其他语言查询和搜索词，以及

2. 在包含多语言文档的数据集上进行多语言查询。

然后，我们将利用混合搜索和重新排序的功能，进一步改进搜索结果。

准备工作

• Python 3.6+

• Elasticsearch 8+

• Elasticsearch Python 客户端： pip install elasticsearch

数据集

COCO 数据集是一个大型字幕数据集。数据集中的每张图片都有多种不同语言的标题，每种语言都有几种翻译。为便于演示，我们将把每份译文作为单独的文件进行索引，并附上第一份可用的英文译文以供参考。

步骤 1：下载多语种 COCO 数据集

为了简化博客并方便阅读，我们在这里通过简单的 API 调用，将 restval 的前 100 行加载到本地 JSON 文件中。或者，您也可以使用 HuggingFace 的库数据集来加载整个数据集或数据集的子集。

如果数据成功加载到 JSON 文件中，你应该会看到类似下面的内容：

Data successfully downloaded and saved to multilingual_coco_sample.json

第 2 步：（启动 Elasticsearch）并在 Elasticsearch 中编制数据索引

a) 启动本地 Elasticsearch 服务器。

b) 启动 Elasticsearch 客户端。

c) 指数数据

数据编入索引后，您应该会看到类似下面的内容：

Successfully bulk indexed 4840 documents

Indexing complete!

步骤 3：部署 E5 训练模型

在 Kibana 中，导航到 "堆栈管理> 训练模型"页面，然后单击 "部署.multilingual-e5-small_linux-x86_64选择。这款 E5 机型是为 linux-x86_64 优化的小型多语言机型，开箱即可使用。单击 "部署 "将显示一个屏幕，您可以在此调整部署设置或 vCPU 配置。为简单起见，我们将使用默认选项，并选择自适应资源，它将根据使用情况自动调整部署规模。

如果您想使用其他文本嵌入模型，也可以选择使用。例如，要使用 BGE-M3，可以使用Elastic 的 Eland Python 客户端从 HuggingFace 导入模型。

然后，导航到 "训练有素的模型 "页面，使用所需的配置部署导入的模型。

第 4 步：利用已部署的模型对原始数据进行矢量化或创建嵌入模型

要创建嵌入模型，我们首先需要创建一个摄取管道，使我们能够获取文本并通过推理文本嵌入模型运行。您可以在 Kibana 的用户界面或通过 Elasticsearch 的应用程序接口进行此操作。

要通过 Kibana 界面完成此操作，在部署训练模型后，单击测试 按钮。这将使您能够测试和预览生成的嵌入式内容。为coco 索引创建一个新的数据视图，将数据视图设置为新创建的 coco 数据视图，并将字段设置为description ，因为这是我们要生成嵌入的字段。

效果很好！现在，我们可以继续创建摄取管道，并重新为原始文档建立索引，将它们通过管道，然后用嵌入创建一个新索引。单击 "创建管道"即可实现这一功能，它将引导您完成管道创建过程，并自动填充所需的处理器，帮助您创建嵌入。

向导还可以自动填充所需的处理器，以便在摄取和处理数据时处理故障。

现在让我们创建摄取管道。我将管道命名为coco_e5 。管道创建成功后，可以立即使用管道生成嵌入，方法是将原始索引数据重新索引到向导中的新索引。单击 "重新索引 "启动该过程。

对于更复杂的配置，我们可以使用 Elasticsearch API。

对于某些模型，由于训练模型的方式不同，我们可能需要在生成嵌入之前在实际输入中预置或附加某些文本；否则，我们将看到性能下降。

例如，在使用 e5 时，模型希望输入文本跟随 "passage：{content of passage}".让我们利用摄取管道来实现这一目标：我们将创建一个新的摄取管道vectorize_descriptions。在此流程中，我们将创建一个新的临时temp_desc 字段，在 "passage：" 添加到description 文本中，通过模型运行temp_desc 以生成文本嵌入，然后删除temp_desc 。

此外，我们可能还想为生成的向量指定量化类型。默认情况下，Elasticsearch 使用int8_hnsw ，但在这里，我需要更好的二进制量化（或bqq_hnsw ），它将每个维度降低到一位精度。这样，内存占用减少了 96% （或 32 倍），但精度却提高了。我之所以选择这种量化类型，是因为我知道稍后会使用重新anker 来改善精度损失。

为此，我们将创建一个名为coco_multi 的新索引，并指定映射。这里的奥妙在于 vector_description 字段，我们在其中指定index_options的类型为bbq_hnsw。

现在，我们可以将原始文档重新索引到新的索引中，我们的摄取管道将对描述字段进行 "矢量化 "或创建嵌入。

就是这样！我们已经成功地利用 Elasticsearch 和 Kibana 部署了一个多语言模型，并逐步了解了如何通过 Kibana 用户界面或 Elasticsearch API 利用 Elastic 数据创建向量嵌入。在本系列的第二部分，我们将探讨使用多语言模型的结果和细微差别。同时，您可以 创建一个 自己的 云集群 ，在您选择的语言和数据集上 使用我们开箱即用的 E5 模型 尝试 多语言语义搜索 。

了解筛选在矢量搜索中是如何工作的，将有助于你平衡性能和召回率之间的权衡，并发现一些优化方法，使矢量搜索在使用筛选时性能更佳。

为什么要过滤？

矢量搜索彻底改变了我们在大型数据集中查找相关信息的方式，使我们能够发现与查询语义相似的项目。

然而，仅仅找到相似的物品是不够的。我们经常需要根据特定的标准或属性来缩小搜索结果的范围。

想象一下，您正在一家电子商务商店中搜索产品。纯矢量搜索可能会显示视觉上相似的商品，但您可能还想根据价格范围、品牌、可用性或客户评价进行筛选。如果不进行筛选，您就会看到大量类似的产品，很难准确找到您要找的产品。

过滤功能可对搜索结果进行精确控制，确保检索到的项目不仅在语义上一致，而且符合所有必要的要求。这将带来更加准确、高效和用户友好的搜索体验。

这正是 Elasticsearch 和 Apache Lucene 的优势所在--对各种数据类型进行有效过滤是它们与其他矢量数据库的主要区别之一。

精确矢量搜索的筛选

进行精确矢量搜索主要有两种方法：

• 为 dense_vector 字段使用flat 索引类型。这使得knn 搜索使用精确搜索而不是近似搜索。

• 使用 script_score 查询 ，该 查询 使用向量函数计算分数。这可用于任何索引类型。

在执行精确向量搜索时，所有向量都会与查询进行比较。在这种情况下，过滤将有助于提高性能，因为只需要比较通过过滤的向量。

这不会影响结果质量，因为所有向量都会被考虑在内。我们只是提前过滤掉不感兴趣的结果，从而减少操作次数。

这一点非常重要，因为当应用筛选器得到的文档数量很少时，执行精确搜索比近似搜索更有效。

经验法则是，当通过过滤器的文件少于 10k 时，应使用精确搜索。BBQ索引的比较速度更快，因此当基于索引的数据少于 100k 时，使用精确搜索是合理的。详情请查看本博文。

如果您的筛选器总是限制性很强，您可以考虑使用flat 索引类型而不是基于 HNSW 的索引类型，将索引重点放在精确搜索而不是近似搜索上。更多详情，请参阅index_options 的属性。

近似矢量搜索的筛选

在执行近似向量搜索时，我们需要用结果的准确性来换取性能。像 HNSW 这样的矢量搜索数据结构可在数百万个矢量上高效搜索近似近邻。它们的重点是通过进行最少的向量比较来检索最相似的向量，而向量比较的计算成本很高。

这意味着其他过滤属性不属于矢量数据的一部分。不同的数据类型有自己的索引结构，如术语字典、发布列表和 doc 值等，可以有效地查找和过滤这些数据。

既然这些数据结构与矢量搜索机制是分开的，那么我们如何将过滤功能应用于矢量搜索呢？有两种选择：在矢量搜索后应用过滤器（后过滤）或在矢量搜索前应用过滤器（预过滤）。

每种方案都各有利弊。让我们深入了解它们！

后过滤

后过滤在矢量搜索完成后应用过滤器。这意味着，在找到前 k 个最相似的向量结果后，才会应用筛选器。

显然，在对结果进行筛选后，我们可能会得到少于 k 个结果。当然，我们可以从矢量搜索中获取更多的结果（k 值更高），但我们无法确定在应用过滤器后是否会得到 k 或更多的结果。

后过滤的优势在于它不会改变矢量搜索的运行时行为--矢量搜索不知道过滤的存在。但是，它确实会改变检索结果的最终数量。

下面是使用knn 查询进行后过滤的示例。检查过滤子句是否与 knn 查询分开：

使用后置过滤器还可对 knn 搜索进行后置过滤：

请记住，您需要在 knn 搜索中使用明确的后置过滤器部分。如果不使用后置过滤器，knn 搜索 会将最近邻 搜索 结果 与其他查询或过滤器 结合起来 ，而不是进行后置过滤器。

预过滤

在矢量搜索前应用筛选器将首先检索出满足筛选条件的文档，然后将这些信息传递给矢量搜索。

Lucene 使用BitSets高效地存储满足筛选条件的文档。然后，矢量搜索会遍历 HNSW 图，并将满足条件的文档考虑在内。在将候选文件添加到结果中之前，它会检查该候选文件是否包含在有效文件的 BitSet 中。

不过，即使候选文件不是有效文件，也必须对其进行探索并与查询进行比较。HNSW 的有效性取决于图中向量之间的联系--如果我们停止探索某个候选向量，就意味着我们可能也会跳过它的邻近向量。

就像开车去加油站一样。如果放弃任何一条没有加油站的道路，您就不可能到达目的地。其他道路可能不是你所需要的，但它们将你连接到目的地。HNSW 图形上的向量也是如此！

因此，应用预过滤比不应用过滤的性能要低。我们需要对搜索中访问的所有向量进行处理，并丢弃不符合筛选条件的向量。我们正在做更多的工作，花更多的时间来获得最高 K 值的结果。

下面是在 Elasticsearch 查询 DSL 中进行预过滤的示例。检查过滤子句是否已成为 knn 部分的一部分：

knn 搜索和knn 查询均可使用预过滤功能：

预过滤优化

我们可以进行一些优化，以确保预过滤的性能。

如果筛选条件非常严格，我们可以切换到精确搜索。当需要比较的向量很少时，对满足筛选条件的少数文档进行精确搜索会更快。

这是Lucene和 Elasticsearch 自动应用的优化。

另一种优化方法是忽略不符合筛选条件的向量。相反，该方法会检查滤波向量的邻近向量是否通过滤波。这种方法不考虑过滤后的向量，而是继续探索与当前路径相连的向量，从而有效减少了比较次数。

这种算法就是 ACORN-1，本篇博文将详细介绍其过程。

使用文档级安全过滤

文档级别安全（DLS）是 Elasticsearch 的一项功能，可指定用户角色可检索的文档。

DLS 通过查询来执行。一个角色可以有一个与索引相关联的查询，这实际上限制了属于该角色的用户可以从索引中检索的文档。

角色查询用作过滤器，用于检索与之匹配的文档，并作为 BitSet 缓存。然后，这个 BitSet 会被用来封装底层的 Lucene 阅读器，因此只有从查询返回的文档才会被认为是实时的，也就是说，它们存在于索引中，并且没有被删除。

由于要从阅读器获取实时文档来执行 knn 查询，因此只考虑用户可用的文档。如果有预检器，DLS 文件将被 添加到 预检器 中 。

这意味着，DLS 过滤可以作为近似矢量搜索的预过滤，具有相同的性能影响和优化效果。

使用精确搜索的 DLS 与应用任何过滤器的好处相同--从 DLS 检索的文档越少，精确搜索的性能就越高。还要考虑 DLS 返回的文档数量--如果 DLS 的作用非常有限，可以考虑使用精确搜索而不是近似搜索。

基准

在 Elasticsearch，我们希望确保矢量搜索过滤的效率。我们有一个专门的向量过滤基准，通过不同的过滤执行近似向量搜索，以确保向量搜索尽可能快地检索到相关结果。

查看 ACORN-1 推出时的改进情况。在只有 2% 个向量通过过滤器的测试中，查询延迟时间缩短到原来的 55% ：

结论

过滤是搜索不可或缺的一部分。确保过滤在矢量搜索中的性能，并了解权衡和优化，是高效和准确搜索的关键所在。

过滤会影响向量搜索的性能：

• 使用过滤功能时，精确搜索速度更快。如果过滤条件足够严格，应考虑使用精确搜索而不是近似搜索。这是 Elasticsearch 的自动优化功能。

• 使用预过滤时，近似搜索速度较慢。通过预过滤，我们可以得到与过滤器匹配的前 k 个结果，但搜索速度会减慢。

• 后过滤并不一定能检索到前 k 个结果，因为在应用过滤器时，这些结果可能已被过滤器过滤。

快乐过滤

在本文中，我们将讨论这些字段类型、每种类型的使用时间，以及它们与嵌入生成和使用策略的关系，包括在索引和查询过程中的关系。

密集矢量类型

Elasticsearch 中的dense_vector 字段类型用于存储密集向量，密集向量是文本、图像和音频等数据的数字表示，其中几乎所有维度都是相关的。这些向量是使用 OpenAI、Cohere 或 Hugging Face 等平台提供的嵌入模型生成的，旨在捕捉数据的整体语义，即使数据与其他文档不共享确切术语。

在 Elasticsearch 中，稠密向量的维度最多可达 4096，具体取决于所使用的模型。例如，all-MiniLM-L6-v2 模型生成的向量有 384 个维度，而 OpenAI 的 text-embedding-ada-002 模型生成的向量有 1536 个维度。

dense_vector 字段通常被用作存储这类嵌入的默认类型，当需要更多控制时，例如使用预生成向量、应用自定义相似性函数或与外部模型集成。

何时以及为何使用 dense_vector 类型？

密集向量非常适合捕捉句子、段落或整个文档之间的语义相似性。当目标是比较文本的整体含义时，即使它们不共享相同的术语，它们也能很好地发挥作用。

密集矢量字段非常适合已经拥有外部嵌入生成管道，使用 OpenAI、Cohere 或 Hugging Face 等平台提供的模型，并且只想手动存储和查询这些矢量的情况。这种类型的字段与嵌入模型具有很高的兼容性，在生成和查询方面具有充分的灵活性，允许您控制矢量的生成、索引和搜索使用方式。

此外，它还支持不同形式的语义搜索，在需要调整排名逻辑的情况下，可使用 k-NN 或 script_score 等查询。这些可能性使密集矢量成为 RAG（检索增强生成）、推荐系统和基于相似性的个性化搜索等应用的理想选择。

最后，该字段允许您自定义相关性逻辑，使用cosineSimilarity 、dotProduct 或l2norm 等函数，根据使用情况的需要调整排名。

对于需要灵活性、定制化和与上述高级用例兼容的用户来说，密集矢量仍然是最佳选择。

如何使用密集矢量类型查询？

对定义为dense_vector 的字段的搜索使用 k 近邻查询。该查询负责查找密集向量与查询向量最接近的文档。下面举例说明如何将 k-NN 查询应用于密集向量场：

除 k-NN 查询外，如果需要自定义文档评分，也可以使用 script_score 查询，将其与余弦相似度、点积或 l2norm 等向量比较函数相结合，以更可控的方式计算相关性。请看示例：

如果您想深入了解，我建议您阅读《如何在 Elasticsearch 中设置向量搜索》一文。

稀疏矢量类型

sparse_vector 字段类型用于存储稀疏矢量，稀疏矢量是一种数值表示，其中大部分值为零，只有少数项具有重要权重。这种类型的向量在基于术语的模型中很常见，如 SPLADE 或 ELSER（弹性学习稀疏 EncodeR）。

何时以及为何使用稀疏向量类型？

当你需要更精确的词汇搜索而又不牺牲语义智能时，稀疏向量是理想的选择。它们将文本表示为标记/值对，只突出显示最相关的术语和相关权重，从而提供清晰度、控制和效率。

这类字段在根据术语生成向量时特别有用，例如在 ELSER 或 SPLADE 模型中，这些模型会根据每个标记在文本中的相对重要性为其分配不同的权重。

如果您想控制查询中特定词语的影响，稀疏向量类型允许您手动调整词语的权重，以优化结果的排名。

它的主要优点包括：搜索透明，因为可以清楚地了解为什么某个文件被认为是相关的；存储高效，因为只保存非零值的标记，而不像密集向量那样存储所有维度。

此外，稀疏向量是混合搜索策略的理想补充，甚至可以与密集向量相结合，将词汇精确性与语义理解相结合。

如何使用稀疏向量类型查询？

sparse_vector 查询可让您根据标记/值格式的查询向量搜索文档。请看下面的查询示例：

如果希望使用训练有素的模型，可以使用推理端点自动将查询文本转换为稀疏向量：

要进一步探讨这一主题，我建议阅读《用训练有素的 ML 模型理解稀疏向量嵌入》。

语义文本类型

semantic_text 字段类型是在 Elasticsearch 中使用语义搜索的最简单、最直接的方法。它通过一个推理端点，在索引和查询时自动处理嵌入生成。这意味着你不必担心手动生成或存储矢量的问题。

何时以及为何使用语义文本？

semantic_text 字段非常适合那些希望以最少的技术投入、无需手动处理矢量即可开始工作的用户。该字段可自动执行嵌入生成和矢量搜索映射等步骤，使设置更快更方便。

如果您重视简单性和抽象性，就应该考虑使用semantic_text ，因为它消除了手动配置映射、嵌入生成和摄取管道的复杂性。只需选择推理模型，其余的就交给 Elasticsearch 处理。

其主要优势包括在索引和查询过程中自动生成嵌入，以及可随时使用的映射，该映射经过预先配置，可支持选定的推理模型。

此外，该领域还提供对自动分割长文本（文本分块）的本地支持，可将大文本分割成较小的段落，每个段落都有自己的嵌入，从而提高搜索精度。这极大地提高了工作效率，尤其是对于那些希望在不处理语义搜索底层工程的情况下快速实现价值的团队而言。

不过，虽然semantic_text 提供了速度和简便性，但这种方法也有一些局限性。它允许使用市场标准模型，只要这些模型可以作为 Elasticsearch 中的推理端点。但它不支持外部生成的嵌入，而dense_vector 字段则可以做到这一点。

如果您需要对向量的生成方式进行更多控制，希望使用自己的嵌入，或需要将多个字段结合起来以实现高级策略，dense_vector 和sparse_vector 字段可提供更多自定义或特定领域方案所需的灵活性。

如何使用语义文本类型查询

在semantic_text 之前，必须根据嵌入类型（密集或稀疏）使用不同的查询。sparse_vector 查询用于稀疏字段，而dense_vector 字段则需要 KNN 查询。

使用语义文本类型时，搜索是通过语义查询进行的，查询会自动生成查询向量，并与索引文档的嵌入进行比较。semantic_text 类型允许您定义用于嵌入查询的推理端点，但如果未指定任何推理端点，则将对查询应用索引过程中使用的相同端点。

要了解更多信息，我建议您阅读 Elasticsearch 新语义_文本映射这 篇文章 ：简化语义搜索 。

结论

在选择如何在 Elasticsearch 中映射嵌入时，必须了解要如何生成向量以及需要对向量进行何种程度的控制。如果您追求简单，语义文本字段可实现自动和可扩展的语义搜索，使其成为许多初始用例的理想选择。当需要更多控制、微调性能或与自定义模型集成时，密集矢量和稀疏矢量场可提供必要的灵活性。

理想的字段类型取决于您的使用案例、可用基础设施以及机器学习堆栈的成熟度。最重要的是，Elastic 提供了用于构建现代化和高度适应性搜索系统的工具。

参考资料

• 语义文本字段类型

• 稀疏矢量场类型

• 密集矢量场类型

• 语义查询

• 稀疏向量查询

• kNN 搜索

• Elasticsearch 新语义文本映射：简化语义搜索

• 用训练有素的 ML 模型理解稀疏向量嵌入

本文中提到的所有完整查询和输出都可以在我们的Elasticsearch Labs 代码库中找到。

为什么要在使用案例中实施更好的二进制量化 (BBQ)？

数学知识固然耐人寻味，但要想完全掌握矢量搜索保持精确的原因，这一点至关重要。归根结底，这一切都与压缩有关，因为事实证明，目前的矢量搜索算法受到数据读取速度的限制。因此，如果能将所有数据都存储到内存中，那么与从存储设备中读取数据相比，速度将得到显著提升 （内存的 读取 速度约为固态硬盘的 200 倍 ）。

有几点需要注意：

• 基于图形的索引，如HNSW（层次导航小世界），对于向量检索来说是最快的。

  • HNSW：一种近似近邻搜索算法，可构建多层图结构，从而实现高效的高维相似性搜索。

• 从根本上说，HNSW 的速度受限于从内存读取数据的速度，或者在最糟糕的情况下，受限于从存储器读取数据的速度。

  • 理想情况下，您希望能够将所有存储的向量加载到内存中。

• 嵌入模型通常以 float32 的精度生成向量，每个浮点数 4 个字节。

• 最后，根据向量和/或维数的多少，内存很快就会不够存放所有向量。

如果把这看作是理所当然的，那么一旦你开始摄入数百万甚至数十亿的向量，每个向量都可能有数百甚至数千个维度，你就会发现问题很快就出现了。题为 "压缩比近似值"的部分提供了一些粗略的数字。

开始需要什么？

要开始使用，您需要具备以下条件：

• 如果使用 Elastic Cloud 或内部部署，则需要高于 8.18 的 Elasticsearch 版本。虽然 BBQ 是在 8.16 中引入的，但在本文中，您将使用vector_rescore ，它是在 8.18 中引入的。

• 此外，您还需要确保集群中有一个机器学习（ML）节点。(注意：加载模型需要至少 4GB 的 ML 节点，但如果要完成生产工作负载，可能需要更大的节点）。

• 如果使用的是无服务器，则需要选择针对向量进行了优化的实例。

• 您还需要具备矢量数据库方面的基础知识。如果您还不熟悉 Elastic 中的矢量搜索概念，可能需要先查看以下资源：

  • 导航弹性矢量数据库

  • 检索增强生成背后的重大理念

更好的二进制量化 (BBQ) 实现

为了使本博客简单明了，您将在可用时使用内置函数。在这种情况下，.multilingual-e5-small 向量嵌入模型将直接在 Elasticsearch 内部的机器学习节点上运行。请注意，您可以用自己选择的嵌入器（OpenAI、Google AI Studio、Cohere等）替换text_embedding 模型。如果您喜欢的模型尚未集成，您也可以自带密集向量嵌入模型）。

首先，您需要创建一个推理端点，为给定文本生成向量。您将从 KibanaDev Tools 控制台运行所有这些命令。该命令将下载.multilingual-e5-small.如果端点还不存在，它将为您设置端点；这可能需要一分钟的时间。你可以在 Outputs 文件夹中的01-create-an-inference-endpoint-output.json文件中看到预期输出。

返回后，模型就设置好了，您可以使用以下命令测试模型是否按预期运行。你可以在 Outputs 文件夹中的02-embed-text-output.json文件中看到预期输出。

如果遇到训练好的模型没有分配到任何节点的问题，可能需要手动启动模型。

现在，让我们创建一个带有 2 个属性的新映射，一个标准文本字段 (my_field) 和一个 384 维的密集矢量字段 (my_vector) ，以匹配嵌入模型的输出。您还可以覆盖index_options.type to bbq_hnsw 。你可以在 Outputs 文件夹中的文件03-create-byte-qauntized-index-output.json中看到预期输出。

要确保 Elasticsearch 生成向量，可以使用Ingest Pipeline。该管道需要三样东西：端点 (model_id)、要为其创建向量的input_field 以及用于存储这些向量的output_field 。下面的第一条命令将创建推理摄取管道，该管道使用推理服务 ，第二条命令将测试管道是否正常工作。你可以在 Outputs 文件夹中的文件04-create and-simulate-ingest-pipeline-output.json中看到预期输出。

现在，您可以使用下面的前 2 个命令添加一些文档，并使用第 3 个命令测试搜索是否有效。你可以在 Outputs 文件夹中的05-bbq-index-output.json文件中查看预期输出。

正如本文章所建议的，当您扩展到非数量级的数据时，建议使用重采样和超采样，因为它们有助于在受益于压缩优势的同时保持较高的召回准确率。从 Elasticsearch 8.18 版开始，您可以使用rescore_vector 这样做。预期输出在 Outputs 文件夹中的06-bbq-search-8-18-output.json文件中。

这些分数与原始数据的分数相比如何？如果您再次进行上述操作，但使用index_options.type: hnsw ，您会发现得分非常接近。你可以在 Outputs 文件夹中的07-raw-vector-output.json文件中看到预期输出。

压缩比的近似值

在使用矢量搜索时，存储和内存需求很快就会成为一项重大挑战。下面的细目说明了不同的量化技术如何显著减少矢量数据的内存占用。

向量 (V)

尺寸（D）

未加工（V x D x 4）

int8 (V x (D x 1 + 4))

int4 (V x (D x 0.5 + 4))

bbq (V x (D x 0.125 + 4))

10,000,000

384

14.31GB

3.61GB

1.83GB

0.58GB

50,000,000

384

71.53GB

18.07GB

9.13GB

2.89GB

100,000,000

384

143.05GB

36.14GB

18.25GB

5.77GB

结论

BBQ 是一种优化方法，可用于压缩矢量数据而不影响精度。它的工作原理是将向量转换为比特，让您能够有效地搜索数据，并使您能够扩展人工智能工作流程，加快搜索速度并优化数据存储。

进一步学习

如果您想了解有关烧烤的更多信息，请务必查看以下资源：

• Lucene 和 Elasticsearch 中的二进制量化 (BBQ)

• 更好的二进制量化（BBQ）与乘积量化比较

• 优化的标量量化更好的二进制量化

• 更好的二进制量化 (BBQ)：从字节到烧烤，更好的矢量搜索的秘密》，本-特伦特著

二进制量化对决

以原始形式存储高维向量会耗费大量内存。量化技术可将这些矢量压缩为紧凑的表示形式，从而大大减少内存占用。然后，搜索在压缩空间内进行，从而降低了计算复杂度，加快了搜索速度，尤其是在大型数据集中。

Elastic 致力于使 Lucene 成为性能一流的矢量引擎。在 Elasticsearch 8.16 中，我们在 Lucene 的基础上引入了更好的二进制量化(BBQ)，并在 8.18 和 9.0 中进一步发展。BBQ 基于一种新的标量量化方法，将 float32 维度减少到比特，在保持高排名质量的同时，减少了 ~95% 内存。

另一方面，OpenSearch 使用多种矢量引擎：nmslib（现已废弃）、Lucene 和 FAISS。在 上 一篇 博客 中，我们比较了 Elasticsearch 和 OpenSearch 的向量搜索。我们使用了三个不同的数据集，并在两种产品上测试了不同的引擎和配置组合。

本博客重点介绍这两种产品目前提供的二进制量化算法。我们使用 BBQ 对 Elasticsearch 进行了测试，并使用FAISS 的二进制量化（openai_vectorRally track）对 OpenSearch 进行了测试。

主要目的是评估两种解决方案在相同召回率下的性能。召回是什么意思？召回率是衡量搜索系统成功检索到多少相关结果的指标。

在这项评估中，recall@k 尤为重要，其中k代表所考虑的顶级结果的数量。因此，Recall@10、Recall@50 和 Recall@100分别用来衡量有多少真正相关的结果出现在检索结果的前 10、50 和 100 项中。召回率以 0 到 1 的范围表示（或 0% 到 100% 精确度）。这一点很重要，因为我们讨论的是近似 KNN (ANN)，而不是精确 KNN，后者的召回率总是 1 (100%).

对于每个k值，我们还指定了n， 即在应用最终排名之前考虑的候选者数量。这意味着，对于 Recall@10、Recall@50 和 Recall@100，系统首先使用二进制量化算法检索n 个候选项，然后对它们进行排序，以确定前k 个结果是否包含预期的相关项。

通过控制n，我们可以分析效率和精度之间的权衡。较高的n通常会增加召回率，因为有更多候选者可供排序，但同时也会增加延迟和 降低 吞吐量。相反，n越小，检索速度越快，但如果初始集合中包含的相关候选信息太少，则可能会降低召回率。

在这次比较中，Elasticsearch 在相同的设置下比 OpenSearch 的延迟更低，吞吐量更高。

方法

完整的配置，以及 Terraform 脚本、Kubernetes 清单和特定的 Rally 轨道，都可在此仓库 openai_vector_bq 下找到。

与之前的基准测试一样，我们使用的 Kubernetes 集群由以下部分组成：

• 1 个用于 Elasticsearch 9.0 的节点池，包含 3 台e2-standard-32 机器（128GB 内存和 32 个 CPU）

• 1 个用于 OpenSearch 2.19 的节点池，包含 3 台e2-standard-32 机器（128GB 内存和 32 个 CPU）

• 1 个用于 Rally 的节点池，包含 2 台e2-standard-4 机器（16GB 内存和 4 个 CPU）

我们建立了一个版本为 9.0 的 Elasticsearch 集群和一个版本为 2.19 的 OpenSearch 集群。

Elasticsearch 和 OpenSearch 都使用了完全相同的设置进行测试：我们使用了经过 一些修改的 openai_vector Rally track，它使用了来自 NQ 数据集 的 250 万份文档，并使用 OpenAI 的 text-embedding-ada-002 模型 生成了丰富的嵌入。

结果报告了在不同召回级别（召回率@10、召回率@50 和召回率@100）下，使用 8 个客户端同时执行搜索操作所测出的延迟和吞吐量。我们只使用一个分片，没有副本。

我们运行了以下 k-n-rescore 组合，例如10-2000-2000，或k:10、n:2000和rescore:2000将检索 n 个候选者（2000）中的前 k（10），并对 2000 个结果进行重新评分（相当于 "超抽样因子 "1）。每次搜索运行 10.000 次，预热 1000 次：

召回@10

• 10-40-40

• 10-50-50

• 10-100-100

• 10-200-200

• 10-500-500

• 10-750-750

• 10-1000-1000

• 10-1500-1500

• 10-2000-2000

回忆@50

• 50-150-150

• 50-200-200

• 50-250-250

• 50-500-500

• 50-750-750

• 50-1000-1000

• 50-1200-1200

• 50-1500-1500

• 50-2000-2000

Recall@100

• 100-200-200

• 100-250-250

• 100-300-300

• 100-500-500

• 100-750-750

• 100-1000-1000

• 100-1200-1200

• 100-1500-1500

• 100-2000-2000

为了复制基准，Rally-elasticsearch 和 rally-opensearch 的 Kubernetes 清单都将所有相关变量外部化到了 ConfigMap 中，可在此处（ES）和此处（OS）查看。可以自定义search_ops参数，以测试 k、n 和 rescore 的任意组合。

OpenSearch Rally 配置

/k8s/rally-openai_vector-os-bq.yml

Opensearch 索引配置

然后，ConfigMap 中的变量将用于索引配置，某些参数则保持不变。OpenSearch 中的 1 位量化是通过 将压缩级别设置为 "32x " 来配置的 。

index-vectors-only-mapping-with-docid-mapping.json

Elasticsearch Rally 配置

/k8s/rally-openai_vector-es-bq.yml

Elasticsearch 索引配置

index-vectors-only-mapping-with-docid-mapping.json

实施结果

对结果有多种解释方法。对于延迟和吞吐量，我们绘制了每个召回级别的简化图和详细图。如果我们考虑到每项指标 "越高越好"，就很容易发现其中的差异。不过，延迟是负值（实际上越低越好），而吞吐量是正值。在简化图表中，我们使用（召回率/延迟）*10000 （简称 "速度"）和 召回率*吞吐量，因此这两个指标都意味着速度越快和吞吐量越大越好。让我们开始吧。

召回 @ 10 - 简化

在这种召回水平下，Elasticsearch BBQ 比 OpenSearch FAISS快 5 倍 （平均快 3.9 倍），吞吐量平均高出 3.2 倍。

召回 @ 10 - 详细

工作

latency.mean

吞吐量平均值

平均调用次数

Elasticsearch-9.0-BBQ

10-100-100

11.70

513.58

0.89

Elasticsearch-9.0-BBQ

10-1000-100

27.33

250.55

0.95

Elasticsearch-9.0-BBQ

10-1500-1500

35.93

197.26

0.95

Elasticsearch-9.0-BBQ

10-200-200

13.33

456.16

0.92

Elasticsearch-9.0-BBQ

10-2000-2000

44.27

161.40

0.95

Elasticsearch-9.0-BBQ

10-40-40

10.97

539.94

0.84

Elasticsearch-9.0-BBQ

10-50-50

11.00

535.73

0.85

Elasticsearch-9.0-BBQ

10-500-500

19.52

341.45

0.93

Elasticsearch-9.0-BBQ

10-750-750

22.94

295.19

0.94

OpenSearch-2.19-faiss

10-100-100

35.59

200.61

0.94

OpenSearch-2.19-faiss

10-1000-1000

156.81

58.30

0.96

OpenSearch-2.19-faiss

10-1500-1500

181.79

42.97

0.96

OpenSearch-2.19-faiss

10-200-200

47.91

155.16

0.95

OpenSearch-2.19-faiss

10-2000-2000

232.14

31.84

0.96

OpenSearch-2.19-faiss

10-40-40

27.55

249.25

0.92

OpenSearch-2.19-faiss

10-50-50

28.78

245.14

0.92

OpenSearch-2.19-faiss

10-500-500

79.44

97.06

0.96

OpenSearch-2.19-faiss

10-750-750

104.19

75.49

0.96

召回 @ 50 - 简化

在这种召回水平下，Elasticsearch BBQ 比 OpenSearch FAISS 快多达 5 倍 （平均快 4.2 倍），平均 吞吐量多 3.9 倍 。

详细结果 - 召回率 @ 50

任务

平均时延

吞吐量平均值

平均召回率

Elasticsearch-9.0-BBQ

50-1000-1000

25.71

246.44

0.95

Elasticsearch-9.0-BBQ

50-1200-1200

28.81

227.85

0.95

Elasticsearch-9.0-BBQ

50-150-150

13.43

362.90

0.90

Elasticsearch-9.0-BBQ

50-1500-1500

33.38

202.37

0.95

Elasticsearch-9.0-BBQ

50-200-200

12.99

406.30

0.91

Elasticsearch-9.0-BBQ

50-2000-2000

42.63

163.68

0.95

Elasticsearch-9.0-BBQ

50-250-250

14.41

373.21

0.92

Elasticsearch-9.0-BBQ

50-500-500

17.15

341.04

0.93

Elasticsearch-9.0-BBQ

50-750-750

31.25

248.60

0.94

OpenSearch-2.19-faiss

50-1000-1000

125.35

62.53

0.96

OpenSearch-2.19-faiss

50-1200-1200

143.87

54.75

0.96

OpenSearch-2.19-faiss

50-150-150

43.64

130.01

0.89

OpenSearch-2.19-faiss

50-1500-1500

169.45

46.35

0.96

OpenSearch-2.19-faiss

50-200-200

48.05

156.07

0.91

OpenSearch-2.19-faiss

50-2000-2000

216.73

36.38

0.96

OpenSearch-2.19-faiss

50-250-250

53.52

142.44

0.93

OpenSearch-2.19-faiss

50-500-500

78.98

97.82

0.95

OpenSearch-2.19-faiss

50-750-750

103.20

75.86

0.96

召回 @ 100

在这种召回水平下，Elasticsearch BBQ 比 OpenSearch FAISS快 5 倍 （平均快 4.6 倍），吞吐量 平均高 3.9 倍。

详细结果 - Recall @ 100

工作

latency.mean

吞吐量平均值

平均调用次数

Elasticsearch-9.0-BBQ

100-1000-1000

27.82

243.22

0.95

Elasticsearch-9.0-BBQ

100-1200-1200

31.14

224.04

0.95

Elasticsearch-9.0-BBQ

100-1500-1500

35.98

193.99

0.95

Elasticsearch-9.0-BBQ

100-200-200

14.18

403.86

0.88

Elasticsearch-9.0-BBQ

100-2000-2000

45.36

159.88

0.95

Elasticsearch-9.0-BBQ

100-250-250

14.77

433.06

0.90

Elasticsearch-9.0-BBQ

100-300-300

14.61

375.54

0.91

Elasticsearch-9.0-BBQ

100-500-500

18.88

340.37

0.93

Elasticsearch-9.0-BBQ

100-750-750

23.59

285.79

0.94

OpenSearch-2.19-faiss

100-1000-1000

142.90

58.48

0.95

OpenSearch-2.19-faiss

100-1200-1200

153.03

51.04

0.95

OpenSearch-2.19-faiss

100-1500-1500

181.79

43.20

0.96

OpenSearch-2.19-faiss

100-200-200

50.94

131.62

0.83

OpenSearch-2.19-faiss

100-2000-2000

232.53

33.67

0.96

OpenSearch-2.19-faiss

100-250-250

57.08

131.23

0.87

OpenSearch-2.19-faiss

100-300-300

62.76

120.10

0.89

OpenSearch-2.19-faiss

100-500-500

84.36

91.54

0.93

OpenSearch-2.19-faiss

100-750-750

111.33

69.95

0.94

烧烤炉的改进

自首次发布以来，BBQ 已经取得了长足的进步。在 Elasticsearch 8.16 上，为了便于比较，我们将 8.16 的基准运行与当前的基准运行放在一起，我们可以看到召回率和延迟从那时起有了怎样的改善。

在 Elasticsearch 8.18 和 9.0 中，我们重写了量化向量的核心算法。因此，8.16 版的 BBQ 已经很不错了，而最新版本则更加出色。您可以在这里和这里了解相关信息。简而言之，每个矢量都通过优化的标量量化进行了单独量化。因此，用户可以在不影响性能的情况下获得更高的向量搜索准确性，使 Elasticsearch 的向量检索功能更加强大。

结论

在 Elasticsearch BBQ 和 OpenSearch FAISS 的性能比较中，Elasticsearch 在矢量搜索方面明显优于 OpenSearch，在各种召回级别中，Elasticsearch 的查询速度平均提高了 5 倍，吞吐量提高了 3.9 倍。

主要发现包括

• Recall@10：与 OpenSearch FAISS 相比，Elasticsearch BBQ 的速度快达 5 倍（平均快 3.9 倍），吞吐量平均高出 3.2 倍。

• Recall@50：与 OpenSearch FAISS 相比，Elasticsearch BBQ 的速度快达 5 倍（平均快 4.2 倍），吞吐量平均高出 3.9 倍。

• Recall@100：与 OpenSearch FAISS 相比，Elasticsearch BBQ 的速度快达 5 倍（平均快 4.6 倍），吞吐量平均高出 3.9 倍。

这些结果凸显了 Elasticsearch BBQ 的效率和性能优势，尤其是在高维向量搜索场景中。Elasticsearch 8.16 中引入的更好的二进制量化（BBQ）技术在保持较高排序质量的同时，大幅减少了内存（~95% ），是大规模矢量搜索应用的上佳选择。

在 Elastic，我们坚持不懈地创新，改进 Apache Lucene 和 Elasticsearch，为搜索和检索用例（包括 RAG（检索增强生成））提供最佳的向量数据库。在 Lucene 10 的基础上，我们最近取得的进步大大提高了性能，使矢量搜索比以前更快、更节省空间。本博客就是这种创新的又一例证。

开发人员现在可以在一个统一的旅程中创建他们的 RAG 应用程序，以一种低代码、灵活的方式将他们的聊天体验建立在他们的私人数据之上。无论您是为客户和内部员工构建人工智能代理，还是在软件中利用 LLMs 生成，Vertex 人工智能平台都能让 Elasticsearch 的相关性触手可及，只需最少的配置。这种集成使 Gemini 模型更容易、更快速地应用于生产用例，推动 GenAI 从 PoCs 进入实际生活场景。

在本博客中，我们将指导您将 Elasticsearch 与谷歌云的 Vertex AI 平台集成，以实现无缝数据落地，并构建完全可定制的 GenAI 应用程序。让我们一起来探索吧。

借助 Elasticsearch，Google 云的 Vertex AI 和 Gemini 模型可在您的数据中落地生根

利用 Vertex AI 服务和工具创建 GenAI 应用程序的用户现在可以访问新的 "接地 "选项，将其私人数据自动引入对话交互。Elasticsearch 现在是该功能的一部分，可以通过这两种方式使用：

• Vertex AILLM API，可在生成时直接丰富 Google 的双子座模型（首选）；

• 地基生成应用程序接口（Grounded Generation API ），在顶点人工智能代理 生成器 （Vertex AI Agent Builder）生态系统中用于构建代理体验。

通过这种集成，下载和部署最多的向量数据库Elasticsearch 将把您的相关企业数据带到您的内部终端客户聊天中所需的任何地方，这对 GenAI 在业务流程中的实际应用至关重要。

上述应用程序接口将允许开发人员在其代码中采用这项新的合作伙伴功能。不过，及时的工程设计和测试仍然是应用程序开发的关键步骤，也是最初的探索过程。为了支持这一点，Elasticsearch 的设计便于用户在 Vertex AI Studio 控制台工具中进行评估。

只需几个简单的步骤，在用户界面的 "自定义接地 "选项卡中用所需的参数（要搜索的索引、要检索的文档数量和所需的搜索模板）配置 Elastic 端点，如下图所示（注意，要使其正常工作，必须在用户界面和下面的代码示例中键入带有"ApiKey" 字样的 API 密钥）。现在，您已经准备好用您的私人知识进行生成了！

轻松实现可投入生产的 GenAI 应用程序

Elastic 和 Google Cloud 致力于提供开发人员优先、全面和愉快的体验。在 Vertex AI 上构建 GAI 应用程序时，通过 LLM 和接地生成 API 原生连接到 Elastic 可降低复杂性和开销，避免不必要的额外 API 和数据协调，同时只需一次统一调用即可接地。

让我们看看在这两种情况下是如何工作的。

第一个示例使用 LLM API 执行：

在上例中，通过请求将内容生成到 Gemini 2.0 Flash 的 API 的retrieval 字段，我们可以根据上下文设置请求的检索引擎。将api_spec 设置为 "ELASTIC_SEARCH "后，就可以使用其他配置参数，如 API 密钥和集群端点（需要将请求路由到 Elastic 集群）、检索数据的索引以及用于搜索逻辑的搜索模板。

同样，通过接地生成 API，设置groundingSpec 参数，也可以获得相同的结果：

使用这两种方法，响应都将提供一个包含 Elasticsearch 中最相关的私有文档的答案，以及相关的连接数据源，以支持您的查询。

但是，不能把简单与缺乏个性化以满足您的特定需求和使用情况混为一谈。考虑到这一点，我们在设计时允许您根据自己的情况对搜索配置进行完美调整。

指尖上的完全自定义搜索：搜索模板

为了最大限度地定制您的搜索方案，我们与 Google Cloud 合作，在我们著名的搜索模板基础上打造了这一体验。Elasticsearch 搜索模板是创建动态、可重用和可维护搜索查询的绝佳工具。它们允许你预定义和重复使用查询结构。在使用不同参数执行类似查询时，它们尤其有用，因为它们可以节省开发时间并减少出错的机会。模板可包括变量占位符，使查询动态化，并适应不同的搜索要求。

在使用 Vertex AI API 和 Elasticsearch 作为基础时，您必须引用所需的搜索模板（如上面的代码片段所示），在该模板中实现搜索逻辑并将其推送到 Elasticsearch。对于 Vertex AI 用户、网络应用程序开发人员或 AI 工程师来说，他们只需在基础 API 中指定模板名称，就能以完全透明的方式异步管理、配置和更新搜索方法，并根据特定的索引、模型和数据进行定制。

这种设计允许完全定制，将广泛的 Elasticsearch 检索功能置于 Google Cloud AI 环境中供您使用，同时确保模块化、透明性和易用性，以适应不同的开发人员，甚至是不熟悉 Elastic 的开发人员。

无论何时您需要 BM25 检索、语义检索或两者的混合方法（您是否已经探索过检索器？在单个搜索 API 调用中使用可组合检索技术），您可以在搜索模板中定义自定义逻辑，Vertex AI 可以自动利用该模板。

这也适用于您选择用来管理向量和结果的嵌入和重排模型。根据您的使用情况，您可能希望在 Elastic 的 ML 节点上托管模型，通过推理 API 使用第三方服务端点，或者在本地运行本地模型。这可以通过搜索模板来实现，我们将在下一节了解其工作原理。

从参考模板开始，然后创建自己的模板

为了帮助您快速上手，我们提供了一套兼容的搜索模板示例，供您作为初始参考，然后您可以修改并建立自己的自定义模板：

• 使用 ELSER 模型（稀疏向量和分块）进行语义搜索

• 使用 e5 多语言模型（密集向量和分块）进行语义搜索

• 使用顶点人工智能文本嵌入模型进行混合搜索

您可以在此GitHub 仓库中找到它们。

让我们来看一个例子：使用谷歌云的顶点人工智能应用程序接口在产品目录上创建嵌入。首先，我们需要在 Elasticsearch 中创建搜索模板，如下图所示：

在本例中，我们将在一次搜索中对两个字段执行 KNN 搜索： title_embedding - 包含产品名称的矢量字段 - 以及description_embedding - 包含产品描述的矢量字段。

您可以利用excludes 语法，避免向 LLM 返回不必要的字段，以免在处理过程中产生噪音，影响最终答案的质量。在我们的示例中，我们排除了包含向量和图片 url 的字段。

矢量是在查询时通过顶点人工智能嵌入式应用程序接口googlevertexai_embeddings_004 的推理端点在提交的输入上即时创建的，其定义如下：

有关如何使用 Elastic Inference API 的更多信息，请点击此处。

现在我们可以测试模板搜索了：

params 字段将替换我们在模板脚本中设置的变量，这些变量位于双卷曲括号中。目前，Vertex AI LLM 和 Grounded Generation API 可以向 Elastic 发送以下输入变量：

• "query" - 要搜索的用户查询

• "index_name" - 要搜索的索引名称

• "num_hits" - 我们希望在最终输出中检索多少文件

下面是输出示例：

上述查询正是 Google Cloud 的 Vertex AI 在引用之前创建的搜索模板时在 Elasticsearch 上运行的幕后查询。Gemini 模型将使用输出文档作为其答案的基础：当您问 "我需要什么来修补干墙？"时，聊天代理将为您提供具体的产品，而不是通用的建议！

借助 Elastic 和谷歌云实现端到端 GenAI 之旅

Elastic 与谷歌云（Google Cloud）合作，创建生产就绪的端到端 GenAI 体验和解决方案。正如我们刚刚看到的那样，Elastic 是第一个直接集成到顶点人工智能平台的用户界面和 SDK 中的 ISV，可以利用我们的矢量搜索功能实现无缝、接地气的双子座模型提示和代理。此外，Elastic 还与 Vertex AI 和 Google AI Studio 的嵌入、重排序和完成模型集成，无需离开 Google 云环境即可创建矢量并对 其 进行排序，确保 遵循负责任的人工智能 原则。通过支持多模式方法，我们共同促进了各种数据格式的应用。

您可以通过我们的Playground 调整、测试和导出 GenAI 搜索代码。

但它不仅仅是构建搜索应用程序：Elastic 利用 Gemini 模型增强 IT 运营能力，如Elastic AI 助手、攻击发现和自动导入功能，减少安全分析师和 SRE 每天在低价值任务上的疲劳，使他们能够专注于改进业务。Elastic 还能全面监控 Vertex AI 的使用情况，跟踪响应时间、令牌和资源等指标和日志，以确保最佳性能。我们共同管理从数据摄取、嵌入生成到混合搜索落地的整个 GenAI 生命周期，同时利用 LLM 驱动的行动确保 GenAI 工具的稳健可观测性和安全性。

更多探索和尝试！

您有兴趣试一试吗？该功能目前在您的 Google Cloud 项目中使用！

如果您还没有开始使用 Elastic Search AI Platform 并探索我们的功能，最简单的方法之一就是免费试用 Elastic Cloud或通过Google Cloud Marketplace 订阅。

本文章中描述的任何特性或功能的发布和时间均由 Elastic 自行决定。目前尚未提供的任何特性或功能可能无法按时交付或根本无法交付。Elastic、Elasticsearch 和相关标记是 Elasticsearch N.V. 在美国和其他国家的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。

你可能会问，为什么要使用多图表呢？这是 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 在矢量和混合搜索方面快速高效而不断努力的一部分。

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

作为 "不遗余力地提高效率 "这一使命的一部分，我们正在利用这些奇特的计算机芯片探索加速机会，你可能听说过英伟达™（NVIDIA®）GPU！(说真的，你没听说过吗？）

在执着于性能时，我们有几个问题空间需要探索--如何索引指数级增长的数据，如何从中获取洞察力，以及如何在涉及 ML 模型时做到这一点。有了 GPU，你就能把所有的优势都发挥出来。

在本篇文章中，我们将深入探讨与英伟达™（NVIDIA®）矢量搜索团队的合作，探索 Elasticsearch 中的 GPU 加速矢量搜索。这项工作为开发人员在实际的 Elasticsearch 应用程序中混合使用 GPU 和 CPU 的用例铺平了道路。激动人心的时刻

Elasticsearch GPU

我们很高兴地与大家分享，Elasticsearch 工程团队正在帮助开发人员构建开源的 cuVS Java API 体验，该体验为矢量搜索算法提供了绑定。这项工作利用了我们以前在巴拿马 FFI 方面的经验。Elasticsearch 和 Apache Lucene 在索引过程中使用英伟达 cuVS API 构建图形。好吧，我们跳到前面，让我们倒退一下。

NVIDIA cuVS 是一个开源 C++ 库，是此次合作的核心。它旨在通过提供更高的吞吐量、更低的延迟和更快的索引构建时间，为矢量搜索提供 GPU 加速。但 Elasticsearch 和 Apache Lucene 都是用 Java 编写的，这怎么行呢？

进入lucene-cuvs和 Elastic-NVIDIA-SearchScale 合作，将其引入 Lucene 生态系统，在 Elasticsearch 中探索 GPU 加速的矢量搜索。在最近发布的英伟达 cuVS 25.02 中，我们为 cuVS 添加了 Java API。新的应用程序接口是试验性的，将继续发展，但目前已经可以使用。也许有人会问：Java 对本地函数的调用不是很慢吗？现在不一样了！我们正在使用新的巴拿马 FFI（外来函数接口）进行绑定，它将 Java 与本地向下调用的开销降至最低。

我们 在 Elasticsearch 和 Lucene 中 使用 巴拿马 FFI 已经有一段时间了。太棒了但是......总是有 "但是 "的，不是吗？FFI 在跨 Java 版本的可用性方面存在挑战。我们将 cuVS 应用程序接口编译到 Java 21，并将实现封装在一个针对 Java 22 的多版本 jar 中，从而克服了这一问题。这样就可以直接在 Lucene 和 Elasticsearch 中使用 cuVS Java。

好了，既然我们已经有了 cuVS Java API，还需要什么呢？

两种 CPU 算法的故事

Elasticsearch 支持用于可扩展近似 KNN 搜索的HNSW 算法。不过，为了最大限度地利用 GPU，我们使用了另一种算法 CAGRA [ CUDAANNGRAph] ，它是专门为 GPU 提供的高并行性而设计的。

在了解如何添加对 CAGRA 的支持之前，我们先来看看 Elasticsearch 和 Lucene 是如何通过 "编解码器格式 "访问索引数据的。这包括

1. 磁盘表示法、

2. 读写数据的接口、

3. 以及处理 Lucene 基于段的架构的机制。

我们正在实施一种新的 KNN（k-近邻）向量格式，该格式内部使用 cuVS Java API 在 GPU 上进行索引和搜索。从这里开始，我们通过 Elasticsearch 的映射将此编解码器类型 "剽窃 "到索引中的字段类型。因此，无论后备索引使用的是 CAGRA 还是 HNSW 图形，现有的 KNN 查询都能继续工作。当然，这忽略了许多细节，我们计划在今后的博客中加以介绍。以下是 GPU 加速 Elasticsearch 的高级架构。

这种新的编解码器格式默认为 CAGRA。不过，它也支持将 CAGRA 图形转换为 HNSW 图形，以便在 CPU 上进行搜索。

在 GPU 上进行索引和搜索：做出一些 "核心 "决定

Elasticsearch Serverless 的无状态架构将索引和搜索分离开来，因此现在有了明确的职责划分。我们选择最佳的硬件配置文件来履行这些独立的职责。

我们预计用户会考虑两种主要的部署策略：

1. 在 GPU 上进行索引和搜索：在索引过程中，建立一个 CAGRA 图，并在搜索过程中使用它--这在需要极低延迟的搜索时非常理想。

2. 在 GPU 上索引，在 CPU 上搜索：在索引过程中，构建 CAGRA 图并将其转换为 HNSW 图。HNSW 图形存储在索引中，随后可用于 CPU 的搜索。

这种灵活性提供了不同的部署模式，在成本和性能之间进行了权衡。例如，索引服务可以使用 GPU 及时高效地构建和合并图形，同时使用性能较低的 CPU 进行搜索。

以下是在 Elasticsearch 中使用 GPU 加速矢量搜索的计划

我们期待为用户带来性能提升和部署策略的灵活性，提供各种旋钮来平衡成本和性能。下面是 NVIDIA GTC 2025 会议对这项工作的详细介绍。

我们要感谢 NVIDIA 和 SearchScale 工程团队的出色合作。在下一篇博客中，我们将更深入地探讨实施细节和性能分析。戴上好奇帽🎩 ！

第一部分重点介绍嵌入向量的基础知识以及向量搜索的工作原理。

有了在第一篇文章中学到的所有知识，第二部分将指导你如何在 Elasticsearch 中设置矢量搜索。

在第三部分中，我们将利用在前两部分中学到的知识，在此基础上深入研究如何在 Elasticsearch 中创建强大的混合搜索查询。

在进入本文的正题之前，让我们回顾一下向量的历史，向量是语义搜索的一个关键概念。

病媒并不新鲜

相信每个人都会同意，自 2022 年 11 月 ChatGPT 问世以来，没有一天不听到或读到关于 "矢量搜索 "的消息。它无处不在，如此普遍，以至于我们经常会觉得这是一项刚刚问世的新尖端技术，但事实上，这项技术已经存在了六十多年！对这一主题的研究始于 20 世纪 60 年代中期，1978 年，信息检索专家杰拉德-萨尔顿和他在康奈尔大学的同事发表了第一批研究论文。萨尔顿在密集和稀疏向量模型方面的研究成果是现代向量搜索技术的基础。

在过去的 20 年里，基于他的研究成果，许多不同的矢量数据库管理系统相继问世并推向市场。其中包括由 Apache Lucene 项目提供支持的 Elasticsearch，该项目于 2019 年开始致力于矢量搜索。

矢量现在无处不在，非常普遍，因此在使用矢量之前，首先要充分掌握其基本理论和内部工作原理。在深入探讨之前，让我们先快速回顾一下词法搜索和矢量搜索之间的区别，以便更好地理解它们的不同之处以及如何相互补充。

矢量搜索与词法搜索

介绍向量搜索的一个简单方法是将其与你可能已经习惯的更传统的词法搜索进行比较。矢量搜索（通常也称为语义搜索）和词法搜索的工作原理截然不同。词法搜索是我们在 Elasticsearch 中使用多年的一种搜索方式。简而言之，它并不试图理解所索引和查询内容的真正含义，而是努力将用户在查询中键入的单词或其变体（如词干、同义词等）的字面意思与之前已通过相似性算法（如 TF-IDF）索引到数据库中的所有字面意思进行词法匹配。

我们可以看到，左上方的三份文档已经进行了标记化和分析。然后，将得到的术语编入倒排索引，该索引只是将分析术语映射到包含这些术语的文档 ID。请注意，所有术语都只出现一次，没有任何文件共享这些术语。搜索 "优秀的德国教师 "时，三份文档的匹配得分各不相同，但没有一份真正符合查询的真正含义。

如下图 2 所示，在处理多义词或同形词（即拼写相同但含义不同的词（right、palm、bat、mean 等））时，情况会变得更加棘手。

搜索"我不对"，返回的文档与第一个返回结果的含义完全相反。如果搜索完全相同的术语，但为了产生不同的含义而对它们进行不同的排序，例如"向右转 "和" 右转"，则会得到完全相同的结果（即第三份文档 "向右转"）。当然，我们的查询过于简化，没有使用短语匹配等更高级的查询，但这有助于说明词法搜索并不了解索引内容和搜索内容背后的真正含义。如果还不清楚，也不要着急，我们将在第三篇文章中再次讨论这个例子，看看矢量搜索在这种情况下如何提供帮助。

对词法搜索来说，当你能够控制如何为结构化数据建立索引（如映射、文本分析、摄取管道等）以及如何制作查询（如巧妙制作的 DSL 查询、查询词分析等）时，你就能利用词法搜索引擎创造奇迹，这是毋庸置疑的！Elasticsearch 的词法搜索能力令人惊叹。在过去的几年里，它所取得的成就以及它对词法搜索领域的普及和改进确实令人瞩目。

但是，如果要为需要提出自由文本问题的用户提供非结构化 数据（如图像、视频、音频、原始文本等）的查询支持，词法搜索就显得力不从心了。此外，有时查询的内容甚至不是文本，而可能是图片，我们很快就会看到。在这种情况下，词法搜索无法胜任的主要原因是，非结构化数据既无法像结构化数据那样被索引，也无法像结构化数据那样被查询。在处理非结构化数据时，语义学开始发挥作用。语义学是什么意思？很简单，就是这个意思！

让我们以简单的图像搜索引擎（如谷歌图像搜索或 Lens）为例。您只需拖放一张图片，谷歌语义搜索引擎就会找到并返回与您查询的图片最相似的图片。在下图 3 中，我们可以看到左侧是一张德国牧羊犬的图片，右侧是所有已检索到的相似图片，第一个结果是与所提供图片相同的图片（即最相似的图片）。

尽管这对我们人类来说听起来简单且合乎逻辑，但对计算机来说却是另一回事。这正是矢量搜索所能实现和帮助实现的。矢量搜索所释放的能量是巨大的，全世界最近都见证了这一点。现在，让我们揭开引擎盖，看看下面隐藏着什么。

嵌入向量

正如我们在前面所看到的，通过词法搜索引擎，文本等结构化数据可以很容易地被标记为在搜索时可以匹配的术语，而不管这些术语的真正含义是什么。然而，非结构化数据可以采用不同的形式，例如大型二进制对象（图像、视频、音频等），而且完全不适合采用相同的标记化流程。此外，语义搜索的整个目的就是为数据编制索引，以便根据数据所代表的意义进行搜索。我们如何做到这一点？答案就在两个字里：机器学习！或者更准确地说，是深度学习！

深度学习是机器学习的一个特定领域，它依赖于基于人工神经网络的多层处理模型，可以逐步提取数据的真实含义。这些神经网络模型的工作方式在很大程度上受到了人脑的启发。下图 4 显示了神经网络的外观，包括输入层、输出层和多个隐藏层：

神经网络的真正功能在于，它能够将单个非结构化数据转化为浮点数值序列，这些浮点数值被称为嵌入向量或简称嵌入。作为人类，只要将向量在二维或三维空间中形象化，我们就能很好地理解向量是什么。矢量的每个分量代表二维 x-y 平面或三维 x-y-z 空间中的一个坐标。

然而，神经网络模型所依赖的嵌入向量可能有几百甚至上千个维度，而且仅仅代表多维空间中的一个点。每个向量维度代表非结构化数据的一个特征或特性。让我们用一个将图像转化为 2048 维嵌入向量的深度学习模型来说明这一点。该模型将把我们在图 3 中使用的德国牧羊犬图片转化为下表所示的嵌入向量。请注意，我们只显示了前三个元素和后三个元素，但表格中还有 2,042 个列/维度。

is_red

是狗

blue_sky

…

no_gras

德国牧羊犬

is_tree

德国牧羊犬 嵌入

0.0121

0.9572

0.8735

…

0.1198

0.9712

0.0512

每一列是模型的一个维度，代表底层神经网络试图建模的一个特征或特性。根据输入与 2048 个维度中每个维度的相似程度，对模型的每个输入进行特征描述。因此，嵌入向量中每个元素的值表示该输入与特定维度的相似度。在这个例子中，我们可以看到模型检测到狗和德国牧羊犬之间的高度相似性，以及一些蓝天的存在。

与词法搜索相比，矢量搜索能让我们更好地了解非结构化数据与模型支持的每个维度的相似程度。因此，嵌入向量可以作为非结构化数据的绝佳语义表示。

秘制酱汁

既然我们已经知道深度学习神经网络是如何将非结构化数据切成嵌入向量的，这些嵌入向量可以从多个维度捕捉数据的相似性，那么我们就需要了解这些向量的匹配是如何进行的。事实证明，答案非常简单。相互接近的嵌入向量代表语义相似的数据片段。因此，当我们查询矢量数据库时，搜索输入（图像、文本等）首先会使用索引所有非结构化数据时使用的相同模型转化为嵌入矢量，最终目标是找到与该查询矢量最近的相邻矢量。因此，我们需要做的就是找出如何测量查询向量与数据库中索引的所有现有向量之间的 "距离 "或 "相似性"，仅此而已。

距离和相似性

幸运的是，由于有了向量算术，测量两个向量之间的距离是一个很容易解决的问题。因此，让我们来看看现代矢量搜索数据库（如 Elasticsearch）支持的最常用的距离和相似性函数。警告，前方有数学题！

L1 距离

两个向量 x 和 y 的 L1 距离（也称为曼哈顿距离）是通过将它们所有元素的成对绝对差值相加来测量的。显然，距离 d 越小，两个矢量就越接近。计算公式非常简单，如下所示：

下图 5 可以直观地说明 L1 距离：

假设有两个向量 x 和 y，例如 x = (1, 2) 和 y = (4, 3)，那么这两个向量的 L1 距离为 | 1 - 4 | + | 2 - 3 | = 4。

L2 距离

测量两个向量 x 和 y 的 L2 距离（也称欧几里得距离）的方法是，首先求出它们所有元素成对差值的平方和，然后取其平方根。它基本上是两点之间最短的路径（也称为斜边）。与 L1 类似，距离 d 越小，两个向量越接近：

L2 距离如下图 6 所示：

让我们重新使用与 L1 距离相同的两个样本向量 x 和 y，现在我们可以计算出 L2 距离为。10 的平方根就是 3.16。

林夫距离

两个向量 x 和 y 的 Linf（表示 L 无穷大）距离，也称为切比雪夫距离或棋盘距离，简单地定义为这两个向量的任意两个元素之间的最长距离，或沿其中一个轴/维测量的最长距离。计算公式非常简单，如下所示：

林夫距离的表示方法如下图 7 所示：

同样，取相同的两个样本向量 x 和 y，我们可以计算出无穷大距离为 max ( | 1 - 4 | , | 2 - 3 | ) = max (3, 1) = 3。

余弦相似性

与 L1、L2 和 Linf 不同的是，余弦相似度不是测量两个向量 x 和 y 之间的距离，而是测量它们的相对角度，即它们是否都指向大致相同的方向。相似度 s 越高，两个向量就越 "接近"。计算公式同样非常简单，如下所示：

两个向量的余弦相似度的表示方法如下图 8 所示：

此外，由于余弦值始终处于[-1, 1]区间，-1 表示相似度相反（即两个矢量之间的夹角为 180°），0 表示相似度不相关（即夹角为 90°），1 表示相似度相同（即夹角为 0°），如下图 9 所示：

让我们再次使用相同的样本向量 x 和 y，用上述公式计算余弦相似度。首先，我们可以计算出两个向量的点积为。然后，我们将两个向量的长度（也称为幅值）相乘：最后，我们用点积除以乘积长度 10 / 11.18034 = 0.894427（即 26°角），这个值非常接近 1，因此可以认为这两个矢量非常相似。

点积相似性

余弦相似度的一个缺点是，它只考虑两个矢量之间的角度，而不考虑它们的大小（即长度），这意味着如果两个矢量大致指向同一方向，但其中一个矢量比另一个矢量长很多，那么这两个矢量仍然会被认为是相似的。点积相似度（也称为标量或内积）考虑了向量的角度和大小，从而改进了点积相似度，提供了更精确的相似度量。

点积相似性的计算有两个等价公式。第一种情况与我们之前在余弦相似性的分子中看到的相同：

第二个公式只是将两个矢量的长度乘以它们之间夹角的余弦：

下图 10 展示了点积相似性：

最后，我们取样 x 和 y 向量，使用第一个公式计算它们的点积相似度，就像之前计算余弦相似度一样，即 (1) + (2) = 10。

利用第二个公式，我们将两个矢量的长度相乘：+(4^2 + 3^2)^{1/2} = 11.18034，再乘以两个向量之间 26°夹角的余弦，就得到 11.18034(26°) = 10。

值得注意的一点是，如果首先对所有向量进行归一化处理（即长度为 1），那么点积相似度就会与余弦相似度（因为 |x| |y| = 1）完全相同，即两个向量之间夹角的余弦值。正如我们稍后将看到的，对向量进行归一化处理是一种很好的做法，这样可以使向量的大小变得无关紧要，从而使相似性只集中在角度上。它还能加快索引和查询时的距离计算速度，这在处理数十亿矢量时可能是个大问题。

快速回顾

哇，到目前为止，我们已经了解了很多信息，让我们稍停片刻，快速回顾一下目前的状况。我们了解到

• ...语义搜索基于深度学习神经网络模型，擅长将非结构化数据转化为多维嵌入向量。

• ......模型的每个维度都代表了非结构化数据的一个特征或特性。

• ......嵌入向量是一串相似度值（每个维度一个），表示给定的非结构化数据与每个维度的相似程度。

• ......两个向量越 "接近"（即近邻），它们代表的语义概念就越相似。

• ......距离函数（L1、L2、Linf）可以测量两个向量的距离。

• ......相似函数（余弦和点积）使我们能够测量两个向量朝同一方向移动的程度。

现在，我们需要深入研究的最后一个部分是矢量搜索引擎本身。当收到查询时，首先对查询进行矢量化，然后矢量搜索引擎会找到与查询矢量最近的相邻矢量。测量查询向量与数据库中所有向量之间的距离或相似性的粗暴方法可以适用于小型数据集，但随着向量数量的增加，这种方法很快就会失效。换句话说，我们如何才能索引数百万、数十亿甚至数万亿的向量，并在合理的时间内找到查询向量的近邻？这就需要我们发挥聪明才智，找出索引矢量的最佳方法，以便在不降低精度的情况下，尽可能快地找到最近的邻近矢量。

矢量搜索算法和技术

多年来，许多不同的研究团队投入了大量精力，开发出了非常聪明的向量搜索算法。在此，我们将简要介绍主要的几种。根据不同的使用情况，有的比有的更适合。

线性搜索

在前面提到将查询向量与数据库中的所有向量进行比较的粗暴方法时，我们简要地提到了线性搜索或平面索引。虽然它在小型数据集上运行良好，但随着向量和维数的增加，性能会迅速下降（复杂度为 O(n)）。

幸运的是，有一种更有效的方法被称为近似近邻（ANN），在这种方法中，嵌入向量之间的距离是预先计算出来的，相似向量的存储和组织方式可以使它们靠近在一起，例如使用聚类、树、哈希或图。这些方法被称为 "近似 "方法，因为它们通常不能保证 100% 的准确性。最终目标是尽可能快地缩小搜索范围，以便只关注最有可能包含相似向量的区域，或者降低向量的维度。

K 维树

K 维树（或 KD 树）是二进制搜索树的一种概括，它在 k 维空间中存储点，并通过将搜索空间连续分成较小的左树和右树来索引向量。搜索时，算法只需访问查询向量（图 11 中的红点）周围的几个树枝，就能找到最近的邻居（图 11 中的绿点）。如果请求的邻居超过 k 个，黄色区域就会扩大，直到算法找到更多邻居。

KD 树算法的最大优势在于，它可以让我们迅速只关注一些局部树枝，从而将大部分向量排除在外。不过，这种算法的效率会随着维数的增加而降低，因为需要访问的分支要比低维空间多得多。

反转文件索引

倒置文件索引（IVF）方法也是一种空间分区算法，它将彼此接近的向量分配到它们的共享中心点上。在二维空间中，使用 Voronoi 图最直观，如图 12 所示：

我们可以看到，上述二维空间被划分为 20 个聚类，每个聚类的中心点用黑点表示。空间中的所有嵌入向量都被分配到其中心点最接近的聚类中。在搜索时，算法首先通过找到与查询向量最接近的中心点来确定要关注的集群，然后就可以简单地将该区域归零，必要时还可以将周围的区域归零，以便找到最近的邻居。

这种算法在高维空间中使用时，也存在与 KD 树相同的问题。这就是所谓的 "维度诅咒"（curse of dimensionality），当空间体积大幅增加，以至于所有数据都显得稀疏，而要获得更精确的结果所需的数据量却呈指数级增长时，就会出现这种情况。当数据稀疏时，这些空间划分算法就很难将数据组织成群。幸运的是，还有其他算法和技术可以缓解这一问题，详情如下。

量化

量化是一种基于压缩的方法，通过降低嵌入向量的精度，我们可以减小数据库的总大小。这可以通过将浮点矢量值转换为整数值的标量量化 (SQ)来实现。这不仅将数据库的大小减少了 8 倍，还降低了内存消耗，并加快了搜索时向量间距离的计算速度。

另一种技术称为乘积量化（PQ），它首先将空间划分为低维子空间，然后使用聚类算法（类似于 k-means）在每个子空间中对相近的向量进行分组。

请注意，量化不同于降维，后者是减少维数，即简单地缩短向量。

分层导航小世界（HNSW）

如果光看名字就觉得很复杂，别担心，其实并不复杂！简而言之，"分层可导航小世界 "是一种基于多层图的算法，非常流行且高效。包括 Apache Lucene 在内的许多不同的矢量数据库都在使用它。下文图 13 显示了国家污水处理厂的概念图。

在顶层，我们可以看到一个由极少数向量组成的图，这些向量之间的链接最长，也就是说，这是一个相似性最小的连接向量图。我们越深入下层，发现的向量就越多，图形就越密集，越来越多的向量相互靠近。在最底层，我们可以找到所有矢量，其中最相似的矢量彼此距离最近。

搜索时，算法从顶层的任意入口点开始，找到最接近查询向量的向量（如灰色点所示）。然后，它再向下移动一层，从它留在上一层的同一个向量开始，重复同样的过程，如此逐层进行，直到到达最底层，并找到与查询向量最近的邻居。

位置敏感散列（LSH）

与迄今为止介绍的所有其他方法一样，对位置敏感的哈希算法试图大幅缩小搜索空间，以提高检索速度。通过这种技术，嵌入向量被转化为哈希值，同时保留了相似性信息，因此搜索空间最终变成了一个可以查询的简单哈希表，而不是一个需要遍历的图或树。基于哈希值的方法的主要优势在于，包含任意（大量）维度的向量可以映射为固定大小的哈希值，这大大加快了检索时间，同时又不会牺牲太多精度。

一般来说，散列数据，特别是嵌入向量，有许多不同的方法，但本文不会深入探讨每种方法的细节。传统的散列方法通常会对看似非常相似的数据产生截然不同的散列值。由于嵌入向量是由浮点数值组成的，因此我们取两个在向量运算中被认为非常接近的浮点数值样本（例如 0.73 和 0.74），然后通过几个常见的散列函数对它们进行运算。从下面的结果来看，普通的散列函数显然无法保留输入之间的相似性。

散列功能

0.73

0.74

MD5

1342129d04cd2924dd06cead4cf0a3ca

0aec1b15371bd979cfa66b0a50ebecc5

SHA1

49d2c3e0e44bff838e1db571a121be5ea874e8d9

a534e76482ade9d9fe4bff3035a7f31f2f363d77

SHA256

99d03fc3771fe6848d675339fc49eeb1cb8d99a12e6358173336b99a2ec530ea

5ecbc825ba5c16856edfdaf0abc5c6c41d0d8a9c508e34188239521dc7645663

传统的散列方法试图尽量减少相似数据之间的散列碰撞，而位置敏感散列的主要目标恰恰相反，即尽量增加散列碰撞，从而使相似数据以很高的概率落在同一个桶中。通过这种方法，多维空间中相距较近的嵌入向量将被哈希到属于同一个桶的固定大小的值。由于 LSH 允许这些散列向量保持其邻近性，因此这种技术在数据聚类和近邻搜索中非常有用。

所有繁重的工作都是在编制索引时进行的，此时需要计算哈希值，而在搜索时，我们只需要对查询向量进行哈希处理，以便查找包含最接近嵌入向量的桶。找到候选桶后，通常会进行第二轮，以确定与查询向量最近的相邻向量。

结束语

为了介绍矢量搜索，我们必须在这篇文章中介绍一些内容。在比较了词法搜索和向量搜索的区别之后，我们了解了深度学习神经网络模型是如何捕捉非结构化数据的语义，并将其意义转码为高维嵌入向量的。值得注意的是，向量搜索和词法搜索并不是相互竞争的信息检索技术，而是相辅相成的（我们将在本系列的第三部分深入探讨混合搜索）。

之后，我们介绍了向量搜索的基本构件，即距离（和相似性）函数，它允许我们测量两个向量的接近程度，并评估它们所代表概念的相似性。

最后，我们回顾了各种最流行的向量搜索算法和技术，它们可以基于树、图、簇或哈希值，其目标是快速缩小多维空间中特定区域的范围，以便找到最近的邻居，而无需像线性暴力搜索那样访问整个空间。

如果您喜欢现在阅读的内容，请务必查看本系列的其他部分：

• 第 2 部分：如何在 Elasticsearch 中设置矢量搜索

• 第 3 部分：使用 Elasticsearch 进行混合搜索

开箱即用的Semantic Kernel Elasticsearch向量存储连接器（Vector Store Connector）支持Semantic Kernel向量存储抽象，这使得开发人员在构建人工智能代理时能够非常容易地将Elasticsearch作为向量存储插件。

Elasticsearch 在开源社区拥有坚实的基础，最近采用了AGPL 许可证。这些工具与开源的微软语义内核（Microsoft Semantic Kernel）相结合，可提供强大的企业级解决方案。您可以通过运行此命令curl -fsSL https://elastic.co/start-local | sh ，在几分钟内启动 Elasticsearch（详情请参考start-local），然后在生产人工智能代理的同时，迁移到云托管或自托管版本。

在本篇博客中，我们将探讨在使用Semantic Kernel（语义内核）时，如何使用Semantic Kernel Elasticsearch向量存储连接器。该连接器的 Python 版本将在未来推出。

高级应用场景：利用 Semantic Kernel& Elasticsearch 构建 RAG 应用程序

下面我们将举例说明。在高层次上，我们正在构建一个 RAG（检索增强生成）应用程序，它将用户的问题作为输入，并返回一个答案。我们将使用 Azure OpenAI （ 也可使用 本地 LLM ）作为 LLM，Elasticsearch 作为向量存储，Semantic Kernel (.net) 作为将所有组件连接在一起的框架。

如果您不熟悉 RAG 架构，可以通过以下文章快速了解： https://www.elastic.co/search-labs/blog/retrieval-augmented-generation-rag。

答案由 LLM 生成，LLM 从 Elasticsearch 向量存储中获取与问题相关的上下文。答复还包括法律硕士用作背景的资料来源。

RAG 示例

在这个具体例子中，我们创建了一个应用程序，允许用户就内部酒店数据库中存储的酒店提出问题。例如，用户可以根据不同标准搜索特定酒店，或要求提供酒店列表。

在示例数据库中，我们生成了一个包含 100 个条目的酒店列表。为了让您尽可能轻松地试用连接器演示，我们特意设置了较小的样本量。在实际应用中，Elasticsearch 连接器将显示出其优于其他选项（如 "InMemory "向量存储实现）的优势，尤其是在处理超大数据量时。

完整的演示应用程序可在 Elasticsearch 向量存储连接器存储库中找到。

让我们先将所需的 NuGet 软件包和指令添加到项目中：

现在，我们可以创建我们的数据模型，并为其提供语义内核（Semantic Kernel）的特定属性，以定义存储模型模式和文本搜索的一些提示：

存储模型模式属性（`VectorStore*`）与 Elasticsearch 向量存储连接器的实际使用最为相关，即

• VectorStoreRecordKey 来标记记录类上的一个属性，作为记录存储在向量存储中的键。

• VectorStoreRecordData 将记录类的一个属性标记为 "数据"。

• VectorStoreRecordVector 将记录类的一个属性标记为矢量。

所有这些属性都接受各种可选参数，可用于进一步定制存储模型。以VectorStoreRecordKey 为例，可以指定不同的距离函数或不同的索引类型。

文本搜索属性 (TextSearch*) 在本示例的最后一步中非常重要。我们稍后再谈。

下一步，我们将初始化语义内核引擎，并获取核心服务的引用。在实际应用中，应使用依赖注入而不是直接访问服务集合。同样的道理也适用于硬编码的配置和秘密，它们应该使用配置提供程序来读取：

现在可以使用vectorStoreCollection 服务创建数据集，并摄取一些演示记录：

由此可见，语义内核（Semantic Kernel）是如何将向量存储的使用及其复杂性简化为几个简单的方法调用的。

在 Elasticsearch 中创建一个新索引，并创建所有必要的属性映射。然后，我们的数据集会完全透明地映射到存储模型中，并最终存储到索引中。下面是映射在 Elasticsearch 中的显示方式。

embeddings.GenerateEmbeddingsAsync() 会透明地调用已配置的 Azure AI 嵌入生成服务。

在这个演示的最后一个步骤中，我们还可以看到更多的神奇之处。

当用户就数据提问时，只需调用InvokePromptAsync ，就能执行以下所有操作：

1.为用户的问题生成嵌入代码

2.在矢量存储器中搜索相关条目

3.将查询结果插入提示模板

4.最终提示形式的实际查询将发送到人工智能聊天完成服务

还记得我们之前在数据模型上定义的TextSearch* 属性吗？有了这些属性，我们就能在提示模板中使用相应的占位符，这些占位符会根据向量存储中的条目信息自动填充。

对于我们的问题"，请告诉我所有拥有屋顶酒吧的酒店。" ，最终答复如下：

正确答案是指 hotels.csv 中的以下条目

这个例子很好地说明了微软语义内核的使用是如何通过其深思熟虑的抽象功能大大降低复杂性，并实现高度灵活性的。例如，只需修改一行代码，就可以更换向量存储或所使用的人工智能服务，而无需重构代码的任何其他部分。

同时，该框架还提供了大量高级功能，如 "InvokePrompt "函数或模板或搜索插件系统。

完整的演示应用程序可在 Elasticsearch 向量存储连接器存储库中找到。

Elasticsearch 还能做什么

• Elasticsearch 新语义文本映射：简化语义搜索

• 利用检索器在 Elasticsearch 中进行语义重排

• 高级 RAG 技术第 1 部分：数据处理

• 高级 RAG 技术第 2 部分：查询和测试

• 使用 Llama 3 开放源代码和 Elastic 构建 RAG

• 使用 LangGraph、LLaMA3 和 Elasticsearch 向量存储从零开始构建本地代理的教程

Elasticsearch& Semantic Kernel（语义内核）：下一步是什么？

• 我们展示了在.NET中构建GenAI应用时，如何将Elasticsearch向量存储轻松插入Semantic Kernel。敬请期待下一步的 Python 集成。

• 由于Semantic Kernel（语义内核）为混合搜索等高级搜索功能建立了抽象，Elasticsearch连接将使.NET开发人员能够在使用Semantic Kernel（语义内核）的同时轻松实现这些功能。

除了集成混合搜索，我们还将演示如何添加功能，使您的搜索解决方案更加强大。其中包括切面和个性化产品促销。此外，我们还将向您展示如何使用 Elastic 的行为分析工具捕捉用户互动并生成有价值的见解。

在本实现中，您将看到如何构建允许用户查看搜索结果并与之交互的界面，以及负责返回信息的应用程序接口。要访问包含源代码的资源库，请点击下面的链接：

• https://github.com/elastic/elasticsearch-labs/tree/main/supporting-blog-content/hybrid-search-for-an-e-commerce-product-catalogue/product-store-search

• https://github.com/elastic/elasticsearch-labs/tree/main/supporting-blog-content/hybrid-search-for-an-e-commerce-product-catalogue/app-product-store

我们将本指南分为几个步骤，从创建索引到实施分面和结果个性化等高级功能。最后，您将拥有一个强大的搜索解决方案，可以在电子商务场景中使用。

电子商务混合搜索的环境设置

在开始实施之前，我们需要设置环境。您可以选择使用 Elastic Cloud 上的服务或容器化解决方案来管理 Elasticsearch。如果选择容器化，可在此版本库中找到通过 Docker Compose 进行的配置：docker-compose.yml。

创建索引和录入产品目录

索引将根据化妆品目录创建，其中包括名称、描述、照片、类别和标签等字段。用于全文搜索的字段，如"名称" 和"描述，" 将被映射为text ，而用于聚合的字段，如"类别" 和"品牌，" 将被映射为keyword ，以便进行分面搜索。

"description" 字段将用于矢量搜索，因为它提供了有关产品的更多背景信息。这个字段将被定义为dense_vector, ，存储描述的矢量表示。

索引映射如下

创建索引的脚本可在此处找到。

嵌入式生成

为了将产品描述矢量化，我们使用了 all-MiniLM-L6-v2 模型。在这种情况下，应用程序负责在编制索引前生成嵌入。另一种方法是将模型导入 Elasticsearch 集群，但在本地环境中，我们选择直接在应用程序中执行矢量化。

我们使用Kaggle上的化妆品数据集来填充索引，为了提高数据摄取的效率，我们使用了批处理方法。在同一摄取阶段，我们将生成"description" 字段的嵌入，并将其索引到新字段"description_embeddings" 中。

整个数据摄取过程可通过存储库中的Jupyter Notebook直接跟踪和执行。该笔记本提供了关于如何读取、处理数据并将其编入 Elasticsearch 索引的分步指南，便于复制和实验。

您可以通过以下链接访问该笔记本：摄入笔记本。

混合搜索实施

现在，让我们来实现混合搜索。对于基于关键字的搜索，我们使用multi_match查询，目标字段为"name、" " category、" 和"description。"这样就能确保检索到这些字段中包含搜索词的文档。

对于向量搜索，我们使用KNN 查询。在执行查询之前，需要对搜索词进行矢量化，这需要使用对输入词进行矢量化的方法来完成。请注意，摄取时使用的同一模型也用于搜索词。

这两种搜索的组合是通过互易等级融合（RRF） 算法完成的，该算法可合并两种查询的结果，并通过减少噪音来提高搜索精度。RRF 允许基于关键字的搜索和矢量搜索共同发挥作用，从而增强对用户查询的理解。

结果比较：关键词搜索与混合搜索

现在，让我们比较一下传统关键词搜索和混合搜索的结果。当使用关键字搜索"干性皮肤粉底" 时，我们会得到以下结果：

1. Revlon ColorStay Makeup for Normal / Dry SkinDescription：露华浓持久彩妆（Revlon ColorStay Makeup）质地轻盈，遮瑕持久，不会结块、褪色或脱妆。这款无油、保湿平衡配方采用了 "定时释放技术"，特别适合中性或干性肌肤使用，能够持续为肌肤补充水分：妆感舒适，可持续使用长达 24 小时；中等至完全遮盖；有多种美丽色调可供选择。

2. 美宝莲梦幻柔滑慕斯粉底液描述：你会爱上它的原因独特的乳霜状粉底提供 100% 婴儿般柔滑的完美肤质。不含油、不含香料，通过皮肤科医生测试，通过过敏测试，不致粉刺，不会堵塞毛孔。适合敏感性皮肤

分析：在搜索"干性皮肤粉底时，" 搜索结果是通过搜索关键词与产品标题和描述之间的精确匹配获得的。然而，这种匹配并不总是最佳选择。例如，Revlon ColorStay Makeup for Normal / Dry Skin就是一个不错的选择，因为它是专为干性皮肤配制的。尽管它不含油分，但其配方设计却能提供持续的保湿效果。相比之下，我们还收到了美宝莲梦幻柔滑慕斯粉底液，虽然这款粉底液不含油分，也能补充水分，但一般更推荐油性或混合性皮肤使用，因为无油产品往往侧重于控油，而不是提供干性皮肤所需的额外水分。这凸显了基于关键词搜索的局限性，因为这种搜索可能会返回无法完全满足干性皮肤患者特殊需求的产品。

现在，使用混合方法进行相同的搜索：

1. CoverGirl Outlast Stay Luminous Foundation Creamy Natural (820):产品简介：CoverGirl Outlast Stay Luminous 粉底液是打造露光妆效和微妙光泽的完美之选。它不含油分，配方不油腻，能为肌肤带来全天候的自然亮泽！这款全天候粉底液可为肌肤补充水分，同时提供无瑕遮瑕。分析： 这款产品非常适合干性皮肤的用户，因为它强调补水。"Hydrates skin" 和"dewy finish" 这两个词符合用户寻找干性皮肤粉底的意图。矢量搜索很可能理解了补水的概念，并将其与解决皮肤干燥问题的粉底需求联系起来。

2. Revlon ColorStay Makeup for Normal / Dry Skin:说明：Revlon ColorStay Makeup 采用轻盈配方，具有持久遮瑕效果，不会结块、褪色或脱落。这款不含油分的保湿平衡配方采用了 "定时释放技术"，特别适合中性或干性肌肤使用，能持续为肌肤补充水分。分析： 这款产品直接针对干性皮肤用户的需求，明确指出其配方适用于中性或干性皮肤。"水分平衡配方" 和持续的保湿效果非常适合寻找适合干性皮肤的粉底的人。矢量搜索成功检索到这一结果，不仅是因为关键词匹配，还因为重点关注补水，并特别提到干性皮肤是目标人群。

3. 精华粉底液说明： 精华粉底液质地轻盈，遮瑕度适中，共有 21 种色调可供选择。这些粉底液的遮瑕度适中，看起来很自然，精华液质地非常轻盈。它们的粘度很低，可使用随附的泵或单独购买的玻璃滴管进行分配。分析：在这款产品中，说明强调的是一款质地轻盈、妆感自然的精华粉底液，这与干性皮肤人群的需求不谋而合，因为干性皮肤人群通常需要的是温和、保湿、妆感不结块的产品。尽管"干性皮肤" 这个词没有被明确提及，但矢量搜索可能从更广泛的背景中捕捉到了轻盈、自然的遮盖力和类似精华液的质地，这与保湿度和涂抹舒适度有关，使其与干性皮肤相关。

面的实施

面孔对于有效提炼和过滤搜索结果至关重要，可为用户提供更有针对性的导航，尤其是在电子商务等产品种类繁多的情况下。它们允许用户根据类别、品牌或价格等属性调整搜索结果，使搜索更加准确。为了实现这一功能，我们在 category和 字段上使用了 术语聚合brand ，这两个 字段keyword 在索引创建阶段被定义为 。

实施的完整代码可在此处找到。

下面是搜索"适用于干性皮肤的粉底" 的面结果：

自定义结果：固定查询

在某些情况下，在搜索结果中推广某些产品可能是有益的。为此，我们使用了 "固定查询"，它允许特定产品出现在搜索结果的顶部。下面，我们将在不推销任何产品的情况下搜索"Foundation" ：

在我们的例子中，我们可以推广带有"无麸质标签的产品。"通过使用产品 ID，我们可以确保产品在搜索结果中的优先级。具体而言，我们将推广以下产品：精华粉底液（编号：1043）、遮瑕粉底液（编号：1042）和Realist 隐形定妆粉（编号：1039）。

我们使用特定的产品 ID 来确保它们在查询结果中的优先级。查询结构包括一个产品 ID 列表，该列表应将"钉在" 的顶部（在本例中，ID 为 1043、1042 和 1039），而其余结果则按照搜索的有机流程，使用"name" 、"category" 和"description" 等字段中的文本查询条件组合。这样，就有可能以可控的方式推广项目，确保其可见性，同时保持搜索的其他部分基于通常的相关性。

下面是查询执行的结果和促销产品：

完整的查询代码可在此处找到。

利用行为分析技术分析搜索行为

到目前为止，我们已经增加了一些功能，以提高搜索结果的相关性和产品的可发现性。现在，我们将通过加入一项功能来最终确定搜索解决方案，该功能将帮助我们分析用户的搜索行为，识别有结果或无结果的查询以及搜索结果的点击等模式。为此，我们将使用 Elastic 提供的行为分析功能。有了它，只需几个步骤，我们就能监控和分析用户的搜索行为，获得宝贵的见解，从而优化搜索体验。

创建行为分析集合

我们的第一项操作是创建一个集合，负责接收所有行为分析事件。要创建集合，请访问Search> Behavioral Analytics 中的 Kibana 界面。在下面的示例中，我们创建了名为tracking-search 的集合。

将行为分析整合到界面中

我们的前端应用程序是用 JavaScript 开发的，为了集成行为分析，我们将按照 Elastic 官方文档中描述的步骤安装行为分析 JavaScript 跟踪器。

实施 JavaScript 跟踪器

现在，我们将把跟踪器客户端导入应用程序，并使用trackPageView 、trackSearch 和trackSearchClick 方法来捕捉用户交互。

免责声明：虽然我们正在使用一种工具来收集用户交互数据，但这对于确保遵守GDPR 至关重要。这意味着要明确告知用户正在收集哪些数据、将如何使用这些数据，并提供选择退出跟踪的选项。此外，我们必须采取强有力的安全措施来保护收集到的信息，并尊重用户的权利，如数据访问和删除，确保所有步骤都符合 GDPR 原则。

步骤 1：创建跟踪器实例

首先，我们将创建用于监控交互的跟踪器实例。在此配置中，我们定义了目标端点、集合名称和 API 密钥：

步骤 2：获取页面浏览量

要跟踪页面浏览量，我们可以配置trackPageView 事件：

有关trackPageView 事件的详细信息，请参阅本文档。

步骤 3：捕捉搜索查询

为了监控用户的搜索行为，我们将使用trackSearch 方法：

在这里，我们收集搜索词和搜索结果。

步骤 4：跟踪搜索结果的点击率

最后，为了捕捉搜索结果的点击，我们将使用trackSearchClick 方法：

我们收集被点击文档的 ID 信息以及搜索词和搜索结果。

在 Kibana 中分析数据

既然已经捕捉到了用户交互事件，我们就可以获得有关搜索操作的宝贵数据。Kibana 使用行为分析工具来可视化和分析这些行为数据。要查看结果，只需导航到搜索> 行为分析> 我的收藏，就会显示捕获事件的概览。

在此概览中，我们可以大致了解集成到界面中的每个操作所捕获的事件。从这些信息中，我们可以获得有关用户搜索行为的宝贵见解。不过，如果您想创建个性化的仪表盘，其中包含与您的特定场景更相关的指标，Kibana 提供了用于构建仪表盘的强大工具，允许您创建各种指标可视化。

下面，我创建了一些可视化和图表来监测，例如，一段时间内搜索次数最多的词语、没有结果的查询、突出显示搜索次数最多的词语的词云，以及最后的地理可视化，以确定搜索访问来自哪里。

结论

在本文中，我们实施了一种混合搜索解决方案，将关键词和矢量搜索相结合，为用户提供更准确、更相关的搜索结果。我们还探索了如何使用其他功能，如面和钉住查询的个性化结果，以创建更完整、更高效的搜索体验。

此外，我们还集成了 Elastic 的行为分析功能，以捕捉和分析用户与搜索引擎交互过程中的行为。通过使用trackPageView 、trackSearch 和trackSearchClick 等方法，我们能够监控搜索查询、搜索结果点击量和页面浏览量，从而对搜索行为产生有价值的见解。

参考资料

数据集

https://www.kaggle.com/datasets/shivd24coder/cosmetic-brand-products-dataset

变压器

https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2

互惠等级融合

https://www.elastic.co/guide/en/elasticsearch/reference/current/rrf.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/retriever.html#rrf-retriever

Knn 查询

https://www.elastic.co/guide/en/elasticsearch/reference/current/knn-search.html

固定查询

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-pinned-query.html

行为分析应用程序接口

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

https://www.elastic.co/guide/en/elasticsearch/reference/current/behavioral-analytics-overview.html

注意如果您熟悉旧版本的 Elasticsearch C# 客户端NEST，请阅读这篇关于 NEST 客户端弃用和新功能的博文。NEST 是上一代的 .NET 客户端，后来被 Elastic.Clients.Elasticsearch package

• 什么是 Blazor？

• 什么是 ESRE？

• 配置 ELSER

• 索引数据

• 建筑应用

什么是 Blazor？

Blazor是微软开发的基于 HTML、CSS 和 C# 的开放源代码网络框架，允许开发人员构建可在客户端或服务器上运行的网络应用程序。Blazor 还允许您制作可重复使用的组件，以更快地构建应用程序；它使开发人员能够在同一个文件中构建 HTML 视图和 C# 操作，这有助于保持代码的可读性和简洁性。此外，有了Blazor Hybrid，您还可以通过.NET代码构建本地移动应用程序，访问本地平台功能。

Blazor 的部分功能使其成为一个非常适合工作的框架：

• 服务器端和客户端渲染选项

• 可重复使用的用户界面组件

• 利用 SignalR 实时更新

• 内置状态管理

• 内置路由系统

• 强大的类型和编译时检查

为什么选择 Blazor？

与其他框架和库相比，Blazor 具有以下优势：它允许开发人员在客户端和服务器代码中使用 C#，提供强大的类型和编译时检查功能，从而提高了可靠性。它与 .NET 生态系统无缝集成，实现了 .NET 库和工具的重用，并提供强大的调试支持。

什么是 ESRE？

Elasticsearch Relevance Engine™ (ESRE)是一套在强大的 Elasticsearch 搜索引擎基础上使用机器学习和人工智能构建搜索应用程序的工具。

要了解有关 ESRE 的更多信息，请点击此处阅读我们的博文。

配置 ELSER

为了充分利用 Elastic 的ESRE功能，我们将使用ELSER作为模型提供者。

请注意，要使用 Elasticsearch 的 ELSER 模型，您必须拥有白金级或企业级许可证，并至少拥有一个 4GB 大小的专用机器学习 (ML) 节点。 点击此处 了解更多信息 。

首先创建推理端点：

如果您是第一次使用 ELSER，在后台加载模型时可能会遇到 502 Bad Gateway 错误。您可以在 Kibana 的Machine Learning > Trained Models 中查看模型的状态。部署完成后，就可以进行下一步。

索引数据

您可以在这里下载数据集，然后使用 Kibana 导入数据。为此，请访问主页并点击"Upload data" 。然后，上传文件并点击Import 。最后，进入Advanced 标签，粘贴以下映射：

我们将创建一个能够运行语义和全文查询的索引。语义文本字段类型将负责数据分块和嵌入。请注意，我们是将 索引longDescription 为semantic_text ， 如果要将一个字段 索引 为semantic_text 和 text` ， 可以使用 copy_to 。

使用 Blazor& Elasticsearch 构建应用程序

API 密钥

我们需要做的第一件事是创建一个 API 密钥，以验证对 Elasticsearch 的请求。API 密钥应为只读，只允许查询books-blazor 索引。

你会看到类似这样的内容：

保存encoded 响应字段的值，以备不时之需。如果您在Elastic Cloud 上运行，还需要您的 Cloud ID。(您可以在此处找到）。

创建 Blazor 项目

首先安装 Blazor，并按照官方说明创建一个示例项目。

创建项目后，文件夹结构和文件应如下所示：

模板应用程序包括Bootstrap v5.1.0用于造型。

安装Elasticsearch .NET客户端，完成项目设置：

完成这一步后，您的页面应该是这样的：

文件夹结构

现在，我们将按如下方式整理文件夹：

文件解释：

• Components/Pages/Search.razor：包含搜索栏、搜索结果和过滤器的主页面。

• Components/Pages/Search.razor.css：页面样式。

• Components/Elasticsearch/SearchBar.razor：搜索栏组件。

• Components/Elasticsearch/Results.razor：结果组件。

• Components/Elasticsearch/Facet.razor: 过滤器组件。

• Components/Svg/GlassIcon.razor: 搜索图标。

• Components/_Imports.razor：这将导入所有组件。

• Models/Book.cs：这将存储图书字段模式。

• Models/Response.cs：这将存储响应模式，包括搜索结果、面和总点击数。

• Services/ElasticsearchService.cs：Elasticsearch 服务。它将处理与 Elasticsearch 的连接和查询。

初始配置

我们先来清理一下。

删除文件：

• Components/Pages/Counter.razor

• Components/Pages/Weather.razor

• Components/Pages/Home.razor

• Components/Layout/NavMenu.razor

• Components/Layout/NavMenu.razor.css

检查/Components/_Imports.razor 文件。您应该有以下进口：

将 Elastic 集成到项目中

现在，让我们导入 Elasticsearch 组件：

我们将从/Components/Layout/MainLayout.razor 文件中删除默认侧边栏，以便为应用程序提供更多空间：

现在让我们输入用户机密的 Elasticsearch 凭据：

使用这种方法，.Net 8 可将敏感数据存储在项目文件夹之外的单独位置，并可通过IConfiguration 界面进行访问。任何使用相同用户秘密的 .Net 项目都可以使用这些变量。

然后，让我们修改Program.cs 文件以读取机密并挂载 Elasticsearch 客户端：

首先，导入必要的库：

• BlazorApp.Services：包含 Elasticsearch 服务。

• Elastic.Clients.Elasticsearch：导入 Elasticsearch 客户端 .Net 8 库。

• Elastic.Transport：导入 Elasticsearch 传输库，它允许我们使用 ApiKey 类来验证请求。

其次，在var app = builder.Build() 行之前插入以下代码：

这段代码将从用户机密中读取 Elasticsearch 凭据，并创建一个 Elasticsearch 客户端实例。

在初始化 ElasticSearch 客户端后，添加以下一行以注册 Elasticsearch 服务：

下一步将在/Services/ElasticsearchService.cs 文件中建立搜索逻辑：

首先，导入必要的库和模型：

其次，添加类ElasticsearchService 、构造函数和变量：

配置搜索

现在，让我们构建搜索逻辑：

• BuildFilters 将使用用户选择的面为搜索查询建立过滤器。

• BuildHybridQuery 将建立一个结合全文和语义搜索的混合搜索查询。

接下来，添加搜索方法：

• SearchBooksAsync该功能将使用混合查询执行搜索，并返回结果，其中包括用于构建切面的聚合。

• FormatFacets：将聚合响应格式化为字典。

• ConvertFacetDictionary：将面字典转换为更易读的格式。

下一步是创建模型，这些模型将代表 Elasticsearch 查询hits 中返回的数据，这些数据将作为结果打印在搜索页面中。

我们首先创建文件/Models/Book.cs 并添加以下内容：

然后，在/Models/Response.cs 文件中设置弹性响应，并添加以下内容：

配置基本用户界面

接下来，添加 SearchBar 组件。在文件/Components/Elasticsearch/SearchBar.razor 中添加以下内容：

该组件包含一个搜索栏和一个执行搜索的按钮。

Blazor 允许在同一文件中使用 C# 代码动态生成 HTML，具有极大的灵活性。

之后，我们将在/Components/Elasticsearch/Results.razor 文件中构建显示搜索结果的结果组件：

最后，我们需要创建面来过滤搜索结果。

注：筛选器允许用户根据特定属性或类别（如产品类型、价格范围或品牌）缩小搜索结果的范围。这些筛选器通常以复选框的形式显示为可点击的选项，帮助用户缩小搜索范围，更轻松地找到相关结果。在 Elasticsearch 的上下文中，面是通过 聚合创建的。

我们在文件/Components/Elasticsearch/Facet.razor 中输入以下代码来设置切面：

该组件从terms 中读取author 、categories 和status 字段的聚合，然后生成一个过滤器列表，发送回 Elasticsearch。

现在，让我们把所有东西放在一起。

在/Components/Pages/Search.razor 文件中：

我们的页面正在运行！

如您所见，该页面功能齐全，但缺乏风格。让我们添加一些 CSS，使其看起来更有条理，反应更灵敏。

让我们开始更换布局样式。在Components/Layout/MainLayout.razor.css 文件中：

在Components/Pages/Search.razor.css 文件中添加搜索页面的样式：

我们的页面开始变得更好看了：

让我们来做最后的润色：

创建以下文件

• Components/Elasticsearch/Facet.razor.css

• Components/Elasticsearch/Results.razor.css

并为Facet.razor.css 添加样式：

供Results.razor.css ：

最终结果

要运行应用程序，可以使用以下命令：

dotnet watch

你做到了现在，您可以使用搜索栏在 Elasticsearch 索引中搜索图书，并按作者、类别和状态过滤结果。

进行全文和语义搜索

默认情况下，我们的应用程序将使用 全文 和 语义搜索 执行 混合 搜索 。您可以通过创建两个独立的方法来改变搜索逻辑，一个用于全文搜索，另一个用于语义搜索，然后根据用户的输入选择一种方法来创建查询。

在/Services/ElasticsearchService.cs 文件中的ElasticsearchService 类中添加以下方法：

这两种方法的工作原理与BuildHybridQuery 方法类似，但它们只进行全文或语义搜索。

您可以修改SearchBooksAsync 方法，使用选定的搜索方法：

您可在此处找到完整的申请表

结论

Blazor 是一个有效的框架，可让您使用 C# 构建网络应用程序。Elasticsearch 是一个功能强大的搜索引擎，可让您构建搜索应用程序。将两者结合起来，您就可以轻松构建强大的搜索应用程序，利用 ESRE 的强大功能在短时间内创建语义搜索体验。

• 与法律硕士进行讨论，实施ChatLanguageModel 和 ChatMemory

• 在记忆中保留聊天记录，以便回忆起之前与一位法律硕士讨论的背景情况

本博文将介绍如何

• 根据文本示例创建向量嵌入

• 将向量嵌入存储在 Elasticsearch 嵌入存储中

• 搜索类似载体

创建嵌入

要创建嵌入式，我们需要定义一个EmbeddingModel 。例如，我们可以使用上一篇文章中使用过的相同的 mistral 模型。它和奥拉马一起跑：

模型能够从文本中生成向量。在这里，我们可以检查模型生成的维数：

要从文本中生成向量，我们可以使用

或者，如果我们还想提供元数据，以便对文本、价格、发布日期等内容进行筛选，我们可以使用Metadata.from().NET。例如，我们在这里添加游戏名称作为元数据字段：

如果您想运行这段代码，请查看Step5EmbedddingsTest.java类。

添加 Elasticsearch 来存储向量

LangChain4j 提供内存嵌入存储。这对运行简单测试非常有用：

但是，这显然不能用于更大的数据集，因为该数据存储将所有内容都存储在内存中，而我们的服务器上没有无限的内存。因此，我们可以将嵌入式数据存储到 Elasticsearch 中，根据定义，Elasticsearch 是"elastic" ，可以随着数据的扩展而扩展。为此，让我们在项目中添加 Elasticsearch：

正如你所注意到的，我们还在项目中添加了 Elasticsearch TestContainers 模块，这样我们就可以从测试中启动 Elasticsearch 实例：

要将 Elasticsearch 用作嵌入式存储，"，" ，就必须从 LangChain4j 内存数据存储切换到 Elasticsearch 数据存储：

这将在 Elasticsearch 中以default 索引的形式存储向量。您还可以将索引名称改为更有意义的名称：

如果您想运行此代码，请查看Step6ElasticsearchEmbedddingsTest.java类。

搜索类似载体

要搜索相似向量，我们首先需要使用之前使用过的相同模型，将问题转换为向量表示。我们已经做到了，所以再做一次并不难。请注意，在这种情况下我们不需要元数据：

我们可以用问题的这种表示法建立一个搜索请求，并要求嵌入式存储空间找出最前面的向量：

现在，我们可以遍历结果并打印一些信息，如来自元数据的游戏名称和得分：

正如我们所预料的那样，"Out Run" 作为第一击：

如果您想运行这段代码，请查看Step7SearchForVectorsTest.java类。

幕后花絮

Elasticsearch 嵌入存储的默认配置是在后台使用近似 kNN 查询。

但这可以通过向嵌入存储区提供默认配置 (ElasticsearchConfigurationKnn) 以外的另一种配置 (ElasticsearchConfigurationScript) 来改变：

ElasticsearchConfigurationScriptscript_score执行程序使用cosineSimilarity 函数 在后台运行 查询 。

基本上，打电话时

现在呼叫

在这种情况下，结果并不会因为"order" 而发生变化，只是分数会有所调整，因为cosineSimilarity 调用并不使用任何近似值，而是计算每个匹配向量的余弦值：

如果您想运行这段代码，请查看Step7SearchForVectorsTest.java类。

结论

我们已经介绍了如何从文本中轻松生成嵌入，以及如何使用两种不同的方法在 Elasticsearch 中存储和搜索近邻：

• 使用ElasticsearchConfigurationKnn 默认选项进行近似和快速knn 查询

• 使用ElasticsearchConfigurationScript 选项进行精确但较慢的script_score 查询

下一步将根据我们在这里学到的知识，构建一个完整的 RAG 应用程序。

欢迎阅读我们关于高级 RAG 技术文章的第二部分！在本系列的第 1 部分中，我们建立、讨论并实施了高级 RAG 管道的数据处理组件：

在这一部分，我们将继续查询和测试我们的实现。让我们直奔主题！

目录

• 搜索和检索，生成答案

  • 用同义词丰富查询

  • HyDE（假设文档嵌入）

  • 混合搜索

• 实验

  • 结果摘要

  • 测试 1：谁审核了 Elastic？

    • AdvancedRAG

    • SimpleRAG

  • 测试 2：2023 年总收入

    • AdvancedRAG

    • SimpleRAG

  • 测试 3：增长主要依赖于什么产品？多少钱？

    • AdvancedRAG

    • SimpleRAG

  • 测试 4：说明员工福利计划

    • AdvancedRAG

    • SimpleRAG

  • 测试 5：Elastic 收购了哪些公司？

    • AdvancedRAG

    • SimpleRAG

• 结论

• 附录

  • 提示

    • RAG 问题解答提示

    • 弹性查询生成器提示

    • 潜在问题生成器提示

    • HyDE 生成器提示

  • 混合搜索查询示例

搜索和检索，生成答案

让我们提出第一个问题，最好是主要在年度报告中找到的一些信息。怎么样？

现在，让我们运用一些技术来增强查询。

用同义词丰富查询

首先，让我们增强查询措辞的多样性，并将其转化为可轻松处理成 Elasticsearch 查询的形式。我们将借助 GPT-4o 将查询转换为 OR 子句列表。让我们来写下这个提示：

当应用到我们的查询时，GPT-4o 会生成基本查询和相关词汇的同义词。

在ESQueryMaker 类中，我定义了一个分割查询的函数：

它的作用是将这串 OR 子句拆分成一个术语列表，使我们能够对关键文档字段进行多重匹配：

最后得出了这个疑问：

这比原始查询涵盖的范围更广，有望降低因忘记同义词而错过搜索结果的风险。但我们可以做得更多。

返回顶部

HyDE（假设文档嵌入）

让我们再次利用 GPT-4o 来实现HyDE。

HyDE 的基本前提是生成一个假设文档--一种可能包含原始查询答案的文档。文件的真实性或准确性并不重要。有鉴于此，让我们写下下面的提示：

由于矢量搜索通常是通过余弦矢量相似性进行操作的，因此 HyDE 的前提是，我们可以通过文档与文档的匹配，而不是查询与文档的匹配，来获得更好的结果。

我们关心的是结构、流程和术语。事实性不强。GPT-4o 可以输出这样的 HyDE 文档：

它看起来非常可信，是我们希望索引的文档类型的理想候选者。我们将把它嵌入并用于混合搜索。

返回顶部

混合搜索

这是我们搜索逻辑的核心。我们的词法搜索组件将是生成的 OR 子句字符串。我们的密集矢量组件将是嵌入式 HyDE 文档（又称搜索矢量）。我们使用 KNN 来有效识别与搜索向量最接近的几个候选文档。我们将词法搜索组件默认称为TF-IDF 和 BM25 评分。最后，将采用Wang 等人推荐的 30/70 比例合并词性和密集向量得分。

最后，我们可以拼凑出一个 RAG 函数。我们的 RAG（从询问到答复）将遵循这一流程：

1. 将查询转换为 OR 子句。

2. 生成 HyDE 文档并嵌入。

3. 将二者作为混合搜索的输入。

4. 检索前 N 个结果，将它们倒转，使最相关的得分是 LLM 上下文内存中"最近的" （反向打包） 反向打包示例：查询："Elasticsearch 查询优化技术" 检索文档（按相关性排序）： LLM 上下文的反向顺序： 通过颠倒顺序，最相关的信息(1)会出现在上下文的最后，从而可能在生成答案时受到 LLM 的更多关注。

   1. "使用 bool 查询可有效组合多个搜索条件。"

   2. "实施缓存策略，缩短查询响应时间。"

   3. "优化索引映射，提高搜索性能。"

   4. "优化索引映射，提高搜索性能。"

   5. "实施缓存策略，缩短查询响应时间。"

   6. "使用 bool 查询可有效组合多个搜索条件。"

5. 将上下文传递给 LLM 生成。

让我们运行查询并得到答案：

不错。没错。

返回顶部

实验

现在有一个重要问题需要回答。我们在这些实施中投入了如此多的精力和额外的复杂性，究竟得到了什么？

让我们来做个小小的比较。我们实施的 RAG 管道与基线混合搜索相比，没有任何增强功能。我们将进行一系列小测试，看看是否会发现任何实质性差异。我们将把刚刚实现的 RAG 称为 AdvancedRAG，把基本管道称为 SimpleRAG。

结果摘要

本表总结了两种 RAG 管道的五次测试结果。我根据答案的细节和质量来判断每种方法的相对优劣，但这完全是主观判断。现将实际答案转载于下表，供您参考。说了这么多，让我们来看看他们的表现如何！

SimpleRAG 无法回答问题 1& 5。AdvancedRAG 对问题 2、3 和 4 的回答也要详细得多。基于更多的细节，我认为 AdvancedRAG 的答案质量更高。

测试

问题

高级 RAG 性能

SimpleRAG 性能

AdvancedRAG 延迟

SimpleRAG 延迟

优胜者

1

谁审核 Elastic？

正确确定普华永道为审计员。

未能确定审计员。

11.6s

4.4s

AdvancedRAG

2

2023 年的总收入是多少？

提供了正确的收入数字。包括往年收入的补充情况。

提供了正确的收入数字。

13.3s

2.8s

AdvancedRAG

3

增长主要依靠什么产品？多少钱？

正确指出弹性云是关键驱动因素。包括总体收入情况& 。

正确指出弹性云是关键驱动因素。

14.1s

12.8s

AdvancedRAG

4

说明员工福利计划

全面介绍了退休计划、医疗计划和其他福利。包括不同年份的具体捐款额。

提供了很好的福利概览，包括薪酬、退休计划、工作环境和 Elastic Cares 计划。

26.6s

11.6s

AdvancedRAG

5

Elastic 收购了哪些公司？

正确列出了报告中提到的近期收购（CmdWatch、Build Security 和 Optimyze）。提供了一些收购日期和收购价格。

未能从提供的上下文中检索到相关信息。

11.9s

2.7s

AdvancedRAG

测试 1：谁审核了 Elastic？

AdvancedRAG

SimpleRAG

摘要：SimpleRAG 没有将普华永道确定为审计机构

好吧，这其实挺让人惊讶的。这看起来像是 SimpleRAG 的搜索失败。没有检索到与审计有关的文件。让我们在下一个测试中降低难度。

测试 2：2023 年总收入

AdvancedRAG

SimpleRAG

摘要：两个 RAG 都得到了正确答案：2023 年总收入为 1,068,989,000 美元

他们都在这里。看来，AdvancedRAG 可能获得了更多的文件？当然，答案会更加详细，并包含往年的信息。考虑到我们所做的改进，这是意料之中的，但现在下结论还为时过早。

让我们提高难度。

测试 3：增长主要依赖于什么产品？多少钱？

AdvancedRAG

SimpleRAG

摘要：两个 RAG 都正确地将弹性云确定为主要增长动力。不过，AdvancedRAG 包含更多细节，将订阅收入和客户增长考虑在内，并明确提及其他 Elastic 产品。

测试 4：说明员工福利计划

AdvancedRAG

SimpleRAG

摘要：AdvancedRAG 更深入、更详细地介绍了美国员工的 401K 计划，以及美国以外地区的缴费计划。报告还提到了 "健康与福利计划"，但没有提到 SimpleRAG 提到的 "Elastic Cares 计划"。

测试 5：Elastic 收购了哪些公司？

AdvancedRAG

SimpleRAG

摘要：SimpleRAG 无法检索到任何有关收购的相关信息，导致回答失败。AdvancedRAG 正确地列出了 CmdWatch、Build Security 和 Optimyze，它们是报告中列出的主要收购项目。

返回顶部

结论

根据我们的测试，我们的先进技术似乎增加了所提供信息的范围和深度，有可能提高 RAG 答案的质量。

此外，可靠性也可能有所提高，因为 AdvancedRAG 可以正确回答Which companies did Elastic acquire? 和Who audits Elastic 等措辞含糊的问题，而 SimpleRAG 则不能。

不过，值得注意的是，在 5 个案例中的 3 个案例中，基本的 RAG 管道（包括混合搜索，但不包括其他技术）设法得出了能够捕捉到大部分关键信息的答案。

我们应该注意到，由于在数据准备和查询阶段加入了 LLM，AdvancedRAG 的延迟一般是 SimpleRAG 的 2-5 倍。这是一笔不小的费用，可能使 AdvancedRAG 只适用于优先考虑应答质量而不是延迟的情况。

在数据准备阶段，使用 Claude Haiku 或 GPT-4o-mini 等更小巧、更便宜的 LLM，就能减轻巨大的延迟成本。将高级模型留待生成答案时使用。

这与 Wang 等人的研究结果一致。结果表明，任何改进都是相对渐进的。简而言之，简单的基线 RAG 就能让您获得大部分体面的最终产品，而且成本更低，速度更快。对我来说，这是一个有趣的结论。对于速度和效率至关重要的使用案例，SimpleRAG 是明智的选择。对于需要榨取每一滴性能的使用案例，AdvancedRAG 中包含的技术可能会提供一条出路。

返回顶部

附录

提示

RAG 问题解答提示

提示 LLM 根据查询和上下文生成答案。

弹性查询生成器提示

提示使用同义词丰富查询内容，并将其转换为 OR 格式。

潜在问题生成器提示

提示生成潜在问题，丰富文件元数据。

HyDE 生成器提示

使用 HyDE 生成假设文档的提示

混合搜索查询示例

最近发表的论文《在检索增强生成中寻找最佳实践》对各种 RAG 增强技术的功效进行了实证评估，目的是为 RAG 找到一套最佳实践。

我们将实施其中一些建议的最佳实践，即旨在提高搜索质量的实践（句子分块、HyDE、反向打包）。

为简洁起见，我们将省略那些侧重于提高效率的技术（查询分类和摘要）。

我们还将实施一些未涉及但我个人认为有用且有趣的技术（元数据包含、复合多字段嵌入、查询丰富化）。

最后，我们将进行一个简短的测试，看看搜索结果和生成答案的质量与基线相比是否有所提高。让我们开始吧！

RAG 概览

RAG 的目的是通过检索外部知识库中的信息来丰富生成的答案，从而增强 LLM。通过提供特定领域的信息，LLM 可以快速适应训练数据范围之外的用例；比微调成本低得多，也更容易保持更新。

提高 RAG 质量的措施通常集中在两个方面：

1. 提高知识库的质量和清晰度。

2. 提高搜索查询的覆盖面和针对性。

这两项措施将实现提高法律硕士获得相关事实和信息的几率的目标，从而减少产生幻觉或利用自身知识的可能性--这些知识可能已经过时或不相关。

方法的多样性难以用几句话说清楚。为了更清楚地说明问题，让我们直接进入实施阶段。

目录

• 概述

  • 目录

• 设置

• 摄取、处理和嵌入文件

  • 数据采集

  • 句子级标记分块

  • 元数据的纳入和生成

    • 通过 TextRank 提取的关键词

    • GPT-4o 提出的潜在问题

    • Spacy 提取的实体

  • 复合多场嵌入

    • 索引至弹性

• 猫休息

• 附录

  • 定义

设置

所有代码均可 在 Searchlabs 软件仓库中找到 。

先说第一件事。您需要以下材料

1. 弹性云部署

2. LLM 应用程序接口--我们在本笔记本中使用了 Azure OpenAI 上的 GPT-4o 部署

3. Python 3.12.4 或更高版本

我们将运行 main.ipynb 笔记本 中的所有代码 。

继续 git 克隆该 repo，导航至 supporting-blog-content/Advanced-rag-techniques，然后运行以下命令：

完成后，创建一个.env文件，并填写以下字段（在.env.example 中引用）。感谢我的合著者 Claude-3.5 提出的有益意见。

接下来，我们将选择要摄取的文档，并将其放在文档文件夹中。在本文中，我们将使用 Elastic N.V. 的《 2023 年年度报告》 。这是一份相当具有挑战性的密集文件，非常适合对我们的 RAG 技术进行压力测试。

现在我们都准备好了，开始摄入。打开main.ipynb，执行前两个单元格以导入所有软件包并初始化所有服务。

返回顶部

摄取、处理和嵌入文件

数据采集

• 个人感言：LlamaIndex 的便利性令我震惊。在还没有 LLM 和 LlamaIndex 的年代，录入各种格式的文档是一个痛苦的过程，需要从各处收集深奥的软件包。现在只需调用一个函数。狂野

SimpleDirectoryReader 将加载directory_path. 文件中的每个文档。对于.pdf 文件，它会返回一个文档对象列表，我将其转换为 Python 字典，因为我觉得它们更容易处理。

每个字典都包含text 字段中的关键内容。它还包含有用的元数据，如页码、文件名、文件大小和类型。

返回顶部

句子级标记分块

首先要做的是将我们的文件缩减成标准长度的块状（以确保一致性和可管理性）。嵌入模型有独特的标记限制（可处理的最大输入尺寸）。标记是模型处理文本的基本单位。为防止信息丢失（内容截断或遗漏），我们应提供不超过这些限制的文本（将较长的文本分割成较小的片段）。

分块对性能有重大影响。在理想情况下，每个信息块都代表一个独立的信息片段，捕捉有关单个主题的上下文信息。分块方法包括字级分块（按字数分割文档）和语义分块（使用 LLM 识别逻辑断点）。

单词级的分块处理成本低、速度快、操作简单，但存在拆分句子从而破坏上下文的风险。语义分块的速度越来越慢，成本越来越高，尤其是在处理像116页的《弹性年度报告》这样的文档时。

让我们选择一种中间路线。句子级分块仍然简单，但比单词级分块能更有效地保留上下文，而且成本更低，速度更快。此外，我们还将采用一个滑动窗口来捕捉周围的一些上下文，并减轻分割段落的影响。

Chunker 类采用嵌入模型的标记化器对文本进行编码和解码。现在，我们将构建每块 512 个令牌的分块，其中有 20 个令牌重叠。为此，我们会将文本分割成句子，对这些句子进行标记化处理，然后将标记化处理后的句子添加到当前语块中，直到无法在不超出标记限制的情况下添加更多句子为止。

最后，将句子解码回原始文本进行嵌入，将其存储在名为original_text 的字段中。数据块存储在一个名为chunk 的字段中。为了减少噪音（又称无用文件），我们将丢弃长度小于 50 个 token 的文件。

让我们在文件上运行一下：

然后得到类似这样的文本块：

返回顶部

元数据的纳入和生成

我们已将文件分块。现在是丰富数据的时候了。我想生成或提取额外的元数据。这些附加元数据可用于影响和提高搜索性能。

我们将定义一个DocumentEnricher 类，它的作用是接收文档列表（Python 字典）和处理器函数列表。这些函数将在文档的original_text 列中运行，并将其输出存储在新字段中。

首先，我们使用TextRank 提取关键词。TextRank 是一种基于图的算法，它能根据词与词之间的关系对关键短语和句子的重要性进行排序，从而从文本中提取关键短语和句子。

接下来，我们将使用 GPT-4o 生成 potential_questions。

最后，我们将使用 Spacy 提取实体 。

由于每项工作的代码都相当冗长和复杂，我就不在此赘述了。如果您感兴趣，这些文件已在下面的代码示例中标出。

让我们运行数据浓缩：

看看结果吧：

通过 TextRank 提取的关键词

这些关键短语是大块核心主题的替身。如果查询与网络安全有关，这块内容的得分就会提高。

GPT-4o 提出的潜在问题

这些潜在问题可能与用户查询直接匹配，从而提高得分。我们会提示 GPT-4o 生成一些问题，这些问题可以用当前语块中的信息来回答。

Spacy 提取的实体

这些实体的作用与关键词类似，但可以捕捉到组织和个人的名称，而关键词提取可能会遗漏这些名称。

返回顶部

复合多场嵌入

现在，我们已经用更多的元数据丰富了我们的文档，我们可以利用这些信息创建更强大、更能感知上下文的嵌入。

让我们回顾一下目前的进程。我们在每份文档中都有四个关注领域。

每个字段都代表了对文件背景的不同看法，可能突出了法律硕士应重点关注的关键领域。

我们的计划是嵌入每个字段，然后创建嵌入的加权和，即复合嵌入。

幸运的话，除了引入另一个可调整的超参数来控制搜索行为外，这种复合嵌入还能让系统变得更加了解上下文。

首先，让我们使用在 main.ipynb 笔记本开头导入的本地定义的嵌入模型，嵌入每个字段并就地更新每个文档。

每个嵌入函数都会返回嵌入的字段，即带有_embedding 后缀的原始输入字段。

现在我们来定义复合嵌入的权重：

通过权重，您可以根据用例和数据质量为每个组件分配优先级。直观地说，这些权重的大小取决于每个组件的语义值。由于大块文本本身的内容迄今为止最为丰富，我将其权重定为 70% 。由于实体最小，只是一个组织或个人名称列表，因此我将其权重定为 5% 。这些值的精确设置必须根据具体情况，根据经验来确定。

最后，让我们编写一个函数来应用权重，并创建我们的复合嵌入。为了节省空间，我们还将删除所有的组件嵌入。

至此，我们完成了文件处理工作。现在我们有了一个文档对象列表，看起来像这样：

索引至弹性

让我们将文档批量上传到 Elastic Search。为此，我很早就在elastic_helpers.py 中定义了一组 Elastic Helper 函数。这是一段非常冗长的代码，所以我们还是只看函数调用。

es_bulk_indexer.bulk_upload_documents 利用 Elasticsearch 方便的动态映射，可以处理任何字典对象列表。

前往 Kibana，确认所有文件都已编入索引。应该有 224 个。对于这么大的文件来说，还算不错！

返回顶部

猫休息

我们休息一下吧，文章有点沉重，我知道。看看我的猫

真可爱帽子不见了，我半信半疑是她偷藏起来的：(

祝贺你们走到这一步 :)

请看第二部分，了解我们对 RAG 管道的测试和评估！

附录

定义

1.句子分块

• RAG 系统中使用的一种预处理技术，用于将文本划分为更小的、有意义的单元。

• 过程：

  1. 输入：大段文本（如文档、段落）

  2. 输出：较小的文本片段（通常是句子或小句子组）

• 目的是

  • 创建细粒度、针对特定上下文的文本片段

  • 允许更精确的索引和检索

  • 提高 RAG 系统检索信息的相关性

• 特点

  • 分段具有语义意义

  • 可独立索引和检索

  • 通常保留一些上下文，以确保独立的可理解性

• 优势：

  • 提高检索精度

  • 使 RAG 管道的扩容更有针对性

2.HyDE（假设文档嵌入）

• 在 RAG 系统中使用 LLM 生成用于查询扩展的假设文档的技术。

• 过程：

  1. 向 LLM 输入查询

  2. LLM 生成回答查询的假设文档

  3. 嵌入生成的文件

  4. 使用嵌入进行向量搜索

• 主要区别

  • 传统 RAG：将查询与文档匹配

  • HyDE：将文档匹配到文档

• 目的是

  • 提高检索性能，尤其是复杂或模糊查询的检索性能

  • 捕捉比简短查询更丰富的语义上下文

• 优势：

  • 利用 LLM 的知识扩展查询

  • 有可能提高检索文件的相关性

• 挑战：

  • 需要额外的 LLM 推理，增加了延迟和成本

  • 性能取决于生成的假设文件的质量

3.反向包装

• RAG 系统中使用的一种技术，用于在将搜索结果传递给 LLM 之前对其重新排序。

• 过程：

  1. 搜索引擎（如 Elasticsearch）按相关性降序返回文档。

  2. 顺序颠倒，将最相关的文件放在最后。

• 目的是

  • 利用 LLM 的新旧偏差，LLM 往往更关注其上下文中的最新信息。

  • 确保最相关的信息"最新鲜的" 在 LLM 的上下文窗口中。

• 举例说明：原始顺序：[最相关、第二最相关、第三最相关、......] 倒序：[......，最重要的第三项，最重要的第二项，最相关的］

4.查询分类

• 通过确定查询是需要 RAG 还是可以直接由 LLM 回答来优化 RAG 系统效率的技术。

• 过程：

  1. 针对使用中的 LLM 开发定制数据集

  2. 训练专门的分类模型

  3. 使用模型对收到的查询进行分类

• 目的是

  • 避免不必要的 RAG 处理，提高系统效率

  • 将查询引导至最合适的响应机制

• 要求：

  • LLM 专用数据集和模型

  • 不断改进以保持准确性

• 优势：

  • 减少简单查询的计算开销

  • 有可能缩短非 RAG 查询的响应时间

5.总结

• 在 RAG 系统中压缩检索文档的技术。

• 过程：

  1. 检索相关文件

  2. 生成每份文件的简明摘要

  3. 在 RAG 管道中使用摘要而非完整文件

• 目的是

  • 关注基本信息，提高 RAG 性能

  • 减少不相关内容的噪音和干扰

• 优势：

  • 有可能提高 LLM 答复的相关性

  • 允许在上下文限制内纳入更多文件

• 挑战：

  • 总结时有可能丢失重要细节

  • 生成摘要的额外计算开销

6.元数据的纳入

• 一种用额外的上下文信息来丰富文档的技术。

• 元数据类型：

  • 关键词

  • 标题

  • 日期

  • 作者详细信息

  • 简介

• 目的是

  • 增加 RAG 系统可用的背景信息

  • 让法律硕士更清楚地了解文件内容和相关性

• 优势：

  • 有可能提高检索的准确性

  • 提高法律硕士评估文件实用性的能力

• 实施：

  • 可在文件预处理过程中完成

  • 可能需要额外的数据提取或生成步骤

7.复合多字段嵌入

• RAG 系统的高级嵌入技术，可为不同的文档组件创建单独的嵌入。

• 过程：

  1. 确定相关字段（例如标题、关键词、简介、主要内容）

  2. 为每个字段生成单独的嵌入

  3. 合并或存储这些嵌入信息，以用于检索

• 与标准方法的区别：

  • 传统：对整个文档进行单一嵌入

  • 复合：针对不同文档方面的多重嵌入

• 目的是

  • 创建更细致入微、更能感知上下文的文档表示法

  • 在文件中获取更多来源的信息

• 优势：

  • 有可能提高模糊或多方面查询的性能

  • 允许在检索中更灵活地加权不同的文件内容

• 挑战：

  • 嵌入存储和检索流程的复杂性增加

  • 可能需要更复杂的匹配算法

8.丰富查询

• 一种用相关术语扩展原始查询以提高搜索覆盖率的技术。

• 过程：

  1. 分析原始查询

  2. 生成同义词和语义相关的短语

  3. 用这些附加术语来扩展查询

• 目的是

  • 增加文件语料库中潜在匹配的范围

  • 提高使用特定或技术语言查询的检索性能

• 优势：

  • 可能检索到与原始查询条件不完全匹配的相关文档

  • 有助于克服查询和文档之间的词汇不匹配问题

• 挑战：

  • 如果不认真执行，则有查询偏移的风险

  • 可能会增加检索过程中的计算开销

返回顶部

向量搜索正在彻底改变我们进行相似性搜索的方式，特别是在 AI 和机器学习等领域。随着向量嵌入模型的日益普及，在数百万个高维向量中进行高效搜索的能力变得至关重要。

在为向量数据库提供支持时，Elastic 和 OpenSearch 采取了显著不同的方法。Elastic 投入巨资优化 Apache Lucene 和 Elasticsearch，使其成为向量搜索应用程序的顶级选择。相比之下，OpenSearch 扩大了其关注范围，整合了其他向量搜索实现，并探索了超出 Lucene 范围的领域。我们对 Lucene 的关注具有战略意义，这使我们能够在 Elasticsearch 版本中提供高度集成的支持，从而形成一个功能更强大的组合，其中每个组件都能相互补充并增强彼此的功能。

本博客详细比较了 Elasticsearch 8.14 和 OpenSearch 2.14 的不同配置和向量引擎。在这项性能分析中，Elasticsearch 被证明是向量搜索操作的卓越平台，而即将推出的功能将更加显著地扩大差异。与 OpenSearch 相比，它在每个基准轨道上都表现出色——平均性能提高了 2 倍到 12 倍。这涉及使用不同的向量数量和维度的场景，包括 so_vector（2M 向量，768D）、openai_vector（2.5M 向量，1536D）和 dense_vector（10M 向量，96D），所有这些都可在此存储库中找到，并附有在 Google Cloud 上配置所有所需基础架构的 Terraform 脚本和用于运行测试的 Kubernetes 清单。

本博客中详述的结果补充了之前发布并经过第三方验证的研究的结果。该研究表明，在最常见的搜索分析操作中，Elasticsearch 比 OpenSearch 快 40%–140%；此类操作包括文本查询、排序、范围、日期直方图和术语过滤。现在我们可以添加另一个差异化因素：向量搜索。

开箱即用，性能提升高达 12 倍

我们在四个向量数据集上的基准测试涉及近似 KNN 和精确 KNN 搜索，考虑了不同的大小、维度和配置，总共进行了 40.189.820 次未缓存的搜索请求。结果：Elasticsearch 在向量搜索中比 OpenSearch 快 12 倍，因此需要更少的计算资源。

图 1：Elasticsearch 和 OpenSearch 中不同组合的 ANN 和精确 KNN 的分组任务。

像 knn-10-100 这样的组表示 KNN 搜索， 和 。在 HNSW 向量搜索中， 决定了查询向量要检索的最近邻居数量。它指定了要找到多少个相似向量。 设置每个段要检索的候选向量数量。更多的候选者可以提高准确性，但需要更多的计算资源。

我们还测试了不同的量化技术，并利用特定引擎进行了优化。各个轨道、任务和向量引擎的详细结果如下。

精确 KNN 和近似 KNN

在处理不同的数据集和用例时，向量搜索的正确方法会有所不同。在本博客中，所有标记为 knn-* 的任务，如 knn-10-100，使用 近似 KNN，而 script-score-* 指的是 精确 KNN，但它们之间有什么区别，为什么它们很重要？

本质上，如果您处理的是更大规模的数据集，首选方法是近似 K 最近邻 (ANN)，因为它具有更出色的可扩展性。对于可能需要过滤过程的规模较小的数据集，精确 KNN 方法是理想选择。

精确 KNN 使用暴力方法，计算数据集中一个向量与其他每个向量之间的距离。然后对这些距离进行排序，找出 个最近的邻居。虽然这种方法能确保精确匹配，但对于大型高维数据集来说，它在可扩展性方面面临挑战。然而，在很多情况下，需要使用精确 KNN：

• 重新评分：在涉及词汇或语义搜索后进行基于向量的重新评分时，精确 KNN 至关重要。例如，在产品搜索引擎中，可以根据文本查询（例如，关键字、类别）筛选初始搜索结果，然后使用与筛选出的项目相关的向量进行更准确的相似性评估。

• 个性化：处理大量用户时，如果每个用户都由相对较少数量（例如 100 万）的不同向量表示，则按用户特定的元数据（例如 user_id）对索引进行排序，并使用向量进行暴力评分会变得高效。这种方法能够根据精准的向量比较，根据用户的个人偏好为用户量身定制个性化推荐或内容交付。

因此，精确 KNN 确保了基于向量相似度的最终排名和推荐精准且符合用户偏好。

另一方面，近似 KNN（或 ANN）采用的方法使得数据搜索比精确 KNN 更快、更高效，尤其是在大型高维数据集中。ANN 并不采用蛮力方法（即测量查询与所有点之间的精确最近距离，从而带来计算和扩展挑战），而是使用某些技术来有效地重构数据集中可搜索向量的索引和维度。虽然这可能会导致轻微的不准确，但它显著提高了搜索过程的速度，使其成为处理大型数据集的有效替代方案。

在本博客中，所有表述为 knn-* 的任务，例如 knn-10-100，均使用近似 KNN，而 script-score-* 指的是精确 KNN。

测试方法

虽然 Elasticsearch 和 OpenSearch 在 BM25 搜索操作的 API 方面相似，但由于后者是前者的分支，向量搜索并非如此，因为它是在分支之后才引入的。在算法方面，OpenSearch 采取了与 Elasticsearch 不同的方法，除了 lucene 之外，还引入了另外两个引擎——nmslib 和 faiss，每个引擎都有其特定的配置和限制（例如，OpenSearch 中的 nmslib 不支持使用筛选器，而筛选器是许多用例的一项基本功能）。

这三个引擎都使用分层可导航小世界 (HNSW) 算法，该算法对于近似最近邻搜索非常高效，尤其在处理高维数据时表现出色。需要注意的是，faiss 还支持第二种算法 ivf，但由于它需要对数据集进行预训练，因此我们将仅关注 HNSW。HNSW 的核心理念是将数据组织成多层连接图表，每一层代表数据集的不同粒度。搜索从最顶层的粗略视图开始，逐步深入到越来越精细的层级，直至到达最底层。

这两个搜索引擎在受控环境中的相同条件下进行了测试，以确保测试的公平性。所采用的方法与之前发布的性能比较类似，为 Elasticsearch、OpenSearch 和 Rally 配备了专用节点池。terraform 脚本（与所有源一起）可用于配置具有以下功能的 Kubernetes 集群：

• 1 个适用于 Elasticsearch 的节点池，包含 3 台 e2-standard-32 计算机（128GB RAM 和 32 个 CPU）

• 1 个 Node 池用于 OpenSearch，配备 3 台 e2-standard-32 机器（128GB RAM 和 32 个 CPU）

• 1 个适用于 Rally 的节点池，包含 2 台 t2a-standard-16 计算机（64GB RAM 和 16 个 CPU）

每个“轨道”（或测试）的每种配置都运行了 10 次，其中包括不同的引擎、不同的配置和不同的向量类型。轨道上的任务会根据轨道的不同重复 1,000 到 10,000 次。如果某个轨道中的某个任务由于网络超时而失败，则所有任务都将被丢弃，因此所有结果都代表了顺利开始并完成的轨道。所有测试结果都经过统计验证，确保改进并非偶然。

详细结果

为什么要使用第 99 个百分位而不是平均延迟来进行比较？考虑一个假设的例子：某个社区的平均房价。平均价格可能表明一个昂贵的地区，但仔细观察后，可能会发现大多数房屋的价值要低得多，只有少数豪华属性抬高了平均价格。这说明了平均价格如何无法准确代表该地区房屋价值的完整范围。这就好比检查响应时间，平均值可能会掩盖关键问题。

任务

• 近似 KNN，k:10 n:50

• 使用 k:10 n:100 的近似 KNN

• 近似 KNN，k:100 n:1000

• 使用 k:10 n:50 和关键字筛选器的近似 KNN

• 使用 k:10 n:100 和关键字筛选器的近似 KNN

• 使用 k:100 n:1000 和关键字筛选器的近似 KNN

• 使用 k:10 n:100 结合索引的近似 KNN

• 精确 KNN（脚本分数）

向量引擎

• lucene 在 Elasticsearch 和 OpenSearch 中，版本均为 9.10

• faiss 在 OpenSearch 中

• nmslib 在 OpenSearch 中

向量类型

• hnsw 在 Elasticsearch 和 OpenSearch 中

• int8_hnsw 在 Elasticsearch 中（采用自动 8 位量化的 HNSW：链接）

• sq_fp16 hnsw 在 OpenSearch 中（采用自动 16 位量化的 HNSW：链接）

开箱即用和并行分段搜索

您可能知道，Lucene 是一个用 Java 编写的高性能文本搜索引擎库，它是 Elasticsearch、OpenSearch 和 Solr 等许多搜索平台的核心。Lucene 的核心是将数据组织成多个段，这些段本质上是独立的索引，使 Lucene 能够更高效地执行搜索。因此，当您向任何基于 Lucene 的搜索引擎发出搜索请求时，您的搜索最终将在这些段中按顺序或并行执行。

OpenSearch 将并发分段搜索作为可选标记引入，默认情况下不使用该标记，您必须使用特殊的索引设置 index.search.concurrent_segment_search.enabled 启用该标记，此处有详细说明，但有一些限制。

另一方面，Elasticsearch 能以开箱即用的方式并发搜索各网段，因此我们在本博客中进行的比较除了考虑不同的向量引擎和向量类型外，还将考虑不同的配置：

• Elasticsearch ootb：开箱即用的 Elasticsearch，支持并行分段搜索；

• OpenSearch ootb：未启用并行分段搜索；

• OpenSearch css：启用并发段搜索

现在，让我们深入了解每个已测试的向量数据集的详细结果：

250 万个向量，1536 个维度（openai_vector）

从最简单的轨道开始，但在维度方面也是最大的，openai_vector——它使用了 NQ 数据集，并通过使用 OpenAI 的 text-embedding-ada-002 模型生成的嵌入来丰富该数据集。它是最简单的，因为它仅测试近似 KNN，并且只有 5 个任务。它既能独立测试（不进行索引），也能与索引一起测试，并且能使用单个客户端和 8 个同时运行的客户端进行测试。

任务

• standalone-search-knn-10-100-multiple-clients：同时使用 8 个客户端搜索 250 万个向量 (k:10, n:100)

• standalone-search-knn-100-1000-multiple-clients：使用 8 个客户端同时搜索 250 万个向量（k: 100，n: 1000）

• standalone-search-knn-10-100-single-client：使用单个客户端在 250 万个向量上搜索（k: 10，n: 100）

• standalone-search-knn-100-1000-single-client：使用单个客户端在 250 万个向量上搜索（k: 100，n: 1000）

• parallel-documents-indexing-search-knn-10-100：在 250 万个向量上搜索，同时索引另外 100,000 个文档 (k:10, n：100)

平均 p99 性能概述如下：

在此我们观察到，在执行索引（即读写）的同时进行向量搜索时，Elasticsearch 比 OpenSearch 快 3 到 8 倍，而在不进行索引的情况下（:10, :100），速度提高了 2 倍到 3 倍，其中 k 和 n 相同。对于 :100 和 :1000（standalone-search-knn-100-1000-single-client 和 standalone-search-knn-100-1000-multiple-clients），Elasticsearch 的平均速度比 OpenSearch 快 2 到 7 倍。

详细结果显示了比较的确切案例和向量引擎：

召回

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0.969485

0.995138

Elasticsearch-8.14.0@lucene-int8_hnsw

0.781445

0.784817

OpenSearch-2.14.0@lucene-hnsw

0.96519

0.995422

OpenSearch-2.14.0@faiss

0.984154

0.98049

OpenSearch-2.14.0@faiss-sq_fp16

0.980012

0.97721

OpenSearch-2.14.0@nmslib

0.982532

0.99832

一千万个向量，96 个维度 (dense_vector)

在具有 1000 万个向量和 96 维的 dense_vector 中。它基于 Yandex DEEP1B 图像数据集。该数据集是从名为 learn.350M.fbin 的“样本数据”文件的前 1000 万个向量创建的。搜索操作使用来自“查询数据”文件查询的向量。public.10K.fbin。

Elasticsearch 和 OpenSearch 在此数据集上的表现都非常出色，尤其是在强制合并之后，这通常是在只读索引上进行的，类似于对索引进行碎片整理，使其成为一个单一的“表”以供搜索。

任务

每个任务预热 100 个请求，然后测量 1000 个请求

• knn-search-10-100：在 1000 万个向量上搜索（k: 10，n: 100）

• knn-search-100-1000：在 1000 万个向量上搜索（k：100，n：1000）

• knn-search-10-100-force-merge：在强制合并后搜索 1,000 万个向量 (k:10, n:100)

• knn-search-100-1000-force-merge：在强制合并后搜索 1000 万个向量 (k: 100, n: 1000)

• knn-search-100-1000-concurrent-with-indexing：在 1,000 万个向量上进行搜索，同时更新数据集的 5% (k:100, n:1000)

• script-score-query：对 2000 个特定向量进行精确的 KNN 搜索。

Elasticsearch 和 OpenSearch 在近似 KNN 上表现良好。当索引在 knn-搜索-100-1000-force-merge 和 knn-搜索-10-100-force-merge 中合并（即只有一个段）时，OpenSearch 在使用 nmslib 和 faiss 时表现优于其他，即使它们都在 15 毫秒左右并且都非常接近。

但是，当索引在 knn-search-10-100 和 knn-search-100-1000 中具有多个分段（这是索引接收其文档更新的典型情况）时，Elasticsearch 将延迟保持在约 7 毫秒和 16 毫秒左右，而所有其他 OpenSearch 引擎则较慢。

此外，当同时搜索和写入索引时 (knn-search-100-1000-concurrent-with-indexing)，Elasticsearch 将延迟保持在 15 毫秒以下（13.8 毫秒），比开箱即用的 OpenSearch 快近 4 倍（49.3 毫秒），并且在启用并发段搜索时仍然更快（17.9 毫秒），但由于过于接近，所以意义不大。

至于精确 KNN，差距则大得多：Elasticsearch 比 OpenSearch快 6 倍（约 260 毫秒对约 1600 毫秒）。

召回

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0.969843

0.996577

Elasticsearch-8.14.0@lucene-int8_hnsw

0.775458

0.840254

OpenSearch-2.14.0@lucene-hnsw

0.971333

0.996747

OpenSearch-2.14.0@faiss

0.9704

0.914755

OpenSearch-2.14.0@faiss-sq_fp16

0.968025

0.913862

OpenSearch-2.14.0@nmslib

0.9674

0.910303

200 万个向量，768 个维度 (so_vector)

此轨道 so_vector 源自于 2022 年 4 月 21 日下载的 StackOverflow 帖子转储。它仅包含问题文档——所有代表答案的文档都已删除。每个问题的标题都已使用句子转换器模型 multi-qa-mpnet-base-cos-v1 编码成一个向量。此数据集包含前 200 万个问题。

与前一个轨道不同，这里的每个文档都包含除向量之外的其他字段，以支持诸如带筛选和混合搜索功能的近似 KNN 等测试功能。此测试中明显缺少适用于 OpenSearch 的 nmslib，因为它不支持筛选器。

任务

每个任务会预热 100 个请求，然后测量 100 个请求。请注意，为了简单起见，我们对任务进行了分组，因为测试包含 16 种搜索类型 * 2 个不同的 k 值 * 3 个不同的 n 值。

• knn-10-50：在没有筛选器的情况下搜索 200 万个向量 (k:10, n:50)

• knn-10-50-filtered：使用筛选器在 200 万个向量上进行搜索 (k:10, n:50)

• knn-10-50-after-force-merge：在强制合并并使用过滤器后，对 200 万个向量进行搜索（k: 10，n: 50）

• knn-10-100：在没有过滤器的情况下搜索 200 万个向量（k: 10，n: 100）

• KNN-10-100-filtered：在 200 万个向量上使用过滤器进行搜索（k: 10，n: 100）

• knn-10-100-after-force-merge：在强制合并后，使用筛选器在 200 万个向量上进行搜索 (k:10, n:100)

• knn-100-1000：在没有过滤器的情况下搜索 200 万个向量（k:100，n:1000）

• knn-100-1000-filtered：使用筛选器在 200 万个向量上进行搜索 (k:100, n:1000)

• knn-100-1000-after-force-merge：在强制合并后使用过滤器在 200 万个向量上搜索（k：100，n：1000）

• exact-knn：带筛选器和不带筛选器的精确 KNN 搜索。

在这项测试中，Elasticsearch 始终比 OpenSearch 的开箱即用速度快，OpenSearch 仅在两种情况下更快，但差距不大（knn-10-100 和 knn-100-1000）。将knn-10-50、knn-10-100 和 knn-100-1000 与筛选器结合使用的任务显示出高达 7 倍的差异（112 毫秒对 803 毫秒）。

执行“强制合并”操作后，两种解决方案的性能似乎趋于平稳，这是可以理解的，从 knn-10-50-after-force-merge、knn-10-100-after-force-merge 和 knn-100-1000-after-force-merge 中可以明显看出这一点。在这些任务中，faiss 的速度更快。

在精确 KNN 的性能上差异再次明显，这次 Elasticsearch 比 OpenSearch 快 13 倍（约 385 毫秒对比 5262 毫秒）。

召回

knn-recall-10-100

knn-recall-100-1000

knn-recall-10-50

Elasticsearch-8.14.0@lucene-hnsw

1

1

1

Elasticsearch-8.14.0@lucene-int8_hnsw

1

0.986667

1

OpenSearch-2.14.0@lucene-hnsw

1

1

1

OpenSearch-2.14.0@faiss

1

1

1

OpenSearch-2.14.0@faiss-sq_fp16

1

1

1

OpenSearch-2.14.0@nmslib

0.9674

0.910303

0.976394

Elasticsearch 和 Lucene 明显胜出

在 Elastic，我们坚持不懈地对 Apache Lucene 和 Elasticsearch 进行创新，以确保我们能够为搜索和检索用例（包括 RAG (Retrieval-Augmented Generation)）提供一流的向量数据库。我们最近取得的进展极大地提升了性能，使向量搜索比以前更快、更节省空间，这是在 Lucene 9.10 所取得的成果基础上实现的。这篇博客介绍了一项研究，该研究表明，在比较最新版本时，Elasticsearch 的速度比 OpenSearch 快多达 12 倍。

值得注意的是，这两款产品都使用相同版本的 Lucene（Elasticsearch 8.14 发行说明 和 OpenSearch 2.14 发行说明）。

Elastic 的创新步伐不仅将为我们的本地部署和 Elastic Cloud 客户提供更多服务，还将为使用我们的无状态平台的客户提供更多服务。在提供对标量量化到 int4 等功能的支持时，我们将进行严格的测试，以确保客户能够在不显著减少召回率的情况下使用这些技术，这与我们对 int8 的测试类似。

由于 AI 和机器学习应用程序的普及，向量搜索效率正成为现代搜索引擎中不可或缺的功能。对于寻求能够满足大容量、高复杂性向量数据需求的强大搜索引擎的组织来说，Elasticsearch 是最佳选择。

无论是扩展已建立的平台还是启动新项目，集成 Elasticsearch 以满足向量搜索需求都是一项战略性举措，将带来切实的长期效益。Elasticsearch 凭借其公认的性能优势，已准备好支撑搜索领域的下一波创新浪潮。

这正是矢量搜索引擎的优势所在。它们可以为同一文本编制索引，以便根据文本所代表的含义及其与其他具有相似或相关含义的概念之间的关系进行搜索。

在本博客中，我们将简要介绍矢量是如何传达文本含义的一个重要数学概念。然后，我们将深入探讨 Elasticsearch 在搜索相邻向量（即搜索含义相似的向量）时支持的不同相似性技术，以及如何对它们进行评分。

什么是向量嵌入？

本文不会深入探讨向量嵌入的复杂性。如果您想进一步了解这一主题，或者在继续学习之前需要一些入门知识，我们建议您查看以下指南。

简而言之，矢量嵌入是通过机器学习过程获得的。深度学习神经网络），可将任何类型的非结构化输入数据（如原始文本、图像、视频、声音等）转化为承载其意义和关系的数字数据。不同类型的非结构化数据需要不同类型的机器学习模型，这些模型经过训练，可以"了解" 每种类型的数据。

每个矢量将特定数据定位为多维空间中的一个点，该位置代表了模型用来描述数据特征的一组特征。维度的数量取决于机器学习模型，但通常从几百到几千不等。例如，OpenAI Embeddings 模型拥有 1536 个维度，而Cohere Embeddings 模型则有 382 到 4096 个维度。从最新版本开始，Elasticsearch dense_vector 字段类型支持多达 4096 个维度。

向量嵌入的真正特点是，意义相似的数据点在空间中靠得很近。另一个有趣的方面是，向量嵌入也有助于捕捉数据点之间的关系。

如何比较向量？

我们知道，非结构化数据会被机器学习模型切割成向量嵌入，以捕捉数据在大量维度上的相似性，现在我们需要了解这些向量的匹配是如何进行的。事实证明，答案非常简单。

相互接近的向量嵌入代表语义上相似的数据片段。因此，当我们查询矢量数据库时，搜索输入（图像、文本等）首先会被转化为矢量嵌入，使用的机器学习模型与索引所有非结构化数据时使用的相同，最终目标是找到与该查询矢量最近的相邻矢量。因此，我们需要做的就是找出如何测量查询向量与数据库中索引的所有现有向量之间的"距离" 或"相似性" - 就是这么简单。

距离、相似性和评分

幸运的是，由于有了向量算术，测量两个向量之间的距离或相似性是一个很容易解决的问题。因此，让我们来看看 Elasticsearch 支持的最常用的距离和相似性函数。警告，前方有数学题！

在开始之前，让我们先来了解一下计分。事实上，Lucene 只允许分数为正。我们即将介绍的所有距离和相似度函数都能衡量两个向量的接近或相似程度，但这些原始数据很少适合用作分数，因为它们可能是负数。因此，需要从距离或相似度值中得出最终分数，以确保分数为正值，分数越大，排名越靠前（即向量越接近）。

L1 距离

两个向量和的 L1 距离（也称作曼哈顿距离）是通过将它们所有元素的成对绝对差值相加来测量的。显然，距离 越小，两个向量就越接近。L1 距离公式 (1) 非常简单，如下所示：

下图（红色）可以直观地说明 L1 距离：

计算以下两个向量的 L1 距离 \vec

重要： 值得注意的是，L1 距离函数仅支持使用 script_scoreDSL 查询进行 精确向量搜索 （又称暴力搜索），但不支持使用knn 搜索选项 或knn DSL 查询 进行 近似 kNN 搜索 。

L2 距离

两个向量和的 L2 距离（也称欧几里得距离）的测量方法是：首先求出它们所有元素的成对差值的平方和，然后取其平方根。它基本上是两点之间最短的路径。与 L1 类似，距离 越小，两个向量越接近：

下图中的 L2 距离用红色表示：

让我们重新使用与 距离相同的两个样本向量 和 距离为 。

就评分而言，两个向量之间的距离越小，它们就越接近（即越相似）。因此，为了得出分数，我们需要反转距离度量，使最小的距离产生最高的分数。使用 L2 距离计算分数的方法如下式（3）所示：

重复使用前面例子中的样本向量，它们的得分是 \frac 0.2352。相距很近的两个向量的得分将接近 1，而相距很远的两个向量的得分将趋于 0。

在总结 L1 和 L2 距离函数时，一个很好的类比方法是将 A 和 B 视为纽约市曼哈顿的两座大楼。一辆从 A 地开往 B 地的出租车必须沿着 L1 路径（街道和大道）行驶，而一只鸟可能会使用 L2 路径（直线）。

余弦相似性

与 L1 和 L2 不同的是，余弦相似度不是测量两个向量和 之间的距离，而是测量它们的相对角度，即它们是否都指向大致相同的方向。相似度 越高，两个矢量之间的夹角就越小，因此，"，它们之间的距离就越近，" ，它们所表达的含义就越相似，"，" 。

为了说明这一点，让我们设想两个人在野外朝不同的方向寻找。在下图中，穿蓝色衣服的人朝矢量的方向看，穿红色衣服的人朝矢量 的方向看。他们的视线越是朝向同一个方向（即他们的矢量越接近），蓝色和红色区域所代表的视野就越是重叠。它们的视场重叠程度就是它们的余弦相似度。但是，请注意，人 B 比人 A 看得更远（即矢量更长）。人 B 可能在看地平线上远处的一座山，而人 A 可能在看附近的一棵树。对于余弦相似度来说，这没有任何作用，因为它只与角度有关。

现在我们来计算余弦相似度。公式 (4) 非常简单，分子是两个矢量的点乘，分母是两个矢量的大小乘积（即长度）：

和之间的余弦相似度如下图所示，是它们之间夹角的度量（红色）：

让我们绕个弯，具体解释一下这些余弦相似度值的含义。从下面描述余弦函数的图片中可以看出，数值总是在区间内摆动。

请记住，要使两个矢量相似，它们之间的夹角必须尽可能锐利，最好接近，即完全相似度为。换句话说，当矢量...

1. ......彼此接近，其角度的余弦接近（即接近）。

1. ......无关，它们的夹角余弦接近（即接近）。

1. ......相反，它们的夹角余弦接近（即接近）。

既然我们已经知道如何计算两个向量之间的余弦相似度，并对如何解释所得值有了很好的概念，那么我们就可以重新使用相同的样本向量和，并使用我们之前看到的公式 (4) 计算它们的余弦相似度。

我们得到的余弦相似度为，更接近于而不是，这意味着这两个矢量有些相似，即不是完全相似，但也不是完全无关，当然也没有相反的含义。

为了从任何余弦相似度值中得出正分数，我们需要使用下面的公式 (5)，该公式将在区间内摆动的余弦相似度值转换为区间内的分数：

因此，样本向量和的得分为\frac 0.8253。

点积相似性

余弦相似度的一个缺点是，它只考虑两个矢量之间的角度，而不考虑它们的大小，这意味着如果两个矢量大致指向同一个方向，但其中一个矢量比另一个矢量长很多，那么这两个矢量仍然会被认为是相似的。点积相似性（也称为标量或内积相似性）考虑了向量的角度和大小，从而改进了点积相似性，提供了更精确的相似性度量。为了使向量的大小变得无关紧要，点积相似性要求首先对向量进行归一化处理，因此我们最终只比较单位长度为 1 的向量。

让我们用同样的两个人来再次说明这个问题，但这次我们把他们放在一个圆形房间的中间，这样他们的视线范围就完全相同了（即房间的半径）。与余弦相似度类似，它们转向的方向越一致（即它们的矢量越接近），它们的视场重叠就越多。然而，与余弦相似性相反的是，两个矢量的长度相同，两个区域的表面相同，这意味着两个人看的是位于相同距离的完全相同的图片。这两个区域的重叠程度表示它们的点积相似度。

在介绍点积相似性公式之前，让我们先快速了解一下如何对向量进行归一化处理。这非常简单，只需两个微不足道的步骤即可完成：

1. 计算向量的大小

2. 将每个分量除以 1 中得到的大小。

举例来说，让我们把向量 \vec我们可以计算出它的大小 \Vert\Vert ，就像我们之前在回顾余弦相似性时看到的那样，即 \sqrt 。然后，将矢量的每个分量除以其幅度，我们就得到了下面的归一化矢量 ：

对第二个向量 \vec ：

为了得出点积相似度公式，我们可以使用公式（4）计算归一化向量和之间的余弦相似度，如下图所示：

由于两个归一化向量的大小现在都是，所以点积相似公式 (6) 就变成了......你猜对了，两个归一化向量的点积：

在下图中，我们显示了归一化向量和，我们可以用一个向量在另一个向量上的投影（红色）来说明它们的点积相似性。

使用新公式 (6)，我们可以计算出两个归一化向量的点积相似度，不出意外，这将得到与余弦相似度完全相同的相似度值：

在利用点积相似性时，得分的计算方法会因向量包含浮点值还是字节值而有所不同。在前一种情况下，得分的计算方法与余弦相似性相同，使用下面的公式（7）：

但是，当向量由字节值组成时，计算得分的方法就有些不同了，如下式（8）所示，其中是向量的维数：

此外，为了获得准确的分数，还有一个限制条件，即包括查询向量在内的所有向量必须具有相同的长度，但不一定是 1。

最大内积相似度

自 8.11 版起，新的相似度函数比点积相似度的限制更少，因为向量不需要进行归一化处理。下面的文章将详细解释其中的主要原因，但简单来说，某些数据集不太适合对其向量进行归一化处理（例如Cohere 内嵌），这样做可能会导致相关性问题。

计算最大内积相似度的公式与点积公式 (6) 完全相同。改变的是计算得分的方式，即使用一个片断函数对最大内积相似度进行缩放，该函数的计算公式取决于相似度是正还是负，如下式（9）所示：

这个分段函数的作用是，在区间内对所有负的最大内积相似度值进行缩放，在区间内对所有正值进行缩放。

总之

从数学的角度看，这真是一次不寻常的旅程，但这里有一些启示，你可能会觉得有用。

您可以使用哪种相似度函数，最终取决于您的向量嵌入是否经过归一化处理。如果您的矢量已经归一化，或者您的数据集与矢量归一化无关（即相关性不会受到影响），那么您可以继续对矢量进行归一化，并使用点积相似性，因为它的计算速度比余弦相似性快得多，因为不需要计算每个矢量的长度。在比较数百万个向量时，这些计算量会增加很多。

如果您的向量没有标准化，那么您有两种选择：

1. 如果无法对向量进行归一化处理，则使用余弦相似度

2. 如果您希望矢量的大小对评分有帮助，可以使用新的最大内积相似性，因为它们确实有意义（例如，Cohere 嵌入）。

至此，计算向量嵌入之间的距离或相似性，以及如何得出它们的分数，对你来说应该已经很清楚了。希望这篇文章对您有所帮助。

灵感和意译是有区别的。阅读一篇内容，获得启发，然后用自己的语言来探讨这个想法，即使得出的结论相似，也是有可能的。

虽然剽窃一直是讨论的话题，但内容的加速生产和发布使其具有现实意义，并构成了持续的挑战。

这种挑战并不局限于书籍、学术研究或司法文件，在这些领域经常会进行抄袭检查。它还可以延伸到报纸甚至社交媒体。

随着信息的丰富和出版的便捷，如何在可扩展的层面上有效检查抄袭行为？

大学、政府机构和公司使用的工具多种多样，虽然直接的词汇搜索可以有效检测直接抄袭，但主要的挑战在于识别转述的内容。

利用生成式人工智能检测剽窃行为

生成式人工智能带来了新的挑战。人工智能生成的内容在复制时是否被视为抄袭？

例如，OpenAI的使用条款规定，OpenAI 不会对 API 为用户生成的内容主张版权。在这种情况下，使用生成式人工智能的个人可以随意使用生成的内容，而无需引用。

不过，是否接受使用生成式人工智能来提高效率仍是一个讨论话题。

为了对剽窃检测做出贡献，OpenAI 开发了一个检测模型，但后来承认其准确性不够高。

"我们认为，这对于独立检测来说精度还不够高，需要与基于元数据的方法、人工判断和公众教育相结合，才能更加有效。"

然而，随着更多工具的出现，现在有了更多检测抄袭的选择，即使是在转述和人工智能内容的情况下。

使用 Elasticsearch 检测剽窃行为

有鉴于此，在本博客中，我们将利用自然语言处理（NLP）模型和矢量搜索（plagiarism detection）来探索元数据搜索之外的另一个使用案例。

我们利用 SentenceTransformers 提供的 数据集（ 其中包含 NLP 相关文章），通过 Python 示例 进行了演示。我们通过 "语义文本相似性 "检查摘要是否抄袭，"语义文本相似性 "考虑的是用之前导入 Elasticsearch 的文本嵌入模型生成的 "摘要 "嵌入。此外，为了识别人工智能生成的内容--人工智能剽窃，还将 OpenAI 开发的NLP 模型导入 Elasticsearch。

下图说明了数据流：

在使用 推理处理器 的摄取管道 中，"抽象 "段落被映射为一个 768 维的向量，即 "abstract_vector.predicted_value"。

绘图：

矢量表示之间的相似性使用矢量相似性度量来衡量，该度量使用 "相似性 "参数来定义。

余弦是默认的相似度量，计算公式为"(1 + cosine(query, vector))/ 2'.除非您需要保留原始矢量，并且无法事先对它们进行归一化处理，否则执行余弦相似性的最有效方法就是将所有矢量归一化为单位长度。这有助于避免在搜索过程中执行额外的矢量长度计算，而应使用 "dot_product"。

在同一管道中，另一个包含文本分类模型的推理处理器会检测内容是可能由人类撰写的 "真实 "内容，还是可能由人工智能撰写的 "虚假 "内容，并将 "openai-detector.predicted_value "添加到每个文档中。

摄取管道：

在查询时，同样的文本嵌入模型也被用于在 "query_vector_builder "对象中生成查询 "model_text "的向量表示。

k-nearest neighbor (kNN) 搜索会根据相似度量找到与查询向量最近的 k 个向量。

每份文档的 分数都来自相似度，确保分数越大，排名越靠前。这意味着文件在语义上更加相似。因此，我们打印了三种可能性：如果得分> 0.9，我们认为是 "高度相似"；如果< 0.7，是 "低度相似"，否则是 "中度相似"。您可以根据自己的使用情况，灵活设置不同的阈值，以确定哪种程度的 _score 是否属于抄袭。

此外，还进行了文本分类，以检查文本查询中是否有人工智能生成的元素。

查询：

输出：

在本例中，利用数据集中的一个 "摘要 "值作为文本查询 "model_text "后，剽窃行为被识别出来。相似度分数为 1.0，表明相似度很高，即直接抄袭。矢量化查询和文档没有被识别为人工智能生成的内容，这在意料之中。

查询：

输出：

通过更新文本查询 "model_text"，使用人工智能生成的文本，在传达相同信息的同时尽量减少相似词语的重复，检测到的相似度仍然很高，但得分为 0.9302529，而不是 1.0，这就是转述剽窃。人们还预计，由人工智能生成的这一查询会被检测到。

最后，考虑到文本查询 "model_text "是关于 Elasticsearch 的文本，而不是这些文档的摘要，检测到的相似度为 0.68991005，表明根据所考虑的阈值，相似度较低。

查询：

输出：

虽然在人工智能生成的文本查询中，以及在转述和直接复制内容的情况下，都能准确识别出抄袭行为，但在剽窃检测领域中，还需要认识到各个方面的问题。

在人工智能生成的内容检测方面，我们探索了一种模式，这种模式做出了宝贵的贡献。不过，必须认识到独立检测的固有局限性，因此需要结合其他方法来提高准确性。

选择文本嵌入模型带来的可变性是另一个考虑因素。使用不同数据集训练的不同模型会产生不同程度的相似性，这突出了所生成的文本嵌入的重要性。

最后，在这些例子中，我们使用了文件摘要。然而，剽窃检测通常涉及大量文件，因此必须解决文本长度的难题。文本通常会超过模型的标记限制，这就要求在建立嵌入之前将文本分割成块。处理这种情况的实用方法是使用 dense_vector 嵌套结构。

结论

在这篇博客中，我们讨论了检测抄袭（尤其是在转述和人工智能生成的内容中）所面临的挑战，以及如何利用语义文本相似性和文本分类来实现这一目的。

结合这些方法，我们提供了一个剽窃检测实例，成功识别了人工智能生成的内容、直接剽窃和转述剽窃。

我们的主要目标是建立一个过滤系统，简化检测工作，但人工评估对于验证工作仍然至关重要。

如果您有兴趣了解更多有关语义文本相似性和 NLP 的信息，我们建议您同时查看以下链接：

• 什么是语义搜索？

• 什么是自然语言处理（NLP）？

• 使用 Elasticsearch 进行词法和语义搜索

• 通过 Ingest 管道对大型文档进行分块，再加上嵌套向量，就能轻松进行通道搜索

准备工作

与本系列的第一部分一样，本示例也需要以下前提条件：

1. 安装 Go 1.21 或更高版本

2. 使用Go 文档中推荐的结构和软件包管理创建自己的 Go 仓库

3. 创建自己的 Elasticsearch 集群，其中包含一组 基于啮齿类动物的页面 ，包括维基百科中与我们友好的 Gopher 的 页面 ：

连接到 Elasticsearch

提醒一下，在我们的示例中，我们将使用 Go 客户端提供的Typed API。要为任何查询建立安全连接，都需要使用以下两种方法之一配置客户端：

1. 云 ID 和 API 密钥（如果使用弹性云

2. 群集 URL、用户名、密码和证书

连接到位于 Elastic Cloud 上的集群的过程如下：

然后，client 连接可用于搜索，这将在随后的章节中演示。

手动增强混合搜索

在组合任何一组搜索算法时，传统的方法是手动配置常量，以提高每种查询类型的效率。具体来说，为每个查询指定一个因子，然后将组合结果集与预期结果集进行比较，以确定查询的召回率。然后，我们对几组因子进行重复计算，选出最接近理想状态的因子。

例如，在两种查询类型中都指定Boost 字段，就可以将系数为0.8 的单一文本搜索查询与系数为0.2 的较低 knn 查询结合起来，如下例所示：

Boost 选项中为每个查询指定的因子会添加到文档得分中。通过将匹配查询的得分提高一个比 knn 查询更大的系数，关键词查询的结果将获得更高的权重。

手动提升的挑战在于，它需要进行调整，以找出能产生理想结果集的因素，这对不是搜索专家的人来说尤其如此。这只是一个尝试随机值的例子，看看什么值更接近你想要的结果集。

混合搜索中的互惠排名融合& Go 客户端

互惠排名融合（RRF）在 Elasticsearch 8.9 混合搜索技术预览版中发布。其目的是降低与调整相关的学习曲线，减少为优化结果集而试验各种因素的时间。

使用 RRF 时，文档得分通过以下算法混合得分重新计算：

使用 RRF 的好处是，我们可以利用 Elasticsearch 中合理的默认值。排序常数k 默认为60 。在对大型数据集进行搜索时，为了在返回文档的相关性和查询性能之间进行权衡，每个考虑过的查询结果集的大小都限制在window_size 的值范围内，默认值为100 ，如文档中所述。

k 和windows_size 也可以在 Go 客户端Rank 方法中的Rrf 配置中进行配置，如下例所示：

结论

在此，我们讨论了如何使用 Elasticsearch Go 客户端 在 Elasticsearch 中将向量搜索和关键字搜索结合起来。

查看GitHub 仓库中本系列的所有代码。如果您还没有阅读本系列的所有代码，请查看第 1 部分和第 2 部分。

祝您打地鼠愉快

资源

1. Elasticsearch 指南

2. Elasticsearch Go 客户端

3. 什么是矢量搜索？| 弹性

4. 互惠等级融合

就像动物、编程语言和您友好的作者一样，搜索也经历了不同实践的演变，您可能很难在自己的搜索用例中做出选择。在本博客中，我们将分享矢量搜索的概述，以及使用 Elasticsearch 和 Elasticsearch Go 客户端 的每种方法的 示例 。这些示例将向您展示如何使用 Elasticsearch 和 Go 中的矢量搜索查找地鼠并确定它们吃什么。

准备工作

要学习本示例，请确保满足以下前提条件：

1. 安装 Go 1.21 或更高版本

2. 使用

3. 创建您自己的 Elasticsearch 集群，其中包含一组基于啮齿动物的页面，包括维基百科中对我们友好的Gopher 的介绍：

连接到 Elasticsearch

在我们的示例中，我们将使用 Go 客户端提供的类型 API。要为任何查询建立安全连接，都需要使用以下两种方法之一配置客户端：

1. 云 ID 和 API 密钥（如果使用弹性云）。

2. 集群 URL、用户名、密码和证书。

连接到位于 Elastic Cloud 上的集群的过程如下：

如后续章节所示，client 连接可用于矢量搜索。

向量搜索

矢量搜索试图通过将搜索问题转换为使用矢量的数学比较来解决这一问题。文件嵌入过程还有一个额外的阶段，即使用模型将文件转换成密集的向量表示，或者简单地转换成数字流。这种方法的优势在于，通过将非文本文档（如图像和音频）翻译成矢量并与查询一起进行搜索。

简单地说，矢量搜索是一组矢量距离计算。在下图中，我们将查询Go Gopher的向量表示与向量空间中的文档进行比较，并返回最接近的结果（用常数k 表示）：

根据为文档生成嵌入式的方法，有两种不同的方法可以找出地鼠吃什么。

方法 1：自带模型

有了白金许可，就可以通过上传模型和使用推理 API 在 Elasticsearch 中生成嵌入。建立模型有六个步骤：

1. 从模型库中选择一个 PyTorch 模型上传。在本例中，我们使用 Hugging Face 的句子转换器/msmarco-MiniLM-L-12-v3来生成嵌入。

2. 使用 Elasticsearch 集群的凭据和任务类型text_embeddings ，使用Python 版 Eland 机器学习客户端将模型加载到 Elastic 中。如果没有安装 Eland，可以使用 Docker 运行导入步骤，如下图所示：

1. 上传后，请使用样本文档快速测试模型sentence-transformers__msmarco-minilm-l-12-v3 ，以确保生成的嵌入结果符合预期：

1. 创建包含推理处理器的摄取管道。这将允许使用上传的模型生成矢量表示：

1. 创建一个新索引，其中包含类型为dense_vector 的字段text_embedding.predicted_value ，用于存储为每个文档生成的向量嵌入：

1. 使用新创建的摄取管道重新索引文档，生成文本嵌入作为每个文档的附加字段text_embedding.predicted_value ：

现在，我们可以使用新的索引vector-search-rodents ，在同一个搜索 API 中使用Knn 选项，如下例所示：

通过解分叉转换 JSON 结果对象的方法与关键字搜索示例完全相同。常量K 和NumCandidates 允许我们配置返回的邻接文件数和每个分区要考虑的候选文件数。需要注意的是，增加候选结果的数量会提高结果的准确性，但由于要进行更多的比较，查询的运行时间会更长。

当使用查询What do Gophers eat? 执行代码时，返回的结果与下图类似，突出显示 Gopher 文章包含所需的信息，与之前的关键字搜索不同：

方法 2：拥抱脸推理应用程序接口

另一种方法是在 Elasticsearch 之外生成相同的嵌入，并将其作为文档的一部分进行摄取。由于该选项不使用 Elasticsearch 机器学习节点，因此可以在免费层上完成。

Hugging Face 公开了一个免费使用、有费率限制的推理 API，只要有账户和 API 令牌，就可以手动生成相同的嵌入式数据，用于实验和原型开发，帮助你开始工作。不建议用于生产。也可以使用类似的方法在本地调用自己的模型来生成嵌入，或使用付费 API。

在下面的函数GetTextEmbeddingForQuery 中，我们根据查询字符串使用推理 API 生成从POST 请求端点返回的向量：

生成的[]float32 类型的向量将作为QueryVector 传递，而不是使用QueryVectorBuilder 选项来利用之前上传到 Elastic 的模型。

请注意，无论使用哪两个选项，K 和NumCandidates 选项都是一样的，而且生成的结果也是一样的，因为我们使用的是同一个模型来生成嵌入结果

结论

在此，我们讨论了如何使用 Elasticsearch Go 客户端 在 Elasticsearch 中执行矢量搜索。查看GitHub 仓库中本系列的所有代码。请继续阅读第 3 部分，了解如何将矢量搜索与 Go 语言第一部分中的关键字搜索功能相结合。

在此之前，祝您打地鼠愉快！

资源

1. Elasticsearch 指南

2. Elasticsearch Go 客户端

3. 什么是矢量搜索？| 弹性

考虑到这一目标，在本篇博文中，我们将探讨使用 Elasticsearch 检索信息的不同方法，重点关注文本搜索：词法搜索和语义搜索。

准备工作

为此，我们将提供 Python 示例，演示在模拟电子商务产品信息生成的数据集上进行搜索的各种情况。

该数据集包含 2,500 多种产品，每种产品都有说明。这些产品分为 76 个不同的产品类别，每个类别包含的产品数量各不相同，如下所示：

树状地图可视化 - category.keyword 的前 22 个值（产品类别）

安装时您需要

• Python 3.6 或更高版本

• 弹性 Python 客户端

• Elastic 8.8 或更高版本，配备 8GB 内存的机器学习节点

• Elastic Learned Sparse EncodeR模型已预装到 Elastic 中，并已在部署中启动

我们将使用 Elastic Cloud，可免费试用。

除了本博文提供的搜索查询外，Python 笔记本还能指导您完成以下过程：

• 使用 Python 客户端与我们的弹性部署建立连接

• 将文本嵌入模型载入 Elasticsearch 集群

• 创建一个索引，其中包含用于索引特征向量和密集向量的映射。

• 创建带推理处理器的摄取管道，用于文本嵌入和文本扩展

词汇检索--稀疏检索

Elasticsearch 根据文本查询对文档进行相关性排序的经典方法是使用BM25模型的 Lucene 实现，这是一种用于词法搜索的稀疏模型。这种方法沿用了传统的文本搜索方法，即寻找完全匹配的术语。

为了实现这种搜索，Elasticsearch 通过执行文本分析将文本字段数据转换为可搜索格式。

文本分析 由 分析器 执行， 分析器 是一套规则，用于管理提取相关词组以供搜索的过程。一个分析器必须有一个 标记符。标记化器接收字符流，并将其分解为单个标记（通常是单个单词），就像下面的例子一样：

用于词法搜索的字符串标记化

输出

在本例中，我们使用的是默认分析器--标准分析器，它能提供基于英语语法的标记化，因此能很好地满足大多数使用要求。标记化可实现单个术语的匹配，但每个标记仍按字面进行匹配。

如果您想个性化搜索体验，可以选择不同的 内置分析器。例如，通过更新代码以使用停顿分析器，就能在任何非字母字符处将文本分解为词块，并支持删除停顿词。

输出

当内置分析器无法满足您的需求时，您可以创建一个 自定义分析器 ，该 分析器 使用零个或多个 字符过滤器 、一个 标记器 和零个或多个 标记过滤器的 适当组合。

在上述结合了标记符号化器和标记符号过滤器的示例中，文本将先由 小写过滤器 进行 小写 处理，然后再由 同义词标记符号过滤器 进行处理。

词汇匹配

BM25将根据术语的频率及其重要性来衡量文档与给定搜索查询的相关性。

下面的代码执行 匹配 查询，搜索最多两个文档，考虑到 "ecommerce-search " 索引中的 "描述" 字段值和搜索查询 " 大阳台的舒适家具 ".

改进文档的匹配标准可以提高查询的精确度。然而，更具体的结果是以较低的差异容忍度为代价的。

输出

通过分析输出结果，最相关的结果是"芭比娃娃梦幻屋" 产品，属于"玩具" 类别，其描述高度相关，因为其中包括术语"家具" 、"大型"和"阳台" ，这是唯一一个在描述中有 3 个术语符合搜索查询的产品，该产品也是唯一一个在描述中有术语"阳台"的产品。

排名第二的产品是"舒适摇椅" ，归类为"室内家具" ，其描述包括"舒适" 和"家具" 等术语。数据集中只有 3 种产品至少与该搜索查询的 2 个词匹配，该产品就是其中之一。

"Comfortable"出现在 105 个产品的描述中，"furniture"出现在 4 个产品的描述中，有 4 个不同的类别：玩具、室内家具、室外家具和 "猫狗用品& 玩具"。

正如您所看到的，考虑到该查询，最相关的产品是玩具，第二相关的产品是室内家具。如果你想了解分数计算的详细信息，知道为什么这些文档是匹配的，可以将explain__query 参数设置为 true。

尽管这两个结果都是最相关的结果，但考虑到该数据集中的文档数量和术语出现率，查询"大型阳台的舒适家具" 背后的意图是搜索实际大型阳台的家具，不包括玩具和室内家具。

词法搜索相对简单快捷，但也有局限性，因为在不了解用户意图和查询的情况下，不可能总是知道所有可能的术语和同义词。自然语言使用中的一个常见现象是词汇不匹配。研究表明，不同的人（同一领域的专家）对同一事物的命名平均有80% 不同。

这些局限性促使我们寻找其他包含语义知识的评分模型。基于变换器的模型擅长处理像自然语言这样的连续输入标记，它通过考虑文档和查询的数学表示来捕捉搜索的基本含义。这样就能对文本进行密集的、上下文感知的矢量表示，为语义搜索提供动力，这是一种查找相关内容的精细方法。

语义搜索 - 密集检索

在这种情况下，将数据转换成有意义的向量值后，利用k-nearest neighbor（kNN）搜索算法在数据集中找到与查询向量最相似的向量表示。Elasticsearch 支持两种 kNN 搜索方法，即精确暴力 kNN和近似 kNN（也称为 ANN）。

粗暴的 kNN 可以保证准确的结果，但在处理大型数据集时并不能很好地扩展。近似 kNN 通过牺牲一些精度来提高性能，从而有效地找到近似近邻。

借助 Lucene 对 kNN 搜索和密集矢量索引的支持，Elasticsearch 利用了分层导航小世界 (HNSW) 算法，该算法在各种ann-benchmark 数据集上都表现出了强大的搜索性能。可以使用下面的示例代码在 Python 中执行近似 kNN 搜索。

使用近似 kNN 进行语义搜索

考虑到产品数据集中 " 描述"字段的嵌入情况，该代码块使用 Elasticsearch 的 kNN 返回最多两个描述与"Comfortable furniture for a large balcony " 的矢量化查询 (query_vector_build) 相似的产品。

产品嵌入之前是在摄取管道中生成的，摄取管道中的推理处理器包含 "all-mpnet-base-v2"文本嵌入模型的推理处理器，根据管道中正在摄取的数据进行推理。

选择该模型的依据是使用 "句子转换器评估"在训练过程中，使用不同的类别来评估模型。"all-mpnet-base-v2" 模型在Sentence-Transformers排行榜上显示出最佳平均性能，并在大规模文本嵌入基准 (MTEB)排行榜上占据有利位置。该模型预先训练了 微软/mpnet-base模型，并在 1B 句子对数据集上进行了微调，将句子映射到 768 维的密集向量空间。

此外，还有许多其他模型可以使用，特别是那些针对特定领域数据进行微调的模型。

输出

根据所选模型、 过滤器 和 近似 kNN 调整，输出结果可能会有所不同。

kNN 搜索结果都属于"Outdoor Furniture" 类别，尽管"outdoor" 这个词并没有作为查询的一部分被明确提及，这凸显了语义理解在上下文中的重要性。

密集矢量搜索有几个优点：

• 启用语义搜索

• 处理超大数据集的可扩展性

• 灵活处理各种数据类型

不过，密集矢量搜索也有其自身的挑战：

• 为您的使用案例选择合适的嵌入模式

• 选定模型后，可能需要对模型进行微调，以优化特定领域数据集的性能，这一过程需要领域专家的参与

• 此外，索引高维向量的计算成本很高

语义搜索--学习型稀疏检索

让我们来探索另一种方法：学习稀疏检索，这是执行语义搜索的另一种方式。

作为一种稀疏模型，它利用 Elasticsearch 基于 Lucene 的倒排索引，该索引得益于数十年的优化。不过，这种方法不仅仅是用 BM25 等词汇评分功能添加同义词那么简单。相反，它利用更深层次的语言知识将学习到的联想融入其中，以优化相关性。

通过扩展搜索查询以包含原始查询中不存在的相关术语，Elastic Learned Sparse Encoder可以改进稀疏向量嵌入，如下例所示。

利用弹性学习稀疏编码器进行稀疏向量搜索

输出

本例中的结果包括"Garden Furniture" 类别，该类别提供的产品与"Outdoor Furniture" 非常相似。

通过分析"ml.tokens" 、"rank_features" 字段，其中包含学习稀疏检索生成的标记，可以明显看出，在生成的各种标记中，有一些术语虽然不是搜索查询的一部分，但其含义仍然相关，如"relax" （舒适）、"sofa" （家具）和"outdoor" （阳台）。

下面的图片突出显示了查询中的一些术语，包括术语扩展和未扩展术语。

正如观察到的那样，该模型提供了一种上下文感知搜索，有助于缓解词汇不匹配问题，同时提供更多可解释的结果。在不进行特定领域再训练的情况下，它甚至可以超越密集向量模型。

混合搜索：结合词法和语义搜索获得相关结果

在搜索方面，没有放之四海而皆准的解决方案。这些检索方法各有所长，但也面临挑战。根据不同的使用情况，最佳选择可能会有所变化。通常情况下，不同检索方法的最佳结果是互补的。因此，为了提高相关性，我们要把每种方法的优势结合起来。

实现混合搜索的方法有多种，包括线性组合、给每个得分加权和互惠等级融合（RRF），其中互惠等级融合无需指定权重。

Elasticsearch：词法和语义搜索的两全之策

在这段代码中，我们使用两个查询值为"大阳台的餐桌和舒适的椅子" 进行了混合搜索。我们没有使用"家具" 作为搜索词，而是指定了我们要查找的内容，并且两个搜索都考虑了相同的字段值，即"描述" 。排名由 BM25 和 ELSER 分数等权重的线性组合确定。

输出

在下面的代码中，我们将对查询使用相同的值，但会使用对等排名融合方法合并 BM25（查询参数）和 kNN（knn 参数）的得分，对文档进行合并和排名。

RRF 功能处于技术预览阶段。在全球大会之前，语法可能会有所改变。

输出

在这里，我们还可以使用不同的字段和值，Python 笔记本中提供了其中一些示例。

正如您所看到的，有了 Elasticsearch，您就可以两全其美：传统的词法搜索和矢量搜索（无论是稀疏搜索还是密集搜索），以实现您的目标并找到问题的最佳答案。

如果您想继续了解这里提到的方法，这些博客会很有用：

• 改进弹性堆栈中的信息检索：混合检索

• Elasticsearch 中的矢量搜索：设计背后的原理

• 如何利用 Elastic 的向量数据库获得词法搜索和人工智能驱动搜索的最佳效果

• 介绍 Elastic 学习稀疏编码器：Elastic 用于语义搜索的人工智能模型

• 改进 Elastic Stack 中的信息检索：介绍我们的新检索模型 Elastic Learned Sparse Encoder

Elasticsearch 提供了矢量数据库以及构建矢量搜索所需的所有工具：

• Elasticsearch矢量数据库

• 使用 Elastic 的矢量搜索用例

结论

在这篇博文中，我们探讨了使用 Elasticsearch 检索信息的各种方法，尤其侧重于文本、词法和语义搜索。为了证明这一点，我们提供了 Python 示例，使用包含电子商务产品信息的数据集展示了不同的搜索场景。

我们回顾了 BM25 的经典词汇搜索，并讨论了其优势和挑战，如词汇不匹配。我们强调了结合语义知识来克服这一问题的重要性。此外，我们还讨论了实现语义搜索的密集矢量搜索，并介绍了与这种检索方法相关的挑战，包括索引高维矢量时的计算成本。

另一方面，我们提到稀疏向量的压缩效果特别好。因此，我们讨论了 Elastic 的 "学习稀疏编码器"（Learned Sparse Encoder），该编码器可扩展搜索查询，以包含原始查询中不存在的相关术语。

在搜索方面，没有放之四海而皆准的解决方案。每种检索方法都有其优势和挑战。因此，我们还讨论了混合搜索的概念。

正如您所看到的，有了 Elasticsearch，您就可以同时拥有传统词法搜索和矢量搜索这两种搜索方式的优点！

准备好开始了吗？查看可用的Python 笔记本并开始免费试用 Elastic Cloud。

随着技术的进步，聊天机器人被用来快速处理更复杂的任务，同时还能为用户提供个性化体验。自然语言处理（NLP）使聊天机器人能够处理用户的语言，识别其信息背后的意图，并从中提取相关信息。例如，"命名实体识别 "通过将文本分类，提取文本中的关键信息。情感分析可确定情感基调，而问题解答则可确定查询的 "答案"。NLP 的目标是使算法能够处理人类语言，并完成历史上只有人类才能完成的任务，如在大量文本中查找相关段落、总结文本以及生成新的原创内容。

这些先进的 NLP 功能建立在一种称为向量搜索的技术之上。Elastic 本身支持向量搜索，可执行精确和近似的k-nearest neighbor (kNN) 搜索，还支持 NLP，可直接在 Elasticsearch 中使用自定义或第三方模型。

在这篇博文中，我们将探讨矢量搜索和 NLP 如何增强聊天机器人的能力，并演示 Elasticsearch 如何促进这一过程。首先，让我们简要介绍一下矢量搜索。

向量搜索

虽然人类可以理解书面语言的含义和上下文，但机器却无法做到这一点。这就是向量的作用所在。通过将文本转换为矢量表示（文本含义的数字表示），机器可以克服这一限制。与传统搜索相比，矢量不依赖于关键词和基于频率的词法搜索，而是使用为数值定义的运算来处理文本数据。

这样，通过使用"嵌入空间" 中的距离来表示给定查询向量的相似性，向量搜索就能定位具有相似概念或上下文的数据。当数据相似时，相应的向量也会相似。

矢量搜索不仅可用于 NLP 应用，还可用于涉及非结构化数据的其他各种领域，包括图像和视频处理。

在聊天机器人流程中，用户的查询可能有多种方式，因此，有不同的方法来改进信息检索，以获得更好的用户体验。由于每种方案都有自己的优点和可能的缺点，因此必须考虑到可用的数据和资源，以及训练时间（如适用）和预期的准确性。在下一节中，我们将介绍 NLP 问答模型的这些方面。

回答问题

问题解答（QA）模型是一种 NLP 模型，旨在回答用自然语言提出的问题。当用户提出的问题需要从多个资源中推断答案，而文档中又没有预先存在的目标答案时，生成式质量保证模型就能派上用场。不过，这些模型的计算成本可能很高，而且需要大量数据来进行与领域相关的训练，因此在某些情况下可能不太实用，尽管这种方法对处理域外问题特别有价值。

另一方面，当用户就特定主题提出问题，而实际答案就在文档中时，就可以使用提取式质量保证模型。这些模型直接从源文档中提取答案，提供透明、可验证的结果，对于希望提供简单高效的问题解答方式的企业或组织来说，是一种更实用的选择。

下面的示例演示了如何使用预先训练好的抽取式质量保证模型从给定上下文中抽取答案，该模型可在 Hugging Face 上获得，并已部署到 Elasticsearch 中：

部署训练有素的模型。

将模型添加到推理摄取管道中。

处理用户查询和检索信息的方法多种多样，在处理非结构化数据时，使用多种语言模型和数据源不失为一种有效的选择。为了说明这一点，我们以一个聊天机器人的数据处理为例，该聊天机器人会根据从选定文档中提取的数据来回答询问。

聊天机器人数据处理：NLP 和向量搜索

如上图所示，聊天机器人的数据处理可分为三个部分：

• 矢量处理：这部分将文档转换为矢量表示。

• 用户输入处理：这部分从用户查询中提取相关信息，并执行语义搜索和混合检索。

• 优化：这部分包括监控，对于确保聊天机器人的可靠性、最佳性能和良好的用户体验至关重要。

矢量处理

对于处理部分，第一步是确定每个文档的组成部分，然后将每个元素转换为矢量表示法；这些表示法可以为多种数据格式创建。

有多种方法可用于计算嵌入，包括预训练模型和库。

值得注意的是，在这些表征上进行搜索和检索的有效性取决于现有数据以及所用方法的质量和相关性。

在计算向量时，它们会以dense_vector字段类型存储在 Elasticsearch 中。

聊天机器人用户输入处理

对于用户来说，在收到问题后，最好先从中提取所有可能的信息，然后再继续提问。这有助于理解用户的意图，在这种情况下，我们使用命名实体识别模型（NER）来帮助理解用户的意图。NER 是将命名实体识别和分类为预定义实体类别的过程。

虽然这不是必要步骤，但通过使用结构化数据或上述或其他 NLP 模型结果对用户的查询进行分类，我们可以使用过滤器对 kNN 搜索进行限制。这有助于减少需要处理的数据量，从而提高性能和准确性。

语义搜索和混合检索

由于提示源于用户询问，而聊天机器人需要处理人类语言的多变性和模糊性，因此语义搜索非常适合。在 Elasticsearch 中，只要将查询字符串和嵌入模型的 ID 传递到 query_vector_builder 对象中，就能在一个步骤中执行语义搜索。这将对查询进行矢量化，并执行 kNN搜索，以检索与查询含义最接近的前 k 个匹配项：

端到端示例：如何部署文本嵌入模型并将其用于语义搜索。Elasticsearch 使用 Okapi BM25 的 Lucene 实现（一种稀疏模型）对文本查询进行相关性排序，而密集模型则用于语义搜索。为了综合矢量匹配和文本查询匹配的优势 ，可以执行混合检索：

将稀疏模型和密集模型相结合，往往能获得最佳结果

稀疏模型通常在简短查询和特定术语方面表现更佳，而密集模型则利用上下文和关联。如果您想进一步了解这些方法如何相互比较和互补，我们在此将 BM25 与两个经过专门检索训练的密集模型进行比较。

最相关的结果通常可能是给用户的第一个答案，分数是一个用来确定返回文档相关性的数字。

优化聊天机器人

为了帮助改善聊天机器人的用户体验、性能和可靠性，除了应用混合评分外，您还可以采用以下方法：情感分析：为了在对话过程中了解用户的评论和反应，您可以采用情感分析模型：

GPT 的功能 ：作为增强整体体验的另一种方法，您可以将 Elasticsearch 的搜索相关性与 OpenAI 的 GPT 问题解答功能相结合，利用聊天完成 API返回给用户由模型生成的回复，并将这些前 k 个文档作为上下文。提示："回答此问题<user_question> 仅使用此文档<top_search_result>"

可观察性：确保任何聊天机器人的性能都至关重要，而监控是实现这一目标的重要组成部分。除了记录聊天机器人的互动日志，跟踪响应时间、延迟和其他相关的聊天机器人指标也很重要。Elastic Observability工具使您能够收集和分析这些信息。

总结

这篇博文介绍了什么是 NLP 和矢量搜索，并举例说明了聊天机器人如何通过考虑从文档的矢量表示中提取的数据来回答用户的询问。

如图所示，利用 NLP 和矢量搜索，聊天机器人能够执行结构化、目标数据之外的复杂任务。这包括使用多种数据源和格式作为上下文进行推荐和回答特定产品或业务相关查询，同时提供个性化的用户体验。

使用案例包括提供客户服务，协助客户进行咨询；帮助开发人员进行查询，提供逐步指导，提出建议，甚至自动执行任务。根据目标和现有数据，还可以利用其他模型和方法来取得更好的效果，改善整体用户体验。

下面是一些关于该主题的链接，可能会对您有所帮助：

1. 如何部署自然语言处理 (NLP)：入门

2. Elasticsearch 中的图像相似性搜索概述

3. ChatGPT 和 Elasticsearch：OpenAI 与私人数据的结合

4. 使用 OpenTelemetry 和 Elastic 监测 OpenAI API 和 GPT 模型

5. IT 领导者需要矢量搜索来改善搜索体验的 5 个原因

通过在 Elasticsearch 中集成 NLP 和本地矢量搜索，您可以利用其速度、可扩展性和搜索功能来创建高效、有效的聊天机器人，从而能够处理大量结构化或非结构化数据。

准备好开始了吗？开始免费试用弹性云。

在本博文中，我们可能会使用或提及第三方生成式人工智能工具，这些工具由其各自所有者拥有和运营。Elastic对第三方工具没有任何控制权，我们对其内容、操作或使用不承担任何责任或义务，对您使用此类工具可能造成的任何损失或损害也不承担任何责任或义务。在使用人工智能工具处理个人、敏感或机密信息时，请务必谨慎。您提交的任何数据都可能用于人工智能培训或其他目的。我们不保证您所提供信息的安全性或保密性。在使用任何人工智能生成工具之前，您都应熟悉其隐私惯例和使用条款。

Elastic、Elasticsearch 和相关标记是 Elasticsearch N.V. 在美国和其他国家的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。

本篇文章主要介绍一种名为文本相似性搜索的特殊技术。在这类搜索中，用户输入一个简短的自由文本查询，然后根据文档与查询的相似度进行排序。文本相似性可用于多种用途：

• 问题解答：给定一系列常见问题，找出与用户输入的问题相似的问题。

• 文章搜索：在研究文章集中，返回标题与用户查询密切相关的文章。

• 图像搜索：在有标题的图片数据集中，查找标题与用户描述相似的图片。

相似性搜索的一种直接方法是根据文档与查询共享的单词数量进行排序。但是，即使一个文档与查询的共同点很少，它们也可能是相似的--一个更稳健的相似性概念应同时考虑其句法和语义内容。

自然语言处理（NLP）界开发了一种名为文本嵌入的技术，可将单词和句子编码为数字向量。这些向量表示旨在捕捉文本的语言内容，可用于评估查询和文档之间的相似性。

本文章将探讨如何利用文本嵌入和 Elasticsearch 的 dense_vector 类型来支持相似性搜索。我们将首先概述嵌入技术，然后使用 Elasticsearch 演示一个简单的相似性搜索原型。

什么是文本嵌入？

让我们仔细看看不同类型的文本嵌入，以及它们与传统搜索方法的比较。

词语嵌入

单词嵌入模型将单词表示为一个密集的数字向量。这些向量旨在捕捉词语的语义属性--向量相近的词语在语义上应该是相似的。在一个好的嵌入中，向量空间中的方向与词义的不同方面相关联。例如，"加拿大" 的向量可能在一个方向上接近"法国" ，在另一个方向上接近"多伦多" 。

一段时间以来，NLP 和搜索界一直对单词的向量表示法很感兴趣。在过去的几年里，人们对单词嵌入的兴趣再次升温，许多传统的任务都在使用神经网络进行重新研究。一些成功的词嵌入算法被开发出来，包括word2vec和GloVe。这些方法利用大量文本集合，并检查每个单词出现的上下文，以确定其向量表示：

• word2vec Skip-gram 模型训练一个神经网络，以预测句子中某个单词周围的上下文单词。网络的内部权重给出了单词嵌入。

• 在 GloVe 中，单词的相似度取决于它们与其他上下文单词出现的频率。该算法根据词的共现计数训练一个简单的线性模型。

许多研究小组分发的模型都是在维基百科或 Common Crawl 等大型文本语料库上预先训练过的，方便下载并用于下游任务。虽然有时会直接使用预训练版本，但调整模型以适应特定的目标数据集和任务可能会有所帮助。这通常是通过在预训练模型上运行 "微调 "步骤来实现的。

词嵌入已被证明是相当稳健和有效的，在机器翻译和情感分类等 NLP 任务中，使用词嵌入来代替单个词块已成为一种普遍做法。

句子嵌入

最近，研究人员开始关注不仅能表示单词，还能表示较长文本部分的嵌入技术。目前的大多数方法都基于复杂的神经网络架构，有时还会在训练过程中加入标记数据，以帮助捕捉语义信息。

训练完成后，这些模型就能处理一个句子，为上下文中的每个单词生成一个向量，并为整个句子生成一个向量。与词嵌入类似，许多模型都有预训练版本，用户可以跳过昂贵的训练过程。虽然训练过程可能非常耗费资源，但调用模型却要轻便得多--句子嵌入模型的速度通常很快，足以作为实时应用的一部分。

一些常见的句子嵌入技术包括InferSent、Universal Sentence Encoder、ELMo 和BERT。改进单词和句子嵌入是一个活跃的研究领域，很可能会引入更多强大的模型。

与传统搜索方法的比较

在传统的信息检索中，将文本表示为数字向量的常见方法是为词汇表中的每个单词分配一个维度。然后，根据词汇中每个术语出现的次数来确定文本的向量。这种表示文本的方式通常被称为"bag of words，" ，因为我们只计算单词出现次数，而不考虑句子结构。

文本嵌入在某些重要方面有别于传统的向量表示法：

• 编码矢量密度高，维数相对较低，通常在 100 到 1000 维之间。相比之下，词袋向量比较稀疏，可以包含 50,000 多个维度。作为语义建模的一部分，嵌入算法将文本编码到低维空间中。理想情况下，同义词和短语最终会在新的向量空间中得到相似的表示。

• 在确定向量表示时，句子嵌入可以考虑单词的顺序。例如，"tune in" 与"in tune" 可能会被映射为截然不同的向量。

• 实际上，句子嵌入通常不能很好地概括大段文本。它们通常不用于表示长度超过一小段的文本。

使用嵌入式进行相似性搜索

假设我们有一大堆问题和答案。用户可以提出一个问题，我们希望在问题集中检索出最相似的问题，以帮助他们找到答案。

我们可以使用文本嵌入来检索类似的问题：

• 在索引编制过程中，每个问题都会通过句子嵌入模型生成一个数字向量。

• 当用户输入一个查询时，它会通过相同的句子嵌入模型产生一个向量。为了对回复进行排序，我们计算每个问题与查询向量之间的向量相似度。在比较嵌入向量时，通常使用余弦相似度。

该版本库提供了一个简单的示例，说明如何在 Elasticsearch 中实现这一功能。主脚本从StackOverflow 数据集中索引约 20,000 个问题，然后允许用户针对数据集输入自由文本查询。

我们很快就会详细介绍脚本的各个部分，但首先让我们看看一些示例结果。在许多情况下，即使查询和索引问题之间没有很强的词语重叠，该方法也能捕捉到相似性：

• "压缩文件" 返回"压缩/解压缩文件夹& 文件"

• "确定某物是 IP" 返回"如何判断字符串是 IP 还是主机名"

• "将字节转换为双倍" 返回"在 Python 中将字节转换为浮点数"

实施细节

脚本首先在 TensorFlow 中下载并创建嵌入模型。我们选择了谷歌的通用句子编码器，但也可以使用许多其他嵌入方法。脚本按原样使用嵌入模型，无需额外的训练或微调。

接下来，我们创建 Elasticsearch 索引，其中包括问题标题、标签以及编码为向量的问题标题的映射：

在 dense_vector 的映射中，我们需要指定向量的维数。索引 title_vector 字段时，Elasticsearch 将检查该字段的维数是否与映射中指定的相同。

为编制文档索引，我们通过嵌入模型运行问题标题，以获得一个数字数组。该数组会添加到文档的 title_vector 字段中。

当用户输入查询时，文本会首先通过相同的嵌入模型运行，并存储在参数 query_vector 中。从 7.3 开始，Elasticsearch 在其本地脚本语言中提供了余弦相似度函数。因此，为了根据问题与用户查询的相似度对问题进行排序，我们使用了 script_score 查询：

我们确保将查询向量作为脚本参数传递，以 避免 在每次新查询时 重新编译 script()。由于 Elasticsearch 不允许负分，因此有必要在余弦相似度中加一个负分。

| 注：这篇博文最初使用了 Elasticsearch 7.3 中的另一种矢量函数语法，但在 7.6 中已被弃用。|

重要限制

script_score 查询旨在封装限制性查询，并修改其返回文档的分数。不过，我们提供了一个 match_all 查询，这意味着脚本将在索引中的所有文档上运行。这是目前 Elasticsearch 中向量相似性的一个限制--向量可用于为文档评分，但不能用于初始检索步骤。基于向量相似性的支持检索是当前工作的一个重要领域。

为了避免扫描所有文件并保持快速性能，可以用选择性更强的查询来代替 match_all 查询。用于检索的正确查询可能取决于具体的使用情况。

虽然我们在上面看到了一些令人鼓舞的例子，但重要的是要注意，结果也可能是嘈杂和不直观的。例如，"压缩文件" 也会给"部分 .csproj 分配高分文件" 和"如何避免使用 .pyc" 。而当方法返回令人惊讶的结果时，如何调试问题并不总是很清楚--每个矢量成分的含义往往是不透明的，与可解释的概念并不对应。使用基于词语重叠度的传统评分技术，通常更容易回答"为何该文档排名靠前？"

如前所述，该原型旨在举例说明如何将嵌入模型与矢量场结合使用，而不是一个可投入生产的解决方案。在制定新的搜索策略时，关键是要测试该方法在自己的数据中的表现，确保与匹配查询等强大的基线进行比较。在取得可靠结果之前，可能有必要对策略进行重大修改，包括针对目标数据集微调嵌入模型，或尝试不同的嵌入方法，如单词级查询扩展。

结论

嵌入技术是捕捉文本语言内容的有力方法。通过索引嵌入和基于向量距离的评分，我们可以使用超越词级重叠的相似性概念来比较文档。

我们期待着引入更多基于向量字段类型的功能。使用矢量进行搜索是一个细致入微、不断发展的领域--我们一如既往地希望在Github和讨论论坛上听到您的使用案例和经验！