向量数据库在千万级数据下召回变慢，是索引选错还是分片姿势不对？

说实话你这个量级真不是调参能救回来的，768维下HNSW的图结构内存占用和检索路径长度会指数级恶化，M=32反而让距离计算量翻倍。我之前在800万条64维数据上遇到过类似拐点，后来发现瓶颈根本不在索引，而在Milvus的segment合并策略——写入压力大时小segment太多，查询要扫多个segment的候选集再merge，这部分开销比索引本身还大。建议你先用collection的stats接口看下segment分布，如果碎片化严重，手动compact一下可能立竿见影。另外检查下query的nprobe或者ef值，千万级数据下召回率掉点往往是因为候选集相对密度变小，你efConstruction调高但查询时ef没跟着涨的话，召回率必然降。GPU版本别急着上，我试过A100跑IVF_PQ，吞吐是上去了但延迟受限于显存和CPU-GPU拷贝，400ms瓶颈未必能解决。最后分片策略的话，如果数据有强过滤字段，用partition能极大缩小检索范围，纯随机分片反而增加跨节点聚合成本。你可以先抓一下query的trace日志看耗时分布，大概率是候选集生成和距离计算占比最高，这时候要么降维到256维，要么直接换ivf_pq量化，别在HNSW一棵树上吊死。

这数据量上来了确实不是简单调参能解决的，768维在千万级上HNSW的图构建和检索开销都非线性增长，M和efConstruction调高虽然能提召回但延迟反而更糟，我猜你大概率是内存带宽瓶颈而不是索引本身。分片的话你检查过数据分布吗？如果按ID取模分片但embedding是随机分布的，那每个shard都要全量扫一遍，等于没分；试试按聚类中心预分组，或者直接上Milvus的partition key按业务字段过滤，能砍掉大半无效计算。另外你这延迟是p99还是平均？如果只是长尾高，可以看看是不是compaction或者删改操作触发了segment碎片，有时候重建索引比调参管用。GPU版本我试过，但900万条768维其实单卡也吃紧，除非你上A100或者多卡并行，不然瓶颈会挪到CPU和GPU之间的数据传输。说实话，这个量级我建议先试试DiskANN或者IVF_PQ，把向量压到64维再检索，召回掉的点用rerank拉回来，延迟能压到100ms以内。你现在的collection里有没有标量过滤字段？加了filter之后索引选择和参数完全是另一套玩法了。