博客园-向量数据库选型实践

向量数据库选型踩坑记：别被宣传PPT忽悠了

做RAG系统的时候，向量数据库是绕不开的一环。现在市面上向量数据库一大堆，宣传文档一个比一个好看，什么"毫秒级检索""亿级向量""99.9%召回率"，真到自己选型的时候才发现，全是坑。

这篇文章不说概念，就聊聊我自己选型过程中踩过的几个真实的坑，给大家做个参考。

一、别上来就追求"亿级向量"

很多人选型的时候，第一反应就是：我们未来要存几个亿的向量，必须选能扛住亿级的数据库。

但真实情况是，大部分中小团队，一开始根本用不到那么多。

我们一开始做RAG的时候，觉得自己未来文档会很多，一上来就选了个分布式的向量数据库，部署一套集群要三台服务器，运维成本一下就上来了。结果跑了三个月，里面一共才存了不到100万向量，连这个数据库能力的十分之一都没用到。

后来我们才想明白：选型不是选最大的，是选最适合你现在的。

• 如果你的文档量在100万以内，根本不需要分布式单机版就够了
• 如果你的日查询量在1000次以内，单机版完全扛得住
• 真的等你数据量到了千万级，再迁移也来得及，现在的向量数据库数据迁移都很方便

别上来就搞个大集群，运维成本比软件本身贵多了。

二、召回率不是越高越好

向量数据库宣传里最常吹的一个指标就是召回率，什么"99.9%召回率"。很多人觉得，召回率当然越高越好，低了不就漏了吗？

但真用的时候你会发现，召回率太高也有问题。

我们一开始测试的时候，用的是精确检索模式，召回率拉满，结果每次检索出来20个文档，里面一大半都是不相关的。把这些文档全塞给大模型，上下文直接爆了，回答效果反而变差了。

后来我们改成了近似检索，召回率从99%降到90%，结果大模型的回答准确率反而升了。因为过滤掉了那些似是而非、其实不相关的文档，大模型看到的都是真正相关的内容。

实际上做RAG的时候，90%左右的召回率就足够了。你不需要把所有语义相似的文档都找出来，你只需要找最相关的那几个。召回率太高，反而把一堆没用的东西塞给大模型，帮倒忙。

三、运维成本才是大头

很多人选型的时候只看功能，不看运维成本，结果后面坑死人。

比如有的向量数据库，功能是真强，但是要自己部署集群，要自己监控节点，要自己做备份，节点挂了还要自己排查。小团队哪有那么多运维人力？我们之前试了一个开源的分布式向量数据库，第一个月光是运维就花了一个工程师半个月的时间，后来实在扛不住，换了个云托管的版本，虽然每个月花点钱，但省下来的人力成本远远超过那点费用。

选型的时候一定要算清楚总账：

• 软件本身多少钱
• 部署需要几台服务器
• 运维需要几个人
• 出了问题有没有人支持

小团队真的别追求什么开源自研，用云托管的就挺好，把精力放在业务逻辑上，别浪费在运维上。

写在最后

向量数据库这个领域现在还在快速发展，没有哪个是完美的。选型的时候别被销售忽悠了，先拿自己的真实数据测一遍，看看速度够不够、召回率够不够、用起来顺不顺手，再做决定。

别一上来就上最重的方案，先从最简单的开始，业务跑起来了，再慢慢升级。做工程嘛，适合自己的才是最好的。