I think their point is the size/performance tradeoff rather than outright performance. The point of TurboQuant is the size savings, while still giving high accuracy.
It's been a while, but I do recall some high-performing vector matching indexes being very large.
Wow! 4GB for 10 million documents. This means one could build a reverse index much faster than before and devx processes like debugging, performance testing would become much smoother. Can't wait for the sqlite bindings to come out!
If anyone is looking to retrofit to an existing pipeline, I use similar ideas to compress vectors for job search, getting roughly 8x compression with about a 3.5% drop in quality. My experiment: https://corvi.careers/blog/vector-search-embedding-compressi...
This looks perfect for local, privacy first search, but since it's built in Rust, has anyone tried compiling it to WASM to run directly inside a browser extension?
Interestingly, while we don't fine-tune generative models for Louie.ai, we found fine-tuning embedding models to be a major $ saver. Instead of 1K-2K wide frontier embedding vector lens... Just 64. Huge savings on vector DB $$$.
I'm curious how that works with something like turboquant. Not needed any more, still dominant, better together, ... .
Bloviating nonsense, 3rd time I’ve seen something like this in HN since TurboQuant came out. You don’t need float32, never did. Source: I’ve been writing on device embedding code for 4 years.
https://ann-benchmarks.com/index.html https://vector-index-bench.github.io/ https://big-ann-benchmarks.com/neurips23.html
reply