阿里云 Elasticsearch AI 引擎版是一款面向 RAG、AI Coding、Agent 记忆和多租户搜索场景的云原生搜索引擎，以 Collection 作为统一访问入口，通过 Slice 组织知识库、代码仓库、Agent 或租户等不同业务空间。
产品概述
阿里云 Elasticsearch AI 引擎版基于 Elasticsearch 9 系列构建，在支持范围内提供全文检索、向量 KNN、过滤和聚合等搜索能力，并以 Collection 作为统一访问入口，通过 Slice 组织知识库、代码仓库、Agent 或租户等不同业务空间。
其核心架构可以概括为三点：持久数据统一保存在对象存储，写入与查询由不同节点负责，多个业务空间通过 Collection 和 Slice 统一组织。
为什么需要：多业务空间搜索的挑战
RAG、AI Coding、Agent 记忆和多租户搜索应用通常需要在一套检索系统中承载多个彼此独立的知识库、代码仓库、记忆空间或租户数据空间。这类业务普遍面临三个挑战：
多业务空间并存：不同业务空间的访问模式差异显著，有的持续活跃，有的长期低频。若为每个空间分别维护索引，管理和容量规划会随着业务增长日益复杂。
冷热分布不均：大量低频空间长期占用计算与存储资源，而活跃空间又需要稳定的低延迟响应，传统架构难以兼顾成本与性能。
读写负载峰谷不同：数据写入和查询各有峰谷。若写入、索引构建和查询共享同一组节点，写入洪峰会直接冲击查询延迟。
针对这些特点，AI 引擎版将持久化存储、写入计算和查询计算解耦：索引数据和持久状态统一保存在对象存储中，索引节点（Index 节点）负责写入与索引构建，查询节点（Search 节点）负责查询。业务可以按写入量和查询量分别配置资源；活跃数据通过本地缓存加速，低频数据在访问时按需加载。
说明：控制台售卖页与实例列表中，两类节点分别显示为「索引节点」和「查询节点」，对应本文的 Index 节点和 Search 节点。
能解决什么问题：核心优势与适用场景
读写分离，独立扩缩
写入和查询使用不同的节点角色。业务可以根据数据接入量配置索引节点，根据查询并发配置查询节点。当其中一类负载增长时，只需调整对应资源，消除写入、索引合并和查询对同一组计算资源的争用。写入洪峰不影响查询延迟，反之亦然。
按需缓存，冷热自动分层
完整索引数据保存在对象存储中，查询节点的本地磁盘用于查询缓存。经常访问的数据持续从缓存中复用（热查询毫秒级响应），低频数据在需要时再从对象存储加载。本地缓存围绕活跃工作集规划，不必等同于全部数据规模；不活跃的业务空间不占用计算和缓存资源，存储成本仅为对象存储按量费用。
缓存收益取决于业务的冷热分布、缓存容量、节点规格和查询并发。对于访问范围高度分散或频繁变化的业务，应使用实际数据进行容量评估和性能测试。
亿级业务空间，统一管理
应用可以将一个知识库、代码仓库、Agent 或租户作为一个 Slice，并通过同一个 Collection 完成读写。平台根据容量管理底层索引和分片，应用无需为每个业务空间分别创建索引，也不需要在业务代码中维护底层索引名称及表结构。
查询时可以选择一个 Slice、多个 Slice，或显式选择全部 Slice。默认要求应用明确给出查询范围，可以减少因遗漏路由信息而误查整个 Collection 的风险。
故障秒级恢复，无需数据搬迁
索引数据、写入日志和集群状态保存在对象存储中，计算节点无本地持久状态。节点故障后，平台可快速调度替换节点从对象存储恢复运行并按需重建本地缓存，无需完整数据搬迁。相比传统有状态架构数十分钟到数小时的分片恢复，故障影响范围显著缩小。
如果写入层暂时无法承载主分片，新写入会暂停；当对应的 Search 分片仍然可用时，系统可以继续查询已经持久化并发布的数据。
兼容 Elasticsearch 生态
在支持的 API 范围内，应用可以继续使用 Elasticsearch REST API 和 Query DSL，并组合使用全文检索、向量 KNN、过滤与聚合等能力。官方 Python / Java / Go / JavaScript 客户端、Kibana 等生态组件可沿用兼容接口的请求结构和查询语法，减少接口层改造。迁移前，请根据实例版本对应的兼容性文档验证所使用的接口和生态组件。
适用场景
场景 | 建议的数据组织方式 | 核心价值 |
企业知识库与 RAG | 将每个知识库作为一个 Slice | 一个 Collection 统一管理亿级知识库；活跃库毫秒级响应，沉睡库仅产生对象存储费用 |
AI Coding 与代码搜索 | 将代码仓库或项目作为一个 Slice | 代码提交后秒级可搜索；开发者实时检索不受批量写入影响 |
Agent 记忆 | 按租户、Agent 或独立记忆空间划分 Slice | 实时写入即可查；海量 Agent 的沉睡记忆不消耗计算和缓存资源 |
多租户搜索服务 | 将每个租户或业务空间作为一个 Slice | 平台管理底层索引，租户间数据物理聚簇；单租户查询成本只取决于自身数据量 |
由哪些模块组成：核心概念与架构
核心概念
理解 AI 引擎版时，首先需要区分 Collection 和 Slice：
概念 | 说明 |
Collection | 应用访问数据的统一入口，使用方式类似 Elasticsearch 索引名。一个 Collection 可以包含多个业务空间。 |
Slice | Collection 内的一个逻辑数据空间。例如，可以将一个知识库、代码仓库、Agent 或租户作为一个 Slice。 |
读写数据时，应用使用 Collection 名称访问数据，并通过 Slice 指定对应的业务空间。平台负责将请求路由到 Slice 对应的数据，并管理底层索引和分片；应用无需保存或直接操作底层索引名称。
重要：Slice 用于组织数据和限定查询范围，不等同于账号权限边界。如需不同租户之间的身份鉴权和权限隔离，需要结合应用鉴权及产品支持的安全机制进行设计。
核心架构
持久状态保存在对象存储中，写入与查询资源各自扩缩，查询数据按需进入本地缓存。各组成部分的职责如下。
组成部分 | 主要职责 |
Collection 与 Slice | Collection 作为数据访问入口；Slice 标识 Collection 内的业务空间，平台据此将请求定位到对应数据。 |
索引节点（Index 节点） | 处理文档写入、写入日志持久化、索引构建和后台合并。 |
查询节点（Search 节点） | 执行全文、向量、过滤和聚合查询，并在本地缓存查询所需的数据。 |
对象存储 | 保存索引数据、写入日志和集群运行所需的持久状态。数据持久性 ≥ 11 个 9，按实际存储量计费，无需预配容量。控制台实例详情页中，该部分容量显示为「OpenStore存储」和「OpenStore存储用量」。 |
数据如何写入
写入数据时，应用在请求路径中使用 Collection 名称，并通过 Slice 标识数据所属的业务空间。
索引节点处理请求。写入日志（Translog）同步保存到对象存储后，系统才向客户端确认写入完成。
索引节点在后台生成索引文件并发布新的索引版本（Commit）。查询节点刷新后，新数据按照 Elasticsearch 的近实时语义进入查询结果。
数据如何查询
查询数据时，应用在请求路径中使用 Collection 名称，并通过 Slice 指定一个或多个业务空间。默认情况下，未指定 Slice 的查询会被拒绝，避免无意发起全量查询。
查询节点先从本地共享缓存读取查询所需的数据。
缓存未命中时，查询节点再从对象存储加载本次查询需要的数据范围；后续查询可以继续复用已经进入缓存的热点数据。
如需在节点故障时保持查询可用，请参见《AI 引擎版使用指南》配置副本数和查询节点数。
磁盘原生向量索引（DiskBBQ）
AI 引擎版使用磁盘原生向量索引 DiskBBQ，通过分层 K-means 聚簇加 BBQ 量化实现 IO 可预测的 KNN 查询。查询时最多探两层质心、按块顺序读取命中簇，天然适配 SSD 缓存与对象存储，不要求向量常驻内存。相比 HNSW，DiskBBQ 索引构建速度约提升一个数量级，且在内存受限时性能平滑退化而非断崖下跌。
性能参考
以下结果来自 2026 年 7 月份在一个典型应用场景下的测试，用于展示该测试条件下的冷热查询性能。测试结果不构成产品 SLA、实例规格承诺或其他环境下的普遍性能结论。
测试项 | 配置 |
测试环境 | 阿里云 Elasticsearch AI 引擎版，2 个索引节点、2 个查询节点，规格均为 16 核 64 GiB |
数据规模 | 10,000 个业务空间，共 9368 万条文档，2.8 TB 数据 |
向量配置 | 512 维向量， |
查询方式 | KNN 查询，返回 10 个结果，候选集为 100 |
延迟口径 | 服务端处理时间 |
访问状态 | 样本数 | P50（中位数） | P90 | P99 |
冷查询 | 180 | 225 ms | 377 ms | 605 ms |
热查询 | 1,800 | 1 ms | 32 ms | 65 ms |
上述数据基于 16 核 64 GiB 规格的索引节点和查询节点得到。节点规格、节点数量下限及专有主节点配置以购买页当前可选项为准；在低于测试规格的配置下无法复现上述延迟表现，请勿按最小规格预期同等性能。
实际查询性能还会受到单个 Slice 数据量、向量维度、召回参数、节点规格、缓存容量、并发负载和网络条件等因素影响。正式选型前，应使用业务的真实数据和查询进行容量评估与压测。
版本与兼容性
AI 引擎版采用 9.99.x 版本号。9.99 表示产品属于 Elasticsearch 9.x 兼容系列，末位版本号用于区分 AI 引擎版自身的功能迭代。该版本号不与 Elasticsearch 9.x 的具体小版本一一对应，也不表示支持 Elasticsearch 9.x 的全部功能和 API。
不同 9.99.x 版本支持的功能和 API 可能有所差异。创建实例或迁移业务前，请根据控制台显示的实例版本查阅对应的 API 兼容性文档，确认数据访问、查询范围、向量检索、数据复制和安全能力等功能的支持情况。
当前AI 引擎版 9.99.0 对应 Elasticsearch 内核版本 9.5.0，因此集群 API 返回的版本号与控制台显示的版本号不同。后续 Elasticsearch 实际版本以集群 API 返回结果为准。安装自定义插件时，请使用与 AI 引擎版匹配的 9.99.0 版本号。
地域与可用区
AI 引擎版在 8 月 30 日前仅限白名单用户申请开通，其支持的地域和可用区以购买页实际可购买项为准；实例规格、计费方式和开通流程以阿里云官网、控制台及正式发布公告为准。正式迁移前，建议结合 API 兼容性、数据规模、冷热分布和目标查询负载完成方案评估与性能验证。
下一步：如何使用
建议按以下步骤开始使用AI 引擎版实例 ：
确认地域与版本：在阿里云官网或控制台确认目标地域已开放售卖，并查阅实例版本对应的 API 兼容性文档，确认所依赖的接口和生态组件受支持。
规划数据组织方式：结合适用场景章节，确定以知识库、代码仓库、Agent 或租户为粒度划分 Slice，并规划 Collection 的数量与命名。
创建实例并配置资源：按预期写入量配置索引节点，按查询并发和活跃工作集配置查询节点；如需在节点故障时保持查询可用，请参见《AI 引擎版使用指南》配置副本数和查询节点数。
接入与验证：使用 Elasticsearch REST API 或官方客户端完成写入与查询接入，通过 Slice 指定查询范围，验证全文、向量 KNN、过滤和聚合等能力。
容量评估与压测：使用业务的真实数据和查询进行容量评估与性能压测，重点关注冷热查询延迟与缓存命中表现，再进行正式迁移。
后续方向
围绕对象存储原生架构底座，后续规划包括：秒级零拷贝分支（基于 copy-on-write 为任意 Slice 创建独立数据分支，适配评测、灰度与回滚）、计算层 Scale to Zero（空闲业务空间自动缩容至接近零，成本进一步向真实活跃负载对齐）、以及与阿里云 Elasticsearch 生态能力的深度结合。具体特性发布时间以产品公告为准。