作者来自 Elastic Sachin Frayne探索 OpenSearch 与 Elasticsearch 在过滤向量搜索filtered vector search基准测试中的表现差异以及为什么向量搜索性能对上下文工程系统context‑engineered systems至关重要。从向量搜索到强大的 REST APIElasticsearch 为开发者提供了最全面的搜索工具包。你可以在 Elasticsearch Labs 仓库中的示例 notebook 中尝试新功能也可以今天开始免费试用或在本地运行 Elasticsearch。为什么搜索速度对 AI agents 和上下文工程很重要在一个 2000 万文档的语料库基准测试中Elasticsearch 在过滤向量搜索上的吞吐量比 OpenSearch 快高达 8 倍同时在我们测试的各种配置中也实现了更高的 Recall100。上下文工程不仅依赖快速的向量检索。团队还需要强大的相关性控制例如混合搜索和过滤、操作简便性以及可预测的性能以支持工作流的迭代。但因为 agents 往往在每次请求中多次执行 “检索 → 推理 → 再检索” 循环检索延迟会被放大因此在这方面的性能提升会直接转化为更好的端到端响应速度和更低的成本。Graph 1: Throughput.对于上下文工程来说检索不是一次性步骤。Agents 和应用会反复执行循环例如检索 → 推理 → 再检索以精炼查询、验证事实、组装有依据的上下文并完成任务。这种模式在 agentic 工作流和迭代式增强生成retrieval augmented generation - RAG中很常见。由于每个用户请求可能会多次触发检索这会增加响应延迟和/或提高基础设施成本。图 1上下文工程通过反复检索和筛选将庞大的上下文池文档、记忆、工具、聊天记录转化为有限的 LLM 上下文窗口。上下文工程的最佳实现仍是新兴技术不同工作流的迭代次数差异很大。这些基准测试结果最核心的概念是上下文工程具有方向性—— 迭代检索会使延迟成倍增加。为什么向量搜索性能至关重要想象一个购物助手回答问题“我需要一个 60 美元以下、能放 15 英寸笔记本、耐水、并能在周五送达的随身背包。”在生产环境中助手很少只发起一次向量查询就停止。它会运行一个检索循环来构建正确的上下文每一步通常受过滤条件限制例如库存、地区、配送承诺、品牌规则和政策资格。步骤 1理解意图并转换为约束条件Agent 将请求转化为结构化过滤器和语义查询例如Filters过滤条件有库存、可配送至用户邮编、周五前送达、价格低于 60 美元、有效商品Vector query向量查询“Carry-on backpack 15-inch laptop water resistant”步骤 2检索候选项并进一步精炼通常会对检索进行多次变体查询以避免错过优质匹配“travel backpack carry on laptop sleeve”“water resistant commuter backpack 15 inch”“lightweight cabin backpack”每个查询都使用相同的资格过滤器因为检索到不相关或不可用的商品只是浪费上下文。步骤 3扩展以确认细节并降低风险Agent 再次检索以验证影响最终答案的关键属性材质与耐水性描述尺寸和笔记本隔层是否合适退换政策或保修限制库存不足时的备选方案这就是多步骤上下文工程检索 → 推理 → 再检索 → 组装。为什么延迟和召回对上下文工程很重要这些交互可能在每个用户会话中涉及数十次带过滤条件的检索调用。这意味着每次调用的延迟会直接乘到端到端响应时间上而低召回率会导致额外重试或者让 agent 错过符合条件的项从而降低答案质量。要点在上下文工程系统中带过滤条件的近似最近邻ANN搜索不是一次性查询而是在约束下的重复操作。因此向量搜索性能会直接影响延迟、吞吐量和成本即便大语言模型LLM是最直观的组件。基准测试结果在图 2 中每个点代表一种测试配置。最佳结果位于左上角表示更高召回率与更低延迟。Elasticsearch 的结果始终更接近左上角相比 OpenSearch 在相同工作负载下表现出更好的速度和精度。结果图 2召回率与平均延迟对比重排序rescore值为 1一些关键洞察s_n_r_valuesize_numCandidates_rescoreOversample 的缩写在这些测试中 k 和 numCandidates 设置为相等例如100_500_1表示 size100、numCandidates500、k500、rescore oversample1Recall该配置下的Recall100测量值Avg latency (ms)每次查询的平均端到端延迟毫秒Throughput每秒查询数QPSRecall %Elasticsearch 相比 OpenSearch 的相对召回提升计算方式为(Elasticsearch - OpenSearch) / OpenSearchLatency XsOpenSearch 平均延迟除以 Elasticsearch 平均延迟Throughput XsElasticsearch 吞吐量除以 OpenSearch 吞吐量例如在100_9000_1配置下OpenSearch 平均每次检索耗时687 毫秒而 Elasticsearch 仅90 毫秒。在一个 10 步的检索循环中这意味着大约10 × (687 − 90) 5970 毫秒即额外近 6 秒的等待时间。从表中可以看出Elasticsearch 在召回率、延迟和吞吐量上均优于 OpenSearch尤其是在大规模向量检索场景中性能优势会被迭代检索放大直接影响端到端响应时间和系统成本。完整结果可查看表格引擎s_n_r_valueRecall平均延迟 (ms)吞吐量召回 %延迟倍数吞吐倍数Elasticsearch100_250_10.770425534.759.70%2.281.91OpenSearch100_250_10.702357.08279.58———Elasticsearch100_500_10.857725.42524.147.20%2.42OpenSearch100_500_10.800160.9262.12———Elasticsearch100_750_10.894729.67528.095.72%2.252.21OpenSearch100_750_10.846366.76239.11———……………………Elasticsearch100_9000_10.983790.08176.960.16%7.637.61OpenSearch100_9000_10.9821687.2523.25———Elasticsearch100_10000_10.984897.64163.310.08%8.388.36OpenSearch100_10000_10.984818.6419.53———例如在100_9000_1配置下OpenSearch 平均每次检索耗时687 毫秒而 Elasticsearch 仅90 毫秒。在一个 10 步的检索循环中这意味着大约10 × (687 − 90) 5970 毫秒也就是额外近 6 秒的等待时间。从表中可以看到Elasticsearch 在召回率、延迟和吞吐量上均优于 OpenSearch尤其是在大规模向量检索场景中这种优势在迭代检索循环中被放大直接影响端到端响应时间和系统成本。完整测试结果如下引擎s_n_r_valueRecall平均延迟 (ms)吞吐量召回 %延迟倍数吞吐倍数Elasticsearch100_250_10.770425534.759.70%2.281.91OpenSearch100_250_10.702357.08279.58———Elasticsearch100_500_10.857725.42524.147.20%2.42OpenSearch100_500_10.800160.9262.12———Elasticsearch100_750_10.894729.67528.095.72%2.252.21OpenSearch100_750_10.846366.76239.11———Elasticsearch100_1000_10.915629.65534.54.66%2.462.44OpenSearch100_1000_10.874872.88219.01———Elasticsearch100_1500_10.938631.84497.33.38%2.712.68OpenSearch100_1500_10.907986.16185.4———Elasticsearch100_2000_10.950734.69457.22.57%2.982.96OpenSearch100_2000_10.9269103.36154.55———Elasticsearch100_2500_10.958237.9418.431.99%3.283.26OpenSearch100_2500_10.9395124.29128.53———Elasticsearch100_3000_10.963641.86379.41.62%3.463.44OpenSearch100_3000_10.9482144.67110.34———Elasticsearch100_4000_10.970550.28316.211.06%3.873.85OpenSearch100_4000_10.9603194.3682.22———Elasticsearch100_5000_10.974958.77270.910.73%4.434.41OpenSearch100_5000_10.9678260.3361.38———Elasticsearch100_6000_10.978166.75238.590.52%4.914.89OpenSearch100_6000_10.973327.4448.81———Elasticsearch100_7000_10.980474.64213.490.38%5.285.27OpenSearch100_7000_10.9767394.2440.53———Elasticsearch100_8000_10.982382.28193.590.27%6.866.83OpenSearch100_8000_10.9797564.1428.33———Elasticsearch100_9000_10.983790.08176.960.16%7.637.61OpenSearch100_9000_10.9821687.2523.25———Elasticsearch100_10000_10.984897.64163.310.08%8.388.36OpenSearch100_10000_10.984818.6419.53———方法论使用 Python 发送查询并跟踪响应时间和其他统计数据我们向引擎发送了以下查询。请记住任何 vector search 引擎的性能都取决于你如何调优其核心参数考虑多少 candidates、多激进地 rescore以及返回多少 context。这些设置会直接影响 recall找到正确答案的可能性和 latency获取结果的速度。在我们的基准测试中我们使用了在典型 agentic retrieval 循环中会调优的相同 candidate、rescore 和 result-size 设置并测量了 Elasticsearch 在该工作负载下的表现。随后我们用相同设置运行 OpenSearch 作为参考。OpenSearchGET INDEX_NAME/_search { query: { knn: { DENSE_VECTOR_FIELD_NAME: { vector: [...], k: NUMBER_OF_CANDIDATES, method_parameters: { ef_search: NUMBER_OF_CANDIDATES }, rescore: { oversample_factor: OVERSAMPLE }, filter: { SOME_FILTER } } } }, size: RESULT_SIZE, _source: { excludes: [ DENSE_VECTOR_FIELD_NAME ] } }size: RESULT_SIZE返回给 client 的 hits 数量。在本次 benchmark 中result size 为 100 用于计算 Recall100。k: NUMBER_OF_CANDIDATESnearest neighbor candidates 的数量。ef_search: NUMBER_OF_CANDIDATES要检查的 vectors 数量。oversample_factor: 在 rescore 之前检索多少 candidate vectors。ElasticsearchGET INDEX_NAME/_search { query: { knn: { field: DENSE_VECTOR_FIELD_NAME, query_vector: [...], k: NUMBER_OF_CANDIDATES, num_candidates: NUMBER_OF_CANDIDATES, rescore_vector: { oversample: OVERSAMPLE }, filter: { SOME_FILTER } } }, size: RESULT_SIZE, _source: { excludes: [ DENSE_VECTOR_FIELD_NAME ] } }size: RESULT_SIZE返回给 client 的 hits 数量。在本次 benchmark 中result size 为 100 用于计算 Recall100。k: NUMBER_OF_CANDIDATES每个 shard 返回的 nearest neighbors 数量。num_candidates: NUMBER_OF_CANDIDATES在每个 shard 执行 knn search 时要考虑的 nearest neighbor candidates 数量。oversample: 在 rescore 之前检索多少 candidate vectors。示例Knn query(100_500_1) 如下OpenSearchGET 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 ] } }ElasticsearchGET 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 manifests 和 benchmark 代码可在该 repository 的 es-9.3-vs-os-3.5-vector-search 文件夹中找到。集群设置我们的测试运行在六台 e2-standard-16 cloud servers 上每台有 16 vCPUs 和 64 GB RAM。在每台服务器上我们为运行 search engine 节点的每个 Kubernetes pod 分配了 15 vCPUs 和 56 GB RAM其中 28 GB 预留给 JVM heap。集群运行 Elasticsearch 9.3.0 和 OpenSearch 3.5.0Lucene 10.3.2。由于在本 benchmark 中两者都使用相同的 Lucene 版本因此我们观察到的 throughput 和 latency 差异不能仅归因于 Lucene而是反映了每个 engine 在执行 filtered k-nearest neighbor (kNN) retrieval 和 rescore 时的集成和执行差异。我们使用了单个 index包含三个 primary shards 和一个 replica总共 6 个 shards每个节点 1 个。我们还使用同一区域的另一台服务器运行 benchmark client 并收集 timing 统计数据。图 2集群设置示意图。数据集在本次基准测试中我们使用了一个大型电商风格目录 embedding 数据集包含 2000 万条文档旨在反映大规模过滤向量检索的实际情况。每条文档代表一个目录项并包括一个 128 维的 dense vector embedding用于近似 kNN 检索。用于过滤的结构化 metadata 字段例如商品有效性和可用性以及其他目录约束支持常见的生产模式检索最近邻时仅在符合条件的子集内进行。我们选择此数据集是因为它捕捉了在 agentic 和 RAG 风格系统中常见的核心性能挑战仅向量相似性不足检索经常受过滤条件约束系统必须在这些约束下保持高 recall 并降低 latency。相比较小的 QA 风格数据集2000 万条文档的语料更能反映过滤 ANN 系统在实际中面临的规模和候选压力。结论在现代 AI 架构中尤其是基于 context engineering 的系统vector search 速度不是一个小细节。它是一个乘数。当 agents 和 workflows 多次执行 retrieve → reason → retrieve 循环时检索性能直接影响端到端 latency、throughput以及输入模型的 context 质量。在我们的基准测试中Elasticsearch 在依赖正确文档检索而不仅仅是相似向量的场景中一直比 OpenSearch 提供更高的 recall 和更低的 latency。在受控数据集上这种差异很明显在生产环境中这些性能提升会在大量检索调用中累积提高响应速度、增加容量余量并降低基础设施成本。进一步阅读什么是 context engineeringhybrid search 和 context engineering 的演变relevance 在 AI agents context engineering 中的影响原文https://www.elastic.co/search-labs/blog/context-engineering-relevance-ai-agents-elasticsearch