HNSW Explorer：可视化的分层可导航小世界
观察搜索如何穿行于分层图中——从稀疏的顶层（高速公路）一直向下延伸至稠密的底层（地方道路）。拖动第 0 层的查询点，并调整M / ef ，观察图结构如何变化。
搜索统计
图层分布
HNSW 的工作原理
- 分层图：每个节点通过指数分布随机分配一个最大层级。大多数节点仅存在于第 0 层；极少数能到达顶层。
- 在每一层中：每个节点与其
M个最近邻相连。较高层较为稀疏（节点少，边长长 = “高速公路”）。第0层较为密集（所有节点，边长短 = “当地道路”）。 - 搜索从顶部开始：从一个固定的入口点出发，贪婪地向最接近查询的邻居移动，重复此过程直至不再有改进。
- 下移一层并重复：上一层的位置将成为下一层遍历的起点。每次下移都会通过更精细的边来优化结果。
- 第0层与
ef：在底层，HNSW 不会在第一个局部极小值处停止，而是维持一个ef最佳候选向量，并扩展其邻域。更大的ef→ 精度更高但速度更慢。
为何如此快速：顶层就像是索引之上的索引——只需跳转几次就能覆盖巨大距离，然后进行缩放。对于 N 个点，搜索过程大约会访问O(log N) 个节点，而不是N 个节点。
什么是HNSW ？
HNSW (Hierarchical Navigable Small World)是一种基于图的近似最近邻算法。它将向量组织成一摞可导航的小世界图：上层为稀疏图，具有用于粗略路由的长程边；底层为稠密图，具有用于最终精细遍历的短边。 搜索过程在每一层都贪婪地向查询点跳跃，然后向下移动——仅访问约O(log N) 个节点，而非扫描全部N个节点。
HNSW 是使用最广泛的内存向量索引，也是Milvus 中的默认图索引。Milvus 还提供 HNSW_SQ 以及 HNSW_PQ 变体，这些变体会对存储的向量进行量化，以牺牲少量召回率为代价来节省内存。
HNSW 参数在Milvus
M(构建时间)：每个节点的最大边数，与上方的滑块控制相同。典型值为 8–64。较高的 M 值可提高召回率和图的连通性，但会线性增加内存占用并减慢构建速度。efConstruction(构建时间)：插入节点时使用的候选向量池大小。数值越大，构建的图质量越高（可实现的召回率越高），但索引构建速度会相应变慢。典型取值范围为 100–500。ef/ef_search（查询时间）：在第0层遍历过程中保留的候选向量池——这是搜索时控制召回率与延迟的主要参数。其值必须至少等于top-K 。将其增大直至召回率趋于平稳；延迟将大致与之呈线性增长。
HNSW vsIVF vsDiskANN
HNSW 通常在内存搜索中能以高召回率提供最佳查询延迟——这就是为什么当数据集（加上图的开销）能容纳在RAM 内时，它会成为默认选择。其代价是内存和构建时间：图结构会为每个向量增加明显的开销，且插入操作比IVF 中的k-means分配更慢。 当您需要快速构建索引或进行激进量化时，请选择IVF ；当数据集过大而无法使用RAM ，但您仍需要高召回率时，请选择DiskANN 。
常见问题
HNSW 中的M参数控制什么？
M 限制了每个节点在每一层中保留的边数。较大的 M 值能使图的连通性更好——召回率更高且路由更稳健——但内存消耗会随 M 呈线性增长，且索引构建速度会变慢。8 到 64 之间的数值可覆盖大多数工作负载；16–32 是常见的最佳范围。
ef 和efConstruction 有什么区别？
两者均为候选向量池的大小，但在不同时间点应用。efConstruction 在构建索引时使用：它决定了每个插入节点搜索邻居的彻底程度，从而控制图的质量。ef （ef_search ）在查询时使用：它控制第0层（Layer-0）搜索的范围，在每次查询中权衡延迟与召回率。
HNSW 索引需要多少内存？
大致包括原始向量和图：对于 float32 数据，每个向量约占用 d × 4 字节，加上每个节点约 M × 2 × 8 字节的边数据。对于内存受限的部署，Milvus 提供了HNSW_SQ 和HNSW_PQ ，这些方法可对存储的向量进行量化；或者使用DiskANN ，该方法将完整向量移至SSD 。
何时应使用 `HNSW ` 而不是 `IVF`？
当高召回率下的查询延迟是优先考虑因素且索引能完全驻留内存时，请使用HNSW ——它通常能胜出。若需频繁重建索引（构建速度更快），或需结合SQ8/PQ 量化以适应紧张的内存预算，请优先选用IVF 。