背景：一个 RAG 需求把选型问题拍到了脸上
三月初产品提了个需求：把过去三年积攒的技术工单做成内部知识库，让用户用自然语言提问。核心就一步——向量相似度检索。团队当时在 Milvus、PGVector、Redis 三套方案里反复横跳，谁也说服不了谁。我干脆拉了一台 16C32G 的机器，把三套都跑了一遍压测，用数据说话。
数据集是 200 万条 768 维的工单向量（text-embedding 模型产出），查询并发压到 50 QPS，对比维度就三条：索引类型、召回率、运维成本。
索引类型：三家走的路完全不同
Milvus 2.2 的索引最丰富，我们试了两种：
- IVF_FLAT：聚类分桶，nlist=1024，查询时 nprobe=32，粗排快但精度依赖分桶质量。
- HNSW：图索引，M=16、efConstruction=200，内存换速度，召回稳。
PGVector 在 2023 年 3 月还只有 ivfflat，HNSW 要等 0.5 版本（六月才出）。建索引语句长这样：
CREATE INDEX ON tickets
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 1000);
SET ivfflat.probes = 20; -- 查询时扫描的列表数，越大越准越慢
Redis 走的是 Redis Stack（RediSearch 2.6），向量字段支持 FLAT（暴力）和 HNSW：
FT.CREATE idx ON HASH PREFIX 1 vec:
SCHEMA embedding VECTOR HNSW 6
TYPE FLOAT32 DIM 768 DISTANCE_METRIC COSINE
召回率与性能：数字比嘴硬
用 1000 条真实查询做 ground truth（brute force 全量比对当正确答案），efSearch/efConstruction 调到接近最优后的结果：
| 方案 | Top10 召回率 | P99 延迟 | 单节点内存 |
|---|---|---|---|
| Milvus HNSW | 0.97 | 12ms | 5.8GB |
| PGVector ivfflat | 0.89 | 48ms | 2.1GB |
| Redis HNSW | 0.96 | 3ms | 6.4GB |
这里有个坑：ivfflat.probes 默认只有 1，召回率会惨到 0.6 以下。调大到 20 才像样，但延迟跟着翻倍。PGVector 的召回上限受 lists 切分粒度限制，数据量再翻十倍基本就不够看了。
Redis 延迟最低，但它是内存来存储向量，200 万条吃掉 6GB 还多，扩展得靠集群分片，跨 slot 查询又得自己兜。Milvus 的 HNSW 召回和性能都均衡，且原生支持分区和标量过滤。
运维成本：容易被忽视的隐性账单
- Milvus：分布式版要 etcd、MinIO、Pulsar 一堆依赖，standalone 模式单机跑也吃资源，版本升级偶有兼容性坑，但生态工具（Attu 可视化）好用。
- PGVector：直接复用现有 Postgres，备份、主从、监控全现成，DBA 零学习成本。代价是向量检索和事务抢同一份资源，大查询会拖慢业务库。
- Redis：运维最轻，但向量只是它的一个字段类型，没有专门的向量管理视图，数据持久化和冷启动加载要自己设计。
小结
最后我们选了 Milvus 做主检索、PGVector 给小业务兜底。选型没有银弹：数据量过千万且要稳定召回，Milvus 值得那点运维投入；团队小、数据量小、不想引入新组件，PGVector 是真香；Redis 适合本来就有 Redis 集群、要极致低延迟的场景。别一上来就堆最重的方案，也别为了省事把向量塞进核心业务库。