剛引發存儲股暴跌就塌房？Google 刷屏 AI 論文遭指控學術不端

前幾天，Google Research 在 X 平臺正式發布了名為 TurboQuant 的 AI 壓縮算法，24 小時內瀏覽量破千萬，存儲芯片股當天集體收跌， Cloudflare CEO Matthew Prince 甚至將其稱為 Google 的「DeepSeek 時刻」。

但就在剛剛，蘇黎世聯邦理工學院博士后高健揚在知乎發出一封公開澄清信。他是論文里被比較算法 RaBitQ 的第一作者，指出 TurboQuant 存在三處嚴重問題：

刻意回避與 RaBitQ 在方法上的直接關聯、在沒有任何證據的情況下將 RaBitQ 的理論成果定性為「次優」、以及在實驗對比中用單核 CPU 跑 RaBitQ、卻用 A100 GPU 跑自己的算法。

：https://zhuanlan.zhihu.com/p/2020969476166808284

更關鍵的是，這些問題在論文投稿前就已通過郵件明確告知 TurboQuant 團隊，對方也表示知情，卻選擇了不予修正。論文隨后被 ICLR 2026 接收，并經由 Google 官方渠道大規模推廣。

質疑并非只來自 RaBitQ 團隊。第三方研究者 Jonas Matthias Kübler 也在 ICLR OpenReview 獨立提出了另一層問題： 論文中寫速度基準是 PyTorch，博客推廣時卻換成了 JAX，兩者口徑不一；

他還指出博客以 FP32 作為對比基準，本身就有失公允 ；

高健揚同步在 X 發布了英文聲明，引發討論。有網友也點出了這場爭議的本質：「這些研究者要的是署名和引用，他們并沒有直接說這篇論文的結論是錯的。」這或許也是理解整件事重要的前提。

以下是知乎網友 gaoj0017 （高健揚）的公開信原文。

對于 Google 的 ICLR 2026 TurboQuant 論文，我們必須公開澄清

大家好，我叫高健揚，目前在蘇黎世聯邦理工學院做博士后，我是 RaBitQ 系列工作的第一作者。

Google Research 于 2026 年 1 月被 ICLR 2026 會議接收的論文 「TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate」 中，有關已有的 RaBitQ 向量量化算法的描述，理論結果對比，實驗對比均存在嚴重問題（詳細情況后文會展開描述）。

這些問題在論文投稿至 ICLR 2026 前已被我們通過郵件明確指出，TurboQuant 團隊也明確表示已知情，但選擇了不予修正。論文隨后被 ICLR 2026 會議接收，然后通過 Google 官方渠道大規模推廣，在社交媒體瀏覽量已達到數千萬次。

我們此時公開說明，是因為錯誤的學術敘事一旦廣泛傳播，糾正的成本會越來越高。

背景：RaBitQ 是什么

RaBitQ 系列論文（如下所列）于 2024 年發表，提出了一種高維向量量化方法，并從理論上證明其達到了理論計算機頂級會議論文（Alon-Klartag, FOCS 2017）給出的漸近最優誤差界。

：https://arxiv.org/abs/2405.12497

RaBitQ（arXiv:2405.12497，2024 年 5 月，隨后發表于頂級會議 SIGMOD 2024） 擴展版（arXiv:2409.09913，2024 年 9 月，隨后發表于頂級會議 SIGMOD 2025）

RaBitQ 的核心想法之一是在量化前對輸入向量施加隨機旋轉（random rotation / Johnson-Lindenstrauss 變換），利用旋轉后坐標分布的性質做向量量化，在理論上實現最優誤差界。

TurboQuant 論文問題一：系統性地回避 TurboQuant 方法與已有 RaBitQ 方法的相似性

RaBitQ 與 TurboQuant 在方法層面有直接的結構聯系，兩者都在量化前對輸入向量施加隨機旋轉（Johnson-Lindenstrauss 變換）。這是兩篇論文方法設計中最核心、最接近的部分。

論文地址：https://arxiv.org/abs/2504.19874

TurboQuant 的作者在 ICLR OpenReview 審稿平臺上對審稿人的回復中，親自這樣描述自己的方法：

「We achieve this by first normalizing the vectors by their l2 norm and then applying a random rotation （隨機旋轉）to ensure the entries of the vectors will have a beta distribution post rotation.（我們通過先按向量的 L2 范數進行歸一化，再施加隨機旋轉來實現這一點，從而保證向量各分量在旋轉后服從 Beta 分布。）」

然而在這段回復、TurboQuant 論文中的方法介紹乃至整篇論文中，從未正面說明這一結構與 RaBitQ 完全一致。這一回避發生在以下背景之下：

2025 年 1 月（TurboQuant 論文在 arXiv 發布的數月前），TurboQuant 論文的第二作者 Majid Daliri 主動聯系我們，請求幫助調試他自己基于 RaBitQ C++ 代碼實現的 Python 版本。他詳細描述了自己復現的步驟、代碼片段和具體報錯，這一點可以說明 TurboQuant 團隊對 RaBitQ 的技術細節有充分的了解。

之后在 2025 年 4 月他們在 arXiv 發布的論文版本，以及 2025 年 9 月他們在 ICLR 2026 會議投稿的論文版本中，他們將 RaBitQ 描述為 grid-based PQ，并且在描述中忽略了 RaBitQ 中核心的 random rotation 的步驟。

ICLR 的一位審稿人也在審稿意見中獨立指出：「RaBitQ and variants are similar to TurboQuant in that they all use random projection」，并明確要求更充分的討論和比較。

盡管如此，在 ICLR 會議最終版本論文中，TurboQuant 的作者不僅沒有加入對 RaBitQ 討論，甚至反而還將原本正文中對 RaBitQ 不完整描述移到了附錄中。

為此，我們于 2026 年 3 月通過郵件聯系了 TurboQuant 所有作者，提出了以上問題及糾正請求后，TurboQuant 作者在回復中以

The use of random rotation and Johnson-Lindenstrauss transformations has become a standard technique in the field, and it is not feasible for us to cite every method that employs them.(隨機旋轉和 Johnson-Lindenstrauss 變換已經成為該領域的標準方法，因此我們無法逐一引用所有采用這些方法的研究)

為由拒絕了這一請求。

我們認為這一回應是在轉移矛盾：作為在相同問題設定下率先將隨機旋轉（Johnson-Lindenstrauss 變換）與向量量化結合、并建立最優理論保證的具體先行工作，RaBitQ 應當在文中被準確描述，其與 TurboQuant 方法的聯系應當充分討論。

TurboQuant 論文問題二：錯誤描述 RaBitQ 的理論結果

TurboQuant 論文在不提供任何論據的情況下，將 RaBitQ 的理論保證定性為「次優」。TurboQuant 論文寫道：

「While the paper’s theoretical guarantees are suboptimal, likely due to loose analysis — as practical performance surpasses theoretical bounds（盡管論文給出的理論保證還不是最優的，這很可能是因為分析較為寬松——因為實際表現已經超過了理論界限。）」

這句話直接將 RaBitQ 的理論保證定性為「次優（suboptimal）」，將原因歸結為「較粗糙的分析（loose analysis）」。但論文沒有提供任何推導、對比或證據來支撐這一判斷。

事實是：我們在拓展版 RaBitQ 論文（arXiv:2409.09913）的 Theorem 3.2 中，已經嚴格證明 RaBitQ 的誤差界達到了理論計算機頂級會議論文（Alon-Klartag, FOCS 2017）給出的漸近最優誤差界。

因為這一結果，我們被邀請至理論計算機科學頂級會議 FOCS 的 Workshop 進行報告。

為此，我們于 2025 年 5 月通過郵件與 TurboQuant 的第二作者 Majid Daliri 進行了多輪詳細的郵件技術討論，逐條澄清了 TurboQuant 團隊對我們理論結果的錯誤解讀。Majid Daliri 在郵件中明確表示已將這些討論告知全體共同作者。

然而后面 TurboQuant 論文在提交至 ICLR 2026、經過審稿、被接收，最終大規模宣發的全過程中，這個對 RaBitQ 理論保證的錯誤定性始終未被修正。

一個沒有證據支撐的斷言，在被原作者具體指出錯誤、且 TurboQuant 作者方已明確知情的情況下，仍被保留在正式發表的 TurboQuant 論文中，我們認為這已超出普通失誤的范疇。

TurboQuant 論文問題三：刻意創造不公平的實驗環境

TurboQuant 論文使用劣化的實現、關閉多線程使用單核 CPU 測試 RaBitQ 的效果，卻使用 A100 GPU 測試 TurboQuant 的效果。

TurboQuant 報告的 RaBitQ 量化速度比我們開源實現的實際速度慢了數個數量級。 2025 年 5 月的郵件中，Majid Daliri 本人解釋了這一差距的來源：

「we were using a single-core CPU instance, and multiprocessing was indeed disabled […] we weren’t fully utilizing parallelism, which explains why it was significantly slower（我們當時使用的是單核 CPU 實例，而且確實禁用了多進程……我們沒有充分利用并行能力，這也解釋了為什么它會明顯更慢。）」

我們的官方 RaBitQ 代碼在論文發布至 arXiv 時（2024 年 5 月與 2024 年 9 月）就已經公開，并且默認采用多線程并行。并且，Majid Daliri 在 2025 年 1 月的郵件中還說明，他成功跑通 RaBitQ 的代碼用以測試，但他用于實驗的仍是自己翻譯的 Python 版本。這意味著，TurboQuant 論文中對 RaBitQ 速度的報告，疊加了兩層系統性的不公平條件：

1.使用自己翻譯的 Python 代碼，而非我們開源的 C++ 實現

2.用單核 CPU，關閉多線程并行測試 RaBitQ 算法，但卻使用 NVIDIA A100 GPU 測試 TurboQuant 算法

以上兩點均未在論文中充分披露。讀者看到的是 RaBitQ 比 TurboQuant 慢數個數量級這一結論，卻無從知道這一結論建立在刻意創造的不公平的實驗條件之上。

事件完整時間線

2024 年 5 月：RaBitQ 論文在 arXiv 發布，同時源代碼公開（后面發表在頂級會議 SIGMOD 2024）

2024 年 9 月：拓展版 RaBitQ 論文在 arXiv 發布，同時源代碼公開（后面發表在頂級會議 SIGMOD 2025）

2025 年 1 月：TurboQuant 論文第二作者 Majid Daliri 聯系我們，請求協助調試 Python 版 RaBitQ 實現

2025 年 4 月：TurboQuant 論文在 arXiv 發布

2025 年 5 月：我們跟 Majid Daliri 通過郵件詢問了實驗條件的差異并清楚解釋了 RaBitQ 的理論保證最優性， Majid Daliri 表示他已告知全體作者，但在我們要求修正 TurboQuant 論文中的事實性錯誤之后，Majid Daliri 停止回復

2025 年 11 月：我們發現 TurboQuant 論文被提交至 ICLR 2026 會議，且論文中的事實性錯誤并未修正，為此我們聯系了 ICLR 2026 PC Chairs，未獲回應

2026 年 1 月：TurboQuant 論文被 ICLR 2026 接收 2026 年 3 月：TurboQuant 團隊通過 Google 官方渠道持續推廣，社交媒體相關瀏覽量已達數千萬次

2026 年 3 月：我們正式向 TurboQuant 全體作者發送郵件，闡述以上三個事實性問題并要求做出修正及澄清。截至目前為止，我們僅收到 TurboQuant 論文第一作者 Amir Zandieh 的籠統答復，承諾會修正問題二和問題三，但拒絕修正問題一（即討論 TurboQuant 與 RaBitQ 在技術上的相似性）。并且，他們僅愿意在 ICLR 2026 正式會議結束之后才做相應修正

我們已經做了什么

在 ICLR OpenReview 發布公開評論:

https://openreview.net/forum?id=tO3ASKZlok

向 ICLR General Chairs, PC Chairs, Code and Ethnics Chairs 再次提交正式投訴，附完整證據包

我們接下來會做什么

在 arXiv 發布詳細的關于 TurboQuant 和 RaBitQ 的技術報告

考慮向相關機構進一步反映

最后

我們提出這些問題，目標是讓公共學術記錄準確地反映各方法之間的真實關系。一篇論文被 Google 以數千萬曝光量推向公眾，在這種體量下，論文中錯誤的敘事不需要主動傳播，只需要不被糾正，就會自動成為共識，這也是我們選擇公開記錄的原因。

在此我們也懇請大家讓更多人知道 TurboQuant 論文背后存在的問題，我們相信真理越辯越明。

附上原文出處地址：

https://zhuanlan.zhihu.com/p/2020969476166808284

我們正在招募伙伴

簡歷投遞郵箱hr@ifanr.com

?? 郵件標題「姓名+崗位名稱」（請隨簡歷附上項目/作品或相關鏈接）