Why does Qdrant set m: 0 on a named vector used purely for reranking (e.g. a ColBERT multivector)?

Setting m to 0 on a named vector tells Qdrant to skip HNSW graph construction entirely for that vector. It still stores the vectors, you can still retrieve them, and you can still score against them - you just cannot run an approximate nearest-neighbor search that originates from that vector. This is exactly what you want for a vector that is only ever used as a reranking field. In a ColBERT-style late-interaction setup, the multivector field is not used to find candidates; it is used to rescore a small set of candidates that were found by a cheaper first-stage retriever (dense or sparse). Building an HNSW graph for it would be wasted memory, wasted build time, and wasted index maintenance, because no query ever traverses that graph.

The mechanism matters because HNSW graph construction is the expensive part of indexing, not vector storage. For a multivector field with, say, 128 token vectors per point, building an HNSW graph over all those token vectors would be hundreds of times more expensive than for a single-vector field, and the resulting graph would be enormous. Since the field is only ever scored against a candidate set of, say, 100 points, the approximate search that HNSW provides is useless - you are doing exact MaxSim over 100 candidates, which is a few milliseconds at most. So m: 0 is not a limitation, it is the correct configuration. The same logic applies to any named vector that is only used for reranking or for exact scoring: set m: 0 to save the index cost and rely on the first-stage retriever to provide candidates. The only thing you lose is the ability to do a direct ANN search against that field, which is exactly the operation you have decided you do not need.