Turbovec: 使用 Google TurboQuant 的高性能向量搜索

Turbovec 是一个使用 Rust 编写并带有 Python 绑定的高性能向量索引，它实现了 Google Research 的 TurboQuant 算法。它能够实现大规模内存缩减——与 float32 需要的 31 GB 相比，将 1000 万文档语料库压缩至 4 GB RAM 中——同时提供优于 FAISS IndexPQFastScan 的搜索速度。

核心技术优势

Turbovec 提供了一种数据无关（data-oblivious）的量化方法，消除了对单独训练阶段的需求，使其适用于语料库随时间增长的动态环境。

内存效率与压缩

Turbovec 通过将向量精度降低到 2-bit 或 4-bit 表示来实现显著的压缩。对于一个 1536 维向量，这将其占用空间从 6,144 字节 (FP32) 减少到 384 字节 (2-bit)，实现了 16 倍的压缩率。

搜索性能

Turbovec 利用手写的 SIMD 内核来最大化不同 CPU 架构下的吞吐量：

ARM: 使用 NEON SDOT/SMMLA 点积内核直接对向量主导布局进行评分。
x86: 采用 AVX-512 VNNI 和 vpermb 进行高速查找和累加。

基准测试表明，Turbovec 在所有测量的配置中都优于 FAISS IndexPQFastScan，在两种架构上，4-bit 模式下平均提速 3.4 倍，2-bit 模式下提升 23%。

在线摄取与持久化

与许多乘积量化 (PQ) 实现不同，Turbovec 支持无需训练步骤、参数微调或索引重建的在线摄取。它具有通过 sync(path) 实现的增量保存机制，该机制仅持久化已更改的数据，并且每次调用仅使用一次 fsync，从而确保了崩溃安全性，并确保无论索引大小如何，追加或删除操作都具有毫秒级的延迟。

TurboQuant 的工作原理

Turbovec 实现了一个多阶段流水线，在保持检索准确性的同时，压缩超球体上的高维方向。

归一化: 剥离每个向量的长度 (norm) 并将其存储为单个 float，将向量转换为单位方向。
随机旋转: 向量乘以一个随机正交矩阵。这确保了无论原始数据分布如何，每个坐标都独立地遵循可预测的 Beta 分布（在高维情况下收敛于高斯分布）。
逐坐标校准 (TQ+): 为了处理有限维度的漂移，TQ+ 拟合一个偏移量和缩放比例，将经验分位数映射到代码本的最外层质心。这通过使用少量具有代表性的样本 (~1024 行) 进行一次性操作完成。
Lloyd-Max 标量量化: 由于分布是已知的，因此可以使用 Lloyd-Max 算法预计算最佳桶边界和质心，以最小化均方误差。
位包装 (Bit-packing): 坐标被转换为小整数 (2-bit 模式下为 0-3，4-bit 模式下为 0-15) 并紧凑地打包进字节中。
长度重归一化评分: 为了修正量化导致的内积系统性低估，Turbovec 为每个向量存储一个修正标量 (||v|| / ⟨u, x²⟩)。搜索内核在堆插入之前应用此标量，从而在不增加搜索时存储成本的情况下消除偏差。

集成与使用

Turbovec 被设计为作为流行 AI 框架中内存向量存储的即插即用替代方案：

LangChain: 通过 pip install turbovec[langchain] 替换 InMemoryVectorStore。
LlamaIndex: 通过 pip install turbovec[llama-index] 替换 SimpleVectorStore。
Haystack: 通过 pip install turbovec[haystack] 替换 InMemoryDocumentStore。
Agno: 通过 pip install turbovec[agno] 替换 LanceDb。

混合检索

Turbovec 支持通过 allowlist (或 slot bitmask) 进行搜索时过滤。SIMD 内核以 32 向量粒度对没有允许槽位的块进行短路处理，从而避免了对最终将被丢弃的向量进行评分的开销。这确保了选择性过滤器不会产生全量索引扫描的完整 SIMD 成本。

社区洞察与反论点

虽然技术基准测试非常出色，但社区就项目的起源以及向量搜索的更广阔领域提出了几点看法：

学术争议: 一些用户指出了 OpenReview 上的评论和外部文章，声称有关原始 TurboQuant 论文的学术不端行为，暗示其与之前的研究如 RaBitQ 存在重叠。
基准对比: 一些批评者认为，FAISS 并不再是现代向量索引基准测试的 SoTA (State-of-the-art) 基准。
替代方案: 讨论强调了 Matryoshka 嵌入模型或微调后的嵌入模型 (将维度降低至 64) 也可以实现显著的内存节省，从而引发了关于量化是否始终是每个流水线的最佳路径的问题。