最近在做一个RAG项目,用的是开源的embedding模型(bge-large-zh),大概有200万条知识库文档。一开始图省事直接用的ES的dense_vector,但召回率总感觉差点意思,尤其是一些同义改写的问题。后来看社区都在推Milvus和Qdrant,就试了一下Milvus,召回确实好了点,但又引入了新的运维成本(我们团队就俩人)。想问问有经验的前辈,对于这种中等规模的场景,是继续调ES的参数(比如加个HNSW的M值)还是直接上专门的向量数据库?另外,如果上Milvus的话,有必要上GPU版的吗?我们现在用的都是CPU机器。
楼主
26天前
各位大佬,向量数据库和ES向量检索到底怎么选?我人麻了
请 登录 后发表回复
全部回复
共 42 条
2楼
6小时前
200万文档这个量级其实挺尴尬的,说大不大说小不小,专门上一套Milvus确实有点重,你们就俩人运维精力肯定吃紧。我自己的经验是ES的dense_vector召回差很多时候不全是索引的问题,得先看看你embedding和query是不是同一套模型、有没有做归一化,还有hybrid search有没有开——纯向量检索在中文同义改写上本来就容易翻车,加个BM25做混合召回,效果提升可能比换库还明显。HNSW的m和ef_search确实值得调,m调到32、ef_search往200以上拉,召回能上来一截,就是延迟和内存会涨。真要上Milvus的话,CPU版跑200万向量完全够用,bge-large才1024维,GPU主要加速的是建索引和批量插入,你这规模没必要,省下的钱不如加内存。我的建议是先别急着换,把ES的混合检索和参数调一轮,实在不行再考虑Qdrant这种轻量点的,Milvus对你们来说运维负担偏重了。
3楼
6小时前
我们当时也是ES转Milvus,200万这个量级其实Qdrant更轻,单机Docker跑就行,运维比Milvus省心多了。召回差不一定全是索引的锅,bge-large-zh本身对同义改写就那样,可以试试换个更大的模型或者加个query改写。CPU跑Milvus检索够用了,GPU主要加速建索引和训练,你们知识库不常全量重建的话没必要上。ES调HNSW参数能救一点,但想质变还是得换专门的向量库。