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

作者：来自 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 倍。即使节点位于同一个数据中心和同一个可用区内，网络和序列化成本依然会带来实际影响。

百分位数	get-then-knn（毫秒）	lookup-knn（毫秒）	降低幅度	加速比
p50	10.3796	3.14093	69.74%	3.30 倍
p90	25.4429	5.89807	76.82%	4.31 倍
p99	27.7167	8.07109	70.88%	3.43 倍
最大值（ p100 ）	28.522	12.6497	55.65%	2.25 倍

此基准测试运行于 200 万文档规模下，而延迟改善幅度将取决于你的整体搜索成本。即使加速幅度较小，lookup 依然能够移除额外的客户端请求。更少的代码，更少的往返请求。

一种更简单的存储向量搜索路径

有时候，小变化也能带来巨大影响。虽然这是一个简单的功能，但我希望它能减少你在使用 Elasticsearch 时的一些不必要摩擦，并让我们变得更加讨人喜欢。

这篇内容对你有多大帮助？

原文：https://www.elastic.co/search-labs/blog/elasticsearch-vector-search-lookup