你让一个语义搜索系统从海量商品里找出“适合雨天通勤的鞋”，它不会直接理解文字，而是先把商品和问题变成向量嵌入（embedding）——一串表示含义的数字，再寻找距离最近的记录。数据少时，可以逐条比较；数据多到上亿条，真正棘手的问题就变成：为了让搜索足够快，要买多少昂贵的内存？
Oleg Tereshin 在 Towards Data Science 的文章中梳理了三种常见选择：HNSW、SPANN 与 DiskANN。核心不是谁绝对更好，而是怎样在查询延迟、检索质量、RAM 用量和磁盘成本之间取舍。本文所有性能与适用范围判断均来自这一篇个人署名文章，未得到论文或独立基准测试的交叉验证。
先决定要不要“走捷径”
向量数据库通常包含三部分：向量嵌入、搜索算法与索引结构，以及存储方式。向量索引可以理解为书的目录：它提前组织数据，避免每次都从第一页翻到最后一页。
精确搜索，也就是 kNN，会遍历全部条目，计算查询向量与已有向量的距离。在距离度量、候选集合和实现条件一致时，它没有近似造成的质量损失，但数据越多，延迟和扩展压力越大。Tereshin 还称，一些现代向量数据库会对只有几千个向量的小集合跳过建索引，直接搜索；不过“几千”不是经过材料验证的通用门槛。
近似最近邻搜索（ANN）则主动少看一些条目，用一定的漏检风险换取速度和扩展能力。评估 ANN 不能只看“快不快”，还要同时看召回率——该找到的结果找回了多少——以及机器成本。
HNSW 快，但内存账单会长大
HNSW（Hierarchical Navigable Small World，分层可导航小世界）把相近向量连成分层图。搜索时，它沿着图中的近路逐步接近目标，不必扫描所有数据。文章将它归为 RAM-based ANN：全部或很大一部分索引留在 RAM，以较高内存成本换取很低的查询延迟。
问题出现在索引装不下，或继续购买 RAM 已经太贵的时候。文章认为，直接把 HNSW 搬到磁盘可能产生大量不连续的随机读取；一次搜索还要在图上多次跳转，磁盘 I/O 因而可能成为瓶颈。作者给出的描述是，延迟可能从毫秒级升到数百毫秒，在高 I/O 压力下甚至更差。另一条路是强力量化——用更紧凑的数字表示压缩向量——但文章称这可能损害检索质量。
这些数字不是硬件无关的保证。实际结果会随数据规模、向量维度、参数和工作负载变化。
SPANN 先找区域，再去磁盘取货
SPANN 面向落盘索引，采用倒排索引式的组织方法。它先把向量分成多个簇，每簇用一个中心点（centroid）代表。中心点和路由层可以放在 RAM，体积更大的向量留在磁盘。
搜索时，系统先通过中心点判断答案可能在哪几个簇，再读取对应向量。文章特别强调，同一中心点代表的向量会在磁盘上连续存放。直观地说，它不是让磁盘四处翻找，而是先确定货架，再连续取出一段货物。材料称 SPANN 的设计目标包括无法全部装进 RAM、规模达到十亿向量以上的索引；这仍是原作者的适用范围判断，并非本文独立验证的阈值。
DiskANN 也被文章列为主要依赖磁盘、减少 RAM 使用的 ANN。不过供稿在展开 SPANN 搜索流程时已经截断，没有提供 DiskANN 的具体结构、读取方式或对照数据，因此无法据此做三者的定量排名。
真正的选择是把什么留在 RAM
这组比较值得关注，因为“落盘”并不是简单地把内存文件复制到磁盘。HNSW 的图遍历追求快速跳转，放到磁盘后可能带来零散读取；SPANN 则通过分簇和连续存放，让磁盘读取更集中。工程上的关键问题因此是：哪些热点路由结构值得留在 RAM，哪些大块数据可以放盘，以及团队能接受多少延迟和漏检。
文章也提醒，这些类别不是绝对边界。HNSW、SPANN 和 DiskANN 的底层结构都可能部分放在内存、部分放在磁盘。实际系统还可能使用缓存、压缩或量化。与其问“内存索引还是磁盘索引”，不如问“每一层分别放在哪里”。
局限与未知
- 供稿只有一个二手技术文章信源，没有论文、官方文档或统一基准测试，无法验证不同算法在相同条件下的延迟、召回率与成本。
- 原始材料被截断，SPANN 的完整流程与 DiskANN 的实现细节均未披露，不能据此判断两种落盘方案谁更优。
- “小中型”“十亿向量以上”等范围只是粗略提示。最终选择仍取决于数据规模、维度、参数、硬件和实际查询负载。