向量数据库选型与应用

一句话定位：向量数据库的选型核心是在召回率、延迟、内存成本三者之间做权衡，索引结构决定了这个权衡的基本形态，自建 vs 托管则是运维成本与灵活性的权衡。

1. 索引结构：HNSW vs IVF-PQ

• HNSW（Hierarchical Navigable Small World，图索引）：构建多层近邻图，查询时从顶层稀疏图逐层下探到底层稠密图，延迟低、召回率高，但需要把完整向量和图结构都放在内存里，内存占用大。
• IVF-PQ（倒排文件 + 乘积量化）：先用聚类把向量分桶（倒排），查询只在候选桶内搜索；用乘积量化压缩向量存储（有损压缩），省内存，但召回率和精度略有损失，适合超大规模、内存敏感的场景。
• 选型判断：数据量在千万级以内且对延迟/召回率要求高 → HNSW；数据量上亿、内存成本敏感、能接受召回率略降 → IVF-PQ。

2. 召回率 vs 延迟的调参

• HNSW 的 ef_search（搜索时探索的候选数）越大，召回率越高但延迟越高；IVF 的 nprobe（搜索的桶数）同理。
• 实践中要先定业务可接受的延迟上限，再反向调参数找到该延迟预算下的最高召回率，而不是先追求”召回率最高”再看延迟能不能接受。

3. 过滤条件与向量检索结合

• 实际业务常需要”向量相似 + 满足某些结构化过滤条件”（如”语义相似 + 时间在近 7 天 + 用户属于某分组”），即混合查询。
• 实现方式一是先过滤再向量搜索（过滤后候选集小则快，候选集仍大则退化成暴力搜索）；二是把过滤条件也编码进索引结构（如带 payload 过滤的图索引），各产品支持程度不同，选型时要专门核实。

4. 写入与索引重建成本

• HNSW 类图索引的增量写入和删除相对复杂（删除通常是软删除标记，需要定期重建索引清理），这是运维时容易被低估的成本点。

5. 自建（Milvus）vs 托管（Pinecone）

• 自建：可控性强、成本可能更低（大规模下），但需要自己承担运维、扩缩容、高可用的工程投入。
• 托管：开箱即用、免运维，但成本随规模线性增长且数据出境/合规需额外考虑（尤其是国内业务场景）。

6. 面试落点

• 能讲清楚 HNSW/IVF-PQ 的核心 Tradeoff（延迟/召回率 vs 内存），并给出具体场景的选型建议，而不是只说”用 Milvus”。
• 可迁移话术：这套”索引结构决定查询性能形态”的思路和大数据里”选 B+树索引还是 LSM 索引”的权衡是同一类工程决策模式。

参考：Milvus 官方文档；Pinecone《Vector database fundamentals》