向量数据库选型关键因素有哪些？

这道题其实问的是怎么根据业务场景做选型匹配，而不是比benchmark数字。说白了，没有最好的[[向量数据库]]，只有最合适的。

先讲性能这块。如果场景是实时对话，对延迟特别敏感，我会优先选 [[HNSW]] 索引，召回率高查询快，但代价是内存占用大。如果数据量到了十亿级，那HNSW就不现实了，内存撑不住，这时候得用 [[IVF]] 系列或者磁盘索引，牺牲一点召回换存储成本。这里有个坑，很多向量库在纯向量检索时表现不错，但一加上元数据过滤就崩了。比如电商场景，你想查某个分类下最相似的商品，得先按分类过滤再向量检索。如果向量库不支持 filter下推，就得全量扫描再过滤，性能直接掉一个数量级。所以上线前我一定会压测带过滤的查询。

再一个就是扩展性和运维。数据量不大，比如几百万条，用pgvector或者简单的[[Faiss]]方案就能搞定，成本低。但要是数据量到了十亿级别，或者并发很高，就得考虑原生分布式的方案，像Milvus、Weaviate。关键要问清楚支不支持 存储计算分离，这直接决定了扩缩容的弹性和成本。举个例子，企业做合规文档检索，平时数据量不大，但月底审计时并发量暴增，如果能计算节点独立扩缩，就能省不少钱。

集成生态这块，优先选LangChain和LlamaIndex官方支持的库，这样接入成本最低。还要检查[[embedding]]模型兼容性，比如支持多种向量维度、动态schema，不然换个模型就得改表结构。

隐性成本容易被忽略。自托管方案比如Milvus、pgvector，运维负担重，得有人管集群、备份、故障恢复，适合有DBA团队的场景。全托管方案像Pinecone、Zilliz Cloud，按量付费，适合快速验证和迭代。云厂商方案比如阿里云向量检索、AWS OpenSearch，网络延迟低，但容易vendor lock-in。

还有个点是数据更新场景。知识库频繁更新时，难点不是能不能插一条新向量，而是在实时性、检索质量和一致性之间平衡。我会把更新分成新增、修改、删除三类。新增最简单，直接走增量插入就能准实时生效；修改和删除要谨慎，我会把修改看成旧版本软删除加新版本新增，删除也不原地动图索引，而是维护删除标记后台异步重建。整体用base加delta双索引，查询时合并再按版本过滤。构建完不能直接上线，我会用一批固定query回放，对比Recall@K和延迟，通过才原子切换，不通过就回滚。规模更大还能做冷热分层。我会特别提醒一句：删除千万别原地动图索引，否则召回质量会崩。

所以我的判断是，百万级先用pgvector或轻量方案快速验证，千万级以上选Milvus或Weaviate自研，追求极致省心就Pinecone或Zilliz Cloud。核心还是看你的场景、预算和运维能力。