Quantize, don't truncate: a float32 embedding is mostly empty space

The article argues that for embedding storage it pays to reduce numeric precision (quantization to int8, int4, or a single bit via RaBitQ/BBQ with oversampling and reranking), not the number of dimensions — a float32 vector carries barely two significant digits, and the rest of the mantissa dissolves into noise under cosine similarity. High dimensionality helps quantization; below ~384 dimensions binary quantization breaks down. Matryoshka Representation Learning, according to the author, solves a different problem — runtime dimension flexibility, not index compression; at the same compression ratio, quantization beats it even on Matryoshka-trained models (the CoRECT comparison).

In November 2024, Elasticsearch 8.16 added a feature with the unassuming acronym BBQ — Better Binary Quantization. It does a single thing: it shrinks every number in a stored vector from thirty-two bits to one, so the memory occupied by the searched vectors drops to roughly one thirty-second. The original vectors stay on disk, and after the coarse binary search the candidates are re-ranked at full precision. On a million 1024-dimensional Cohere embeddings such an index holds above 90% recall@100 — all it takes is threefold oversampling, which is in fact the default setting today. At first glance it looks like a fraud committed against information theory.

It isn't. It is a corrective accounting entry. It shows that a float32 embedding, the way most of us store it without thinking, is largely empty space. And we pay for that space in disk and in RAM every time we run semantic search or RAG over hundreds of millions of documents.

My claim is that when storing embeddings it pays to reduce the precision of the number, not the number of dimensions. And that Matryoshka, which many teams reach for as their first option, solves a different problem than they think. To defend that, I first have to answer a question almost nobody asks: how much useful information does a single number in an embedding actually carry?

The answer can be read off from what survives quantization. Dropping to int8 — 256 levels instead of full floating point — comes out almost lossless in both industry benchmarks and independent measurements; a November 2025 study on the BEIR SciFact retrieval benchmark measured a fourfold saving for int8 at the cost of a one- to two-percent drop in nDCG@10 — and that on a small, 384-dimensional model. Quality holds up even deeper: broader comparisons show that int4 or int2 hold up for most models, and in many deployments even a single bit per dimension. If the signal does not collapse even after rounding to eight bits, to four, in places to one, that means the sixteen bits of float16 or the thirty-two of float32 carry barely two significant digits; the rest of the mantissa is, in cosine similarity, noise that dissolves in the sum over hundreds of coordinates. A stored embedding is therefore largely not information. It is extra space we have grown used to treating as a given.

Once you accept that shrinking a vector means removing bits that carry nothing, two levers come into view, not one. The first lowers the precision of each dimension — that is quantization. The second lowers the number of dimensions and leaves precision alone — that is what Matryoshka Representation Learning does: a model trained so that the first 256 or 512 coordinates of the embedding are a usable vector in their own right, one you can cut off and stop computing. Both levers do fundamentally the same thing; they differ only in the axis. And that is where the decision is made.

Where that axis should be depends on where the model put its signal. A natively trained model, without the Matryoshka constraint, spreads information roughly evenly across all dimensions; its singular-value spectrum is flat and every coordinate carries its share. Matryoshka does the exact opposite: training forces it to pack as much as possible up front, so that cutting off the tail hurts as little as possible. Its spectrum is therefore steep, the leading dimensions overloaded, the trailing ones nearly empty. For a native vector the natural compression is quantization — the redundant bits sit in precision, not in the number of axes, so truncation would take real information away from it. For a Matryoshka it is the other way round.

It is precisely with a native model that one-bit quantization works unexpectedly well, and there is hard theory behind it. The RaBitQ method, published in 2024 by Jianyang Gao and Cheng Long of NTU Singapore, and from which Elastic derived its BBQ, quantizes a D-dimensional vector into D bits and provides an unbiased estimate of similarity with a sharp error bound; that error falls inversely with the square root of the dimension. The more informative coordinates the signal has, the more reliably the one-bit noise averages out. High dimensionality does not obstruct quantization, it helps it. The same holds from the other side: once we drop below roughly 384 dimensions, binary quantization breaks down — the SciFact study mentioned above calls it unusable on its short vectors, and even Elastic's documentation concedes caution below that threshold. A small dimension hurts quantization too.

This brings us to the confusion that made me write this text. Matryoshka is sold as compression: you train once, cut to 256 dimensions, the index is smaller. But the very possibility of cutting is an admission that the trailing dimensions carry almost nothing. Why have a thousand coordinates when three quarters of them can be thrown away and almost nothing happens? That discardability is not a virtue. It is saturation built into the model during training — the fine-grained resolution that in a native model would lie in the tail of the spectrum was simply sacrificed by Matryoshka training.

From this follows the refutation of the most common objection I hear against this line of reasoning: that a steep spectrum is more resistant to quantization, because the information sits in large, robust components, whereas a flat native vector also holds it in small values that quantization noise drowns. The argument sounds good, and in one context it even holds — but that context is low-precision training of language models. The paper that formalizes, for the embedding layers of GPT-2 and TinyLlama, how quantization noise clips the small components of the spectrum says nothing about vector search or about Matryoshka; transferring its conclusion to the storage of retrieval vectors is a confusion of domains. And even if it did hold: "it survives better" here only means "it has nothing left to lose." Matryoshka bought its resilience in advance by discarding nuance during training. That is not a quality, it is loss in the guise of robustness.

I don't want to write Matryoshka off, that would be a straw man. It solves a real problem quantization cannot: dimensional flexibility at runtime. One deployed model from which you take 256 coordinates, or the full 1024, according to your budget, without recomputing the corpus — that is legitimate and useful. Last year Google showed that for model weights the Matryoshka principle can even be carried down to the bits themselves: integer types have a nested structure, int4 sits in the upper bits of int8, and a single trained model can then be served at several precisions at once. But all of this is deployment flexibility, not index compression. Anyone reaching for Matryoshka for storage reasons has picked up a tool for a different problem — and the extensive CoRECT comparison from the University of Passau, from late 2025, quantifies it: at the same compression ratio, quantization beats plain truncation even for Matryoshka-trained models. The only thing worth taking from Matryoshka when storing is mild trimming as a supplement — for three of the four models tested, the best result came from combining mild truncation with quantization, not from truncation alone.

In practice this yields an ordering that runs against the intuition of many teams. Leave the dimension alone and go after precision. int8 is a sensible default, on large models almost without loss. When space is tight, int4, or straight to binary RaBitQ/BBQ with oversampling and re-ranking at full precision; one bit per dimension on a thousand-dimensional model holds a quality that a sixty-four-dimensional float16 version could never deliver at the same bit budget. Just measure it on your own data, not in someone else's table — the same Passau comparison of eight types of compression method on corpora of up to a hundred million passages ends with the conclusion that the best choice differs from model to model. And that is the only point that can be generalized safely.

And float32? A million embeddings from the BGE-M3 model, which took up four gigabytes to begin with, fit into a hundred and twenty-eight megabytes of RAM after binary quantization. The difference was not information. It was space we were paying out for a number pretending to be thirty-two bits while it carried two.

Sources (verified as of 5 July 2026): J. Gao, C. Long, "RaBitQ", SIGMOD 2024 (arXiv:2405.12497). Elastic Search Labs, "Better Binary Quantization (BBQ) in Lucene and Elasticsearch" (2024) and the Elasticsearch documentation on BBQ; Elasticsearch 8.16, November 2024. "Dimension vs. Precision", arXiv:2511.13057 (2025). A. Kusupati et al., "Matryoshka Representation Learning", NeurIPS 2022. P. Nair et al., "Matryoshka Quantization", arXiv:2502.06786 (Google DeepMind, 2025). L. Caspari et al., "CoRECT: A Framework for Evaluating Embedding Compression Techniques at Scale", arXiv:2510.19340 (University of Passau, 2025; v3 January 2026). The counter-argument about the spectrum: "On the Spectral Flattening of Quantized Embeddings", arXiv:2602.00969 (2026).

Transparency of creation:

The concept, structure and editorial line of the article are the work of the author, who prepared the content outline, established the key theses and directed the entire creative process. Generative AI (Claude, Anthropic) was used as a tool for research, for locating primary sources and for the stylistic elaboration of the author's content outline.

The author edited the outputs throughout, verified the key findings and approved the final wording. No part of the text was published without human review. All factual data were verified against the publicly available sources cited in the text.

This procedure complies with the requirements of Article 50 of EU Regulation 2024/1689 (the AI Act) on the transparency of AI-generated content. #poweredByAI