当前位置：首页 > news >正文

在 Elasticsearch 中，存储向量查询速度最高提升 3 倍

news 2026/5/22 7:39:36

作者：来自 Elastic Benjamin Trent

Elasticsearch 9.4 提供了一种更简单的方式来搜索存储在 Elasticsearch 索引中的向量，并将延迟最高降低 3 倍。

从向量搜索到强大的 REST API，Elasticsearch 为开发者提供了最全面的搜索工具集。深入体验 Elasticsearch Labs 仓库中的示例 notebooks，尝试一些新功能。你也可以立即开始免费试用，或者在本地运行 Elasticsearch。

过去，在 Elasticsearch 中查找与某个已存储向量相似的文档需要两次往返请求：先使用 GET 获取向量，然后在 k 最近邻（ kNN ）查询中将该向量发送回去。Elasticsearch 9.4 通过 query_vector_builder.lookup 将这一流程合并为一次请求，从而简化了 API，并在双节点 Google Cloud Platform（ GCP ）基准测试中将延迟最高降低 3 倍。

为什么存储向量搜索过去需要两次请求

此前，当你想查找与某个已存储向量相似的文档时，你需要：

调用 GET 从 Elasticsearch 获取向量值。
调用 _search，并在 Elasticsearch 中引用该向量值：
- 通过 JSON 序列化该向量值。

这意味着需要两次承担序列化和网络成本：

两次请求中的向量序列化与反序列化成本。
双向网络延迟成本。
云部署中的潜在出口流量成本。

在 Python 中，这种模式会是：

from elasticsearch import Elasticsearch es = Elasticsearch(HOST) # 1) Fetch the seed vector from Elasticsearch seed_doc = es.get( index=source_index, id=seed_id, _source_includes=[vector_field], ) query_vector = seed_doc["_source"][vector_field] # 2) Send it back in a kNN query resp = es.search( index=target_index, query={ "knn": { "field": vector_field, "k": 10, "num_candidates": 100, "query_vector": query_vector, } }, )

虽然这两次调用看起来开销不大，但这些额外成本其实没有必要。让我们把它变得更好。

Elasticsearch 9.4 中 query_vector_builder.lookup 的工作原理

在 Elasticsearch 9.4 中，我们新增了 lookup，以简化 API 并消除不必要的成本：

from elasticsearch import Elasticsearch es = Elasticsearch(HOST) resp = es.search( index="products", query={ "knn": { "field": "product-vector", "k": 10, "num_candidates": 100, "query_vector_builder": { "lookup": { "index": "seed-products", "id": "product-123", "path": "product-vector" } }, } }, )

现在，此请求会获取存储在 product-vector 字段中的 dense_vector 值，该值位于 seed-products 索引中 ID 为 product-123 的文档里。这个示例是一个 “more like this” 搜索，用于查找与 ID 为 product-123 的向量最接近的向量。你可以引用任何索引，从而有效地将 lookup 用作查询向量存储。

lookup 向量搜索能够减少多少延迟

我们的目标是简化使用体验并提升速度。性能提升不仅来自于消除客户端往返请求。许多 Elasticsearch 实例都涉及多个节点，而节点之间的流量本身也会带来序列化和网络成本。Elasticsearch 会主动将执行偏向本地节点，这也减少了服务器端的网络序列化成本。

为了展示潜在的性能提升，我们运行了一项基准测试。我们使用了经过修改的 so_vector 版本，其中一条路径采用 GET 然后 _search 的模式，另一条则使用 lookup。在 GCP 同一区域中的两个节点上运行后，结果非常显著。延迟持续提升接近 3 倍。即使节点位于同一个数据中心和同一个可用区内，网络和序列化成本依然会带来实际影响。