我们如何构建 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 版本持续改进。当新的量化类型和硬件平台出现时，它们从第一天起就能获得经过调优的内核。而现有类型也会随着我们不断优化已发布的实现而持续变快。

正因如此，我们才构建了只读仪表板。这是您一直在要求的控制权。放心地共享仪表板，无需担心下一个拥有编辑权限的人会更改或破坏仪表板。

注意：只读权限在 Elastic Cloud Serverless 中可用，并且从 9.3 版本开始在 Elastic Cloud Hosted 和 Elastic Self-Managed 中可用。

当“人人皆可编辑”成为障碍时

在 Kibana 中，共享通常意味着空间层级的权限。如果有人可以在某个空间创建仪表板，他们也可以编辑或删除其他人的仪表板。这对协作来说原本是件好事，直到情况变得不妙。一次意外的编辑可能会导致错误的决策、失去信任和大量的清理工作。

我们听说过一些替代方案：“我们在仪表板名称中加上‘只读’，希望用户能注意到”。或者：“我们给它们贴上标签，然后祈祷好运。”希望并不是一种权限模型。您需要一种真正的方法来锁定仪表板，同时又不将所有人拒之门外。

到底出了什么问题

Deb 和 Kevin 都拥有对运营空间中的日志监控仪表板的编辑权限。Kevin 对图表进行了一些更改。当 Deb 回来后，发现数字与她之前提交的不符。她必须追溯哪些地方发生了变化（通常凭记忆），然后进行修正，还要弄清楚有多少份报告发出了错误数据。

只读仪表板：合理的所有权和控制权

只读仪表板可解决此问题，让您能够控制其他用户是否可以编辑该仪表板。共享仪表板时，您可以选择：编辑（默认，与当前相同）或查看。在查看模式下，只有你（和 Kibana 管理员）可以对其进行更改或删除。其他人可以打开它、使用它、信任它，但他们无法对其进行修改。

您将获得的内容

• 仪表板完整性：在查看模式下，该空间内具有编辑权限的其他用户无法修改或删除仪表板。如果他们尝试，会被告知仪表板已锁定。您的图表和逻辑将保持原样。

• 您掌控一切：你是所有者。您随时都可以编辑、完善和更新。以“仅查看”的方式共享并不会将您锁定，而是会锁定其他人看到的版本。

• 灵活的生命周期：您可以随时将仪表板切换回“可编辑”状态。Kibana 管理员仍然可以管理所有仪表板（例如，在仪表板所有者离开的情况下）。因此，不会出现无人管理的情况。

您可以广泛共享最终确定的关键任务仪表板，并确信这些仪表板将保持一致。所有 Elastic 层级和产品（包括 Serverless）均提供此功能。

谁能做什么？

按角色快速参考：

• 仪表板所有者：您创建了它；您拥有完全的编辑权限。

• Kibana 管理员：可以管理所有仪表板。

• 具有空间编辑权限的用户：可以创建和编辑自己的仪表板；但不能编辑或删除仅查看的仪表板。

• 具有空间视图的用户：只能查看（和列出）仪表板。

操作

仪表板所有者

Kibana 管理员

具有空间编辑权限的用户

具有空间视图的用户

列出并查看仪表板

✔

✔

✔

✔

创建新的仪表板

✔

✔

✔

✘

修改/删除可编辑的仪表板

✔

✔

✔

✘

修改/删除只读仪表板

✔

✔

✘

✘

如何启用只读

您可以在保存新仪表板时设置仅查看模式，也可以稍后从共享菜单中设置。

保存新仪表板时

• 创建您的仪表板，然后单击“保存”。

• 在“另存为新仪表板”模态框中，找到“权限”。

• 从“可编辑”更改为“可查看”。

• 单击“保存”。完成。它对其他所有人都是只读的。

对于您已拥有的仪表板

• 打开仪表板。

• 打开“共享仪表板”菜单。

• 在共享模式中，找到“权限”并切换到“可查看”。将立即应用更改；空间中的其他用户将无法再编辑或删除它。

• 您可以将鼠标悬停在“共享”操作上，查看给定仪表板拥有的权限类型。

查看哪些仪表板被锁定

在主仪表板列表中，无法编辑或删除的仪表板有一个禁用选择复选框。这为找出“仅查看”的内容提供了一种简便的方法。

在仪表板中，您还会发现“编辑”操作已禁用，并且会出现一个工具提示，说明仪表板已设置为“仅查看”。

试用

只读仪表板现已推出。创建仪表板，将其切换到“可查看”，然后共享。您的团队将获得单一可信来源，而您则高枕无忧。标题中不再包含“请勿编辑”字样。

我们很想听听您是如何使用只读仪表板的。在我们的社区论坛中分享您的反馈。

在 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 密集向量字段的自适应提前终止默认处于启用状态（最终可以通过相同的索引级别设置将其关闭）。

在为高并发工作负载调优 Elasticsearch 时，标准方法是最大限度地增加 RAM，将工作文档集保存在内存中，以实现低搜索延迟。因此，best_compression 很少被考虑用于搜索工作负载，因为它主要被视为 Elastic Observability 和 Elastic Security 用例中优先考虑存储效率的节省存储措施。

在本博客中，我们证明当数据集大小显著超出操作系统页面缓存时，best_compression通过减少 I/O 瓶颈来提升搜索性能和资源效率。

设置

我们的用例是一个运行在 Elastic Cloud CPU 优化实例上的高并发搜索应用程序。

• 数据量：约 5 亿份文档

• 基础架构：6 个 Elastic Cloud（Elasticsearch 服务）实例（每个实例：1.76 TB 存储 | 60 GB 内存 | 31.9 个 vCPU）

• 内存与存储比率：约 5% 的总数据集可存储在 RAM 中

症状：高延迟

我们观察到，当当前请求数在 19:00 左右激增时，搜索延迟显著恶化。如图 1 和图 2 所示，尽管每个 Elasticsearch 实例的流量峰值约为每分钟 400 个请求，但平均查询服务时间仍恶化至超过 60 毫秒。

在完成初始连接处理后，CPU 使用率保持相对较低，表明计算并非瓶颈。

查询量与页面错误之间出现了强相关性。随着请求增加，我们观察到页面错误比例上升，峰值约为每分钟 40 万次。这表明活跃数据集无法完全放入页面缓存。

同时，JVM 堆使用率也显示正常且平稳。这排除了垃圾回收问题，并确认瓶颈在于 I/O。

诊断：I/O 瓶颈

系统存在 I/O 瓶颈。Elasticsearch 依赖操作系统页面缓存从内存提供索引数据。当索引过大而无法放入缓存时，查询会触发开销很大的磁盘读取。虽然典型的解决方案是水平扩展（添加节点/RAM），但我们希望先充分利用现有资源的效率改进。

解决方案

默认情况下，Elasticsearch 对其索引段使用 LZ4 压缩，在速度和大小之间取得平衡。我们假设，改用 best_compression （使用 zstd）会减少索引的大小。更小的占用空间使得更大比例的索引能够放入页面缓存，以微不足道的 CPU 增加（用于解压缩）换取磁盘 I/O 的减少。

为了启用 best_compression，我们使用索引设置 index.codec: best_compression 重新索引了数据。或者，也可以通过关闭索引、将索引编解码器重置为 best_compression，然后进行段合并，也可实现相同的结果。

结果

结果证实了我们的假设：存储效率的提高直接转化为搜索性能的大幅提升，而 CPU 利用率并未相应增加。

应用 best_compression 后，索引大小减少了约 25%。虽然低于在重复日志数据中观察到的减少幅度，但这 25% 的减少实际上将我们的页面缓存容量提升了相同的比例。

在下一次负载测试期间（从 17:00 开始），流量甚至更高，每个 Elasticsearch 节点的请求峰值达到每分钟 500 次。

尽管负载更高，但 CPU 利用率仍低于上一次运行。先前测试中较高的使用率可能是由于过多的页面错误处理和磁盘 I/O 管理开销所致。

至关重要的是，页面错误显著下降。即使在更高的吞吐量下，错误次数也稳定维持在每分钟低于 20 万次，而基准测试中的错误次数则超过 30 万次。

尽管页面错误结果仍然不太理想，但查询服务时间却减少了约 50%，即使在负载更重的情况下也保持在 30 毫秒以下。

结论：为搜索启用 best_compression

对于搜索用例中数据量超过可用物理内存的情况，best_compression 是一个强大的性能调优工具。

应对缓存未命中的常规解决方案是通过扩展来增加 RAM。然而，通过减少索引占用空间，我们实现了相同的目标：最大化页面缓存中的文档数量。我们的下一步是探索索引排序，以进一步优化存储并从现有资源中获得更多性能。

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

转向系统性评估

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

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

这种方法的价值在于：

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

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

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

如何开始建立判断列表

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

示例：电影评分应用

准备工作

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

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

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

查询

DocID

文本

迪卡普里奥的表演

doc1

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

迪卡普里奥的表演

doc2

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

迪卡普里奥的表演

doc3

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

迪卡普里奥的表演

doc4

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

让人热泪盈眶的悲伤电影

doc5

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

让人热泪盈眶的悲伤电影

doc6

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

让人热泪盈眶的悲伤电影

doc7

让你捧腹大笑的轻松喜剧

让人热泪盈眶的悲伤电影

doc8

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

正在创建索引：

批量请求：

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

从判断到指标

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我们做到了！对不对？

没那么快！

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

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

使用判断列表的最终建议

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

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

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

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

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

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

什么是递归分块？

递归分块法会遍历所提供的分块模式列表，逐步将文档分成更小的分块，直到达到所需的最大分块大小。

如何配置递归分块？

以下是用户为递归分块提供的可配置值：

• (必填）max_chunk_size ：字块中的最大字数。

• 任选其一：

  • separators:用于将文档分割成块的 regex 字符串模式列表。

  • separator_group:一个字符串，它将映射到 Elastic 定义的默认分隔符列表，用于特定类型的文档。目前，markdown 和plaintext 。

递归分块是如何工作的？

递归分块的过程如下：给定输入文档、max_chunk_size （以字数为单位）和分隔符字符串列表：

1. 如果输入文档已经在最大分块大小范围内，则返回一个涵盖整个输入文档的分块。

2. 根据分隔符的出现次数，将文本分割成潜在的文本块。对于每个潜在的数据块

   1. 如果潜在数据块在最大数据块大小范围内，则将其添加到要返回给用户的数据块列表中。

   2. 否则，从第 2 步开始重复，只使用潜在文本块中的文本，并使用列表中的下一个分隔符进行分割。如果没有其他分隔符可以尝试，就退回到基于句子的分块。

配置递归分块的示例

除了分块大小，递归分块的主要配置是选择应使用哪些分隔符来分割文档。如果您不确定从哪里开始，Elasticsearch 提供了一些默认的分离器组，可用于常见的使用情况。

利用分离器组

要使用分隔组，只需在配置分块设置时提供要使用的组名即可。例如

这样就可以利用分隔符列表["(?<!\\n)\\n\\n(?!\\n)", "(?<!\\n)\\n(?!\\n)")] 来实现递归分块策略。对于一般的纯文本应用程序，这种方法效果很好，可以在 2 个换行符后再分隔出 1 个换行符。

我们还提供一个分隔符组markdown ，它将利用分隔符列表：

这个分隔符列表可以很好地适用于一般的标记符使用情况，在 6 个标题层次和分节符上分别进行分隔。

创建资源（推理端点/语义文本字段）时，与当时分隔符组相对应的分隔符列表将存储在您的配置中。如果以后更新了分隔符组，也不会改变已创建资源的行为。

使用自定义分隔符列表

如果预定义的分隔符组不适合您的使用情况，您可以定义一个符合您需求的自定义分隔符列表。请注意，可以在分隔符列表中提供正则表达式。以下是使用自定义分隔符配置分块设置的示例：

上述分块策略将在 2 个换行符、1 个换行符和一个字符串“<my-custom-separator>” 上进行分割。

递归分块的实际应用示例

让我们来看一个递归分块的实例。在本示例中，我们将使用以下分块设置和自定义分隔符列表，使用顶部两层标题分割标记符文档：

让我们来看看一个简单的未分块 Markdown 文档：

现在，让我们使用上面定义的分块设置对文档进行分块：

注意：每个分块（分块 3 除外）末尾的换行符不会突出显示，而是包含在实际分块边界内。

今天就开始使用递归分块技术！

有关使用该功能的更多信息，请查看有关配置分块设置的文档。

请阅读 " 利用 Elasticsearch 构建人工智能代理工作流 "博客 ，了解更多有关这项工作的 "全貌"，或阅读 " 你的第一个弹性代理" 博客 ，了解更多有关这项工作的实用入门知识 ：从单个查询到人工智能驱动的聊天 》，了解更多实用入门知识。

不过，在本博客中，我们将放大一些，看看当您开始聊天时最先发生的事情之一，并向您介绍我们最近做出的一些改进。

这里发生了什么？

当您与 Elasticsearch 数据聊天时，我们默认的人工智能代理会执行此标准流程：

1. 检查提示。

2. 确定哪个索引可能包含该提示的答案。

3. 根据提示为该索引生成查询。

4. 使用该查询搜索该索引。

5. 综合结果。

6. 结果能否解决提示问题？如果是，请回答。如果不行，就重复，但要尝试不同的方法。

这看起来并不新奇--它只是检索增强一代（RAG）。正如您所期望的那样，回复的质量在很大程度上取决于初始搜索结果的相关性。因此，在我们努力提高响应质量的过程中，我们一直在密切关注在第 3 步中生成和在第 4 步中运行的查询。我们注意到一个有趣的模式。

通常情况下，当我们的首次响应 "糟糕 "时，并不是因为我们运行了一个糟糕的查询。这是因为我们选错了要查询的索引。第 3 步和第 4 步通常不是我们的问题，问题在于第 2 步。

我们在做什么？

我们最初的实施很简单。我们建立了一个工具（名为 index_explorer），它可以有效地进行_cat/indices ，列出我们可用的所有索引，然后要求 LLM 识别这些索引中哪个最符合用户的信息/问题/提示。您可以 在这里 看到 最初的实施方案 。

效果如何？我们不确定！我们有一些效果不佳的明显例子，但我们真正面临的第一个挑战是如何量化我们的现状。

确定基线

从数据开始

我们需要的是一个 "黄金数据集"，用于衡量工具在用户提示和已有索引集的情况下选择正确索引的效率。而我们手头并没有这样的数据集，所以我们生成了一个。

致谢：我们知道，这不是 "最佳做法"。但有时，前进总比骑自行车好。进步，简单完美。

我们利用这一提示为多个不同领域生成了种子指数。然后，对于每个生成的域，我们使用 该提示又生成了几个索引（目的是用硬否定和难以分类的示例给 LLM 制造混乱）。接下来，我们手动编辑了每个生成的索引及其说明。最后，我们使用该提示生成了测试查询：

和测试用例，如

创建测试线束

从这里开始的过程非常简单。脚本工具可以

1. 使用目标 Elasticsearch 集群建立一片净土。

2. 创建目标数据集中定义的所有索引。

3. 针对每个测试场景，执行 index_explorer 工具（很方便，我们有一个执行工具 API）。

4. 将结果索引与预期索引进行比较，并捕捉结果。

5. 完成所有测试方案后，将结果制成表格。

调查说...

不出所料，最初的成果平平。

总体而言，77.14% 能准确识别正确的索引。这是在 "最好的情况 "下，即所有指数都有好的、语义上有意义的名称。使用过 `PUT test2/_doc/foo{...}` 的人都知道，索引的名称并不总是有意义的。

因此，我们有了一个基准线，而且它显示出很大的改进空间。现在是时候来点科学知识了！🧪

实验

假设 1：映射将有助于

这样做的目的是确定一个索引，其中包含与原始提示相关的数据。而索引中最能描述其所含数据的部分就是索引的映射。即使不抓取索引内容的任何样本，只要知道该索引有一个 double 类型的价格字段，就意味着该数据代表了要出售的东西。文本类型的作者字段意味着一些非结构化语言数据。两者合在一起可能意味着数据是书籍/故事/诗歌。通过了解索引的属性，我们可以获得很多语义线索。因此，我在本地分支中调整了 `.index_explorer工具，将索引的完整映射（连同索引名称）发送给 LLM，由 LLM 做出决定。

结果（来自 Kibana 日志）：

该工具的最初作者已经预见到了这一点。虽然索引映射是一座信息金矿，但它也是一个相当冗长的 JSON 数据块。而在实际情况中，您需要比较众多指数（我们的评估数据集定义了 20 个指数），这些 JSON blob 会不断增加。因此，我们希望为 LLM 的决策提供更多的背景信息，而不仅仅是所有选项的索引名称，但又不至于提供每个选项的完整映射。

假设 2："扁平化 "映射（字段列表）是一种折中方案

我们首先假设索引创建者会使用有语义的索引名称。如果我们将这一假设扩展到字段名呢？我们之前的实验之所以失败，是因为 JSON 映射包含了大量繁琐的元数据和模板。

例如，上面的代码块有 236 个字符，只定义了 Elasticsearch 映射中的一个字段。而字符串 "description_text "只有 16 个字符。字符数几乎增加了 15 倍，但在描述该字段对可用数据的含义方面却没有任何有意义的改进。如果我们要获取所有索引的映射，但在将其发送到 LLM 之前，将其 "扁平化 "为字段名列表，会怎么样？

我们试了一下。

这太棒了！全面改进。但我们能做得更好吗？

假设 3：映射 _meta 中的描述

如果仅仅是字段名而没有额外的上下文就能带来如此大的跳跃，那么增加大量的上下文可能会更好！每个索引都附加描述并不一定是常规做法，但可以在映射的 _meta 对象中添加任何类型的索引级元数据。我们回到生成的索引，为数据集中的每个索引添加说明。只要描述不是太长，就应该比完整映射使用更少的标记，并能更好地说明索引中包含了哪些数据。我们的实验验证了这一假设。

稍有改进，我们现在的>90% 准确度全面提高。

假设 4：总和大于部分

字段名增加了我们的成果。说明增加了我们的成果。因此，同时 使用描述和字段名称应该会得到更好的结果，对吗？

数据显示 "否"（与上次实验相比没有变化）。这里的主要理论是，由于描述是从索引字段/映射开始生成的，这两个上下文之间没有足够的不同信息，因此在将它们组合在一起时无助于添加任何 "新 "信息。此外，我们为 20 个测试指数发送的有效载荷越来越大。我们迄今为止所遵循的思路是无法扩展的。事实上，我们有充分的理由相信，在有成百上千个索引可供选择的 Elasticsearch 集群上，我们迄今为止进行的所有实验都不会奏效。任何随着索引总数的增加而线性增加发送到 LLM 的信息量的方法，可能都不是通用的策略。

我们真正需要的是一种方法，它能帮助我们从众多候选人中筛选出最相关的选项...

这就是一个搜索问题。

假设 5：通过语义搜索进行选择

如果一个索引的名称具有语义意义，那么它就可以存储为一个向量，并进行语义搜索。

如果索引的字段名具有语义意义，那么就可以将其存储为向量，并进行语义搜索。

如果一个索引有一个具有语义意义的描述，那么它也可以存储为一个向量，并进行语义搜索。

如今，Elasticsearch 索引并不能搜索到这些信息（也许我们应该这样做！），但要想解决这个问题却非常容易 。利用 Elastic 的连接器框架，我构建了一个连接器，可以为集群中的每个索引输出文档。输出文件将类似于

我将这些文件发送到一个新的索引，并在其中手动定义了映射：

这样就创建了一个单一的 semantic_content 字段，其他所有具有语义意义的字段都会被分块并编入索引。搜索该索引变得非常简单，只需.....：

修改后的index_explorer 工具现在速度更快，因为它不需要向 LLM 提出请求，而是可以为给定的查询请求单个嵌入，并执行高效的向量搜索操作。以最高点击率为选定索引，我们得到的结果是

这种方法具有可扩展性。这种方法效率很高。但这种方法比我们的基准线好不了多少。但这并不奇怪，因为这里的搜索方法太天真了。没有任何细微差别。不承认索引的名称和描述应比索引包含的任意字段名称更有分量。没有加权精确词性匹配而非同义匹配的功能。不过，要建立一个高度细致的查询，需要对手头的数据进行大量假设。到目前为止，我们已经对索引和字段名称的语义做了一些大的假设，但我们还需要更进一步，开始假设它们有多大的意义以及它们之间的关系。如果不这样做，我们可能无法可靠地将最佳匹配结果确定为我们的首要结果，但更有可能说最佳匹配结果就在前 N 个结果中的某个地方。我们需要的是一种能够在语义信息存在的语境中消费语义信息的东西，它可以与另一个可能以不同语义方式表示自己的实体进行比较，并在两者之间做出判断。比如法学硕士。

假设 6：候选集减少

还有很多实验我就不一一列举了，但关键的突破是放弃了纯粹从语义搜索中挑选最佳匹配项的愿望，转而利用语义搜索作为过滤器，从 LLM 的考虑范围中剔除不相关的索引。我们将线性检索、混合检索与 RRF 以及semantic_text 结合起来进行检索，将结果限制在匹配指数的前 5 位。

然后，对于每个匹配项，我们都将索引名称、描述和字段名称添加到 LLM 的信息中。结果非常好：

这是迄今为止精度最高的实验！由于这种方法不会使信息大小与索引总数成正比，因此这种方法的可扩展性要好得多。

成果

第一个明确的结果是，我们的基线可以改进。现在回想起来，这一点似乎显而易见，但在实验开始之前，我们曾认真讨论过是否应该完全放弃index_explorer 工具，而依靠用户的明确配置来限制搜索空间。虽然这仍然是一个可行且有效的选择，但这项研究表明，在无法获得此类用户输入的情况下，实现索引选择自动化的道路大有可为。

下一个明确的结果是，一味地增加描述性文字的数量，其回报率会越来越低。在这项研究之前，我们一直在讨论是否应该投资扩展 Elasticsearch 存储字段级元数据的能力。如今，这些meta 值的上限是 50 个字符，而且有一种假设认为，我们需要增加这个值，以便能够从语义上理解我们的字段。但情况显然不是这样，法律硕士似乎只需填写字段名称就可以了。我们以后可能会进一步调查这个问题，但现在已经没有紧迫感了。

相反，这也清楚地证明了 "可搜索 "索引元数据的重要性。在这些实验中，我们破解了指数的索引。但是，我们可以研究将其直接构建到 Elasticsearch 中，构建应用程序接口来进行管理，或者至少围绕其建立一个惯例。我们将权衡各种选择并进行内部讨论，敬请期待。

最后，这项工作证实了我们花时间进行试验和做出数据驱动决策的价值。事实上，它帮助我们再次确认，我们的代理生成器产品需要一些强大的产品内评估功能。如果我们需要专门为一个选取指数的工具构建整个测试线束，那么我们的客户绝对需要在进行迭代调整时对其定制工具进行定性评估的方法。

我很期待看到我们的成果，希望你们也是！

想象一下，一位财务经理需要在与客户会面之前加快速度。现在，他们只需向定制的代理直接提问，而无需手动挖掘新闻源和交叉参考投资组合仪表板。这就是"聊天优先" 方法的好处。经理与他们的数据直接对话，询问诸如"ACME 公司的最新消息是什么，它对我客户的持股有何影响？"并在几秒钟内得到综合的专家答复。

今天，我们正在打造一个金融专家，其应用就像您的数据一样多种多样。同样的能力可以造就一名网络安全分析师来寻找威胁，造就一名现场可靠性工程师来诊断故障，或者造就一名营销经理来优化营销活动。无论在哪个领域，核心任务都是一样的：将您的数据转化为您可以与之交谈的专家。

步骤 0：我们的数据集

我们当前的数据集是一个基于金融的合成数据集，包含金融账户、资产头寸、新闻和财务报告。虽然它是合成的，但复制了真实金融数据集的简化版本。

financial_accounts:具有风险特征的客户组合

financial_holdings:有购买记录的股票/ETF/债券仓位

financial_asset_details:股票/ETF/债券的详细信息

financial_news:人工智能生成的带有情感分析的市场文章

financial_reports:公司收益和分析师报告

您可以根据此处的随附笔记本自行加载该数据集。

步骤 1：基础--作为 ES|QL 的业务逻辑

每一项人工智能技能都以坚实的逻辑为起点。对于我们的财务经理代理，我们需要教它如何回答一个常见问题："我担心市场情绪。你能告诉我哪些客户最容易受到坏消息的影响吗？这个问题超出了简单的搜索范围。这要求我们将市场情绪与客户投资组合联系起来。

我们需要找到负面文章中提到的资产，识别持有这些资产的每一位客户，计算其风险敞口的当前市值，然后对结果进行排序，优先考虑风险最高的客户。这种复杂的多连接分析是我们先进的 ES|QL 工具的完美工作。

下面是我们要使用的完整查询。它看起来令人印象深刻，但概念却简单明了。

分解：接合点和护栏

在这个查询中，有两个重要的概念使代理生成器发挥作用。

1.查找联接

多年来，Elasticsearch 最受欢迎的功能之一就是根据一个共同的键来连接来自不同索引的数据。有了 ES|QL，LOOKUP JOIN 。

在我们的新查询中，我们会执行一连串的三个LOOKUP JOIN's：首先将负面新闻与资产详细信息连接起来，然后将这些资产与客户持有的资产连接起来，最后再与客户的账户信息连接起来。这样，在一次高效的查询中，就能从四个不同的索引中获得极其丰富的结果。这意味着我们可以将不同的数据集结合起来，创建一个具有洞察力的单一答案，而无需事先将所有数据反规范化为一个巨大的索引。

2.作为 LLM 护栏的参数

您会发现查询使用了?time_duration 。这不仅是一个变量，还是人工智能的护栏。虽然大型语言模型 (LLM) 是生成查询的好帮手，但让它们自由支配数据可能会导致查询效率低下甚至错误。

通过创建参数化查询，我们迫使 LLM 按照人类专家已经定义的经过测试、高效且正确的业务逻辑工作。这与多年来开发人员使用搜索模板安全地向应用程序公开查询功能的方式类似。代理可以解释用户的请求，如"this week" 来填充time_duration 参数，但它必须使用我们的查询结构来获取答案。这使我们在灵活性和控制性之间取得了完美的平衡。

最终，这种查询可以让了解数据的专家将其知识封装到一个工具中。其他人和人工智能代理只需提供一个参数，就能使用该工具获得相关结果，而无需了解底层的复杂性。

步骤 2：技能--将查询转化为可重复使用的工具

在我们将 ES|QL 查询注册为工具之前，它只是一个文本。在代理生成器中，工具不仅仅是一个已保存的查询；它还是一个"技能" ，人工智能代理可以理解并选择使用。神奇之处在于我们提供的自然语言描述。该描述是连接用户问题和底层查询逻辑的桥梁。让我们注册一下刚刚创建的查询。

用户界面路径

在 Kibana 中创建工具的过程非常简单。

1.导航至代理

• 单击 " 工具 "或 "管理工具"，然后单击 "新建工具"按钮。

2.在表格中填写以下详细信息：

• 工具 ID： find_client_exposure_to_negative_news

i.这是工具的唯一 ID

• 描述 "查找客户投资组合受负面新闻影响的情况。该工具会扫描最近的新闻和报道，查找负面情绪，识别相关资产，并找到持有该资产的所有客户。它会返回一个按头寸当前市值排序的列表，以突出潜在风险最高的头寸。"

i.法律硕士就是通过阅读这些内容来判断这个工具是否适合这项工作。

• 标签：retrieval 和 risk-analysis

标签用于帮助对多个工具进行分组

• 配置：粘贴步骤 1 中的完整 ES|QL 查询

i.这是代理将使用的搜索

3.单击从查询中推断参数。用户界面会自动查找?time_duration ，并将其列在下面。为每项功能添加一个简单的说明，以帮助代理（和其他用户）了解其用途。

• time_duration:搜索负面新闻的时间范围。格式为"X 小时" 默认为 8760 小时

4.测试一下！

• 单击保存& 测试。

• 您将看到一个新的快捷方式，可以在此测试查询，以确保其工作符合预期。

i.在time_duration 中输入所需的范围，这里我们使用 "8760 小时"。

• 点击 "提交"，如果一切顺利，您将看到一个 JSON 响应。要确保它按预期运行，请向下滚动并查看values 对象。这就是返回实际匹配文档的地方。

5.点击右上角的 "X "关闭测试窗口。现在，您的新工具将出现在列表中，随时可以分配给代理。

应用程序接口路径

对于喜欢自动化或需要以编程方式管理工具的开发人员来说，只需调用一个 API 就能实现同样的效果。只需向带有工具定义的/api/agent_builder/tools 端点发送POST 请求即可。

步骤 3：大脑--创建您的定制代理

我们开发了一种可重复使用的技能（工具）。现在，我们需要创建代理，即实际使用它的角色。代理是一个 LLM 的组合，是你授予它访问权限的一套特定工具，最重要的是，它还包含一套自定义指令，作为它的章程，定义了它的个性、规则和目的。

提示的艺术

要创建一个可靠的专业代理，最重要的一点就是要及时。一套精心设计的指令是普通聊天机器人与专注、专业的助手之间的区别所在。在这里，你可以设置防护栏、定义输出并赋予代理任务。

对于Financial Manager 代理，我们将使用以下提示。

让我们来分析一下为什么这个提示如此有效：

• 它定义了一个成熟的角色： 第一句话立即将代理人定位为"专业的数据智能助理，" 定下了专业、干练的基调。

• 它提供了一个推理框架： 通过告诉代理"Understand（理解）、Plan（计划）、Execute（执行）和 Synthesize（综合），" ，我们给了它一个标准的操作程序。这提高了它处理复杂、多步骤问题的能力。

• 它促进了互动对话： "提出澄清性问题的指令" 使代理更加稳健。这将最大限度地减少对模棱两可的请求做出不正确的假设，从而获得更准确的答复。

用户界面路径

1.导航至代理。

• 单击 " 工具 "或 "管理工具"，然后单击 "新建工具"按钮。

2.填写基本信息：

• 代理编号： financial_assistant.

• 说明 复制上面的提示。

• 标签 Finance.

• 显示名称： Financial Assistant 。

• 显示说明： An assistant for analyzing and understanding your financial data 。

3.回到顶部，点击 "工具"。

• 勾选find_client_exposure_to_negative_news 工具旁边的复选框。

4.单击保存。

应用程序接口路径

您可以通过POST 请求/api/agent_builder/agents 端点来创建完全相同的代理。请求正文包含所有相同的信息：ID、名称、描述、全套指令以及允许代理使用的工具列表。

步骤 4：回报--进行对话

我们已将业务逻辑封装在一个工具和一个"大脑" 中，准备在我们的 Agent 中使用它。是时候见证这一切了。现在，我们可以使用专门的代理与数据聊天了。

用户界面路径

1. 导航至 Kibana 中的代理 。

2. 使用聊天窗口右下角的下拉菜单，从默认的Elastic AI 代理切换到我们新创建的财务助理 代理。

3. 请提出一个问题，以便代理人使用我们的专业工具：

   1. 我担心市场情绪。您能告诉我哪些客户最容易受到坏消息的影响吗？

片刻之后，代理将返回一个格式完美、内容完整的答案。由于法律硕士的性质，您的答案格式可能会略有不同，但这次运行中，代理返回的答案是一样的：

刚刚发生了什么？代理人的推理

该特工并不只是"知道" 答案。它以选择最佳工具为中心，执行了一个多步骤计划。下面我们来看看它的思考过程：

• 识别意图：它将您问题中的关键字，如"风险" 和"负面新闻、" 与find_client_exposure_to_negative_news 工具的描述相匹配。

• 执行计划：它从您的请求中提取了时间范围，并对该专业工具进行了一次调用。

• 委托工作：然后，该工具就能完成所有繁重的工作：链式连接、值计算和排序。

• 合成结果：最后，代理按照提示规则，将来自工具的原始数据格式化为清晰、人类可读的摘要。

如果我们拓展思维，看到更多细节，我们就不只是猜测了。

应用程序接口路径

您也可以通过编程来启动同样的对话。只需将输入问题发送到converse API 端点，确保指定我们的financial_manager 的agent_id 。

致开发人员：与应用程序接口集成

虽然 Kibana UI 为构建和管理代理提供了美妙而直观的体验，但您今天所看到的一切也都可以通过编程来实现。代理生成器基于一套应用程序接口（API）构建，允许您将此功能直接集成到自己的应用程序、CI/CD 管道或自动化脚本中。

您将使用的三个核心端点是

• /api/agent_builder/tools:创建、列出和管理可重复使用的技能的终端。

• /api/agent_builder/agents:角色：定义代理角色的终端，包括重要的说明和工具分配。

• /api/agent_builder/converse:与代理互动、开始对话和获取答案的终端。

有关使用这些应用程序接口执行本教程中每一步的完整实践演示，请查看我们 GitHub 软件仓库中的配套Jupyter Notebook 。

总结：轮到你来建设

我们首先使用 ES|QL 查询，并将其转换为可重复使用的技能。然后，我们建立了一个专门的人工智能代理，赋予它明确的任务和规则，并赋予它这种技能。它是一个复杂的助手，能够理解复杂的问题，并执行多步骤分析，提供精确的数据驱动型答案。

这一工作流程是 Elastic 中新的代理生成器的核心。它的设计足够简单，非技术用户可以通过用户界面创建代理，但又足够细致，开发人员可以在我们的应用程序接口基础上构建定制的人工智能驱动应用程序。最重要的是，它可以让您安全可靠地将 LLM 连接到自己的数据，由您定义的专家逻辑进行管理，并与您的数据进行聊天。

准备好使用代理与您的数据聊天了吗？

巩固所学知识的最好方法就是动手实践。在我们的免费互动实践研讨会上，尝试我们今天讨论的所有内容。您将在专门的沙盒环境中经历整个流程以及更多。

在今后的博客中，我们将向您展示如何使用独立应用程序与我们的Financial Assistant 代理交互，并深入探讨使这一切成为可能的模型上下文协议 (MCP)。在另一篇博客中，我们将讨论 Agent Builder 对开发中的 Agent2Agent（或 A2A）协议的支持。

敬请期待，祝您建筑愉快！

代理生成器：构建数据驱动型人工智能代理的基础

人工智能代理的承诺很简单：给它一个目标，它就能完成工作。但对于开发商来说，现实却是一系列复杂的挑战。首先，代理的能力取决于其对环境的感知以及为实现用户目标而提供的工具。那么，如何从纷繁复杂的企业数据中提供正确的上下文是一项巨大的挑战。最后，所有这一切都必须由一个可靠的推理循环来协调，该循环可以进行规划、执行和学习。

为了解决这个问题，开发人员需要从头开始构建一个复杂而脆弱的堆栈。如今的代理架构需要将多个不同的部分拼接在一起：一个 LLM、一个向量数据库、一个元数据存储、用于日志记录和跟踪的独立系统，以及一些评估它们是否都能正常工作的方法。这不仅复杂，而且成本高昂、容易出错，并且难以建立用户所需的高质量、值得信赖的人工智能系统。

因此，我们想让它变得更简单。为此，我们的方法是将有效的上下文驱动型代理的重要部分直接集成到 Elasticsearch 的核心中，并提供一套名为Elastic AI Agent Builder 的新功能。这一新层提供了一个框架，其中包含创建由 Elasticsearch 支持的人工智能代理所需的所有基本构件：一套开放的基元、基于标准的协议和对数据的安全访问--因此您可以根据真实世界的数据和要求构建代理系统：

提供人工智能体验：这是终极目标。以我们的搜索人工智能平台和您的数据为基础，您可以构建任何类型的生成式人工智能应用程序：从定制聊天界面到与 LangChain 等代理框架或 Salesforce 等业务应用程序的集成。

由 Agents& 工具提供支持：在平台之上，我们提供了一个简洁的抽象层。您可以直接与代理和工具互动，并根据具体需求进行定制。您还可以通过强大的应用程序接口和开放标准（如 MCP 和 A2A）访问平台的功能。

由搜索人工智能平台支持：这是我们集成了各种组件的核心引擎。先进的矢量数据库、代理逻辑、查询结构、安全功能、评估跟踪都在这里，由 Elastic 管理和优化。

释放数据的力量：任何优秀代理商的基础都是优秀的数据。我们的平台首先能够摄取或联合访问您的所有企业数据

平台中的代理建设

Agent Builder 集成到搜索人工智能平台中，为代理开发提供了一个完整的框架。它建立在五个关键支柱之上，每个支柱都旨在解决构建和部署生产级人工智能系统的一个关键方面。让我们来分析一下，代理如何定义目标，工具如何提供功能，开放标准如何确保互操作性，评估如何提供透明度，安全如何提供信任。

代理商

代理是 Elasticsearch 这一新层中最高级别的构建模块。代理定义了要实现的目标、可用于执行的工具集以及可操作的数据源。代理并不局限于对话式交互，它们还可以支持完整的工作流、任务自动化或面向用户的体验。

当一项查询被提交给代理机构时，它遵循一个结构化的循环：

1. 解释您的意见和目标

2. 选择正确的执行工具和参数

3. 工具响应的原因

4. 决定是返回结果还是继续进一步调用工具

Elastic 负责这一循环的协调、上下文和执行。开发人员专注于定义代理应该做什么：目标、工具和数据，而系统则管理如何进行推理和执行工作流程。

默认代理

我们在该平台上构建的第一个代理是 Kibana 中的原生会话代理，让您能够立即与数据进行交互。它在提供即用体验的同时，还具有完全的可扩展性，无需额外配置即可立即开始与数据交互。

您可以直接在 Kibana 中通过新的聊天用户体验或通过 API 与此体验进行交互。

通过 API 查询默认代理只需一次调用：

由于会话是有状态的，因此您可以使用会话 ID 继续与代理交互，或检索完整的会话历史记录：

海关代理

开发人员还可以通过简单的应用程序接口创建自己的定制代理。代理封装了指令、工具和数据访问，创建了量身定制的推理引擎。

创建自定义代理只需调用一次应用程序接口。下面的示例显示了一个例子，"配置 "字段包含所有关键细节，如说明或可用工具：

一旦创建，就可以直接查询代理：

这种方法将代理从一个需要从头开始构建的复杂系统转变为一个简单、声明式的业务逻辑单元，使您能够更快地交付智能自动化。

如需深入了解如何从头开始构建专门的代理，请参阅我们的详细分步指南：您的第一个弹性代理：从单一查询到人工智能驱动的聊天。

工具

如果说代理确定了要完成的任务，那么工具则确定了如何完成。

工具为代理执行和检索信息或执行操作暴露了特定的弹性核心功能。工具可以包括获取索引或获取映射等核心功能，也可以包括从自然语言到 ES|QL 等更高级的功能。

Elasticsearch 随附一套针对常见需求进行了优化的默认工具。但真正的灵活性来自于自己的创造。通过定义工具，您可以决定将哪些查询、索引和字段通过 ES|QL 暴露给代理，从而对速度、准确性和安全性进行精确控制。

注册新工具也很简单，只需调用一次应用程序接口。您可以创建一个工具，利用我们的ES|QL（Elasticsearch 查询语言）查找特定金融资产的相关新闻：

注册后，您就可以将新工具分配给您的自定义代理，为他们提供一套经过精心设计的能力，让他们在合适的时候进行推理和调用。

我们提供了一个平台，可根据您的特定需求创建定制工具，例如使用 ES|QL，将代理从通用代理转变为特定领域的专家，立足于您独特的数据和业务领域。

开放标准和互操作性

Elasticsearch 代理和工具通过开放式标准 API 公开，因此很容易作为基础模块集成到更广泛的代理框架生态系统中。我们的方法很简单：没有黑盒子。我们希望您能够利用 Elastic 在搜索方面的核心优势，并将其与互补功能和其他代理系统搭配使用。

为了实现这一点，我们正在通过应用程序接口、新兴协议和开放标准公开我们的能力。

模型上下文协议（MCP）

模型上下文协议（MCP）正迅速成为跨系统连接工具的开放标准。通过支持 MCP，Elasticsearch 可以将对话式人工智能与您的数据库、索引和外部 API 相连接。通过 Elastic Stack 内置的远程 MCP 服务器，任何兼容 MCP 的客户端都可以访问 Elastic 的工具，并将其用作大型代理工作流程的构建模块。

这不是一条单行道。您还可以从外部 MCP 服务器导入工具，使其在 Elasticsearch 中可用。不久之后，MCP 服务器将可能适用于几乎所有功能，而且比我们自己创建的任何功能都要全面得多。Elastic 提供大规模的搜索和检索功能，您可以将其与其他平台的专业功能相结合，构建有效的代理。

代理对代理（A2A）

我们还在努力提供代理对代理 (A2A) 支持。MCP 是连接工具，而 A2A 则是连接代理。有了 A2A 服务器，您构建的 Elastic 代理就能与其他系统的代理直接对话：共享上下文、委派任务和协调工作流。

将其视为推理层的互操作性。您的弹性代理可以处理搜索和检索，然后将任务交给专门的支持或 IT 代理，并无缝地返回结果。这样就形成了一个由合作代理组成的生态系统，每个代理都在做自己最擅长的事情。

最终，采用 MCP 和 A2A 加强了我们对 Elasticsearch 作为一流公民角色的承诺，确保在更广泛的代理生态系统中实现开放式集成。

追踪和评估

随着搜索与代理的整合，有效评估的挑战变得至关重要。要在真实的企业环境中自信地部署代理，就必须确保代理不仅准确，而且高效可靠。如何衡量性能、诊断不良响应或改进基线？一切从可见度开始。

因此，我们从一开始就设计了透明的代理 API。考虑一下这个简单的代理互动：

回复不仅包括最终答案，还包括完整的执行跟踪，详细说明代理选择了哪些工具、使用了哪些参数以及每一步的结果。

全面的跟踪和日志记录对持续改进循环至关重要，不久之后，您就可以直接在 Elasticsearch 中存储和查看这些代理跟踪。更妙的是，这些跟踪记录是基于 OpenTelemetry 协议构建的，确保了它们的标准化和可移植性，以便与您选择的可观测性平台集成。

这种详细程度是真正持续改进循环的基础。它使您能够建立一套全面的测试、调试故障、识别失败模式以防止回归，并捕捉成功模式以微调性能。归根结底，这种数据驱动的方法是将有前途的原型转化为生产级、值得信赖的人工智能系统的关键。

安全性

随着代理和工具的功能越来越强大，安全性不再是可有可无的，而是基础性的。要公开应用程序接口、自动执行任务和工作流程，就必须信任企业系统。特别是当代理开始自动执行更多的工作流程时，确保这些流程安全并满足企业要求的能力就显得尤为重要。

上述功能都继承了 Elastic 目前已有的控制功能，包括针对 API 调用和 API 密钥管理的基于角色的访问控制 (RBAC)。我们还将同样的控制扩展到 MCP 等新协议。这意味着支持 OAuth 等标准，以及插入自定义身份验证机制的能力。

我们的目标是让您灵活地尝试使用代理和工具，同时保持组织所需的安全性、合规性和管理水平。

下一步行动

我们不仅要增加功能，还要扩展 Elasticsearch 的代理上下文工程。我们计划在这些原则的基础上继续发展：

1.致力于开放源码& 标准

我们致力于开放源代码和开放标准，确保这些功能与外部代理框架保持互操作性。您始终能够在生态系统中连接、扩展和组成代理，同时将数据和工作流程置于您的控制之下。

2.背景的价值

人工智能代理的背景是其最大的资产。在代理执行搜索和工作流操作时管理上下文是一项极具挑战性的任务。我们正在利用 Elastic 的核心优势来解决上下文工程问题，确保您的代理始终可以获得最相关的信息。

3.关注代理数据流

展望未来，代理将成为越来越大的数据源，包括代理的输出（生成的文档、报告、可视化）和代理的执行轨迹（其思维、工具调用、内存/上下文）。Elastic 非常适合处理此类数据，我们正在研究如何利用这些数据进行分析、评估和自动改进。

4.设计的安保和安全

人工智能代理带来了全新的安全保障挑战。Elastic 一直是安全解决方案的领导者，我们将继续构建企业级防护、访问控制和"零信任" 原则。

5.嵌入平台

构建人工智能代理的功能已嵌入 Elasticsearch 平台。这意味着平台级功能，如跟踪、评估、可视化和分析，都适用于代理。希望根据代理执行情况开发仪表板--这是内置功能。希望通过情感分析来评估人工智能代理的性能--该平台可以实现这一点。这样就能围绕人工智能体验构建一个完整的生命周期。

Elastic 的目标是为您提供建立对话式人工智能和自动化工作流程的接口，这些接口完全集成、可扩展并以您的数据为基础。更多技术细节和进展情况将很快与大家分享。

代理生成器 "现已推出私人预览版。与我们联系，申请访问。有问题或反馈？在我们的Slack 工作区或讨论区与我们的开发人员社区联系。

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

为什么要过滤？

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

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

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

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

这正是 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 个结果，因为在应用过滤器时，这些结果可能已被过滤器过滤。

快乐过滤