先这样答
我的选型顺序是先明确四个条件：数据量级、查询延迟要求、要不要标量过滤、团队愿意养多少运维，然后按这些条件匹配。
FAISS 是 Meta 开源的向量检索库，不是数据库——单机、没有增删改查的完整能力、没有持久化和高可用，但检索性能很好，适合原型验证和离线批量跑，放进生产要自己在外面补服务化那一圈。
PGVector 是 PostgreSQL 的插件，一个库同时管业务表和向量表，事务、备份、权限全套现成的，SQL 就能做标量过滤。千万级以下向量规模完全够用。团队已经在用 PG 的，这是改动最小的路径。它的短板是性能上限和水平扩展，量大了检索延迟能感觉到。
Milvus 这类专用向量数据库，为大规模场景设计：分布式架构、标量向量混合查询、多副本、多种索引类型可选。亿级向量、高并发、要做复杂过滤的场景用它。代价是一套独立的存储计算设施要养，小团队前期没必要。
中间还有一个常见的务实选项：Elasticsearch 或 OpenSearch，本来就在跑的关键词检索上加向量字段，一站拿到混合检索。已有 ES 的团队经常这么走。
向量库选型的坑通常不在「选小了」，而在「选大了」：设施养不起、链路复杂化。不如先用 PGVector 跑通业务，量到了再迁移。
面试官会怎么追问
- 向量检索的索引原理了解吗？ HNSW 是主流：多层跳表式的图结构，查询快但内存占用高；IVF 类先聚类再搜桶，省内存但精度略降；数据量大时两类会组合用。
- 为什么标量过滤这么重要？ 企业场景几乎都要按权限、部门、时间过滤，检索前过滤还是检索后过滤，实现方式直接影响召回和延迟，选型时要验证库的过滤性能。
- 迁移成本怎么控制？ 入口把向量化和检索两层抽成接口，库只是实现之一；元数据里存原文，迁移就是重灌。
回答的坑
- 背一堆库名说不出差别。每个库要能落到「什么场景选它、代价是什么」。
- 忽略团队现状。已有 PG 或 ES 的团队，复用比引入新设施合理得多。
同系列的题
—— 本题完 ——