• 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
    • Anthropic employee. This is what your brain on kool aid looks like
      • 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
  • 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...
  • 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, ... .

  • 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?
  • 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.

  • 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
  • I am not convinced that Turbovec yields better retrieval than the same amount of bits of a Matryoshka embedding.
  • 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.

  • 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.
  • Well. That is insane. O_O Fantastic job!
  • Another vibe coded slop where they can't even spend time on Readme or documentation around code...
  • 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]