做了三个 RAG 项目后，我总结了向量数据库选型的几个坑

最近一年前后做了三个不同规模的 RAG 项目，从几万条数据的内部知识库到几百万条文档的企业级搜索，踩了不少坑。今天把选型过程中遇到的问题整理一下，给正在做技术选型的朋友做个参考。
先说结论：没有最好的向量数据库，只有最适合你业务场景的。
先讲个踩过的坑
第一个项目刚开始的时候，领导说要上就上最好的，直接选了某开源明星项目，部署在自己服务器上。
结果呢？数据量上来之后，查询延迟直接从几十毫秒涨到了两秒多。更坑的是，那个版本的过滤查询性能特别差，我们要按部门、按文档类型过滤，一过滤就慢得没法用。
后来被迫迁移到了另一个方案，前前后后折腾了快一个月。这个坑踩得我到现在都记得。
选型要看哪几个维度？
我现在选型的时候，主要看这几个方面：

1. 数据量和查询延迟要求
   这个最直观。
   如果你的数据量在 10 万条以内，其实不用想太多，用什么都行，差别不大。SQLite 加个向量扩展都能跑起来。
   但如果数据量到百万级了，就要认真考虑了。特别是当你还要做混合检索（向量 + 关键词）的时候，很多开源方案的性能会掉得很厉害。
2. 过滤查询性能
   这个是最容易被忽略的点。
   很多人一开始测试的时候，都是纯向量搜索，测出来性能都很好。但真实业务场景里，你几乎总是要加过滤条件的：只搜某个部门的、只搜最近三个月的、只搜某种类型的文档。
   过滤性能好不好，直接决定了系统能不能用。我之前踩的那个坑，就是栽在这上面了。
3. 运维复杂度
   这个也很重要。
   如果你是一个小团队，没有专门的运维，那选一个运维简单的方案真的能省很多事。有些向量数据库看着功能强大，但部署、扩容、监控都很麻烦，小团队根本搞不定。
   这种情况下，选云服务可能更划算。虽然贵一点，但你不用操心运维，出了问题有厂商支持。
4. 生态和 SDK 支持
   这个容易被忽略，但实际用起来影响很大。
   你的业务用什么语言写的？Python 还是 Java？有没有现成的 SDK？跟你现在的技术栈能不能很好地集成？
   这些问题在选型的时候就要想清楚，不然等你写了一半才发现 SDK 不好用，就麻烦了。
   三个常用方案的对比
   我把我们用过的几个方案简单说一下，仅供参考：
   方案一：轻量级，适合小项目
   优点是部署简单，几行代码就能跑起来，适合做原型验证、内部小工具。缺点是数据量大了之后性能不行，分布式能力弱。
   方案二：开源自建，适合中等规模
   优点是功能比较全，社区也活跃，能满足大部分中等规模的需求。缺点是运维成本不低，需要有人专门维护。
   方案三：云服务，适合不想操心的团队
   优点是开箱即用，不用管运维，扩容也方便。缺点是贵，特别是数据量大了之后，费用会涨得很快。
   最后说两句
   向量数据库选型这个事，真的没有标准答案。
   我见过有人几百万条数据还在用轻量级方案，也见过有人几万条数据就上了企业级集群。关键是看你的业务需求是什么，你的团队有多少人能维护。
   别一上来就追最新最火的技术，先把自己的需求想清楚。合适的才是最好的。
   有什么问题评论区聊。