向量数据库在千万级数据下RAG召回率暴跌，是分片策略还是模型问题？

我上周刚踩过这坑，先查下分片数和nlist的乘积，低于总向量数就别怪模型了。

召回率差这么多大概率是分片后nlist没按数据量重新算，试试把总nlist调成shard数的平方根倍数。

建议直接对比下各分片的召回分布，八成是某个shard拖后腿了。

看到这个召回率差距我第一反应就是排查下查询时的nprobe设置，默认值太小的话分片再多也白搭，另外你这数据量单机8分片其实有点尴尬，shard间数据分布不均匀也会放大PQ误差。之前我调过类似问题，最后是把nlist调大到4096同时把nprobe从8提到64才稳住，建议你先把暴力检索和向量索引的召回差异按召回条数分段对比下，定位是头部还是尾部丢的。阈值的话最好用实际badcase反推，别太信理论值。

八成是量化+分片双重叠加的问题，8个shard每个都独立建索引，nlist小了PQ粗量化误差会被放大，尤其你这数据量分布又不一定均匀。建议先查下各shard的向量分布，有没有严重倾斜，再试试把nlist提到4096或8192，或者直接关掉量化用原始向量跑一把对比。另外Milvus的top-k是每个shard各取再合并，如果某片召回质量差会拖整体，可以看下各shard单独召回率差异大不大。我之前遇到过类似情况，最后是换成分片内暴力检索+全局重排才救回来。

八成是分片后nlist没跟着调，PQ量化误差被放大了，先试试把nlist提到分片数的十倍以上。

我上次也栽这坑里，暴力检索准说明embedding没毛病，问题就出在索引参数和分片不匹配上。

我之前也踩过类似的坑，问题大概率不在HNSW参数上。你试试把nlist调大或者直接关掉PQ，用原始浮点向量做暴力检索对比下分片后的召回，如果差距还在，那八成是分片导致的数据分布不均，某些shard的聚类中心代表性不够了。另外，800万条对单机Milvus来说确实有点勉强，建议查下每个shard实际分配了多少向量，负载不均衡也会让召回率虚低。最后efSearch在查询时记得也调高到500左右，只调构建参数不调查询参数效果很有限。

我也踩过类似的坑，八成不是模型的问题。你重点查下分片后每个shard的nlist和nprobe，尤其是nprobe如果没跟着分片数放大，召回率肯定会被砍。另外PQ量化对高维向量损失很敏感，试试把IVF换成HNSW的粗量化，或者干脆关掉量化用暴力索引对比下。对了，确认下Milvus里实际检索的metric是不是和暴力检索用的同一个，cosine和IP差一点结果就差很多。

我之前调过类似的，问题大概率出在分片后的nlist上，800万数据拆成8个分片，每个分片单独建索引时nlist得按分片内数据量重新算，不是简单沿用全局配置。另外PQ量化在分片场景下误差确实会被放大，建议先试试把nlist调大几倍，或者临时换成flat索引对比一下，这样能快速定位是索引还是模型的问题。还有个坑是Milvus的相似度阈值默认用的不是余弦距离的直观值，你确认过返回的score范围和本地暴力检索一致吗？我之前就是被这个坑了两天。

你这个问题我去年踩过几乎一模一样的坑，800万1536维单机8分片，也是召回率对不上。先说结论：大概率不是模型问题，而是Milvus默认的索引参数在你这个数据规模下把PQ量化误差放大了。你查一下每个分片实际用的index_type，如果是IVF_SQ8或者IVF_PQ，nlist和nprobe的组合很关键，nprobe太小的话每个query只扫几个簇，暴力检索能命中但近似检索直接漏掉。另外有个容易忽略的点，Milvus分片是按主键哈希的，不是按语义聚类的，所以每个shard的向量分布其实跟全量差不多，这时候你把nlist设成跟单机一样大反而让每簇样本变少，训练出来的质心偏移更明显。你可以先把nprobe从默认的1调到16或者32试试，如果召回率一下子上来了那就是这个原因。还有一个坑是metric_type，OpenAI的embedding用COSINE和L2在高维下排序结果会有细微差异，Milvus里如果collection建的时候写的是L2但你本地用cosine算，85%和62%的差距完全可能。建议你把查询向量dump出来，用同一批query分别在Milvus和faiss里跑，对比top-5的id列表，看是漏召回还是排序错位，这个能快速定位是索引问题还是metric问题。

分片后每片数据量小，nlist反而不能设太小，不然聚类中心太稀疏，召回肯定掉。先查查每片实际nlist和PQ配置吧。