怎么考「Milvus / Chroma / pgvector / Elasticsearch 怎么选？」
谁在问：工程向一二面；技术负责人尤其关注运维成本这条
开场怎么问
你们向量库用的什么？为什么选它不选别的？
换个问法
- pgvector 够用吗？什么时候必须上专用的向量库？
- 如果让你重新选一次，你会怎么选？
五层追问链
左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。
在给出结论前，你会先问我什么问题？
- 期望
- 数据量级和增长曲线、QPS 与延迟要求、是否需要混合检索、是否已有 PG/ES 技术栈、团队运维能力、数据能否出内网、预算。这题本身就是在测「先澄清再方案」的习惯。
- 信号
- 答不出要问什么的，说明平时是拿到需求直接动手。
pgvector 和专用向量库的差距具体在哪？
- 期望
- 性能上专用库在百万级向量的 QPS 通常是 pgvector 的数倍；索引类型上专用库支持 HNSW/IVF/DiskANN 等多种，pgvector 支持有限。但 pgvector 的优势是零额外运维 + 事务一致性 + 能和业务数据同库 JOIN——向量和权限、时间等业务字段在一个事务里更新，这在很多场景比性能更重要。
- 信号
- 能说出「同库 JOIN 和事务一致性」这个优势的，是真权衡过而非人云亦云。
什么是预过滤和后过滤？为什么这个很关键？
- 期望
- 带元数据条件的查询有两种执行顺序。后过滤的致命问题：先取 Top-100 再过滤，可能只剩 3 条满足条件，结果不够用甚至为空。预过滤则先缩小候选范围再做向量搜索。Qdrant、Milvus 默认预过滤；pgvector 要留意查询计划。权限隔离场景下这直接决定系统可用性。
- 信号
- 这是本题最好的探针——用过带过滤的生产系统的人一定被这个坑过。
现在让你从 Chroma 迁到 Qdrant，怎么做？停机吗？
- 期望
- 向量不用重算，导出向量+payload 重新 upsert；平滑迁移用双写 + 灰度读切换：先双写保证新库数据完整，再按比例把读流量切过去，对比两边结果一致后全量切换，观察期后下线旧库。百万级迁移作业本身通常半小时内。
- 信号
- 只会说「导出导入」而想不到双写灰度的，没做过线上迁移。
你们已经在 Chroma 上跑了半年，现在数据涨到三百万，延迟爆了，明天要给方案，怎么办？
- 期望
- 分短期和中期。短期止血：降低
ef_search/top-k 换延迟、加缓存、把冷数据分区剔除；中期：按上面的双写灰度迁到 Qdrant 或 Milvus。同时要给出量化的验收标准（P95 延迟目标、召回率不得低于当前值）和回滚方案。
- 信号
- 只给「迁库」一个答案、没有短期止血和回滚计划的，缺乏线上事故处理经验。
危险信号
听到这些话，基本可以判定是背题而不是做过。
评分卡
- 先问约束再给结论（或至少明确列出决策维度）
- 能对至少三个库给出甜点区和代价
- 把运维复杂度作为独立维度而非附带提一句
- 知道 Chroma 不适合生产及具体原因
- 知道混合检索支持度是关键筛选项
- 加分：知道迁移不需要重算向量、成本可控
- 加分：知道预过滤 vs 后过滤的差别及其影响
- 加分：pgvector 的事务一致性/同库 JOIN 优势
参考答案与考察意图面试中途别看这一段
考察意图
选型题的通用考点：能不能先问约束再给结论。上来就报一个库名的候选人，等于告诉面试官「我只用过这一个」。真正的观察点是：① 你知不知道该问数据规模、团队运维能力、是否已有 PG/ES 技术栈；② 你有没有意识到运维成本常常比性能更决定选型；③ 迁移成本你估得准不准。
参考答案
60 分答案（及格线）
要看几个维度：数据规模、是否需要分布式、团队运维能力、是否已有相关技术栈、要不要混合检索。粗略地说：pgvector 适合已有 PostgreSQL 且百万级以内，装个扩展就能用，零额外运维；Qdrant 单二进制部署，性能好、元数据过滤强，适合中等规模；Milvus 适合亿级和真正需要分布式的场景，但依赖组件多、运维重；Chroma 适合原型验证，不建议上生产；Elasticsearch 适合团队已有 ES 栈、BM25 底子厚的情况。
90 分答案（有生产经验的回答）
补四层：
先讲两个真实反面案例（这比罗列参数有说服力）：一种是「重装上阵」——项目刚立项就上 Milvus 集群，知识库才两万条，团队一半精力耗在维护依赖组件上；另一种是「轻装冒进」——Chroma 跑了半年原型，数据涨到三百万条，某天延迟从 80ms 飙到 2 秒，单机索引内存放不下，扩容只能整库重建。两种坑的根子一样：选型时只看「能不能跑起来」，没看「这条路能走多远」。
把运维成本摆到台面：「部署复杂度」最容易被低估——它不是「装起来几步」，而是长期运维负担。Chroma 是进程内嵌库，坏了重启即可；Qdrant 一个 docker run 就能起；Milvus 通常要拉起元数据存储、对象存储、消息队列等多个依赖，任何一个挂了整个集群受影响，排障链路长一个量级。所以选型前先问自己：团队里有没有人愿意长期盯这套分布式系统的告警？
迁移成本没想象中高（重要的反直觉点）：embedding 结果是确定性的，换库不需要重新计算向量，导出向量和元数据重新写入即可，百万级通常半小时内完成。所以「先用简单的，顶不住再迁」是合理策略——前提是别拖到三百万条才想起来。
混合检索能力是 2026 年的关键筛选项：Qdrant、Milvus、Weaviate、Elasticsearch 都原生支持；pgvector 要手动组合向量与全文检索；Chroma 不支持——这也是不建议它上生产的重要原因之一。Milvus 2.5+ 内置 BM25 全文检索，一个库就能做完混合检索，省掉维护两套系统。