跳转至

向量存储支撑 Agent 检索链路：三种索引取舍与 Serverless 化（千问AI平台）

Ch11.150 向量存储支撑 Agent 检索链路：三种索引取舍与 Serverless 化（千问AI平台）

📊 Level ⭐⭐ | 8.3KB | entities/vector-storage-agent-retrieval-qianwen-aliyun-2026.md

向量存储支撑 Agent 检索链路：三种索引取舍与 Serverless 化

阿里云官方（千问AI平台）从 Agent 实际需求出发，系统梳理向量存储在 Agent 检索与记忆中的角色、三种主流 ANN 索引实现的取舍、混合检索与分布式查询的设计思路，并首次把「Serverless 资源交付」作为 Agent 场景下的新选型维度，给出 Tablestore SearchIndex 与 OSS Vectors 两种 Serverless 向量存储的产品化用法。

向量存储在 Agent 中的双重角色

向量存储并非所有 Agent 的必选组件——当数据量很小、内容能完整放入上下文、或查询总能通过确定主键完成时，文件和普通数据库已够用。它主要处理「数据规模持续增长、查询者不知道准确位置和关键词、只能根据内容含义寻找结果」这类问题。

在需要处理外部知识和跨任务记忆的 Agent 架构里，向量存储承担两个角色：检索（为当前任务补充模型参数外的外部数据，解决用户问题与原始资料的语义表达差异）和记忆（把历史对话、执行结果、用户反馈向量化，让 Agent 跨任务复用经验，如运维 Agent 用当前故障现象检索过去症状相似的处理记录）。两个场景本质是同一件事：从持续增长的数据中找出与当前任务语义相关的内容。

三项关键技术：索引、混合检索、分布式

一个完整向量存储系统要同时管理向量、文本和元数据，写入查询都围绕这三类数据展开。三项技术直接影响能力边界：向量索引（避免全量扫描）、混合检索（组合语义+关键词+业务条件）、分布式架构（突破单机容量吞吐）。

三种 ANN 索引路线

实际系统用 ANN（近似最近邻）索引避免全量计算，代价是可能漏掉真实近邻。评价指标为召回率（近似 TopK 与精确 TopK 重合度）、查询性能、资源成本、数据规模。主流没有一种索引能同时最优，三类路线是：

  • HNSW（内存图索引）：多层邻接图，上层节点少跨度大快速接近目标、底层节点多密度完成局部搜索；用内存换低延迟高召回，适合查询频繁、延迟要求高、能提供足够内存的场景
  • DiskANN（磁盘图索引）：针对 SSD 优化，内存保留量化向量/入口点/热点，完整向量及主要图数据放 SSD，用较少内存维持在线查询承载更大规模；适合规模大、仍要求稳定在线查询的场景
  • IVF（聚类分区索引）：先训练聚类中心，把向量分到最近分区，查询只在相近分区内计算（nprobe 调节搜索分区数）；元数据小、易利用大容量低成本存储，适合超大规模、成本敏感场景

三种路线差异可归纳为「数据组织 × 查询路径 × 主要资源 × 适合场景」，不存在统一最优，选型要在相同召回率目标下用业务数据比较延迟、吞吐、成本。

混合检索与分布式查询

混合检索的关键是候选如何产生、过滤在哪一步执行、结果怎样排序。过滤时机直接影响结果：先召回向量 TopK 再按租户/权限过滤会导致大量候选被排除、最终数量不足，让过滤条件参与候选生成才能在满足业务条件的数据中找近邻。全文和向量分数含义不同不能直接相加，常见做法是归一化各路分数或用 RRF（Reciprocal Rank Fusion）按排名融合——RRF 不依赖不同引擎原始分数尺度，多系统召回中易落地。混合检索可在单引擎内完成，也可多系统召回后应用层合并（后者更灵活但要处理数据同步、延迟、融合）。

分布式查询把数据和索引拆到多分片，各分片并行返回局部 TopK，协调节点合并成全局 TopK。查询成本取决于访问多少分片：全部可能含近邻则广播整个索引，能按租户/业务属性准确路由则查询前缩小范围（减少计算/网络开销和合并压力）。扩容带来分片迁移和索引重建，需保持查询稳定。

Serverless：Agent 场景下的新选型维度

选型分两层：第一层是检索能力和数据规模（三项技术怎么匹配业务），第二层是资源如何创建、交付和计费——过去主要关注前者，但 Agent 应用让后者越来越重要。三个因素互相影响，不能单项选择，要从完整数据和查询负载出发。

Agent 平台可能按用户/任务动态创建大量数据空间，负载差异很大（有的长期空闲、有的持续活跃、有的短暂突发）。固定实例很难经济地承载这种分散且变化频繁的负载——Agent 需要的不是更大的实例，而是能跟着负载走的交付方式。Serverless 让用户只管理逻辑数据空间，系统按负载自动扩缩容、按实际使用量计费，Agent 平台通过 API 创建和使用存储，低频空间不长期占用实例，突发查询不依赖人工调容量。

阿里云两种 Serverless 向量存储

阿里云在表格存储和对象存储中提供 Serverless 向量能力，面向不同查询场景：

  • Tablestore SearchIndex：把向量检索放入多元索引，向量、全文、业务字段可在一次查询中组合，适合需要混合检索的在线查询。资源层次为实例→数据表→多元索引，创建向量字段时指定维度和距离度量；数据表按主键读写，SearchIndex 负责向量/全文/条件查询
  • OSS Vectors：通过 Vector Bucket 和 Vector Index 管理向量及元数据，与普通 OSS Bucket 原始内容关联（object_key），适合海量、长尾向量数据。原始文档/图片/视频放普通 Bucket，向量记录通过 object_key 关联，查询结果不保存完整内容也能在召回后读原文/媒体

两种服务都通过 API 管理逻辑资源，用户不需部署维护向量检索集群。Agent 平台保存业务空间与云资源映射，多小规模租户可共享索引通过 tenant_id 过滤，隔离要求高/规模大的用独立索引；底层索引构建、分片、扩缩容、故障恢复由服务完成。

工程落地要点

写入和查询必须用相同 Embedding 模型、向量维度、距离度量，否则向量空间语义关系对不上；换模型用版本字段隔离新旧向量，索引重建完成后再切换查询版本；多租户每次查询带租户条件，少一次可能返回跨租户结果；向量记录保留原始数据标识，不然检索到内容却不知来源；召回率和资源消耗受 TopK、过滤条件、数据分布共同影响，必须用真实数据验证（尤其 OSS Vectors 的标量过滤在结果阶段执行，过滤筛掉大部分结果时 TopK 设再大返回数量也可能很少）。

关联实体