如何在大规模文档 RAG 中优化 Milvus 的索引选择以降低查询延迟

在实战大规模文档检索时，我发现最核心的矛盾在于「检索精度」与「内存占用」的平衡。如果你追求极致的低延迟且内存资源充足，HNSW 依然是首选，但关键在于参数调优。默认参数在数据量大时会导致索引构建极慢且查询延迟增加，建议将 M（最大连接数）下调，efConstruction 根据精度需求适当降低。

{
  "index_type": "HNSW",
  "index_params": {
    "M": 16, 
    "efConstruction": 64
  }
}

但当文档规模突破千万级，内存开始吃紧时，我会切换到 IVF_SQ8。它是量化索引，通过将向量压缩到 1 字节，能节省 75% 的内存，且查询速度在大多数 RAG 场景下比 HNSW 更快，因为减少了内存页交换。踩过的一个大坑是 nlist（聚类中心数）的设置：如果 nlist 太小，查询时扫描的桶太多，延迟会飙升；如果太大，量化误差会导致召回率骤降。经验法则是在 sqrt(N) 到 4*sqrt(N) 之间尝试。

针对不同规模的配置建议：

10万-100万量级： 直接上 HNSW。配置 ef (search params) 在 64-128 之间，延迟通常在 10ms 以内。

100万-1000万量级： 尝试 IVF_FLAT。虽然内存占用高，但不需要量化，精度最高。nlist 建议设在 1024-4096。

1000万量级以上： 强制使用 IVF_SQ8 或 IVF_PQ。此时必须关注 nprobe 参数。nprobe 越大，召回率越高但延迟线性增加。

实操中，我通过以下 Python 代码片段动态测试 nprobe 对延迟的影响，从而找到性能拐点：

from pymilvus import Collection

collection = Collection("doc_embeddings")
# 循环测试 nprobe 从 1 到 32 的延迟
for n in range(1, 33):
    search_params = {"metric_type": "L2", "params": {"nprobe": n}}
    res = collection.search(
        data=[query_vector], 
        anns_field="vector", 
        param=search_params, 
        limit=10, 
        output_fields=["doc_id"]
    )
    print(f"nprobe: {n}, latency: {res.latency}ms")

最后一点优化技巧：在大规模 RAG 中，尽量在 Milvus 层面做标量过滤（Scalar Filtering），而不是把结果拉回内存后再过滤。利用 Milvus 的分区（Partition）功能将文档按时间或类别物理隔离，能将查询范围从亿级直接降低到万级，这比任何索引优化都有效。