向量数据库选型 vector db milvus

你已经决定做 RAG，切分和嵌入模型都跑通了，卡在最后一步：向量库到底选哪个。Milvus 常被第一个想到，但它不是所有团队的默认答案——规模、运维人力、过滤条件复杂度都会改结论。这篇给一套先定条件再挑产品的判断顺序，外加一份能直接跑的验证清单，帮你在一周内把选型结论落到文档里。

你已经决定做 RAG，切分和嵌入模型都跑通了，卡在最后一步：向量库到底选哪个。Milvus 常被第一个想到，原因是它文档全、社区大、分布式路线清晰。但它不是所有团队的默认答案。规模、运维人力、过滤条件复杂度，这三件事随时会改结论。

这篇不讲各家产品参数，给一套先定条件、再挑产品的判断顺序，外加一份能直接跑的验证清单，帮你在一周内把选型结论落到文档里。价格和规格数字别在这里猜，到站内价格与模型资料库核对当时的数字。

先把条件写下来，再去看产品

选型最常见的错误是先打开产品对比表，看谁的宣传页更漂亮，再回头想自己其实需要什么。反过来的顺序才对：先写四件事，范围定了再挑。这四件事写不清，后面所有对比都是在比文档排版。

• 数据量级：向量条数是万级、百万级还是千万级，量级不同，能选的产品形态完全不一样
• 过滤检索：要不要按租户、时间、权限、类目做过滤后再召回，很多召回变差都是过滤条件太复杂导致的
• 运维人力：团队里有没有人能长期盯一套集群，包括扩容、备份、升级和故障排查
• 数据边界：是否要求数据不出内网，这条会直接砍掉一批托管形态

还有两个常被忽略的条件。一是检索形态：只用纯向量，还是向量加关键词的混合检索，后者对引擎的多路召回和过滤下推能力要求更高。二是查询侧：QPS 峰值、可接受的召回延迟、是否需要边写边查，这三项决定你能不能先用单机方案起步。

自建一套，还是先用托管/单机版起步

Milvus 走的是分布式路线，能力上限高，但运维成本随之上升。它适合有专人负责基础设施、数据量确实到了分布式量级的团队。如果这两条只满足一条，就要多想一步：你是在为未来买单，还是在为当下的故障面买单。

迁移成本要提前问清楚，这是很多人事后才后悔的点。换库时，嵌入要不要重算、原向量 ID 与元数据能不能映射过去、重建索引要多久，这些都会影响你能不能随时回头。接口层做一层薄封装，换库时只改适配层，代价才可控。

选型验证清单：拿你自己的数据测，别信 demo

别用官方 demo 数据判断效果，demo 里的数据分布和你的业务差了十万八千里。正确做法是准备一套真实基准集，拿它去跑每一款候选库，跑完再比谁更合适。下面这份清单可以直接照着执行。

1. 准备基准集从真实业务里抽出 50 到 200 条问题，每条标注正确片段，作为后面所有对比的基准，标注不了就说明你的切分还没稳定
2. 测召回准确度用基准集跑一遍，看正确答案有没有被召回；再叠加真实的过滤条件跑第二遍，看召回掉得厉害不厉害
3. 测写入与更新做一次批量写入和增量更新，看写入吞吐是否顺畅、更新完多久能被搜到，边写边查的场景尤其要看
4. 测真实延迟在你们自己的网络环境里测，别在本地机器上测完就下结论，跨机房和冷启动的差距往往很大
5. 分离变量把嵌入模型和向量库分开测，召回差先怀疑切分和嵌入，确认不是这一层的问题再考虑换库

记录测试条件与结论这一点非常重要。改一次切分参数、换一次嵌入模型，都要重跑一遍基准集，否则很容易凭印象拍板，过两周自己都想不起来当时的结论是怎么来的。

上线前留好退路和观察点

选型不是一次性的决定，上线之后必然会遇到召回异常、写入堆积、延迟波动这些问题。所以选型阶段就要把退路和观察点一起设计进去，而不是等出事了再想怎么切。

• 接口层做薄封装，检索调用不直接写死在业务代码里，换库时只改适配层
• 设置降级路径，向量检索超时或报错时退回关键词检索，别让整条问答链路直接挂掉
• 记录检索日志，包含查询文本、命中的片段 ID、耗时、是否走了降级，出问题时才有据可查
• 定期跑一遍基准集做回归，召回质量下滑往往不是突然发生的，而是慢慢漂移

需要横向看候选产品时，建议先到站内向量数据库目录把能力项过一遍，再决定要不要换。没跑过基准集就切库，风险比你想的高，因为你不清楚效果变差到底是因为新库不行，还是因为迁移过程中数据没对齐。要核对当时的规格与费用，到 /price-watch 和 /rankings 看当时的数字，不要拿旧截图做决策。