向量数据库选型#
一句话答案#
主流向量数据库：Milvus（开源高性能）、Pinecone（云托管）、Weaviate（混合搜索），按规模和运维能力选择。
核心要点
| 产品 | 特点 |
|---|---|
| Milvus | 开源/高性能/支持亿级 |
| Pinecone | 云托管/免运维 |
| Weaviate | 混合搜索(向量+关键词) |
| Chroma | 轻量/适合原型 |
| pgvector | PostgreSQL 插件 |
索引类型： 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是开源高性能方案，支持亿级向量，适合有运维能力的团队自建；Pinecone是全托管云服务，免运维开箱即用，适合快速上线但有持续成本；Weaviate支持向量加关键词的混合搜索，适合需要多种检索方式的场景；如果只是做原型验证，Chroma足够轻量；团队如果已有PostgreSQL技术栈，pgvector作为插件可以避免引入新组件。索引类型的选择也很关键：HNSW基于图的近似搜索，召回率高但内存占用大；IVF基于倒排索引，吞吐量高适合大规模场景；FLAT是暴力精确搜索，小数据集用没问题但大规模不可行。我们项目中选择了Milvus加HNSW索引，百万级文档召回延迟控制在50ms以内。选型时除了看性能指标，还要考虑与现有技术栈的集成难度、社区活跃度和长期维护成本。
追问与易错
追问方向：
- Milvus 和 Pinecone 怎么选？各自适合什么场景？ → Milvus 开源可自建，适合数据不出境 + 深度定制；Pinecone 全托管免运维，适合快速上线 + 小团队。百万级以上数据量 Milvus 性价比更高
- HNSW 和 IVF 索引的区别？什么时候用哪个？ → HNSW 内存常驻、查询快但内存占用大；IVF 磁盘友好、内存省但查询略慢。数据量 <1000 万用 HNSW，超大规模用 IVF_PQ
- 向量维度对检索性能的影响有多大？ → 维度从 768→1024 内存增 33%，检索速度下降约 20%。维度越高语义表达越丰富但边际收益递减，通常 768-1024 是甜区
- 向量数据库和传统数据库 + ANN 插件（如 pgvector）怎么选？ → 数据量 <100 万且已有 PG 基础设施用 pgvector 够了；百万级以上或需要高级索引/分区/动态 Schema 选专用向量库
易错点：
- ❌ 只看召回率不看延迟和成本 → 生产环境需要平衡 Recall、Latency、内存占用三者
- ❌ 不考虑向量维度对性能的影响 → 1024 维比 768 维内存占用增加 33%，检索速度也会下降
- ❌ 忽略索引构建时间 → 百万级向量构建 HNSW 可能需要数小时，需要规划离线构建时间
项目实践（DocMind）： 选用 Milvus，HNSW 索引（ef=64），1024 维 Embedding，COSINE 距离度量，top-K=50。选 Milvus 而非 pgvector 的原因：百万级以上向量专用引擎性能优势明显，支持动态 Schema 和分区，与 Spring AI 集成开箱即用。向量 ID 与 MySQL kb_chunk 表的 vector_id 字段一一映射，支持精确删除。