苏黎世联邦理工博士后公开指控Google论文TurboQuant：方法相似却未引用、实验对比不公

开源模型模型性价比模型评测与对比

2026-03-30 09:43

139 浏览

0 点赞

AI 速览

苏黎世联邦理工博士后高健扬公开指控Google Research在ICLR 2026论文TurboQuant中存在学术规范问题，涉及方法引用、理论评价及实验公平性争议。核心事实 - 争议主体：苏黎世联邦理工博士后高健扬（RaBitQ作者）vs Google Research（TurboQuant作者） - 核心指控：TurboQuant未充分讨论RaBitQ的相似性、错误评价其理论为次优、实验对比条件不公 - 关键证据：OpenReview审稿记录显示审稿人已指出相似性；邮件承认测试时禁用多进程导致性能偏差 - 官方回应：Google承诺修正实验和评价部分，但拒绝修改关于JL变换无需引用的立场价值点揭示了AI学术界在模型对比、引用规范及实验透明度方面的潜在风险，提醒开发者关注技术溯源与公平评估。

3月30日消息，苏黎世联邦理工学院博士后研究员高健扬（Jianyang Gao）在知乎和X平台发布公开信，指控Google Research发表于ICLR 2026的论文TurboQuant存在三项学术规范问题：系统性回避与RaBitQ的方法联系、发表未经验证的"次优"评价、以及实验条件对比不公。

苏黎世联邦理工博士后公开指控Google论文TurboQuant：方法相似却未引用、实验对比不公

核心争议：相似方法未被充分讨论

高健扬是RaBitQ系列工作的第一作者。RaBitQ发表于SIGMOD 2024（扩展版SIGMOD 2025），核心方法是随机旋转（Johnson-Lindenstrauss变换）配合极致量化，可将高维向量压缩至3bit左右用于近似最近邻搜索。

TurboQuant由Google Research团队发表于ICLR 2026，核心方法同样包含随机旋转配合极化量化（PolarQuant），同样支持3bit极致压缩。高健扬指出，两者在问题设定、核心技术和压缩目标上高度相似。

根据OpenReview公开记录，ICLR审稿人曾明确指出"RaBitQ和TurboQuant都使用随机投影"，并要求作者"更充分地讨论和比较"相关工作。但TurboQuant作者在最终版本中反而将RaBitQ的描述从正文移至附录，未加强讨论。

作者在OpenReview的回应中称："随机旋转和JL变换已成为领域标准技术，不可能引用每一个使用它们的方法。"高健扬反驳称，审稿人独立指出的相似性恰恰说明这并非"标准技术"的泛泛使用，而是需要明确说明的方法论联系。

"次优"评价缺乏证据支撑

TurboQuant论文中描述RaBitQ时称："该论文的理论保证是次优的，可能是由于分析过于宽松——实际性能超过了理论界限。"高健扬指出，这一判断没有任何推导、对比或证据支撑。

事实上，RaBitQ扩展版（arXiv:2409.09913）中的Theorem 3.2已严格证明其达到Alon-Klartag（FOCS 2017）的渐近最优误差界。高健扬因此被邀请至FOCS Workshop做专题报告。

高健扬表示，2025年5月曾与TurboQuant作者Majid Daliri通过邮件进行多轮技术讨论，明确澄清了RaBitQ的理论最优性，对方表示已告知全体作者。但论文从审稿、接受到Google官方推广的整个过程中，这一错误描述始终未被纠正。

实验对比条件差异巨大

高健扬指控TurboQuant的实验对比存在"两层系统性不公平条件"：测试RaBitQ时使用单核CPU且禁用多进程，而测试TurboQuant时使用A100 GPU；同时使用的是非官方的Python翻译版本，而非官方开源的C++多线程实现。

根据高健扬公开的邮件记录，Majid Daliri在2025年5月的邮件中承认："我们使用的是单核CPU实例，多进程确实被禁用……我们没有充分利用并行性，这解释了为什么速度明显慢得多。"官方RaBitQ代码（C++多线程）早在2024年5月arXiv发布时即已公开。

高健扬指出，TurboQuant论文报告的RaBitQ速度比实际公开版本慢数个数量级，且论文中对此"未充分披露"。

时间线：从代码求助到公开指控

根据高健扬披露的时间线，争议并非突然爆发：

2024年5月/9月：RaBitQ及扩展版论文发布，官方C++代码开源

2025年1月：TurboQuant第一作者Majid Daliri邮件联系高健扬团队，请求协助调试Python版RaBitQ实现，邮件中包含详细复现步骤和报错信息

2025年4月：TurboQuant论文发布于arXiv

2025年5月：双方就RaBitQ理论最优性进行多轮邮件讨论

2026年1月：TurboQuant被ICLR 2026接收

2026年3月：Google官方博客推广TurboQuant，称其为"重新定义AI效率"；高健扬发布公开信

高健扬在公开信中称，TurboQuant论文被接受后Google进行了大规模宣传，24小时内浏览量破千万，存储芯片股当日集体收跌，Cloudflare CEO更称其为Google的"DeepSeek时刻"。他担心在品牌效应下，不准确的学术记录可能被洗成"共识"，因此选择公开澄清。

Google团队回应：承诺部分修正

根据高健扬公开的邮件记录，Google团队在3月的邮件中承诺修正问题2（"次优"评价）和问题3（实验对比），但拒绝修正问题1（方法联系），坚持认为JL变换是"标准技术"无需特别说明。

截至发稿，Google Research官方博客和相关论文尚未公开更新。

舆论反应

事件在知乎和X平台引发广泛讨论。知乎相关文章获得大量转发和评论，Reddit上亦有讨论帖。舆论基本呈一边倒态势，多数评论质疑Google的学术诚信。

高健扬表示，他的目标并非否定TurboQuant的技术贡献，而是希望学术记录准确，让首创者得到应有的引用和认可。他计划发布arXiv技术报告，进一步澄清技术细节。

相关链接：

高健扬知乎公开信：https://zhuanlan.zhihu.com/p/2020969476166808284

TurboQuant OpenReview页面：https://openreview.net/forum?id=tO3ASKZlok

RaBitQ论文：https://arxiv.org/abs/2405.12497

TurboQuant论文：https://arxiv.org/abs/2504.19874

好文章，需要你的鼓励

# 报错信息分析与调试指南 ## 任务说明请分析用户提供的报错信息，推测可能的错误原因，并提供系统性的调试步骤。 ## 分析要求 1. **错误类型识别** - 确定是语法错误、运行时错误、逻辑错误还是环境配置错误 - 识别具体的错误类别（如空指针、数组越界、类型不匹配等） 2. **原因推测** - 基于错误信息中的关键线索进行合理推断 - 考虑常见的导致此类错误的编程场景 - 分析可能的代码问题或环境问题 3. **调试步骤** - 提供从简单到复杂的逐步调试方法 - 包括代码检查、日志添加、环境验证等具体操作 - 给出预防类似错误的最佳实践建议 ## 输出格式 - **错误类型**：[具体的错误分类] - **可能原因**： 1. [原因1] 2. [原因2] 3. [原因3] - **调试步骤**： 1. [步骤1] 2. [步骤2] 3. [步骤3] 4. [步骤4] - **解决方案**：[具体的修复建议] ## 示例 **输入**：【报错信息】 ``` TypeError: Cannot read property 'length' of undefined at processData (app.js:25:18) at main (app.js:10:5) ``` **输出**： - **错误类型**：运行时错误 - TypeError - **可能原因**： 1. 变量未正确初始化就被访问其 length 属性 2. 函数参数传递了 undefined 值 3. 异步操作中数据还未加载完成就尝试访问 - **调试步骤**： 1. 检查 app.js 第25行附近的变量声明和赋值 2. 在访问 length 属性前添加类型检查：`if (variable && variable.length)` 3. 使用 console.log() 输出相关变量的值确认其状态 4. 检查函数调用时传入的参数是否正确 - **解决方案**：在访问对象属性前先验证对象是否存在，或确保变量在使用前已被正确初始化。