2026 年 3 月 25 日，Google Research 官方博客公布的一篇学术论文引起了轩然大波：TurboQuant作为一项向量压缩算法宣称可将大模型 KV Cache 内存占用减少 6 倍，引发内存股当日集体大跌。但随后，TurboQuant 陷入学术不端风波：涉嫌隐瞒核心技术借鉴、错误贬低先行研究、在实验中进行极度不公平的硬件对比，并且早在一年前 arXiv 上公布预印本时，在明知存在大量事实性错误的情况下，依然投稿到今年的 ICLR 学术顶会。
其作者团队曾在此期间做出公开澄清，但实际上并没有正面回应上述问题。随着舆论的发酵，TurboQuant 事件引发了更多研究者和业内人士的评论和谴责。
而该起事件中的另一方 RaBitQ 作者团队，在选择发声前的更早时间线里：2025 年 5 月，就已经在积极联络对方，希望其能够修正论文事实性错误；2025 年 11 月，通过官方渠道联系 ICLR 2026 PC Chairs；2026 年 3 月公开发声前再次与 PC Chairs 发出请求，希望对其进行正式的学术道德审查等诉求。
4 月初，我们联系到了 RaBitQ 论文两位作者，并第一时间与之进行了深入交流：
一位是新加坡南洋理工大学计算与数据科学学院副教授，也是 VectorDB@NTU 的负责人龙程。
一位是苏黎世联邦理工学院从事博士后研究的高健扬，他此前跟随龙教授攻读博士学位，是 VectorDB@NTU 最早从事向量量化与向量检索研究的博士生，同样也是 RaBitQ 的第一作者。
访谈中，高健扬提到：在谷歌官方博客发布后，曾第一时间选择给 TurboQuant 所有的作者团队再发邮件，要求其进行更正。但当时收到了第一作者 Amir Zandieh 比较强硬的回复。" 他们不仅不愿意在谷歌博客更正这两个方法的相似性，并且只同意在 ICLR 2026 会议结束后才会修正论文。错误的事实已经大规模传播了，这种以冷处理的方式我们无法接受。"
而后又等待了一天，在没有得到其他作者回复尤其是最后一位作者（谷歌副总裁 Vahab Mirrokni）的回复后，高健扬选择了公开发声。
与此同时，我们注意到自 2017 年 Faiss 库和 HNSWlib 开源后，向量检索一直以 HNSW 图索引、IVF 倒排索引两大方向为主要演进路线，而向量压缩算法 RaBitQ 在 2024 年被提出并开源后，则将向量检索引入一个新的阶段。
目前 RaBitQ 已经得到多个版本演进，包括重构代码及开源 RaBitQ Library，并且被 20 多家国内外互联网大厂和数据库厂商引入其向量产品中。而在向量检索之外的更多场景，例如现阶段备受业内关注的大模型 KV Cache 量化等工程解法，RaBitQ 依然存在可拓展的空间。
在这场小团队与大公司的公开较量中，输赢暂无定论，但我们看到了一个做基础性且具有奠基价值的科研工作者的学术智慧、底气与坚守。
以下是本次独家对话内容，文字有精简：
从 LSH 到 HNSW、IVF，再到 PQ，RaBitQ 已经做到理论上的最优误差
Q：两位老师可以先介绍下自己。以及讲讲您过去在向量数据库的向量量化 / 压缩技术改进所做的相关研究。
龙程：我是龙程，现任新加坡南洋理工大学计算与数据科学学院副教授，也是 VectorDB@NTU 的负责人。过去几年，我们在向量数据库方向开展了一系列研究工作。
具体来讲，我们在 2023 年发表了 "ADSampling" 的工作，旨在提升向量数据库中两个向量间距离计算算子的速度。随后，我们设计出了 RaBitQ 向量压缩算法，成果发表在数据库顶会 SIGMOD 2024 和 SIMGOD 2025。此后，我们围绕 RaBitQ 这一基础算法，将其与向量数据库中流行的索引结构（如图索引或倒排表索引）相结合。2025 年发表的新工作 "SymphonyQG"，便是图索引与 RaBitQ 结合的成果。
近期，我们与英伟达合作，致力于 GPU 加速场景下的向量检索，这个成果正在英伟达 cuVS 向量检索库的预审阶段。以上是我们在该领域工作的概览。
高健扬：2021 年至 2025 年期间，我在新加坡南洋理工大学跟随龙老师攻读计算机博士，之后前往苏黎世联邦理工学院从事博士后研究工作。我是 VectorDB@NTU 最早从事向量量化与向量检索研究的博士生，RaBitQ 系列也是我的一作成果。
关于工作内容，龙老师已提及几点。我在此稍作补充或通俗化解释：RaBitQ 的核心目标是解决向量存储空间占用大的问题。它利用了高维空间中的一些特殊性质，使得在大幅缩减向量存储空间的同时，仍能保证使用压缩后的向量进行精确计算。
Q：向量数据库这个概念，我最开始了解到也是在 2022 年。当时与 Zilliz 创始人沟通，也没有意识到大模型会有今天这么火。最开始大家对这个领域的定义也比较模糊。业内也是在不断综合向量数据或 AI 数据处理的特点，做一些全新的设计和研发。二位老师基本也是在这个时间段进入这个领域。当时无论是学术圈还是工业界，大家处于怎样的探索状态？
龙程：向量数据库虽是近几年的热门词汇，但相关研究可追溯至约 30 年前，即 90 年代末期，学术界已开始研究高维数据的近似搜索问题。高维数据在那时本质上就是高维向量。例如，一张图片可提取诸多特征（如长、宽、颜色等），组合起来便构成一个向量。当时已有此类向量数据，一个比较经典的应用是搜图：给定一张图片，在存有大量图片（每张图对应一个特征向量）的数据库中搜索相似图片。1998 年，Piotr Indyk 与导师 Rajeev Motwani 做了一系列解决这类问题的工作，其中局部敏感哈希（LSH）方法是这个领域的典型代表。
大约 2014、2015 年后，随着深度学习的普及，出现能够有效学习各类非结构化数据的表征，即嵌入向量。文字、图片、音频、视频均可通过表征技术转化为高维向量。此后，业界开始专门开发用于存储、管理和查询这些非结构化数据的系统，一开始还没有专门称为向量数据库，而是类似于非结构化数据系统。
这一时期，向量搜索算法也取得一定突破，基于图的索引（如当前主流的 HNSW）以及倒排索引等方法开始涌现。
在工业界，也出现了一些开源的向量搜索引擎，最具代表性的是当时 Facebook Research（现 Meta）发布的 FAISS 库。随后在 2022 年底 ChatGPT 的出现，检索增强生成（RAG）技术开始流行。RAG 的基本思想是在将问题提交给大模型前，先从知识库中搜索可能与问题相关的上下文信息，结合后再提交给大模型，以期获得更准确、更具时效性且更少幻觉的答案。
自那时起，向量数据库在大模型推理 pipeline 中的重要作用开始被广泛认识。我记得在 2023 年美国西雅图 SIGMOD 会议期间，许多人在讨论向量数据库。那个时候，各类向量数据库，包括开源的、闭源的、基于通用数据库扩展的、专门针对向量数据开发的系统大量涌现。
我们团队则是在 2021 年底，即 ChatGPT 发布前约一年，进入这个领域。契机是健扬在 2021 年来南洋理工攻读博士，我们开始为他寻找博士课题，经过几个月探索后确定了向量搜索方向，觉得还挺有研究价值。不过，当时我们也没有意识到后面会有如此大的应用前景。
Q：健扬你也谈谈当时是如何确定这个方向的？是突发奇想，还是受到某些论文启发，认为向量搜索具有研究价值？
高健扬：当时促使我们做出决定主要有三方面因素。最初契机是龙老师推荐了几篇向量检索的论文。我们当时在广泛探索了多个方向，包括 AI4DB 及一些传统数据库理论。但在阅读向量检索相关论文后，我感觉这个方向对我来说比之前探索的都更有趣。
第二点，当时虽然没有 ChatGPT，但 AI 已非常火热。自 2012 年 AlexNet 起，计算机视觉和自然语言处理领域成果井喷且在实际生活中已有大量应用。当时的想法是，既然所有 AI 模型都将非结构化数据表示为向量，那么对向量数据的研究，无论针对何种任务，在未来都至关重要。
第三点，我本人是数学背景，相比于其他方向，高维向量相关问题背后的数学结构更为干净、漂亮，可能更容易获得可分析、可证明的理论结果。这一点与我的个人背景和兴趣相契合。所以，在多种因素共同驱使下，我们开始了对向量数据库的研究。
Q：确实，RaBitQ 的提出也显示出在数学领域的理论证明。我们具体聊聊向量数据库。例如，大模型火热后，业界可能关心内存占用大、加速效果不理想、召回率较低等问题，难以解决所谓的 " 不可能三角 "。当时，业内对向量数据库的瓶颈（如内存）最早有哪些解决方案？后来出现了哪些改进思路？
高健扬：解决方案主要分两类：算法层面和系统层面。
算法层面的话，主要是向量量化。这个领域最早采用标量量化，其做法非常简单，即将实数舍入为一个有限精度的整数。之后在 2010 年左右，出现了乘积量化（PQ）方法。相比于标量量化，这个方法针对特定输入数据集设计具体的量化码本，在实践中表现非常好，在很长一段时间内是向量数据库（或向量压缩领域）的事实标准。随后便是 RaBitQ。相较于 PQ 等方法，其主要创新在于利用随机旋转（Johnson-Lindenstrauss 变换），结合高维空间中的特殊性质，获取 " 免费 " 信息以提高向量量化的精度。按我的理解，RaBitQ 现已成为向量数据库的主流方案，已在超过 20 家公司的真实系统中得到大规模部署。
而在系统层面，为节省内存，一个自然的思路是不将所有数据存于内存，而是存储于硬盘等其他介质。这个方向的典型代表是微软的 DiskANN 工作。其核心思想是：原始向量存储于内存成本高昂，所以将其存于硬盘，同时在内存中存储压缩后的向量用于检索。
这两方面大体概括了当前向量数据库解决内存瓶颈的主要途径。
Q：技术演进节奏还是比较快的。RaBitQ 提出至今，你提到已有超过 20 多家数据库厂商和互联网企业作为重要技术引入，从你的角度看，原因有哪些？是否注意到或总结过具体的行业场景？
龙程：我先尝试回答为何 RaBitQ 在工业界如此流行并被众多公司采用。我觉得至少有以下几方面原因：
首先，RaBitQ 相较于之前的乘积量化、标量量化，具有理论保障。所有量化都会产生误差，RaBitQ 可以给出这个误差的界。在相同压缩率下，其误差界是在最坏情况下能达到的最优保证。而之前的 PQ 等方法完全没有此类保证。在工业界，缺乏保证的技术会带来不安全感。只凭经验，可能在某些数据集上有效，在另一些上则无效，且无法预知在新数据集上的表现。
RaBitQ 则没有这个问题，这在向量搜索中提供了重要保障。再讲细一点，RaBitQ 支持层次化处理。例如，可先将每个向量压缩至 4-bit。检索时并非一开始就使用全部 4-bit 估算结果，而是先使用 1-bit。由于 1-bit 运算更快，且有其对应的误差保证。如果根据这个保证可解决问题或排除答案，则无需使用剩余 3-bit，过程即可终止。仅在 1-bit 无法解决时，才引入剩余 3-bit 进行增量计算。这种二阶段计算范式非常具有性价比，是先前算法无法实现的。
第二个优势是这个方法实现相对简单。可以说很干净：先进行随机旋转，如果是 32 倍压缩，则可以取正负号；如果是更多 -bit，则可以在网格上取整。内部操作简洁，易于实现，且与 CPU 的并行特性兼容良好，上手容易。
第三个优势是大家特别关心的：实际效果到底好不好？实际上，众多公司在不同业务场景、不同数据上的测试表明，其效果稳定。由于我们的保障不依赖于具体数据，对数据不做任何假设，因此泛化性极佳。RaBitQ 并非基于特定数据特性设计的方法，所以能在多种数据集上取得良好效果。
截至目前，采用的企业包括许多大型厂商，如 Meta、Apple、微软；国内则有字节、腾讯、阿里、蚂蚁等，它们均有向量搜索的需求，因此都实现或采用了 RaBitQ。
在开源生态中，包括 Milvus、VectorChord、Elasticsearch、OpenSearch 以及其他一些国内外公司，也都采用了 RaBitQ。
具体行业方面，由于 RaBitQ 的研发初衷确实是向量搜索，因此上述企业及其产品主要聚焦于向量搜索领域，如 RAG、推荐等。但我相信 RaBitQ 的应用可更广泛，包括接下来可能讨论的 KV Cache 量化，大模型权重量化，我认为也极具前景，我们也在探索这个方向。
任何需要压缩空间、提高速度的场景，均可应用 RaBitQ
Q：那么提到 KV Cache 及大模型参数层面的量化，能否具体展开讲讲？具体来讲，向量的量化和压缩技术都有哪些区别？比如我们现在会提到在权重压缩和 KV Cache 的量化压缩，又有哪些具体需要区别的？
龙程：我想这个问题可能包含两部分。一是你提到的 " 量化 " 和 " 压缩 " 听起来相似，那么有什么区别？二是 " 权重压缩 " 和 "KV Cache 压缩 " 或量化，有什么具体区别？
严格来讲，" 压缩 " 是目的，" 量化 " 是方法，" 量化 " 是 " 压缩 " 算法的其中一种类型，这两个术语侧重点不同。简单来说，" 量化 " 通常指用低精度的数值表示去近似高精度的数值表示，更强调数值表示的离散化。压缩更强调最终系统资源减少。
第二部分，" 权重压缩 " 即大模型权重的压缩，以及 "KV Cache" 的压缩。相同点在于，它们都是向量。权重是向量（如权重矩阵由众多向量堆叠而成），KV Cache 也是（每个 token 的 key 和 value 均为向量）。它们都是向量，所以都有量化需求。
量化目标在于减小大模型尺寸，使其能在更低配置的 GPU 上运行。KV Cache 量化同样有需求，且都需要保证：量化后，基于量化数据进行的计算，其结果与量化前的结果相差不应过大，以确保准确性。
两者可能的不同之处在于：大模型权重数据相对静态。模型训练完成后，你可以用它跑很多遍，反复用于各种查询，参数保持不变，除非需要重新训练新版本模型。否则大模型权重不会产生变化。这个场景下的量化类似于离线量化。
而 KV Cache 则不同，每个查询都会产生新的 KV，数据动态性强，更类似于在线量化场景。
因此，针对权重量化，就我目前看到的论文倾向于利用数据自身特点，可能使用一些校准数据辅助量化任务，不仅考虑矩阵（向量）本身，还考虑其具体应用场景。而 KV Cache 因变化较大，不同查询差异显著，所以较少使用校准数据。因为更换查询后，校准数据可能完全失效，难以考虑 KV Cache 之外的因素。如果将 RaBitQ 用于此场景，我们实际上无需校准数据，可直接进行 KV Cache 量化。
高健扬：把这件事讲得更通俗一点：权重是向量，KV Cache 是向量，向量数据库中的向量也是向量。一个通用的向量压缩算法，理论上可以在完成一定系统层面的适配之后应用于所有存在向量的场景。
Q：如果具体讨论 RaBitQ 在 KV Cache 量化压缩中的应用，企业或厂商如果想进一步采用，需要进行哪些改进？
高健扬：当前的 RaBitQ 相比最初版本已演进许多。现在如果想使用 RaBitQ，我首先建议企业尝试 RaBitQ Library 中提供的版本。这个库集成了我们现有的更好的旋转算法、量化算法，以及在现代 GPU、CPU 上的具体实现。如果想在 KV Cache 场景应用，最好采用 RaBitQ 最新的技术，以最大化其效率。
龙程：RaBitQ Library 是我们团队基于 RaBitQ 论文和算法自主开发的开源库，集成了可能更快的随机旋转算法、量化算法的新变种，以实现更好效果。
Q：关于 RaBitQ，2026 年还有哪些方向的探索？
龙程：关于 RaBitQ，我认为可能分两部分。一部分仍在向量数据库领域，我认为还有许多探索空间。如前所述，RaBitQ 是一种向量量化方法，可压缩空间并提高速度。任何需要压缩空间、提高速度的场景，均可应用 RaBitQ。因此，它可以与向量数据库中各种不同的向量搜索索引（如图索引、IVF）结合。这种结合仍有空间做得更好，这是这个方法的一个方向。
当前大家研究较多的是经典场景：每个对象有一个向量，查询对象也是一个向量，即用一个向量搜索一个向量。但在现实应用中，其实存在多种方式。例如，可结合其他标量信息进行搜索（如混合向量搜索）；或流式场景，向量非一次性全部到位，而是持续流入并实时搜索。
此外，软硬件环境也存在多种情况。数据可全存于内存，数据量较大时，也可将部分数据存于硬盘，甚至远程存储。计算环境方面，有时仅有 CPU，有时兼具 CPU 与 GPU。事实上，我们从去年下半年开始与英伟达在此方向合作，一项成果是基于 RaBitQ 的索引，将集成至英伟达的 cuVS 库中，目前处于代码审核阶段。还可能考虑云环境、分布式计算环境等。向量数据库领域仍有许多可探索的问题，我们将持续发力。
第二部分，我们想跳出向量数据库应用场景，探索包括 KV Cache、大模型权重量化在内的其他领域。可能还会审视整个机器学习基础设施栈中，是否有其他环节可利用向量搜索技术进行提升或加速。这一块探索空间可能更大，对我们而言也更未知，但我们非常有兴趣在此方向进行探索。
重构代码、开源 RaBitQ Library，但我们还做的不够快、不够好
Q：聊聊 RaBitQ 背后的一些故事。从这个方法提出至今（2024 年至今）已两年多。此过程中有哪些感受？或者说，是否感受到 RaBitQ 确实广受欢迎，因而不断对方法进行改进，包括开源 RaBitQ Library？此过程中经历了哪些事情？
高健扬：这个过程经历还是蛮丰富的，相对来说比较偏学术界之外。学术方面，我们未经历太多波折。2023 年初，我们内部完成 RaBitQ 工作，做完理论证明和实验验证后，其实我们内心已比较有底。后续的论文投稿、发表，很大程度上是水到渠成的过程。
但在学术界之外，发布 RaBitQ 论文和代码后，相当短的时间内便有公司跟进，他们会利用我们的代码进行测试或部署。我们与其中绝大多数公司都有非常愉快的交流，甚至后续合作。也有个别公司将 RaBitQ 用于其自身产品，但在媒体宣传时，对 RaBitQ 算法的描述做了微调，更改了名称，并声称是其自身创新。
我们与许多公司有接触、交流、合作，这个过程中也收到许多意见或建议。其中一个对我们改变较大的点是，我们发现大部分公司相比于学术论文中的理论严谨性，更在乎现实实现的效果。当然两者兼具最好，但如果需选择，他们会选择现实效果。这一点驱使我们重构了 RaBitQ 代码，以及后续开源 RaBitQ Library。具体而言，在重构代码及后续开源过程中，我们融入了许多实际效率更高的近似算法，以及更适合当前系统的实现。这可能是此过程中我们的主要改变和收获。
在拥有 RaBitQ Library 后，我们发现国内外有更多公司能更快地将 RaBitQ 部署至其产品中，进一步放大了项目影响力。这些可能是一个非常简单的概述。但现在回顾起来，我认为我们大部分事情：完成 RaBitQ 工作后，开放代码、论文，并积极与公司交流，后续开源 RaBitQ Library，在后看来都做对了。当然另一点是，在回头看这件事，我觉得我们可能做得还不够快、不够好。
Q：有哪些方面觉得做得不够快？是因为人单力薄，尚未形成更大团队、开源社区或商业公司？
高健扬：我觉得 " 人单力薄 " 这个词非常准确。总体而言，我们仍是学术界中一个非常小的团队。团队中可能只有龙老师一位教师，加上几名学生，这便是我们拥有的全部人力。在此条件下，要求我们编写工业级别的大型系统，确实比较强人所难。
Q：是否有想法做成像 Databricks 这样的公司？其创始人经历也是从开源到商业化公司。
高健扬：我个人感觉比较困难。一方面，当前环境与 Databricks 当年完全不同；另一方面，具体技术而言，RaBitQ 是一个更核心、更精巧的算法，而 Databricks 是系统层面的创新。据我理解，系统层面的研究更有可能带来商业上的壁垒，而 RaBitQ 这样的算法研究可能更适合在更多的系统中发挥它的价值。
龙程：健扬提到 RaBitQ 是一个较小的算法，我也要提一句，这个算法较为底层，实际上可与不同索引结合，发挥更大价值。
抛开现实因素，仅从技术角度看，例如围绕 RaBitQ 开发不同索引，搭建系统，或者在存储方面围绕 RaBitQ 开展工作，我认为具有可行性。但问题在于，当前已有大量向量数据库，如果我们再重新开发一个，缺乏差异化优势，市场已较拥挤。除非后续我们找到新出口，它不仅仅是向量数据库，可能是一个更大场景，且那时这个场景玩家不多，我认为可以畅想。但如果局限于向量数据库领域，可能确实特别困难，因为时机已过，同类产品过多。
向量量化的进步，并不意味着存储需求会减少，但也必须由更多硬件来应对
Q：存储这件事情，从硬件层面优化的进程和优势会比较明显吗？
高健扬：当前情况是假设有固定总量的存储需求，我们想以更低成本满足。有两个途径：硬件途径与软件途径。软件途径指设计新的模型架构、新的向量量化算法以降低存储开销；硬件途径则是生产更多硬件。
据我理解，像 RaBitQ 这样的方法，已做到理论上的最优。即在相同误差情况下，向量量化的压缩率本质上已不可能比 RaBitQ 更好。因此，在软件层面，我认为向量量化已发展至瓶颈，甚至达到天花板，没有继续优化的可能。这反而意味着，后续存储需求的增长，必须由更多硬件来应对。我个人认为，向量量化技术的进步，并不意味着存储需求会减少。相反，它意味着未来除了使用更多硬件进行存储，我们别无他法。
我们还观察到，许多团队正尝试使用其向量数据库来管理大模型的 KV Cache。在这种意义上，未来对 KV Cache 的管理也可能像数据库一样，具备多级存储（包括远程存储、本地硬盘、内存等）。这两个方向目前呈现合流趋势。
相关链接：
https://zhuanlan.zhihu.com/p/2020969476166808284
https://x.com/Tim_Dettmers/status/2041497412989071707
相关 arxiv 链接：
RaBitQ ( 1-bit ) ：https://arxiv.org/pdf/2405.12497
RaBitQ ( multi-bit ) :https://arxiv.org/pdf/2409.09913
RaBitQ Library:https://github.com/VectorDB-NTU/RaBitQ-Library
（本文作者 | 杨丽，编辑 | 杨林）
