阿里云 ES AI 引擎版：面向 Agent 场景，为亿级租户、千亿规模向量设计的搜索引擎

导读：基于 OSS 的无状态多租户搜索方案：全文、向量混合检索，亿级租户、千亿级向量，成本只与活跃数据线性相关，完全兼容 Elasticsearch 生态。

一、概述

搜索正在成为 AI 应用的核心基础设施，agent 场景搜索需求爆发式增长。与传统搜索相比，Agent 场景的搜索有三个鲜明特点：

强租户化：一个用户 / 一个代码仓库 / 一个知识库就是一个独立检索库，租户数从万级走向亿级，且冷热极端倾斜------绝大多数长期沉睡，少数突发活跃。
极致规模化：Agent 需求爆发式增长，单租户的数据规模与租户数量被同步推高。系统要能随之持续扩展，规模越大，查询延迟与召回越不能下滑。
数据实时涌入、负载起伏大：代码提交、文档编辑随时产生新数据，写入即需可查；批量接入新租户时写入陡增，查询流量又随用户活跃大幅波动------写入与查询相互争抢、资源需求频繁伸缩。

以企业知识库为例：平台同时托管数百万个知识库，每个企业 / 团队就是一个独立检索库、文档更新后需秒级可查，但同一时刻只有少数知识库在被问答访问。客户真正需要的不是单次向量查询更快，而是知识库数量与文档量持续增长时检索性能依然稳定、活跃库新增文档秒级可查，占绝大多数的沉睡库几乎不产生成本。

这些特点叠加在一起，恰恰是传统检索架构难以承受的地方。

二、AI 应用面临的检索挑战

面对这样的负载，传统检索架构有四个瓶颈：

💰 成本高：向量索引常驻内存、数据多副本，千亿向量需上万分片、100TB 以上内存；绝大多数租户长期沉睡，资源照付。
📉 规模化能力弱：向量数据库租户上限数万，搜索引擎到十万级租户即瓶颈；大规模下检索劣化到秒级，召回率随数据量下滑。
⚡ 弹性能力弱：扩缩容要搬数据，时间以小时计；故障靠副本重建，恢复慢。
🔀 读写互相影响：写入、建索引、合并与查询争抢同一批节点，写入洪峰引发查询抖动；

三、阿里云 ES 基于 OSS 的无状态多租户搜索方案

写入层、查询层、OSS 对象存储

OSS 是唯一持久存储（数据、WAL 日志、元数据）；计算节点无状态，本地 Memory / SSD 只作缓存。
写入以 WAL 落 OSS 为确认点，确认即持久；建索引与合并全部后台异步。
查询经 Memory / SSD 两级缓存按需加载，只读目标租户的数据。
一个租户 = 一个 Slice，存储上物理聚簇；Slice Collection 把亿级租户自动分布到多组物理索引，业务只见一个集合名。

3.1 对比业界竞品

同一负载下，与自建 ES、开源 Milvus 的逐项对比

对比维度	自建 ES	开源 Milvus	本方案（阿里云 ES）
千亿向量成本	高（内存索引 + 多副本 + 运维）	高（按内存计价）	低（OSS 单份存储，冷租户零常驻）
租户规模	十万级即瓶颈	上限数万	亿级租户
大规模检索性能	劣化至秒级	劣化至秒级	毫秒级查询，召回稳定
读写隔离	无，互相影响	弱	读写分离，互不影响
弹性	小时级，需搬数据	运维复杂	分钟级，无数据搬迁
全文 + 过滤 + 聚合	完整	较弱	完整，且与向量检索混合

四、核心技术

逐项应对成本、规模化、弹性与读写互扰四大挑战

01 对象存储原生的存算分离：以 OSS 为唯一数据源，而非冷数据分层：数据单份存储，较多副本 SSD 降低一个数量级；不被访问的租户不占任何计算与缓存；多 Bucket 存储池突破单桶带宽上限。

02 磁盘原生向量索引 DiskBBQ：不走 HNSW"向量与图常驻内存"的路线：分层 K-means 聚簇 + BBQ 量化，查询最多探两层质心、按块顺序读取命中簇，IO 可预测，天然适配 SSD 缓存与对象存储。

10×	平滑	2 层
索引构建速度约为 HNSW 的 10 倍	内存受限时性能平滑退化，HNSW 则断崖	查询最多探两层质心，IO 可预测

03 租户级物理隔离与集合扩展：同一租户的倒排、向量、行存、列存聚簇为连续区间，查询、缓存、预热、清理都以租户为边界------单租户检索成本只取决于自身数据量。Slice Collection 把亿级租户分配到多组物理索引，统一入口、集中治理。

04 读写分离与 WAL 实时写入：写入层与查询层独立伸缩，写入洪峰不影响查询延迟，反之亦然；WAL 同步落 OSS 即确认，建索引与合并不占读写路径。

05 无状态计算与自动容灾：节点除缓存外无状态：扩容即接流量，缩容即回收，无数据搬迁；故障由替换节点从 OSS 接续；写入层整体不可用时索引自动转只读可查，查询不中断。

五、核心能力

成本：整体成本相比自建 ES 降低 70%；存储较多副本 SSD 降低一个数量级；不活跃租户零计算、零缓存成本。
规模：千亿级向量、亿级租户；
性能：召回率 ≥ 0.95，不随规模衰减；数据可按租户预热，冷查询首访后即转热。典型数据集下的查询延迟（P99）：
- 向量检索（1024 维 · 10M 文档 · ~40GB）：热 ~30ms（1M）/ ~60ms（10M），冷 ~500ms（1M）/ ~1.5s（10M）。
- 全文检索（BM25 · 10M 文档 · ~9GB）：热 ~20ms（1M）/ ~50ms（10M），冷 ~470ms（1M）/ ~700ms（10M）。
读写分离：读写路径独立扩缩，写入层不可用时查询不中断。
弹性：分钟级扩缩容，无数据搬迁，亚分钟级故障恢复。
完整搜索能力：全文、向量、过滤、聚合混合检索；租户级导入、预热、清理与秒级 copy-on-write 分支。

六、典型应用场景和实际案例

为海量租户、极端冷热倾斜的 AI 负载而生

🤖 企业知识库 / RAG：亿级知识库统一承载，活跃库毫秒级响应，沉睡库零成本。
💻 AI Coding：每个代码仓库一个索引库，提交后秒级可检索；亿级仓库下单库延迟稳定。
🧠 Agent 记忆（Memory）：每个 agent / 会话独立记忆库，实时写入即查，海量 agent 下沉睡记忆零成本。

6.1 场景实例：某企业知识库

某企业知识库平台托管约 10 万个知识库、合计百亿级文档，需全文 + 向量混合检索，且 90% 以上长期冷置------少数库高频问答，绝大多数长期沉睡。

最佳实践

① 一个 SliceCollection 承载全部知识库 ：业务只面向一个 collection 名读写（PUT /_slice_collection/{name}），每个知识库就是一个 slice。

② 写入 ：沿用标准 ES API，用 _slice=<知识库 ID>（或 routing=<知识库 ID>）定位知识库，auto_create_slice 下首次写入自动建库：

shell 复制代码

# 单文档写入知识库 kb-42
PUT /kb-search/_doc/doc-1?_slice=kb-42
{ "title": "报销制度", "content": "......", "status": "published", "embedding": [0.02, 0.13, ...] }

# 批量写入，每条 item 指定所属知识库
POST /_bulk
{ "index": { "_index": "kb-search", "_id": "d1", "_slice": "kb-42" } }
{ "title": "......", "content": "......", "embedding": [ ... ] }
{ "index": { "_index": "kb-search", "_id": "d2", "_slice": "kb-87" } }
{ "title": "......", "content": "......", "embedding": [ ... ] }

③ 查询 ：_search?_slice=<知识库 ID> 只命中该知识库所在的 backing shard，单库检索成本只与自身数据量相关；跨库可传多 slice：

bash 复制代码

# 在知识库 kb-42 内做「全文 + 向量 + 过滤」混合检索
GET /kb-search/_search?_slice=kb-42
{
  "query": {
    "bool": {
      "must":   { "match": { "content": "如何申请报销" } },
      "filter": { "term":  { "status":  "published" } }
    }
  },
  "knn": {
    "field": "embedding",
    "query_vector": [0.03, 0.11, ...],
    "k": 10,
    "num_candidates": 100
  }
}

# 跨多个知识库检索
GET /kb-search/_search?_slice=kb-42,kb-87
{ "query": { "match": { "content": "年假天数" } } }

④ 缓存预热 ：对可预测访问（用户打开知识库时）用 POST /{collection}/_warm_slice?_slice=<知识库 ID> 主动预热。

成本和性能收益

七、总结与展望

本方案以 OSS 对象存储为唯一持久层，彻底解耦存储与计算，用一套统一架构同时化解了 Agent 时代检索面临的成本、规模、弹性与读写互扰四大难题：支撑亿级租户与千亿级向量、活跃库毫秒级响应，且成本只与活跃数据线性相关。它完全兼容 Elasticsearch 生态，全文、向量、过滤与聚合可混合检索，让业务无需在能力与成本之间取舍。

围绕这一底座，后续 Roadmap 将进一步释放对象存储原生架构的潜力：

秒级零拷贝分支（Branching）：基于 commit 的 copy-on-write 模型，为任意租户在常数时间内创建独立数据分支，不复制、不下载任何数据；创建后源库与分支读写互不影响，天然适配评测、灰度、A/B 与回滚。
自动弹性（Scale to Zero）：计算层随负载自动伸缩，空闲租户与集群可缩容至接近零，成本进一步向真实活跃负载对齐，把"不访问不付费"做到极致。
融入阿里云 Elasticsearch 生态：依托完整的 ES 生态能力，与 mem-0（Agent 记忆）、FalconSeek、SearchLake 等能力深度结合，构建面向 Agent 的一体化检索、记忆与数据底座。