向量数据库选型#
一句话答案#
主流向量数据库：Milvus（开源高性能）、Pinecone（云托管）、Weaviate（混合搜索），按规模和运维能力选择。
核心要点
| 产品 | 定位 | 混合检索 / 稀疏 | 量化 |
|---|---|---|---|
| Milvus | 开源分布式，支持亿级 | sparse 向量字段 + 内置 BM25 全文检索函数；hybrid_search 配 RRF / 加权 ranker | 支持 PQ、SQ 等多种量化索引 |
| Qdrant | 开源，Rust 实现，payload 过滤强 | named sparse vector（可开 IDF 修正）；Query API prefetch + fusion: rrf / dbsf | 标量、乘积、二值（含 1.5/2 bit）、非对称量化 |
| Weaviate | 开源，模块化（内置向量化/rerank 模块） | 内置 BM25F，hybrid 查询，融合可选 ranked / relativeScore | 旋转量化 RQ（新集合默认开 8-bit）、PQ、BQ、SQ |
| Pinecone | 全托管云服务，免运维 | 全文检索（BM25）、sparse / sparse-dense 索引、托管 rerank | 托管，内部实现不暴露 |
| pgvector | PostgreSQL 扩展 | sparsevec 类型；BM25 需配合 PG 全文检索或其他扩展，融合通常在 SQL/应用层做 | halfvec（半精度）、bit 二值 + 表达式索引量化 |
| Elasticsearch / OpenSearch | 搜索引擎加向量能力 | 原生 BM25 + kNN；ES 用 rrf / linear retriever，OpenSearch 用 hybrid 查询 + search pipeline | 均支持标量/二值等量化选项（以官方文档为准） |
| Chroma | 轻量，适合原型，也有云服务 | 已支持 BM25 / SPLADE 稀疏向量与混合检索（Search() API） | 以官方文档为准 |
各产品迭代很快（例如 Milvus 已进入 3.x，Weaviate、Qdrant 每几个月一个小版本），具体能力和参数名以官方文档为准。
索引类型： HNSW(高召回) / IVF(高吞吐) / FLAT(精确但慢)
ANN 索引工作原理（暴力搜索是 O(N) 全量比对，ANN 用”近似”换速度）
HNSW（分层可导航小世界图）： 把”分层图 + 跳表”思想结合——构建多层图，上层节点稀疏、连边长，像”高速公路”快速跨越大距离；下层稠密、连边短，做精细定位。查询从顶层入口点开始，每层做贪心搜索：在当前层不断走向离查询点更近的邻居，走到该层局部最近点就”下沉”到下一层，逐层逼近，最底层（含全部节点）输出结果。查询复杂度约 O(log N)。
三个核心参数（含义不能混）：
| 参数 | 作用阶段 | 含义 | 调大的影响 |
|---|---|---|---|
| M | 构建 | 每个节点的最大连边数（图的稠密度） | 召回高、图更稳，但内存大、构建慢 |
| efConstruction | 构建 | 构建时维护的候选邻居数 | 图质量更高（邻居选得更准），构建更慢 |
| efSearch | 查询 | 查询时维护的候选列表长度 | 召回高，但单次查询更慢（速度↔召回的旋钮） |
为何内存大： 全图必须常驻内存才能高效随机跳转（图遍历是随机访存，不适合走磁盘）；且每个节点要存多层的邻接表（每层最多 M 条边），原始向量 + 多层邻接结构一起占用，所以 HNSW 是”以内存换召回与速度”。
IVF（倒排文件索引）： 离线先用 k-means 把全部向量聚成若干簇、得到一批质心，每个向量归入最近质心的”桶”（倒排列表）。查询时先算查询向量到各质心的距离，只在最近的 nprobe 个桶里做精确搜索，跳过其余桶。nprobe 是召回↔速度的权衡：调大搜更多桶、召回高但更慢。优点是构建快、内存省、适合超大规模；缺点是桶边界处的近邻可能被漏掉（落在没被搜的相邻桶里）。
PQ（乘积量化，省内存的压缩手段）： 把每个高维向量切成若干子段，对每个子段位置单独训练一套聚类码本，用最近码字的**编号（几个字节）**替代原始子段浮点数，从而把向量压缩成一串短编码。大幅降低内存（可压缩到原来几十分之一），代价是量化引入精度损失。实际常与 IVF 组合成 IVF_PQ：IVF 缩小搜索范围、PQ 压缩向量，是超大规模（亿级）+ 内存受限场景的主力方案。
FLAT（暴力精确）： 不建索引，逐一精确比对，召回 100% 但 O(N)。仅适合小数据集或对精度要求极高、数据量可控的场景。
面试回答（2分钟版）
向量数据库是RAG系统中存储和检索Embedding向量的核心组件，选型要根据数据规模和运维能力来决定。主流方案有几类：Milvus是开源分布式方案，支持亿级向量，适合有运维能力的团队自建；Qdrant也是开源方案，payload过滤和量化选项比较丰富；Pinecone是全托管云服务，免运维开箱即用，适合快速上线但有持续成本；现在主流向量库基本都支持向量加关键词的混合检索和RRF融合，差别主要在实现方式和运维成本；如果只是做原型验证，Chroma足够轻量；团队如果已有PostgreSQL技术栈，pgvector作为插件可以避免引入新组件。索引类型的选择也很关键：HNSW基于图的近似搜索，召回率高但内存占用大；IVF基于倒排索引，吞吐量高适合大规模场景；FLAT是暴力精确搜索，小数据集用没问题但大规模不可行。内存吃紧时再叠加量化（标量、二值、PQ），用少量精度换内存，必要时对候选做原始向量重打分。选型时除了看性能指标，还要考虑与现有技术栈的集成难度、社区活跃度和长期维护成本。
追问与易错
追问方向：
- Milvus 和 Pinecone 怎么选？各自适合什么场景？ → Milvus 开源可自建，适合数据不出境 + 深度定制；Pinecone 全托管免运维，适合快速上线 + 小团队。百万级以上数据量 Milvus 性价比更高
- HNSW 和 IVF 索引的区别？什么时候用哪个？ → HNSW 内存常驻、查询快但内存占用大；IVF 磁盘友好、内存省但查询略慢。数据量 <1000 万用 HNSW，超大规模用 IVF_PQ
- 向量维度对检索性能的影响有多大？ → 维度从 768→1024，原始向量内存增 33%，距离计算量也近似按维度线性增加。维度越高语义表达越丰富但边际收益递减；支持 Matryoshka 的模型可以截短维度，在自己的评测集上比较召回再定
- 向量数据库和传统数据库 + ANN 插件（如 pgvector）怎么选？ → 数据量不大（常见经验是百万级以内）且已有 PG 基础设施，pgvector 够用，还能和业务数据做事务、JOIN；数据量更大、需要分布式扩展、多种量化索引、内置混合检索时选专用向量库
- 带过滤条件的向量检索有什么坑？ → ANN 先搜后过滤时，过滤条件很严格会导致返回条数不足。各家的应对不同：Qdrant 在 HNSW 图上做过滤感知的遍历，pgvector 0.8 起提供 iterative index scan（默认关闭），Milvus 支持标量字段索引和分区。选型时要用真实的过滤比例压测召回和延迟
易错点：
- ❌ 只看召回率不看延迟和成本 → 生产环境需要平衡 Recall、Latency、内存占用三者
- ❌ 不考虑向量维度对性能的影响 → 1024 维比 768 维原始向量内存增加 33%，距离计算也更慢
- ❌ 忽略索引构建时间 → HNSW 构建耗时随数据量、M、efConstruction 增长，大库可能到小时级，需要规划离线构建和重建时间
结合项目时可以讲： 选了哪个库、为什么不选另外几个（数据量、已有技术栈、运维能力），索引和距离度量怎么定，向量 ID 怎么和业务库的 chunk 记录对应以支持精确删除，以及用什么数据验证了召回和延迟。