18 comments

  • Eridrus 7 hours ago
    • nl 5 hours ago
      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.

    • ehsanu1 2 hours ago
      Surprised that usearch isn't in any of these, it's pretty fast.
  • ghm2199 10 hours ago
    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!
    • ghm2199 10 hours ago
      Also the removal latency is on a log scale. Which is quite insane.
  • nharada 10 hours ago
    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
    • badatnames 9 hours ago
      Anthropic employee. This is what your brain on kool aid looks like
      • deeviant 9 hours ago
        Then again, if the only thing the human doing is bitching about AI use, it's not really that comparatively useful.
        • righthand 5 hours ago
          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?
  • lmeyerov 1 hour ago
    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, ... .

  • bobmarleybiceps 7 hours ago
    people should read turboquant's open review comments: https://openreview.net/forum?id=tO3ASKZlok
  • anishvarghese 10 hours ago
    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?
  • cat-whisperer 5 hours ago
    What's a good embedding model and search to run locally? something fast and lightweight.
  • beernet 8 hours ago
    Why not just use Qdrant? They've been integrating TurboQuant for months, works well.
    • kanungle 3 hours ago
      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
  • sp1982 10 hours ago
    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...
  • OutOfHere 5 hours ago
    I am not convinced that Turbovec yields better retrieval than the same amount of bits of a Matryoshka embedding.
  • burgerboii 10 hours ago
    Who is this co-author called t <t@t>?
    • cute_boi 8 hours ago
      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.

  • spoaceman7777 9 hours ago
    Well. That is insane. O_O Fantastic job!
  • esafak 11 hours ago
    lancedb and duckdb integrations would be great...
  • cute_boi 8 hours ago
    Another vibe coded slop where they can't even spend time on Readme or documentation around code...
  • refulgentis 8 hours ago
    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.
  • zuzululu 10 hours ago
    what could i use this for as part of my agentic workflow? codebase indexing? docs ?
    • kyxsc 10 hours ago
      notes/docs/wiki is a great use case
  • myshapeprotocol 5 hours ago
    [dead]
  • tracespect 7 hours ago
    [flagged]