Elasticsearch过滤向量搜索速度比OpenSearch快8倍

搜索速度这事儿，在AI袋里和上下文工程里到底有多重要？直接看数据吧。我们在一个包含2000万篇文档的语料库上跑了基准测试，结果很说明问题——Elasticsearch在过滤向量搜索方面，吞吐量比OpenSearch高出8倍，而且在我们测试的所有配置里，Recall@100都更高。

上下文工程可不仅仅是依赖快速的向量检索。随着工作流不断迭代，团队还需要强大的相关性控制手段，比如混合搜索和过滤，操作上要简便，性能上要可预测。但关键在于，袋里在每个请求里通常要多次运行“检索→推理→再检索”这样的循环，检索延迟就成了一个倍增器。所以，这方面的任何改进，都会直接转化为更好的端到端响应速度和更低的成本。

OpenSearch 与 Elasticsearch：过滤向量搜索基准测试的吞吐量比较

图 1：吞吐量。

对于上下文工程而言，检索从来不是一次性的。袋里和应用程序会反复运行循环，比如检索→推理→检索，目的是优化查询、验证事实、构建更贴切的上下文，最终完成任务。这种模式在袋里工作流和迭代检索增强生成（RAG）中相当常见。每个用户请求都可能多次调用检索，这自然就拉长了响应延迟，或者推高了基础设施成本。

上下文工程将庞大的上下文池转换为有限的 LLM 上下文窗口。

图 1：上下文工程通过重复检索和整理，将大型上下文池（文档、内存、工具、聊天记录）转换为有限的大型语言模型 (LLM) 上下文窗口。

上下文工程的优化实施是一项新兴技术。迭代次数因工作流程而异。这些基准测试结果中最根本的关键概念是：上下文工程是有方向性的，迭代检索会让延迟成倍增加。

为什么向量搜索的性能至关重要？

场景是这样的：一位购物助理要回答一个需求——“我需要一个价格低于60美元的随身背包，能装下15英寸笔记本电脑，防水，而且周五之前必须送到。”

在生产环境中，这个助手很少只发一次向量查询就完事。它会跑一个检索循环来构建正确的上下文，每一步都常常受到库存、地区、配送承诺、品牌规则、政策资格等筛选条件的限制。

第一步：理解意图，并将其转化为约束条件。

袋里会把请求转换成结构化的过滤器和语义查询，比如：

筛选条件：有现货、可配送至用户邮编、周五前送达、价格低于60美元、有效商品信息
矢量查询：“可携带15英寸笔记本电脑的防水背包”

第二步：检索候选对象，然后进行筛选。

它会用不同的方法反复检索，避免错过好的匹配项：

“旅行背包，可携带笔记本电脑”
“15英寸防水通勤背包”
“轻便登机背包”

每次查询都带着相同的资格筛选器，因为检索到不相关或不可用的项目，只会浪费宝贵的上下文窗口。

第三步：展开确认细节，降低风险。

然后，袋里会再次检索，验证那些影响最终答案的关键属性：

材质和防水性能描述
尺寸和笔记本电脑隔层适配性
退货政策或保修限制
库存不足时的替代方案

这就是多步骤的上下文工程：检索、推理、检索、组装。

为什么延迟和召回对上下文工程至关重要

在每一个用户会话中，这些交互可能涉及数十次带筛选的检索调用。这意味着，每次调用的延迟会直接放大端到端的响应时间。而低召回率则迫使袋里进行额外的重试，或者导致它错过符合条件的项目，最终影响答案质量。

核心要点在于：在上下文相关的系统中，过滤近似最近邻（ANN）搜索不是单次查找，而是一项在约束条件下反复进行的操作。因此，即使大型语言模型（LLM）是最显眼的组件，向量搜索性能也会立竿见影地体现在延迟、吞吐量和成本上。

基准测试

结果

在图2里，每个点代表一个测试配置。效果最好的结果出现在左上角附近，意味着更高的召回率和更低的延迟。Elasticsearch的结果始终比OpenSearch更靠近左上角，说明在相同的工作负载下，Elasticsearch的速度和准确性都更胜一筹。

图 2：回忆率与平均延迟（重新评分 1）。

图 2：回忆率与平均延迟的关系，重新评分为 1。

一些关键见解

s_n_r_value：简写形式size_numCandidates_rescoreOversample（在这些测试中，k 和 numCandidates 均等于 numCandidates），例如，100_500_1表示 size=100，numCandidates=500 和 k=500，rescore oversample=1
召回率：该配置下测得的召回率（Recall@100）
平均延迟（毫秒）：每次查询的平均端到端延迟
吞吐量：每秒查询次数
召回率：Elasticsearch 相对于 OpenSearch 的相对召回率提升（Elasticsearch 值减去 OpenSearch 值）/ OpenSearch
延迟 Xs：OpenSearch 平均延迟除以 Elasticsearch 平均延迟
吞吐量 Xs：Elasticsearch 吞吐量除以 OpenSearch 吞吐量

举个例子，在100_9000_1配置下，OpenSearch上每次检索平均耗时687毫秒，而Elasticsearch只要90毫秒。如果在一个10步的检索循环里，那就要多等大约10 × (687 - 90) = 6秒钟。这差距，可不是一点半点。

查看完整结果。

方法论

我们使用Python发送查询，并跟踪响应时间和其他统计数据。需要说明的是，任何向量搜索引擎的性能都取决于核心参数的调优方式：考虑多少候选答案、重新评分的频率、返回多少上下文信息。这些设置直接决定了召回率（找到正确答案的可能性）和延迟（获得结果的速度）。

在基准测试中，我们使用了与袋里检索循环中通常调优的相同的候选列表、重评分和结果大小设置，测量了Elasticsearch在此工作负载下的性能。然后，我们使用相同的设置运行OpenSearch作为参考。

OpenSearch

GET /_search
{
  "query": {
    "knn": {
      "": {
        "vector": [...],
        "k": ,
        "method_parameters": {
          "ef_search": 
        },
        "rescore": {
          "oversample_factor": 
        },
        "filter": {
          
        }
      }
    }
  },
  "size": ,
  "_source": {
    "excludes": [""]
  }
}

"size": ：返回给客户端的命中次数。在此基准测试中，结果集大小为 100，以计算 Recall@100。"k": ：最近邻候选对象的数量。"ef_search": ：要检查的向量数量。"oversample_factor": ：在重新评分之前检索到多少个候选向量。

Elasticsearch

GET /_search
{
  "query": {
    "knn": {
      "field": "",
      "query_vector": [...],
      "k": ,
      "num_candidates": ,
      "rescore_vector": {
        "oversample": 
      },
      "filter": {
        
      }
    }
  },
  "size": ,
  "_source": {
    "excludes": [""]
  }
}

"size": ：返回给客户端的命中次数。在此基准测试中，结果集大小为 100，以计算 Recall@100。"k": ：从每个分片返回的最近邻居的数量。"num_candidates": ：在进行 knn 搜索时，每个分片要考虑的最近邻候选数。"oversample": ：在重新评分之前检索到多少个候选向量。

例子

对于配置100_500_1，对应的查询语句如下：

OpenSearch

GET search_catalog_128/_search
{
  "query": {
    "knn": {
      "search_catalog_embedding": {
        "vector": [...],
        "k": 500,
        "method_parameters": {
          "ef_search": 500
        },
        "rescore": {
          "oversample_factor": 1
        },
        "filter": {
          "term": {
            "valid": true
          }
        }
      }
    }
  },
  "size": 100,
  "_source": {
    "excludes": ["search_catalog_embedding"]
  }
}

Elasticsearch

GET search_catalog_128/_search
{
  "query": {
    "knn": {
      "field": "search_catalog_embedding",
      "query_vector": [...],
      "k": 500,
      "num_candidates": 500,
      "rescore_vector": {
        "oversample": 1
      },
      "filter": {
        "term": {
          "valid": true
        }
      }
    }
  },
  "size": 100,
  "_source": {
    "excludes": ["search_catalog_embedding"]
  }
}

完整的配置，包括Terraform脚本、Kubernetes清单和基准测试代码，都可以在这个存储库的es-9.3-vs-os-3.5-vector-search文件夹中找到。

集群设置

我们在六台e2-standard-16云服务器上进行了测试，每台服务器配备16个vCPU和64GB内存。在每台服务器上，我们为运行搜索引擎节点的每个Kubernetes pod分配了15个vCPU和56GB内存，并为JVM堆保留了28GB内存。

集群运行的是Elasticsearch 9.3.0和OpenSearch 3.5.0（底层都是Lucene 10.3.2）。由于两个系统用了相同的Lucene版本，我们观察到的吞吐量和延迟差异就不能简单归因于Lucene本身，而是反映了每个引擎在集成和执行过滤后的k近邻（kNN）检索和重评分方面的差异。我们使用了一个包含三个主分片和一个副本的索引（总共6个分片，每个节点1个）。

另外，我们在同一区域用了另一台服务器来运行基准测试客户端，并收集计时统计数据。

Elasticsearch 和 OpenSearch 基准测试的集群设置

图 2：集群设置示意图。

数据集

为了进行这项基准测试，我们使用了一个包含2000万份文档的大规模电子商务风格目录嵌入数据集，旨在反映现实世界中大规模过滤向量检索的挑战。

每个文档代表一个目录项，包含：

• 用于近似kNN检索的128维稠密向量嵌入。
• 用于筛选的结构化元数据字段（例如，项目有效性和可用性，以及其他目录约束），这样可以模拟常见的生产模式：检索最近的邻居，但仅限于符合条件的子集内。

选择这个数据集，是因为它捕捉到了我们在生产环境中遇到的智能体和RAG类系统的核心性能挑战：仅靠向量相似度远远不够，检索经常受限于各种过滤器，系统必须在这些限制下保持高召回率和低延迟。与规模较小的问答类数据集相比，一个包含2000万篇文档的语料库，能更好地反映过滤式ANN系统在实践中面临的规模和候选词压力。

结论

在现代AI架构中，尤其是那些围绕上下文工程构建的架构，向量搜索速度不是一个可以忽略的实现细节，而是一个关键的倍增器。当袋里和工作流迭代地执行“检索→推理→检索”流程时，检索性能直接影响端到端延迟、吞吐量，以及最终喂给模型的上文质量。

在我们的基准测试中，当正确性取决于是否检索到正确的文档（而不仅仅是相似的向量）时，Elasticsearch始终比OpenSearch提供更高的召回率和更低的延迟。在受控数据集上，这种差异已经很明显；到了生产环境，这些优势会随着大量检索调用而不断累积，最终带来更快的响应速度、更多的容量余量，以及更低的基础设施成本。