about
Lossless Compression of Vector IDs for Approximate Nearest Neighbor Search (arxiv.org)
151 points by fzliu on Jan 22, 2025 | hide | past | pdf | 6 comments on HN

In plain words: Search indexes for finding similar vectors store lots of ID numbers and links, and this work squeezes them losslessly by reordering IDs freely and encoding them with compact bit codes. IDs shrank 7-fold with no accuracy or speed loss, cutting billion-scale index size by 30%.

Abstract

Approximate nearest neighbor search for vectors relies on indexes that are most often accessed from RAM. Therefore, storage is the factor limiting the size of the database that can be served from a machine. Lossy vector compression, i.e., embedding quantization, has been applied extensively to reduce the size of indexes. However, for inverted file and graph-based indices, auxiliary data such as vector ids and links (edges) can represent most of the storage cost. We introduce and evaluate lossless compression schemes for these cases. These approaches are based on asymmetric numeral systems or wavelet trees that exploit the fact that the ordering of ids is irrelevant within the data structures. In some settings, we are able to compress the vector ids by a factor 7, with no impact on accuracy or search runtime. On billion-scale datasets, this results in a reduction of 30% of the index size. Furthermore, we show that for some datasets, these methods can also compress the quantized vector codes losslessly, by exploiting sub-optimalities in the original quantization algorithm. The source code for our approach available at https://github.com/facebookresearch/vector_db_id_compression.

Daniel Severo, Giuseppe Ottaviano, Matthew Muckley, Karen Ullrich, Matthijs Douze
arXiv:2501.10479 · cs.LG, cs.DB, cs.IR · submitted Jan 16, 2025
abstract · pdf · html

add comment on HN

ANN search is usually memory bandwidth limited from a search speed prospective, so it doesn’t surprise me that the CPU has a few extra cycles to decompress without losing much latency
Brute-force indices are usually arithmetic bound (e.g., GEMM). Cell-probe based indices are usually memory bandwidth bound (IVF, LSH bucketing, etc). Graph-based indices are usually memory latency bound (traversing linked lists / graph data structures).

(I wrote the GPU half of Faiss and work with the people who wrote this paper).

Why would that be true? Every approach I've seen needs to jump around in memory to find indices and then the coordinates. It's the polar opposite of being bound by memory bandwidth.
Yes the GP said “bandwidth” when they perhaps meant “latency” but the gist and spirit of their post was good. The cpu has a lot of spare cycles, particularly if it can be arranged to be without dependency so it can be crunched instead of stalling?
what is surprisingly missing from their comparison is roaring bitmaps [0]

i'm sure they should've seen this paper because it's quite old

[0]: https://arxiv.org/pdf/1603.06549

> Approximate nearest neighbor search for vectors relies on indexes that are most often accessed from RAM. Therefore, storage is the factor limiting the size of the database that can be served from a machine. Lossy vector compression, i.e., embedding quantization, has been applied extensively to reduce the size of indexes. However, for inverted file and graph-based indices, auxiliary data such as vector ids and links (edges) can represent most of the storage cost. We introduce and evaluate lossless compression schemes for these cases. These approaches are based on asymmetric numeral systems or wavelet trees that exploit the fact that the ordering of ids is irrelevant within the data structures. In some settings, we are able to compress the vector ids by a factor 7, with no impact on accuracy or search runtime. On billion-scale datasets, this results in a reduction of 30% of the index size. Furthermore, we show that for some datasets, these methods can also compress the quantized vector codes losslessly, by exploiting sub-optimalities in the original quantization algorithm. The source code for our approach available at this https URL.

https://github.com/facebookresearch/vector_db_id_compression