向量数据库本质是对高维向量做相似度检索 + 配套元数据管理，选型要从业务规模、检索性能、工程运维、成本、生态合规几个维度评估，下面分大类梳理，适合技术方案评审。

一、业务与向量本身特征（最先评估）

向量维度
- 低维（<256）：大部分库都轻松支持；
- 中维（256~1024）：主流 Embedding 模型（text-embedding、BGE 等）；
- 高维（>1024，图像 / 多模态）：对索引、内存压力大，有些数据库高维性能衰减明显。
向量总量 & 单分片向量数
- 百万级：轻量方案（FAISS、Chroma、Milvus 单机）够用；
- 千万～亿级：必须分布式（Milvus、PGVector 分布式、Qdrant、Weaviate 等）；
- 十亿 +：重点看分片、水平扩展、冷热分离能力。
向量更新模式
- 只读 / 少量新增：FAISS 最优；
- 频繁插入、更新、删除（RAG 知识库持续增删文档）：要关注动态索引，FAISS IVF 不适合频繁删改；优先 Qdrant、Milvus、PGVector。
相似度度量方式 支持：余弦 Cosine、欧氏距离 L2、内积 IP、曼哈顿距离。
文本 Embedding 大多用余弦；归一化向量内积等价余弦。部分数据库对某些距离函数优化差异很大。
查询模式
- TopK 检索：最常见；
- 带过滤检索（元数据 where 条件过滤后再向量检索，RAG 非常常用）：过滤能力是选型大坑，很多向量库先查向量再过滤，召回率暴跌；要看是否支持预过滤 / 后过滤；
- 批量查询、范围检索、多向量联合检索。

二、检索性能指标（核心指标）

性能不能只看 QPS，要结合召回率，召回率 @K 是第一位。

索引类型支持

索引	特点
FLAT	暴力全扫，100% 召回，只适合小数据
IVF	倒排，适合亿级，频繁删改开销大
HNSW	图索引，召回高、速度快，内存占用高，主流首选（Qdrant、Milvus、Weaviate 都支持）
DiskANN	磁盘索引，内存占用低，适合超大向量库，牺牲少量延迟
SCANN	Google，适合大规模内积检索

重点：是否支持动态 HNSW（增删向量不需要重建索引）。

内存 / 磁盘架构
- 全内存：速度最快，成本高；
- 磁盘向量索引（DiskANN 等）：把向量放磁盘，降低内存成本，适合海量冷数据；
- 冷热分离：热向量内存，冷向量落盘，Milvus、Qdrant 支持。
分布式能力
- 是否原生分布式，还是单机套一层代理；
- 分片策略：按向量 ID 分片？按范围分片？
- 副本：高可用，副本是否同步索引；
- 扩缩容：能否在线加节点，不需要停机迁移数据。
持久化 & 可靠性
- 宕机数据丢失风险；WAL 日志；
- 事务支持：PGVector 有事务；很多原生向量库仅支持最终一致性；
- 备份恢复、快照能力。

元数据管理：向量绑定结构化字段（文档 ID、时间、来源、标签）
混合检索（Filter + 向量检索）
- 预过滤：先筛元数据，再向量检索，元数据筛选量大时性能差；
- 后过滤：先向量召回 TopN，再过滤元数据，容易召回不足；
- 是否支持嵌套过滤、范围查询、标签查询。
多租户：隔离向量集合，权限隔离，企业知识库场景。
多向量字段：一个文档多个向量（比如标题向量 + 正文向量）。
向量版本 / 快照：知识库版本管理。
全文检索 + 向量检索融合（Hybrid Search）：BM25 + 向量，Weaviate、PGVector、Milvus 支持。

部署形态
- 纯库 SDK（FAISS）：嵌入式，无独立服务，适合程序内调用，但是要自己做分布式、持久化；
- 独立服务（Qdrant、Milvus）：REST/gRPC，微服务友好；
- 数据库扩展插件（PGVector、MySQL Vector）：复用现有数据库运维体系，开发成本最低。
资源开销：CPU、内存、磁盘 IO；HNSW 非常吃内存。
可观测性：监控指标（延迟、召回、队列、索引状态）、日志、告警。
运维复杂度：是否需要调参（HNSW ef_construction、ef_search）、扩容是否麻烦。
编程语言 SDK：Python/Java/Go，你的业务开发语言是否完善。
集成生态：是否对接 LangChain、LlamaIndex、Dify 等 RAG 框架。