摘要： 阿里云 Elasticsearch 在 ES 9.4 上以 FalconSeek HNSW 重构从候选生成、批量计算到原始向量重排的端到端路径。在 VectorDBBench 压测中，Cohere10M、Top10、Recall 约 0.98 时，查询吞吐达到 82,520.18 QPS，独立延迟测试中的 P99 为 1.8 ms。本文展开介绍了带来这些结果背后的技术细节。

大模型、RAG、语义搜索和多模态应用正在加速进入生产环境。文本、图片、音视频、商品和用户行为被编码为高维向量后，向量检索也从一个独立的算法组件，逐渐成为 AI 应用的数据基础设施。

当数据规模从百万增长到千万乃至更高，问题就不再只是“能不能找到相似向量”。生产系统还要同时面对高召回、低延迟、高并发、持续写入、过滤查询以及资源成本等要求。单独优化一个距离计算函数，往往无法转化为稳定的端到端收益。

阿里云 Elasticsearch 云原生内核 FalconSeek 给出的回答，是在保持 HNSW 图搜索语义的同时，重构这条端到端路径。它面向高维、千万到亿万规模和高并发近似最近邻检索，通过压缩量化表示完成候选召回，再以原始精度重排，并结合 CPU、内存和数据路径的协同优化，取得了新的端到端性能结果。

在 32 vCPU g9i 服务端上，Cohere10M 的 Recall 约为 0.98 时：

●Top10 吞吐达到 82,520.18 QPS，P99 延迟为 1.8 ms。

一、VectorDBBench 最新结果

下表汇总了 Elasticsearch 在 VectorDBBench 在不同数据集、不同检索 TopK 下的性能数字，结果表明经相关优化后阿里云 ES 性能结果都领跑榜单。8 组端到端的压测结果可以直接看到 TopK 和数据规模变化下的吞吐分布，同时保留每组 Recall 与单并发 p99 延迟：

这些结果覆盖了 768 维通用语义向量和 1024 维生物医学文本向量。它们说明 FalconSeek HNSW 的收益并不局限于某一个数据集，也不只出现在 Top10：当 TopK 增大、候选搜索和原始精度重排成本上升时，端到端数据路径优化仍能保持较高吞吐。

二、FalconSeek HNSW 如何实现极致向量检索性能

FalconSeek HNSW 不改变 HNSW 的图遍历与候选队列语义，而是把查询拆分为压缩表示召回和原始向量重排两个阶段，并围绕这条路径组织计算、数据布局和 segment 生命周期。

理解这套设计的关键，是看清同一个查询向量如何分别进入候选召回与原始精度重排两条数据路径：

量化数据用于召回，原始向量重排

索引中同时保存用于图搜索的量化数据和用于最终打分的原始向量。查询进入 HNSW 图后，先使用量化数据计算近似距离、遍历邻接关系并维护候选队列；候选集合确定后，再读取这些候选对应的原始向量，重新计算相似度并输出 TopK 结果。

量化分数只用于候选召回，不直接作为最终结果分数。候选集合的大小可以独立配置，用来控制进入原始向量重排阶段的数据范围。

批量计算与指令级并行

HNSW 图遍历由候选队列驱动，但同一批邻居节点的距离计算彼此独立。FalconSeek HNSW 将这些距离计算组织成批次，通过硬件向量指令一次处理多个数据元素，并在不同候选之间安排指令级并行和预取。

批量计算只改变距离内核和邻居处理的执行方式。候选入队、出队、访问标记和终止条件仍遵循 HNSW 的图搜索逻辑。

按访问模式组织热数据

图邻接表、量化向量和辅助信息会在遍历期间反复访问，FalconSeek HNSW 将它们组织为面向查询的紧凑只读布局。物理排列会参考图节点之间的访问关系，使经常沿同一条遍历路径读取的数据保持相近。

segment 打开时会校验这些数据，并把图结构、量化数据和查询计划绑定到当前 segment。大页只读内存布局可以作为热点索引的数据承载方式，但不改变图的连接关系和检索语义。

原始向量与图遍历数据分开存储，只在候选重排阶段按需读取。

原始向量的按需批量重排

图搜索产生的候选 ID 会映射到稳定的原始向量行。重排内核根据候选列表直接读取这些向量，并以批量方式计算查询向量与多个候选之间的原始精度相似度。

重排阶段不重新遍历图，也不使用量化空间中的近似分数。所有候选完成原始精度打分后，再按该分数排序并截取最终 TopK。

与 segment 生命周期协同

FalconSeek HNSW 复用 Elasticsearch 的 shard、segment、refresh 和 merge 生命周期，索引数据作为 segment 的一部分进行管理。新写入的数据完成 refresh 后，以新的可搜索 segment 对外提供查询；merge 生成新 segment 时，同时生成与之对应的图结构、量化表示和原始向量数据，并随新 segment 原子发布。

建图阶段可以根据构建策略选择量化数据或原始向量计算节点距离。该选择属于 segment 构建策略，不改变查询阶段“量化召回、原始向量重排”的两阶段接口。

82K QPS 和 1.8 ms P99 因而不是某个单独优化的结果，而是候选生成、精排计算、指令级并行、数据布局和 Segment 生命周期共同作用后的端到端表现。

三、阿里云 Elasticsearch 在向量引擎的全方位增强

阿里云 Elasticsearch 对向量检索的增强，首先体现在不再试图用一种索引覆盖所有规模和资源条件：从少量数据的精确扫描，到性能优先、内存优先和容量优先的近似检索，再到面向 Agent 的超大规模多租户架构，每条路线都对应不同的首要瓶颈。

稠密向量引擎覆盖不同规模与资源目标

进入稠密向量召回内部，瓶颈还会随数据规模和业务形态继续变化：数据量较小时，更重要的是结果精确和使用简单；规模上升后，CPU、内存带宽和查询延迟成为主要约束；当向量无法稳定驻留内存时，问题又会转向磁盘访问、存储成本和冷热分层。

选型时真正需要先判断的，不是哪个算法“更高级”，而是当前负载首先受限于哪一类资源。下面的能力谱系图把精确扫描、高性能内存型 ANN、量化图索引以及磁盘与对象存储型检索放回各自解决的问题中，并把面向 Agent 的系统级路线与单索引选型区分开来：

少量数据：flat 保持精确与简单

当索引规模较小，或者查询先经过结构化条件过滤、最终只剩少量候选时，构建近似图未必划算。flat 会逐一计算查询向量与候选向量之间的距离，不引入近似图召回误差，也不需要维护图结构，数据写入、更新和 segment merge 的处理路径都更直接。

它尤其适合小型知识库、精确性优先的离线评测，以及过滤后候选集合很小的检索。当候选数量持续增长时，扫描计算量也会近似线性增长；因此，flat 的判断标准不只是索引总量，还要看一次查询实际需要比较多少向量。

性能优先：falconseek_hnsw 面向高并发、低延迟

当数据进入百万到亿万规模，并且业务同时要求高维向量、高并发和低延迟时，查询路径本身成为主要矛盾。FalconSeek HNSW 使用紧凑的量化表示完成 HNSW 图遍历和候选召回，再读取候选对应的原始浮点向量进行重排。量化表示负责缩小搜索范围，原始向量负责最终打分，两阶段可以分别控制候选规模和结果质量。

FalconSeek HNSW 还围绕现代 CPU 组织批量距离计算、图遍历热数据和原始向量重排，并把索引产物纳入 Elasticsearch 的 refresh、segment 和 merge 生命周期。它适合查询性能是第一目标、热点索引能够稳定驻留内存或高速缓存，并且希望继续沿用 Elasticsearch 索引和查询体系的业务。前文 Cohere 与 BioASQ 的端到端结果，展示的正是这条性能优先路线。

内存优先：bbq_hnsw 压缩图搜索工作集

bbq_hnsw 保留 HNSW 的多层近邻图，但将图搜索使用的浮点向量量化为1 bit 表示。对于浮点向量，用于搜索的向量表示可以压缩到原始宽度的约三十二分之一；原始向量仍保留在磁盘上，用于候选重排、重建和后续索引演进。

这条路线适合仍然需要 HNSW 低延迟图搜索，但内存容量或内存带宽已经成为约束的高维、大规模场景。二值量化会带来更多近似误差，通常需要扩大候选集合，并通过原始向量重排恢复结果质量。同时，HNSW 图结构本身仍然存在，因此 bbq_hnsw 解决的是向量表示的内存占用，并不是把整个索引变成磁盘型索引。

海量数据：bbq_disk 走向磁盘与对象存储

当向量规模明显超过可用内存时，继续要求完整 HNSW 图和搜索数据常驻内存，会让容量与成本成为扩展瓶颈。bbq_disk 不再依赖 HNSW 图，而是通过聚类把相近向量划分到不同搜索子空间。查询先定位与查询向量最接近的聚类中心，再读取命中聚类中的压缩向量进行候选计算，最后按需使用原始向量重排。

这种访问方式把随机图遍历转换为围绕少量聚类的数据读取，适合 SSD、本地磁盘，以及以 SSD 作为缓存、对象存储作为持久层的存算分离架构。它主要解决的是“数据无法全部放进内存”之后的规模与成本问题。业务需要根据 Recall 目标决定访问多少聚类：访问范围越大，参与比较的候选和存储读取也越多，因此 bbq_disk 更适合容量与成本优先，而不是单纯追求最短延迟的场景。

面向 Agent：AI 引擎版承载亿级多租户

Agent 记忆、企业知识库和 AI Coding 带来的不只是更大的单个索引。一个用户、一个 Agent、一个代码仓库或一个知识库，都可能成为独立的检索租户；绝大多数租户长期沉睡，少数租户会突然活跃，同时还要持续接收新文档、对话和代码变更。此时，选型问题已经从“使用哪种向量索引”升级为“如何管理海量租户及其冷热数据”。

面向这类负载，阿里云 ES AI 引擎版提供了另一条系统级路线：面向亿级租户、千亿级向量设计，以 OSS 作为持久存储，计算节点保持无状态，本地内存和 SSD 作为按需缓存；写入与查询资源独立伸缩，并以租户为边界组织、加载和回收数据。它同时保留 Elasticsearch 的全文、向量、过滤和聚合能力，适合需要混合检索的 Agent 数据底座。

向量引擎解决了“如何在不同规模和资源约束下完成高效召回”的问题。进入生产级 AI 搜索后，系统还要回答另一个问题：怎样把向量召回与原始文本、稀疏语义、模型推理和结果重排组织成一条完整链路。

从向量引擎延伸到完整 AI 搜索链路

生产级 AI 搜索并不是用向量检索替代 BM25，而是让不同检索信号协同工作：全文检索负责产品型号、代码符号和专有名词等精确匹配；稀疏向量通过模型生成的加权词项补充语义扩展；稠密向量则捕获意图、上下文和多模态语义。

Inference Service 把模型调用接入写入与查询流程，生成稀疏或稠密表示；原始文本、sparse_vector 和 kNN 随后形成多路召回，由 Retrievers 使用 RRF 或 Linear 完成融合，并可对候选集调用 Rerank 模型精排。结构化过滤、租户隔离和访问权限贯穿整条检索路径：

这套能力的关键不是把所有查询强制改成同一种模式，而是让每种信号解决擅长的问题，再在统一查询框架中组合。由此，阿里云 Elasticsearch 以向量引擎提供检索底座，并通过多路召回、Inference 和 Rerank 延伸为完整的 AI 搜索链路。

四、从引擎到模型：AI Search 的竞争正在转向全栈协同

阿里云 Elasticsearch 在向量引擎的优化了千万级向量召回可以同时追求高吞吐、高召回与低延迟，但对 Agent 来说，“取得候选”只是上下文生产链路的一环。正如《从 VDBBench 到 MMEB 榜首：阿里云 AI Search 从引擎到模型的全栈优化》 所总结的，生产级 AI Search 还要同时处理传统检索热路径、多路结果融合，以及文本、图片、PDF 页面等内容的语义理解。该文记录的另外三组结果，从传统检索与多模态模型两个方向补充了这条全栈链路的证据：

五、结语

向量检索的性能边界，从来不由一个距离函数单独决定。数据规模上升后，真正决定生产体验的是一整条路径：候选如何生成，热数据如何布局，原始向量如何读取与重排，索引如何随 Segment 生命周期持续演进，以及向量召回如何与全文、过滤和重排协同。

FalconSeek HNSW 在 VectorDBBench 中的结果，是这条端到端路径已经形成工程闭环的一次集中证明。它把量化召回与原始精度重排结合起来，在高召回条件下同时提升吞吐、压低尾延迟，并自然融入 Elasticsearch 的数据与查询体系。

如果您正在建设企业知识库、RAG、Agent Memory、多模态搜索或其他大规模向量检索场景，可进一步参阅使用 FalconSeek 云原生内核加速 Elasticsearch 查询。

阿里云ES免费试用：https://free.aliyun.com/?spm=5176.14058969.J_3759233040.1.1c5069afFW3p4q&productCode=elasticsearch

钉钉交流群（群号35183864）

郑重声明：此文内容为本网站转载企业宣传资讯，目的在于传播更多信息，与本站立场无关。仅供读者参考，并请自行核实相关内容。