What is a multivector point, and how does it differ from a point with several named vectors?

The distinction is structural. A point with several named vectors has multiple independent vector fields, each holding exactly one vector. For example, a document might have a title_vector field (768-dim), a body_vector field (768-dim), and an image_vector field (512-dim). Each field is a separate embedding space with its own distance metric and its own index, and you search them independently or combine them at query time. A multivector point has a single named vector field that holds a list of vectors. The classic example is a ColBERT-style document representation, where the document is encoded as one vector per token - a 200-token document produces a field containing 200 vectors of, say, 128 dimensions each. The field is one logical vector, but its value is a matrix rather than a single row. You do not search it independently; you score it against a query multivector using a late-interaction comparator like MaxSim.

The mechanism difference is what you do at query time. With named vectors, you typically issue separate queries against each field and then fuse the results, or you use a prefetch to retrieve candidates from one field and rerank with another. With a multivector, you cannot do a simple ANN lookup because there is no single vector to look up - the field is a set of vectors. Instead, you use a comparator that defines how to score a query multivector against a stored multivector. Qdrant's MAX_SIM comparator implements the ColBERT scoring: for each query token vector, find the maximum similarity to any document token vector, then sum those maxima across query tokens. This is a fundamentally different operation from a dot product or cosine similarity between two single vectors. It is also why multivector fields are typically configured with m: 0 - there is no meaningful HNSW graph to build over a set of vectors that are scored as a set rather than individually. The exception is when you want to search against individual token vectors, which is a different use case.

The trade-off is flexibility and cost. Named vectors give you a clean separation of embedding spaces and let you search each independently, which is useful for multi-modal or multi-aspect retrieval. But each field has its own index, so memory and build cost scale with the number of fields. A multivector gives you a much richer representation of a single document - token-level rather than document-level - which improves retrieval quality on tasks where fine-grained matching matters (e.g. question answering, code search). But the storage cost is M times higher per point than a single vector, and the query cost is O(query_tokens * doc_tokens) per candidate, which is why multivector scoring is typically applied only to a small candidate set from a first-stage retriever. The common mistake is confusing the two: engineers sometimes try to model a ColBERT document as N named vectors (one per token), which is wrong because it loses the set semantics and prevents the MAX_SIM comparator from being applied. The other mistake is trying to build an HNSW index over a multivector field and being surprised that it does not work well - the field is not a single point in a metric space, so graph-based ANN over it is not meaningful. Version note: multivector support and the MAX_SIM comparator were added in recent Qdrant releases; on older versions, you may need to implement late interaction outside the vector store.

Version-dependent: the multivector_config and MultiVectorComparator.MAX_SIM API is part of the qdrant-client 1.10+ surface. On older clients, multivector fields may not be supported or may use a different configuration shape. The ability to set m: 0 per field is also a relatively recent addition. Verify against your client and server versions before designing around these features.