TurboQuant vs RaBitQ：Google ICLR 论文涉嫌学术不端风波

一句话版本：Google Research 发表了一篇 ICLR 2026 论文（TurboQuant），声称提出了一种全新的向量量化方法。但 ETH 的 Jianyang Gao 公开指控：这篇论文的方法与他自己之前发表的 RaBitQ 高度相似却故意不引用、错误贬低 RaBitQ 的理论贡献、并且用不公平的实验设置来证明 RaBitQ 比 TurboQuant 慢好几个数量级。

来源

• 🔗 Jianyang Gao 公开发文 (DEV.to)
• 🔗 Google Research 官方博客 (Promo)
• 🔗 TurboQuant ICLR 2026 OpenReview
• 🔗 RaBitQ 论文 (arXiv)
• 🔗 RaBitQ 扩展版 (arXiv)
• 🔗 Medium 转载
• 🔗 Milvus Blog: 中立分析

日期: 2026-03-31（Jianyang Gao 首次公开披露）

核心内容

背景

• RaBitQ（Random Bit Quantization）是 Jianyang Gao 在 NTU 读博期间的研究成果，发表于 SIGMOD 2024/2025。它的核心思想是对输入向量做随机旋转（Johnson-Lindenstrauss 变换）后进行量化，并且理论上证明了它达到了 Alon-Klartag (FOCS 2017) 建立的渐进最优误差界。
• TurboQuant 是 Google Research 的论文，发表于 ICLR 2026，声称提出了一种"近最优"的在线向量量化方法，可对 KV Cache 做 3-bit 量化而质量无损。

三大指控

❗ 问题 1：系统性回避方法相似性

• RaBitQ 和 TurboQuant 都使用同一核心技术——对输入向量做随机旋转 (Johnson-Lindenstrauss 变换)，这是两者最核心的设计重合。
• TurboQuant 论文中却将 RaBitQ 描述为"基于网格的 PQ"，故意省略了随机旋转这个关键步骤。
• 关键证据：TurboQuant 第二作者 Majid Daliri 在 2025 年 1 月（TurboQuant 投稿前数月）主动联系 Gao，请求帮助调试他自己从 RaBitQ C++ 代码翻译过来的 Python 实现。这说明 TurboQuant 团队对 RaBitQ 的技术细节有详细了解。
• ICLR 审稿人独立指出了这一点，要求 TurboQuant 更全面地讨论 RaBitQ，但作者不仅没有添加讨论，反而把已有的不完整描述从正文移到了附录。
• Gao 要求纠正，TurboQuant 作者回应："随机旋转和 JL 变换已成为该领域标准技术，我们不可能引用每种用了它们的方法。" Gao 反驳：RaBitQ 不是"众多无关方法之一"——在同样的问题设定下，它是第一个把随机旋转和向量量化结合起来并证明了最优误差界的具体前人工作。

❗ 问题 2：错误描述 RaBitQ 的理论结果

• TurboQuant 论文直接将 RaBitQ 的理论保证描述为 "suboptimal"（次优的），归因于"宽松的分析"——且没有提供任何推导或证据。
• 事实上 RaBitQ 扩展版（Theorem 3.2）已经严格证明了它达到了 Alon-Klartag (FOCS 2017) 的渐进最优误差界。因为这项成果，Gao 被邀请在 FOCS 的 workshop 上演讲。
• 2025 年 5 月，Gao 与 Daliri 进行了多轮详细技术邮件交流，逐点纠正了 TurboQuant 团队的误读。Daliri 明确表示已将这些讨论传达给所有合著者。
• 然而这个错误描述从未被修正，通过了审稿、被接收、被大规模推广。

❗ 问题 3：故意设置不公平的实验对比

• TurboQuant 论文测试 RaBitQ 时使用了退化的实现 + 单核 CPU（关掉了多线程），而测试 TurboQuant 时用的是 NVIDIA A100 GPU。
• 报告的速度数据是 RaBitQ 比 TurboQuant 慢几个数量级。
• 但 Gao 的官方 RaBitQ 代码（2024 年 5 月就已公开，默认多线程并行）从未被使用——TurboQuant 用的是作者自己翻译的慢速 Python 实现。
• Daliri 在 2025 年 5 月的邮件中自己承认："我们在用单核 CPU 实例，多进程确实被禁用了……没有充分利用并行性，这就是为什么它慢很多。"
• 论文中没有充分披露这两点不公平因素。

时间线

后续进展

• Gao 已向 ICLR 总主席、PC 主席、Code and Ethics 主席提交正式申诉及完整证据包
• 计划在 arXiv 发布详细技术报告
• TurboQuant 第一作者 Amir Zandieh 承诺在 ICLR 2026 大会结束后修正问题 2 和 3，但拒绝讨论问题 1

分析

与向量数据库 / LLM 推理领域的关系

这场争议不仅关乎两篇论文的优先权，它直接影响的领域包括：

• KV Cache 量化：TurboQuant 声称 3-bit 量化 LLM KV Cache 质量无损——如果方法上与 RaBitQ 高度相似，则 RaBitQ 才是这个方向的原创者。
• 向量搜索：向量量化是 ANN 搜索的核心技术，影响的系统包括 Milvus、Faiss、DiskANN 等。

为什么这很重要

• Google 的推广力量：通过 Google Research 官方博客推广，社交媒体曝光量达数千万。一个错误叙述在如此大规模的传播下，如果不纠正，"就成了默认共识"。
• 学术规范：如果 Gao 的指控成立，这意味着一个 Google 团队在知道前人工作的情况下，不仅没有正确引用，还通过不公平的实验来衬托自己的方法，且在被指正后拒绝纠正——这已经超出了"普通错误"的范畴。
• ICLR 评审的失效：审稿人指出了问题，但论文作者绕过，论文最终被接收。

值得注意的细节

• Gao 在 2025 年 11 月联系 ICLR PC Chairs 没有收到回复
• TurboQuant 团队仅愿意在 ICLR 大会结束后才修正——这意味着论文将以未更正的版本在会议展示
• Google 官方博客宣传 TurboQuant 时，完全没有提及 RaBitQ

与技术栈的关联

如果你的项目涉及 LLM 推理优化 或 向量搜索，这场争议直接相关：

• 如果你在使用或考虑 RaBitQ 做向量量化，TurboQuant 论文中对 RaBitQ 的描述（"次优的"、"慢几个数量级"）可能给你误导性的信息。
• TurboQuant 声称的"3-bit 无损 KV Cache 量化"效果如果确实很大程度上依赖于 RaBitQ 的技术，那么 RaBitQ 本身就值得关注。

评分

报告生成: 2026-05-24 | 来源: DEV.to, Google Research Blog, OpenReview, arXiv