考察点
这道题考的是工程决策能力：不是让你罗列向量库名单，而是看你能不能按数据规模、QPS、过滤需求、运维成本做权衡。后半问「ES 换向量后什么变好什么变差」是在考你对倒排索引和 ANN 两种检索范式本质差异的理解。追问一般往 ANN 算法参数、标量过滤、大规模部署走。
参考答案
选型先按数据量级分层
百万级以下、团队已有 PostgreSQL，直接上 pgvector，少维护一个组件，SQL 生态全保留，这个量级性能完全够。百万到亿级、有独立检索服务需求，看 Qdrant 或 Milvus：Qdrant 部署轻、Rust 写的、过滤性能好；Milvus 功能全、分布式能力强、生态成熟，但组件多（依赖 etcd、MinIO 等），运维重。如果公司已有 ES 或 OpenSearch 集群且数据量中等，ES 8.x 的 dense_vector + HNSW 是务实选择，还能和 BM25 在一个引擎里做混合检索。Faiss 要单独说：它是向量检索库不是数据库，没有增删改、没有服务化，适合自己包一层服务或者做离线实验。
ANN 算法是选型的里子
向量检索全是近似最近邻（ANN），主流两条路线。HNSW 是图索引，召回率高、查询快，是各家的默认选项，代价是内存大——向量加图结构基本要全量常驻内存；核心参数 M（每个节点的边数，影响精度和内存）和 ef_search（查询时搜索宽度，影响召回率和延迟）。IVF-PQ 是倒排加量化的路线，内存省得多，但召回率有损，适合亿级以上、内存敏感的场景。选型时问清楚目标库的索引类型支持和过滤方式，比看跑分有用。
ES 换成向量检索：提升了什么
第一是语义召回能力。BM25 本质是词频统计，「怎么退款」和「退货流程怎么走」在倒排里几乎没有共词，向量检索能靠语义把它们连起来。第二是跨语言和对同义改写、口语化表达的鲁棒性，用户怎么问都能命中规范文档。第三是对长尾 query 的泛化，不需要人肉维护同义词典——ES 那套 synonym、ik 分词调优的苦活大幅减负。
下降了什么
精确匹配能力下降。产品型号「KFR-35GW」、错误码「0x80004005」、人名缩写这类字符串，embedding 会把它们压成语义空间里模糊的一团，BM25 却能精确命中。结构化过滤和聚合能力下降：ES 的 term filter、range、agg 是强项，向量库的标量过滤（metadata filtering）虽然都有，但复杂度和性能普遍不如倒排，而且 pre-filter 和 post-filter 各有坑——先过滤再检索可能把图剪得召回率暴跌，先检索再过滤可能 top-K 过滤完剩不下几条。可解释性也变差了：BM25 分数能拆成词项贡献，向量分数为什么是这个值，说不清楚。
所以成熟的生产系统基本不是「替换」而是「混合」：ES 继续扛 BM25 和结构化过滤，向量库扛语义召回，两路结果融合后 rerank。这道题的加分项就是主动说出「我不换，我混着用」。
可能的追问
- HNSW 参数怎么调？答：建库时 M 越大图越稠、召回越高但内存和构建时间涨，常见 16-64；查询时 ef_search 控制召回率和延迟的 trade-off，线上按延迟预算压测调，一般用召回率-延迟曲线找拐点。
- 亿级向量怎么办？答：分片水平扩展，索引换 IVF-PQ 或量化版本压内存，冷热分层，必要时按租户或业务线拆库。
- 标量过滤和向量检索怎么结合？答：低过滤率（过滤后剩得多）用 pre-filter，高过滤率（过滤后剩极少）用 post-filter 加过采样，中间地带各家实现差异大，要实测。