AI Search+ES 9.4.X最佳实践:“更快、更准、更安全的企业级搜索引擎”＂为 Agent提供坚实底座”

企业搜索的能力从 Keyword Search、全文检索、同义词和聚合，逐步扩展到语义搜索、向量搜索、语义重排、RAG、混合搜索和多模态检索；进入 Agentic AI 阶段后，又增加 MCP Servers、Agent Memory、Skills、Advanced RAG 与个性化能力。演进的重点不只是检索方式增多，而是搜索结果开始直接服务后续推理和行动。

传统系统通常由人构造关键词、筛选条件或查询语句。面向 Agent 时，人向 Agent 提出目标，Agent 再动态调用索引、企业数据、外部 API 或其他 Agent。搜索由“获取信息”转向“驱动行动”，既作为知识库，也承担记忆体角色。与此同时，多 Agent 并发会显著增加搜索量，准确率、信噪比、溯源能力和响应速度都成为执行链路中的基础要求。

整体架构的底层覆盖向量、文本、对象、列存、行存、日志、地理和时序数据，ES|QL 位于其上，承担统一查询、转换与分析。Agent 层由 Agents、Tools/Skills 和 Workflows 构成，通过统一推理接口连接 Embedding、Rerank 与大语言模型，并通过 MCP、A2A/ACP 和 API 对接外部 Agent、模型应用和自定义 AI 应用。

在数据处理层面，平台同时覆盖结构化与非结构化数据、稀疏向量与稠密向量、地理位置、日志和时序指标。多模态搜索支持多种查询与过滤组合；日志的数据组织和索引针对时序日志优化；指标数据则由专门的时序指标引擎处理。这样，搜索、运维和安全场景可以共享同一套数据与计算基础。

9.X 的演进围绕四条主线展开：向量搜索、指标引擎、ES|QL 和 AI 基础设施。9.0 引入 Lucene 10 底座并让 BBQ 量化正式可用；9.1 将 BBQ 设为 384 维及以上向量的默认方式，并完善过滤检索、全文查询和 JOIN；9.2 推出 DiskBBQ、GPU 加速索引技术预览与 Smart Lookup Join；9.3 让 Agent Builder 正式可用，并预览 Workflows；9.4 则集中交付 DiskBBQ 默认与多位宽量化、GPU 加速、TSDB++、PromQL、TS 命令、Workflows 和 Agent Skills。

向量部分的实施重点包括算法结构、标量过滤、量化计算、原生 CPU 指令和 GPU 索引构建。目标不是只优化一次向量距离计算，而是覆盖从数据写入、索引构建、过滤检索到在线查询的完整路径。

BBQ 通过二进制量化压缩 float32 向量，但 bbq_hnsw 仍依赖 HNSW 全图驻留内存。数据扩展到十几亿、几十亿向量或多租户场景后，冷数据会长期占用内存，RAM 不足时性能可能悬崖式下降。DiskBBQ 改用层次化 K-Means 分簇：查询先比较簇中心，只加载相关簇，主体数据驻留磁盘，因此在内存受限时表现为线性缓降。9.4 又增加三项优化：高标量过滤场景提速 3-5 倍；两级质心非对称量化将查询量化开销从约 20% 降至 4%，整体提速约 5 倍；int4 紧凑打包与原生点积使 QPS 提升 2.5-3 倍。在同等召回、网络挂载存储条件下，DiskBBQ 吞吐最高达到 Qdrant 的 7 倍。

传统全文搜索可以依靠数据结构跳过大量无关内容，而高维向量比较包含持续的硬计算，因此必须更充分地利用硬件。加速路径从编译器自动向量化，发展到 Panama Vector API 的确定性 SIMD/FMA 指令，再通过 Panama FFI 调用 x86 与 ARM 本地优化代码，最后将适合并行的索引构建交给 GPU。不同阶段分别解决“能否触发指令”“能否按数据类型手工优化”和“能否把大批量计算并行化”的问题。

SimdVec 将每次向量距离计算下沉到原生引擎。Java 负责 Lucene 与 Elasticsearch 查询路径中的调度，经 FFI 调用 C++ 手工调优内核，覆盖 int8、int4、bfloat16、1bit 和非对称 BBQ，并在启动时按平台选择 AVX2、AVX-512 VPOPCNTDQ 或 ARM NEON。其距离计算相对串行代码加速约 50 倍，相对 Java Panama Vector API 提升 2-3 倍；9.4 原生块评分中，BBQ 相对 float32 吞吐达到 66 倍，AVX-512 VPOPCNTDQ 在 AVX2 之上还能带来 1.3-2.1 倍追加收益。

HNSW 图构建需要数十亿次向量比较，适合 GPU 并行；在线搜索若无法长期维持每秒数万 QPS，持续占用 GPU 则不经济。因此，推荐路径是使用 NVIDIA cuVS 加速批量索引构建与段合并，再由 CPU 承担查询流量。结果为向量索引吞吐提升 12 倍、段合并提速 7 倍。小集群或 PoC 可以把构建与搜索放在一体节点；生产规模可设置专职 GPU 摄入层。需要注意，cuVS 不支持 bbq_hnsw，GPU 层先构建 int8_hnsw，BBQ 转换在后续 CPU 节点完成。

BBQ 的落地过程包括研读 SIGMOD 论文、在 Lucene 架构中验证可行性、完成 SIMD 指令集工程改造、将代码合入 Apache Lucene，并在 Elasticsearch 8.16 正式上线。基准选择 AWS M6a、M7a、M8a 三代平台，用于观察不同 AVX 指令能力下的表现：ES BBQ 在 M7a 上超过 Milvus IVF RabitQ 在 M8a 上的性能；在 M6a 上超过 Milvus IVF RabitQ 在 M7a 上 15%-25%；与 Milvus HNSW FP32 相比，M6a 上的 BBQ 性能接近其 3-4 倍，同时节省大量内存。

指标部分不是在原有时序结构上做局部压缩，而是将存储组织、标识生成、数据跳过与查询执行连续改造成纯列式路径，并通过 Prometheus Remote Write 与 PromQL 保持现有采集和查询习惯。

TSDB++ 将每个指标与维度字段独立保存在 Doc Values 列中，并由向量化 ES|QL 执行。以 OTel 指标为例，单个数据点从 25 字节降至 3.75 字节，即 6.6 倍压缩；存储效率达到 Prometheus 的 2.6 倍，查询相对 Prometheus/Mimir 提升 30 倍，相对旧版 TSDS 的时序查询提升 160 倍，一年累计索引吞吐提升 50%。这些结果来自四项连续改动：Doc value skippers、Synthetic _id、序列号裁剪，以及将 Codec 块从 128 扩大到 512。Synthetic _id 不再为 _id 建倒排索引，而是由 _tsid 与 @timestamp 即时计算，并使用布隆过滤器去重；这一项使存储下降 34%、摄入 CPU 下降 6%，9.4 起在新时序索引中默认启用。

迁移路径尽量保持现有采集体系不动。Prometheus 或 OTel 继续通过 Remote Write 写入 /_prometheus/api/v1/write，由系统自动推断类型并将标签转换为维度。查询侧同时提供 PromQL 与 ES|QL：PROMQL 作为 ES|QL 的 source command，返回结果被转成普通列，后续还可以继续执行 WHERE、LOOKUP JOIN、排序和限制，也可以把结果交给大语言模型判断。当前对主流 Grafana 开源仪表盘的查询覆盖超过 80%，group modifiers、or/and/unless、histogram_quantile、predict_linear 等能力仍在路线图中，因此目标是逐步完成兼容，而不是忽略现有差异。

ES|QL 的变化不只是增加一种查询语法，而是以管道式语言配合新的计算引擎，承接原本需要在 Java 或 Python 代码中完成的数据转换、关联和后处理。

From、Eval、Where、Stats、Join、Sort、Limit 等步骤可以像 Unix 管道一样串联。管道中既可以使用文本搜索、向量搜索、地理位置搜索和聚合计算，也可以连接集群内、跨集群或外部数据，并在中间步骤调用推理能力完成问题回答、总结、翻译或文本生成。逐步连接的结构也便于大语言模型生成和修正查询。

在检索侧，MATCH、MATCH_PHRASE 和 QSTR 等全文函数把 _score 带入分析管道，查询可以组合 OR、权重和分数阈值，再继续排序和截断。9.4 增加对全部已摄入字段的访问：即使 JSON 字段写入时没有建立 mapping，也可以通过 JSON_EXTRACT 按路径读取和计算。对于结构变化频繁的日志，可以先按时间或关键词缩小数据范围，再对原始 JSON 做动态提取，以支持临时分析和故障排查。

计算侧的关键增强包括 Lookup Join、子查询、逻辑视图和近似查询。Lookup Join 支持多字段匹配、表达式 Join 和跨集群 Remote Join，右侧过滤条件可以自动下推，带过滤场景最高提速 90 倍；当前能力大致对应 Left Join，尚未覆盖完整的 Inner、Right 等 Join 语义。子查询允许在单条语句中组合多个独立管道，并把谓词下推到子查询内部。逻辑视图可以把复杂管道封装为虚拟索引，供仪表盘、告警、业务用户或 Agent 直接引用，减少重复生成查询和反复试错。近似查询通过采样完成大规模聚合，最高获得 100 倍提速，同时输出置信区间，用于先观察整体分布，再缩小范围执行精确统计。

TS 时序分析在 9.4 正式可用，提供 rate、changes、cumulative、trange、clamp 和 *_over_time 等聚合函数。聚合窗口可以小于时间桶，例如在 10 分钟时间桶中计算 5 分钟 RATE；降采样会感知计数器重置，通过保存首个值并在重置时补充辅助文档，提高 rate 计算准确性并保持向后兼容。METRICS_INFO 与 TS_INFO 则用于在提交重聚合查询前查看 schema 和指标结构，使日志与指标的监控、告警和报表可以继续使用同一语言和工具。

Agent 基础设施建立在多模态混合搜索之上：结构化数据、非结构化数据、BM25、稀疏向量、稠密向量和地理位置查询可以通过 RRF 融合；ES Inference API 连接云模型或自部署模型；ES|QL 与 API 用于定义 Agent 可调用的 Tools；MCP 对外提供服务；Agent Builder 与 Workflow 则分别完成 Agent 构建和多 Agent 编排。

Agent Builder 由 Agent Chat、Agents、Skills 和 Tools 四部分组成：Agent Chat 提供自然语言同步交互；Agents 将自定义指令与工具集组合为执行体；Skills 是按需加载的可复用领域技能包；Tools 把 Elasticsearch 数据、Kibana 仪表盘、工作流和 ES|QL 封装成模块化函数。9.4 新增 Skills、Attachments、Connectors 和 Plugins 四类原语。Skills 按需加载、结果卸载和选择性压缩共同使长对话 Token 成本在内部实测中下降 40%。现成内容包括 5 个安全 SOC 技能和 5 个 SRE 工作流技能，语义元数据层则用于发现 Elastic、Drive、SharePoint 等连接源中的对象。

Agent Builder 定义 Agent“知道什么、能推理什么”，Workflows 定义“行动时做什么”。Workflow 采用 YAML 描述多步过程，步骤可以调用 HTTP API、Kibana、Elasticsearch、内部 Agent 或外部 Agent；Agent 可以把 Workflow 当作工具，Workflow 也可以在步骤中调用 Agent。示例流程从恶意软件告警出发，依次查询 VirusTotal 文件哈希、创建高严重性案例、附上告警与可观测对象、通知 SOC 频道，并把 human.approval 作为行动前的人工检查点。9.4 的案例管理提供 25 个全生命周期自动化步骤，Human-in-the-loop 被作为一等原语。YAML 的声明式结构便于评审、移植，也适合由大语言模型生成符合 schema 的工作流。

贯穿四条技术主线的实施方式，是把不同层次的重复工作固化下来：将常用查询封装为逻辑视图和 Tools，将领域方法沉淀为 Skills，将多步骤行动写入 Workflow；PromQL、全文检索、向量查询、时序计算和 Join 则由 ES|QL 继续串联。这样，Agent 不必在每次请求中重新拼装全部查询，也不必为相同业务逻辑反复消耗 Token 和推理资源。企业私有数据的搜索、分析、推理与行动由此连接到同一套执行链路中。

阿里云ES免费试用：

https://free.aliyun.com/spm=5176.14058969.J_3759233040.1.1c5069afFW3p4q&productCode=elasticsearch 

分享嘉宾

INTRODUCTION

Jerry Zhu

Elastic 

中国首席解决方案架构师

往期推荐

面向企业智能办公 Agent 的本体驱动知识工程构建与应用

RAG 落地全干货深度分享：从“效果不理想”到生产级 RAG 系统的进化之路

这些坑不用再踩了！Agentic数据架构落地中的真实断点，一次说透！

数据工程师危？Claude Code vs. Data Agent实测对比，复杂SQL编写真要被替代了？

Palantir把Ontology写进代码：企业AI应用开始进入“本体即代码”时代

MemoHarness来了：Agent的下一次进化，开始发生在模型之外

从“字”到“画”：基于Elasticsearch Serverless 的多模态商品搜索实践

客服、审批、运营、协同——阿里董晓庆出品DACon「Agentic Workflow」论坛，谈数字员工如何重构企业流程

Data Agent 不该直接写 SQL，它需要一层“业务编译器”

模型越多越焦虑？Shopee大模型工程负责人李超：企业需要的不是选型清单，而是组合策略

点个在看你最好看

SPRING HAS ARRIVED