决策看这 6 个维度
| 维度 | 影响什么 |
|---|
| 数据量 N | 小→FLAT；中→HNSW；大/亿级→IVF-PQ/DiskANN |
| 向量维度 d | 越高越慢越占内存；能 768 别 1536 |
| 内存预算 | 紧→必须量化(PQ/BQ)；松→HNSW |
| 召回要求 | 极高→FLAT/HNSW；可容忍≈95%→IVF-PQ |
| 更新频率 | 频繁增删→LSH/支持增删的库；批量→均可 |
| 元数据过滤 | 需"带过滤的检索"→选支持 pre-filter 的库 |
选型决策树
图 1：按数据量 × 内存的索引选型决策树。
主流向量库 / 引擎定位
| 引擎 | 形态 | 定位与擅长 |
|---|
| Faiss | Python/C++ 库 | 底层引擎，算法最全(HNSW/IVF-PQ/...)，需自己搭服务 |
| Milvus | 分布式服务 | 十亿~千亿级，云原生，水平扩展强 |
| Qdrant | Rust 服务 | 易用、过滤(带条件的检索)强、性能好 |
| Weaviate | 图式服务 | 模块化、原生混合检索、GraphQL 接口 |
| pgvector | Postgres 扩展 | 已在 PG 里，运维省，中小规模够用 |
| Chroma | 嵌入式 | 轻量、原型/本地最快上手 |
选库不只为"快"，还要看：是否支持带元数据过滤、能否水平扩展、团队是否熟 Postgres。很多"检索不准"的锅其实是过滤没做好。
参数速查
| 索引 | 先调哪个 | 建议起步 |
|---|
| FLAT | 无 | 小数据直接上 |
| HNSW | efSearch | M=16, efConstruction=200, efSearch=64→256 |
| IVF-PQ | nprobe | nlist≈√N, nprobe=16/32, m=16/32 |
| 混合 | RRF 的 k | k=60，权重各 0.5 起 |
上线前检查清单
- 维度定了吗？能用 768 就别 1536。
- 向量归一化了吗？→ 用内积检索，速度更快。
- 建索引与查询用同一种度量（cosine / IP / L2 一致）。
- 召回率测过吗？拿一批真实 query 对暴力结果算 Recall@k。
- 内存算过吗？N×d×4 是否放得下，放不下就量化/分片。
- 需要过滤吗？选支持 pre-filter 的库，避免"先召回再过滤"导致召回不足。
- 有重排(Cross-Encoder)兜底吗？召回 95% + 重排，效果更稳。
本系列 10 篇从"是什么"到"怎么选"形成闭环：基础 → 度量 → 耗时 → ANN 全景 → HNSW / IVF-PQ / LSH → 量化 → 混合检索 → 选型。按这个顺序读，向量检索就通了。