1. 概述

搜索技术正迅速演变为AI应用的核心基础设施，在Agent场景中这一趋势尤为突出。目前，Agent场景下的搜索需求正经历爆发式增长，但与传统搜索相比，它呈现出几个显著特征。只有充分理解这些特点，才能明白为何需要一套全新的检索架构来支撑。

• 强租户化：每个用户、每个代码仓库、每个知识库都是一个独立的检索库。过去，租户数量可能只有万级，而现在直接跃升至亿级。更关键的是，这些租户的冷热程度极端分化——绝大多数长期处于“沉睡”状态，只有少数会突然活跃起来。
• 极致规模化：随着Agent需求的爆发，单个租户的数据规模与租户总数同步被推高。系统必须能够持续扩展，而且规模越大，查询延迟和召回率越不能下降，这对架构的线性扩展能力提出了极高要求。
• 数据实时涌入、负载起伏大：代码提交、文档编辑随时产生新数据，写入后必须能在秒级内被检索到。批量接入新租户时写入量会飙升，查询流量又随用户活跃程度大幅波动。写入和查询互相争抢资源，资源需求频繁伸缩。

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

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

2. AI 应用面临的检索挑战

面对这样的负载，传统检索架构存在四个绕不开的瓶颈：

• 成本高：向量索引常驻内存，数据多副本。千亿向量需要上万分片、100TB以上内存。问题是，绝大多数租户长期沉睡，资源照付不误，成本像“无底洞”。
• 规模化能力弱：向量数据库租户上限数万，搜索引擎到十万级租户就遇到瓶颈。大规模下检索性能劣化到秒级，召回率随数据量增长持续下滑。
• 弹性能力弱：扩缩容要搬数据，时间以小时计。故障恢复依赖副本重建，过程缓慢。
• 读写互相影响：写入、建索引、合并与查询争抢同一批节点。写入洪峰一来，查询就跟着抖动，谁也跑不了。

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

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

这套方案的核心思路非常清晰：

• OSS是唯一持久存储，数据、WAL日志、元数据都存放在这里。计算节点无状态，本地Memory/SSD仅作为缓存使用。
• 写入以WAL落OSS为确认点，确认即持久化。建索引与合并全部在后台异步完成，不阻塞写入路径。
• 查询通过Memory/SSD两级缓存按需加载，只读取目标租户的数据，不浪费任何资源。
• 一个租户等于一个Slice，存储上物理聚簇。Slice Collection将亿级租户自动分布到多组物理索引，业务端只看到一个集合名，简单又强大。

3.1 对比业界竞品

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

4. 核心技术

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

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

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

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

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

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

5. 核心能力

• 成本：整体成本相比自建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分支。

6. 典型应用场景和实际案例

为海量租户、极端冷热倾斜的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下首次写入自动建库：

# 单文档写入知识库 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：

# 在知识库 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>主动预热，减少冷查询延迟。

成本和性能收益

7. 总结与展望

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

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

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