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.
FAISS is no longer close to SoTA:
https://ann-benchmarks.com/index.html https://vector-index-bench.github.io/ https://big-ann-benchmarks.com/neurips23.html
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.
Surprised that usearch isn't in any of these, it's pretty fast.
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!
Also the removal latency is on a log scale. Which is quite insane.
It would be nice to have the README be a little more human written for a project where you actually want people to adopt it
[flagged]
Then again, if the only thing the human doing is bitching about AI use, it's not really that comparatively useful.
Sure it is useful, the bitching is canary in the shit software mine. How do you know the software isnt shit if the Readme is shit?
people should read turboquant's open review comments: https://openreview.net/forum?id=tO3ASKZlok
tl,dr: there is an allegedly better alternative, and it's already implemented everywhere: https://github.com/VectorDB-NTU/RaBitQ-Library#rabitq-in-ind...
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?
oxirs does embeddings and GraphRAG, and full text search with Tantivy; oxirs-vec, oxirs-graphrag
There's an oxirs-wasm with RDF and SPARQL bindings with a query budget. Tantivy-wasm says that the release WASM bundle is 1.5 MB.
cool-japan/oxirs: https://github.com/cool-japan/oxirs
oxirs-wasm: https://crates.io/crates/oxirs-wasm
tantivy-wasm: https://github.com/phiresky/tantivy-wasm
Is there an advantage to adding an MCP local memory interface over agent instructions on how to use a rust CLI?
And then write Markdown documents with Google OKF-like frontmatter YAML metadata for agents that work with tokens not linked data graphs; https://github.com/GoogleCloudPlatform/knowledge-catalog/blo...
Can WASM use AVX512-VNNI?
> Can WASM use AVX512-VNNI?
wasmtime-mte implements ARM64 Memory Tagging Extensions in a fork of the wasmtime WASM runtime.
Memory Tagging Extensions for RISC-V would be a great project too
Already in the works: https://lists.riscv.org/g/tech-announce/message/782
No, WASM only has 128b SIMD instructions, for now.
nope
Also interested.
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, ... .
I am not convinced that Turbovec yields better retrieval than the same amount of bits of a Matryoshka embedding.
What's a good embedding model and search to run locally? something fast and lightweight.
Why not just use Qdrant? They've been integrating TurboQuant for months, works well.
Integrated in 5 weeks and just expanded data types for turbo4 in last release. No longer need to store fp32 vectors if you don't need them
There are already several openreview comments alleging academic misconduct around TurboQuant: https://openreview.net/forum?id=tO3ASKZlok
Some write-ups argue that this was deliberate rather than a good-faith mistake: https://dev.to/gaoj0017/turboquant-and-rabitq-what-the-publi...
And now this. Pretty bold AI slop.
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.
Another vibe coded slop where they can't even spend time on Readme or documentation around code...
Who is this co-author called t <t@t>?
As it is heavily vibe coded, I think member of technical staff at antropic has no clue....
Next Prompt: remove t@t and force commit.
lancedb and duckdb integrations would be great...
what could i use this for as part of my agentic workflow? codebase indexing? docs ?
notes/docs/wiki is a great use case
[flagged]
Well. That is insane. O_O Fantastic job!
[dead]
[dead]
[dead]
[dead]
[flagged]