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

作者来自 Elastic Benjamin TrentElasticsearch 9.4 提供了一种更简单的方式来搜索存储在 Elasticsearch 索引中的向量并将延迟最高降低 3 倍。从向量搜索到强大的 REST APIElasticsearch 为开发者提供了最全面的搜索工具集。深入体验 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( indexsource_index, idseed_id, _source_includes[vector_field], ) query_vector seed_doc[_source][vector_field] # 2) Send it back in a kNN query resp es.search( indextarget_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( indexproducts, 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毫秒降低幅度加速比p5010.37963.1409369.74%3.30 倍p9025.44295.8980776.82%4.31 倍p9927.71678.0710970.88%3.43 倍最大值 p100 28.52212.649755.65%2.25 倍此基准测试运行于 200 万文档规模下而延迟改善幅度将取决于你的整体搜索成本。即使加速幅度较小lookup 依然能够移除额外的客户端请求。更少的代码更少的往返请求。一种更简单的存储向量搜索路径有时候小变化也能带来巨大影响。虽然这是一个简单的功能但我希望它能减少你在使用 Elasticsearch 时的一些不必要摩擦并让我们变得更加讨人喜欢。这篇内容对你有多大帮助原文https://www.elastic.co/search-labs/blog/elasticsearch-vector-search-lookup