在当前的 RAG（检索增强生成）和 AI 搜索架构中，Elasticsearch 经常被作为底层的数据存储。在最新发布的 9.4 版本中，官方没有盲目去堆砌一些听起来宏大的概念，而是针对实际生产环境中的网络开销、硬件成本、多模态支持等痛点，做了一些非常实在的优化。
本文不聊虚的，直接用白话和大家拆解一下，Elasticsearch 9.4 到底更新了哪些对算力和工程有实质帮助的技术。
一、减少网络往返：向量的 lookup 检索支持单次请求
在过去，如果我们手头有一个特定的文档（比如一个已经入库的商品图片），想在集群里查找和它相似的其他文档，通常需要走两步：
第一步： 先发送一个查询，把这个目标文档的向量数据捞回到业务客户端。
第二步： 在客户端拿到这串长长的向量数组后，再组装成一个新的kNN 查询，重新发给 Elasticsearch 开展相似度计算。
这种“折返跑”的交互方式不仅浪费网络带宽，而且在客户端高频做 JSON 的序列化和反序列化也会平白消耗 CPU。
9.4 带来的改变：query_vector_builder.lookup
9.4 版本引入了 lookup 机制。简单来说，现在你只需要把目标文档的ID 和向量字段名传给 ES，ES 会在集群内部自己去把向量读出来并直接做检索，整个过程只需要一次网络请求。
{"query": {"knn": {"field": "image_vector","query_vector_builder": {"lookup": {"index": "my_vector_index","id": "target_doc_id","path": "image_vector"}},"k": 10,"num_candidates": 100}}}
实际效果： 减少了数据在网络上的反复传输。官方测试表明，这种原生闭环的检索方式将该场景下的查询延迟降低了显著的幅度（部分场景可达 3 倍）。
工程体验： 业务代码少写了一半，不再需要处理“先拿向量、后传向量”的胶水逻辑。
二、算法与算力优化：DiskBBQ 迭代与 GPU 稳定版
向量检索最让人头疼的就是内存占用高和索引构建慢。9.4 版本在算法层和硬件利用上都做了比较接地气的改进。
1. DiskBBQ 算法的前置过滤与多比特量化
DiskBBQ 是 Elastic 用于优化向量索引的底层算法。在 9.4 版本中，它有两点实际的提升：
前置过滤加速： 很多时候我们在做向量检索前，会带上很多业务过滤条件（比如“只查过去3天内、属于某个分类的向量”）。9.4 优化了预过滤下的质心处理逻辑，使这类复合查询的速度大幅提升。
更灵活的量化方案： 向量太大会撑爆内存，所以需要把浮点数压缩（量化）。9.4 提供了更丰富的量化选项（支持 1、2、4 和 7 比特）。并且引入了 Preconditioning（前置处理）技术，解决了一部分非均匀分布的向量在做二进制压缩时精度掉得太厉害的通病，让压缩后的召回率更稳定。
2. GPU 加速构建索引正式商用（GA）
利用 NVIDIA cuVS 库通过 GPU 来加速构建向量图索引（如 HNSW）的功能，在 9.4 中正式进入商用阶段。
速度提升： 相比纯 CPU 构建，利用 GPU 算力可以大幅缩短索引建立的时间（官方极端测试下最高有 12 倍的吞吐提升）。
降级容错机制： 考虑到生产环境中 GPU 资源可能比较紧张或偶尔繁忙，9.4 增加了一个平滑的处理逻辑：当 GPU 算力不够用或排队时，系统在 Flush 数据时会自动切换回 CPU 来构建索引。这保证了哪怕硬件资源吃紧，数据写入也不会卡死或报错。
三、智能体底座：Agent Builder 的逻辑重构
现在很多人用 ES 来做 AI Agent（智能体）的知识库。传统的做法是：Agent 负责在外面调度，ES 只负责死板地吐出 Top-K 的文档。
在 9.4 中，Elastic Agent Builder 的底层逻辑更加清晰。它增强了对 Skills（技能）、Attachments（附件）和 Connectors（连接器）的整合能力。简单来说， 以前 Agent 构建上下文（Context）时很容易塞进一堆无用的噪声数据。9.4 允许 Agent 拥有更好的规则来控制“如何去收集上下文”和“如何过滤无关信息”。相当于把一部分原本需要写在外部的大模型编排逻辑，下沉并固化到了 ES 内部，让整个 RAG 流程的链路变短了。
四、机器学习：扩大模型兼容性
在机器学习（ML）和模型集成方面，9.4 主要是做了一些修修补补的稳定性工作：
新模型支持： 官方的模型图校验白名单里，正式加入了对Jina v5 和EuroBERT 等常见文本嵌入模型的算子支持，部署这些模型时不容易报错。
内存与稳定性： 升级了内置的 PyTorch 库（至 2.7.1），改善了运行大模型时因为内存不足（OOM）导致进程崩掉时的错误日志输出。以前崩了可能很难查原因，现在日志给得更直白，方便运维排查。
总结
看完 9.4 版本的更新，可以发现 Elastic 的思路非常务实。它没有去发明一些新奇的概念，而是盯着“怎么让向量查询少走一次网络”、“GPU 忙的时候怎么让 CPU 顶上”、“向量怎么压缩才不失真”这些在实际生产中天天会碰到的麻烦事去下功夫。
对于已经在使用 Elasticsearch 作为搜索底座的团队来说，这些更新意味着你不需要换掉技术栈，就能在 RAG 性能和硬件成本上获得比较实在的收益。
关于公司
感谢您关注新智锦绣科技（北京）有限公司！作为 Elastic 的 Elite 合作伙伴及 EnterpriseDB 在国内的唯一代理和服务合作伙伴，我们始终致力于技术创新和优质服务，帮助企业客户实现数据平台的高效构建与智能化管理。无论您是关注 Elastic 生态系统，还是需要 EnterpriseDB 的支持，我们都将为您提供专业的技术支持和量身定制的解决方案。
易捷问数(NewmindExAI)
易捷问数(NewmindExAI)平台是新智锦绣科技（北京）有限公司自主研发的一款开箱即用的企业级一体化智能数据分析平台，基于 Apple Mac Studio 硬件，以 Elastic 为数据底座，扩展支持其它数据源，依托本地LLM/在线LLM、集成 NewRAG 智能知识库、NewFlow智能中枢工作流和 NewChat 智能聊天三大功能为一体，实现 LLM 驱动的一体化解决方案。
欢迎关注我们，获取更多技术资讯和数字化转型方案，共创美好未来！
 |  |
Elastic 微信群 | EDB 微信群 |
发现“分享”和“赞”了吗，戳我看看吧
