在 Milvus 以及业界绝大多数主流向量数据库中HNSW 都是默认且性能最优的密集向量索引算法。HNSW 是一种基于图的近似最近邻ANN搜索算法。它的核心思想是构建多层结构的图底层是包含所有节点的密网越往上层节点越稀疏类似于生活中的“高速公路-国道-乡道”网络。HNSW 的重要参数分为两类建索引Index Building时的参数和检索Search时的参数。1. 建索引期参数影响内存与构建时间这两个参数在你调用 Milvus 的create_index接口时需要一次性设定好一旦建好索引就无法更改除非重建索引。M(最大边数 / Maximum Degree)含义在构建图时每个节点在每一层中与其他节点相连的最大边数即每个节点最多能有几个“邻居”。作用原理它直接决定了图的“密集程度”。权衡 (Trade-off)M越大图的连通性越好搜索时不容易陷入局部最优召回率准确率更高。代价会显著增加内存消耗因为要存储更多的边并且建树时间会变长。经验值通常设置为 8 到 64 之间。对于简单的低维数据8 或 16 足够对于高维数据或追求极高召回率的场景常设置为 32 或 48。efConstruction(构建时的候选集大小)含义在插入新节点并为其寻找最近邻居连边时系统会在内部维护一个动态候选队列这个参数就是该队列的最大长度。作用原理它决定了建树时的“搜索深度”和“连接质量”。权衡 (Trade-off)efConstruction越大算法在建树时会探索得更广构建出的图质量越高越接近真实的物理距离分布从而提升最终检索的召回率上限。代价会成倍增加建索引的时间。但好消息是它不会增加内存消耗也不会影响查询时的延迟。经验值通常设置为 64 到 512 之间。一条常见的经验法则是让efConstruction至少等于M * 2。2. 检索期参数影响延迟与准确率这个参数是在你实际发起向量查询调用search接口时动态传入的也就是你可以针对不同业务场景随时调整的“旋钮”。ef(检索时的候选集大小有时也称efSearch)含义在实际执行搜索时用于控制搜索路径宽度的动态候选队列大小。它决定了算法在图中漫游时同时追踪多少个可能有潜力的分支。作用原理这是调节“性能 vs 准确率”最核心的参数。权衡 (Trade-off)ef越大探索的节点越多找到绝对最近邻的概率越大召回率越高。代价搜索延迟Latency显著增加系统吞吐量QPS下降。硬性限制ef的值必须大于或等于你期望返回的 Top-K 结果数即ef top_k。经验值通常在 16 到 256 之间调整。如果你的业务要求top_k10你可以先将ef设为 64测试召回率和耗时如果嫌慢就降到 32如果准确率不够就提至 128。总结与调优建议资源充足且追求极致准确率在建库阶段下血本。调大M如 32 或 48和efConstruction如 256 或 512。虽然建库很慢、占内存大但底子打得好。查询时给一个中等偏上的ef即可获得极高召回率。对 QPS 要求极高需要毫秒级响应维持适中的M16 左右并在查询时尽可能压低ef的值逼近你的top_k。