作者：来自 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