如何在本地用 Milvus 搭建支持千万级数据的 RAG 知识库？

我实测下来，本地跑千万级规模，最稳的方案是采用 Milvus Standalone + MMap (Memory-mapped files)。千万级数据如果全部加载到内存，内存压力极大，开启 MMap 可以让索引在磁盘和内存之间灵活调度，虽然牺牲了一点点速度，但能保住系统不挂。

环境快速起步

不要用复杂的 K8s，本地直接用 Docker Compose。关键点是在 milvus.yaml 配置文件中调整内存限制，并确保 etcd 和 minio 的存储路径挂载在 SSD 上，否则加载索引时你会等得绝望。

# 快速启动 Milvus 独立版
wget https://github.com/milvus-io/milvus/releases/download/v2.3.0/milvus-standalone-docker-compose.yml -O docker-compose.yml
docker-compose up -d

核心配置技巧：索引选择是关键

千万级数据量下，千万不要用 FLAT 索引（全量扫描，慢死），建议直接上 HNSW。但 HNSW 非常吃内存，建议配置 M 为 16，efConstruction 为 64。如果你发现内存还是顶不住，可以考虑 IVF_FLAT，虽然召回率稍低，但内存占用极低。

# 创建索引的实战代码
from pymilvus import Collection

collection = Collection("knowledge_base")
index_params = {
    "index_type": "HNSW", 
    "metric_type": "L2", 
    "params": {"M": 16, "efConstruction": 64}
}
collection.create_index("vector", index_params)

踩坑指南与效率提升

1. 批量导入不要用循环 insert
千万级数据如果一行一行插入，网络开销会让你怀疑人生。必须用 bulk_insert 或者将数据先存成 JSON 文件，利用 Milvus 的 Import 功能，效率能提升 10 倍以上。

2. 分片（Shards）的误区
本地单机部署时，shards_num 设置为 2 左右即可。设置过多会导致管理开销增加，反而拖慢速度。

3. RAG 检索链路优化
为了防止千万级数据导致检索结果噪声太大，我现在的做法是在 Milvus 检索时加上 expr 过滤条件（标量过滤）。比如通过 doc_id 或 category 缩小范围，这样即使数据量大，检索速度依然能维持在 50ms 左右。

# 带有标量过滤的检索示例
results = collection.search(
    data=[query_vector], 
    anns_field="vector", 
    param={"nprobe": 10}, 
    limit=5, 
    expr="category == 'technical_docs'" # 必须加上过滤，否则噪声太强
)

如果你需要对千万级数据进行频繁更新，记得把 index_type 换成支持动态更新的类型，否则每次重建索引的时间成本极高。