向量索引选型时如何比较召回、内存和更新代价

向量索引选型不能只看一次查询的速度。真正上线后，召回是否够用、索引占多少内存、文档更新会不会拖慢写入，往往比单次延迟更先暴露问题。以 Redis 的向量检索为例，FLAT 适合精确结果，HNSW 适合用图结构换取查询速度，支持压缩的 SVS-VAMANA 则更关注大规模场景下的内存边界。

官方文档：https://redis.io/docs/latest/develop/ai/search-and-query/vectors/

如果还没有真实基准，先用 FLAT 做小规模“精确结果基线”，再拿 HNSW 或 SVS-VAMANA 比较召回、p95 延迟、RSS、写入吞吐和重建时间。不要把“更快”直接等同于“更适合”。

先把召回、内存和更新代价拆开

“召回”回答的是：真实最近邻里，有多少被索引找回来了。一个常见做法是让 FLAT 对同一批查询产生精确 topK，把它当作参考集合，再计算近似索引命中的比例。这个比例只对当前 embedding、距离度量、过滤条件和 topK 有意义，不能把某次实验的数字搬到另一套模型上。

“内存”也不只是向量本体。向量维度、数据类型、索引图连接、元数据和查询工作区都会影响 RSS。HNSW 需要维护节点间的连接，参数 M 越激进，通常越需要内存；压缩方案可以降低占用，但要重新测精度。更新代价则要看在线写入、批量导入、向量替换和重建是否同时发生。

FLAT、HNSW 与 SVS-VAMANA 怎么选

FLAT 会把查询向量与索引中的向量逐个比较，结果精确、结构简单，代价是数据变大后查询工作量随规模线性增长。数据量还小、必须保留精确排序，或者你需要一个可靠的评测基线时，FLAT 往往是起点。

HNSW 用多层图缩小搜索范围，查询通常更快，但它不是免费加速：图连接增加了内存和建索引成本，近似搜索还需要用 EF_RUNTIME 等参数在召回与延迟之间取舍。它适合查询压力较高、能够接受可调近似结果、又希望跨硬件部署的常规生产场景。

SVS-VAMANA 是另一类图索引，在支持的 Redis/Redis Search 环境中可以配合压缩减少内存占用。它更适合向量规模和内存价格都成为约束的场景，但必须把兼容版本、数据类型和压缩后的召回一起列入验收条件，不要只看理论节省空间。

可以先用下面的参数骨架建立两个对照索引。示例只表达字段和算法的关系，实际 DIM、距离度量和数据类型要与 embedding 模型一致。

# 精确索引用于建立 topK 参考结果
FT.CREATE docs_flat ON HASH PREFIX 1 docs: SCHEMA \
  embedding VECTOR FLAT 6 TYPE FLOAT32 DIM 768 DISTANCE_METRIC COSINE

# 近似索引通过图参数平衡召回、内存与查询延迟
FT.CREATE docs_hnsw ON HASH PREFIX 1 docs: SCHEMA \
  embedding VECTOR HNSW 10 TYPE FLOAT32 DIM 768 DISTANCE_METRIC COSINE \
  M 16 EF_CONSTRUCTION 200 EF_RUNTIME 20

把更新代价放回业务读写节奏

如果数据是每天批量导入，索引构建时间和切换窗口可能比单条写入延迟更重要；如果是知识库持续接收新文档，就要观察在线写入和查询同时发生时的尾延迟；如果 embedding 模型升级，旧向量与新向量的替换还可能触发整批重算。相同的索引，在这三种节奏下结论并不一样。

FLAT 的维护结构相对直接，但数据越多，查询扫描和内存仍会持续增长。HNSW 更新时不只保存一个新向量，还要维护图关系，因此应把写入吞吐、图结构维护和后台重建分开记录。算法选择在索引创建时确定，若要从 FLAT 换成 HNSW，或在不同算法间迁移，通常需要新建索引、回填数据，再安排切换，而不是在线改一个开关。

评估时至少固定四件事：同一批向量和查询集、同一距离度量、同一 topK 与过滤条件、同一硬件和数据生命周期。然后记录以下结果：

• 以 FLAT 为参考的召回率，以及不同查询类型的最低召回表现；
• 冷启动和稳态下的 p50/p95 查询延迟、峰值 RSS；
• 批量导入、在线新增、向量替换时的写入吞吐和错误率；
• 创建、回填、重建和切换所需时间，以及失败后的回退路径。

用一张决策表收敛选型

这张表只能帮助你选出候选，不替代基准测试。特别是“数据量阈值”应当视为实验起点：模型维度、过滤比例、硬件和查询分布都会改变拐点。生产决策最好保留一份固定测试集，并把索引参数、Redis 版本和数据规模写入测试记录，方便下一次模型升级时复跑。

常见问题

HNSW 一定比 FLAT 好吗？

不一定。HNSW 通常用内存和近似结果换查询效率；数据规模小或必须精确排序时，FLAT 更容易解释，也更适合当基准。

召回率应该和什么结果比较？

用同一查询集上的 FLAT topK 作为参考集合，并固定距离度量、过滤条件和 topK。不要拿不同模型或不同过滤条件的结果直接比较。

能不能只调查询参数，不重建索引？

HNSW 的部分运行时参数可以调节召回与延迟，但 FLAT、HNSW、SVS-VAMANA 之间的算法切换属于索引结构变化，通常要新建、回填并切换。