这两个参数常被混淆，但作用域完全不同。ef 控制 HNSW 图搜索时的候选集宽度，主要解决「图搜索不足导致的遗漏」——调大 ef，算法会在当前层探索更多节点，召回提升但 QPS 下降。refine_k 控制 refinement 阶段用原始浮点向量重排的候选规模，主要修正「量化距离造成的排序偏差」——即使图中找到了正确候选，量化后的距离计算可能把它们排到后面，增大 refine_k 可以拉回这些正确项。关键结论：当 PQ/PRQ 召回率进入平台期后继续提 ef 收益有限，应转向增大编码预算或启用 refinement。

SQ 逐维独立量化(每个 float32 映射为 uint8)，压缩比固定约 4x，计算简单；PQ 将高维向量切分为 M 个子向量，每个子空间用 k-means 聚类形成码本，用码本索引替代浮点值，压缩比由 M 和 nbits 控制，可高达 16x+；PRQ（Polarized RaBitQ）是 Milvus 引入的新型量化，在保持 PQ 压缩比的同时，通过极坐标下的对称化设计减少量化误差，在 Cohere 1M 测试中 Recall@100 比 PQ 提升约 18 个百分点。三者的本质差异在于：SQ 牺牲精度换内存，PQ 在子空间做聚类压缩，PRQ 则在极坐标系中做更紧凑的表示。

文章聚焦 HNSW 系列量化变种，但实际工程中 IVF-PQ 是另一个主流路线。IVF 通过 k-means 聚类将向量分桶，查询时只搜最近的 nprobe 个桶，内存占用远低于 HNSW（无图结构指针开销），更适合十亿级以上超大规模场景。阿里云和 SelectDB 的测试数据显示，IVF-PQ 在百亿级 DINO 数据集上导入吞吐达 17 万 向量/秒，是 HNSW 的 4 倍以上。但 IVF-PQ 的 P99 延迟通常比 HNSW 高一个数量级，召回率峰值也更依赖 nprobe 的暴力增大。HNSW 赢在低延迟与高召回，IVF-PQ 赢在内存效率与导入速度，不存在绝对最优。

文章所有结论基于内存索引（HNSW 全在 RAM），但阿里云已将 DiskANN 与 RaBitQ 量化深度融合，在 1 亿 768 维数据上将磁盘索引 QPS 提升至开源 Milvus 的 20 倍，P99 延迟降至 1/10，内存减少 29%，召回率 98%+。DiskANN 用 Vamana 图替代 HNSW 的多层图，配合 PQ 或 RaBitQ 做内存距离估算，核心数据驻留 SSD。这正在改变量化索引的选型框架：过去工程师在『内存够就 HNSW，内存紧就 PQ』之间做取舍，未来『用磁盘换内存 + 近似图 + 新型量化』的组合可能让亿级场景不再依赖 HNSW 的内存开销。

文章给出的是近似索引选型建议，但金融风控、医疗影像等硬实时场景要求 Recall@K 必须 ≥ 0.999——此时任何量化都是不可接受的。真正值得追问的是：能不能把 HNSW 当粗召回，用 GPU 做批量精排？或者用 Cascade 架构：HNSW-SQ 先扫出一批候选，再让原始 FP32 向量做精确 Top-K？Milvus 的 refinement 机制本质就是这种思路，但 refine_k 如果设得过大，内存会超过原版 HNSW。是否存在一种『两级量化』方案——第一级用 SQ8 粗排，第二级只在 AI 集群的 GPU 上做精排？