延迟交互模型，为什么是下一代RAG的标配？

一个好的 Reranker 模型，几乎成了决定 RAG 系统研发成败的关键角色。这或许是对它最直白的评价。因为在 RAG 的工作流程中，仅仅依赖向量搜索来做召回，命中率往往无法保证——很多时候，一次粗糙的初筛结果，就决定了最终输出的质量天花板。于是，业界普遍认可的做法是：先用向量搜索做粗筛（第一阶段），再用更高级的 Reranker 模型做精排（第二阶段），形成一个串联的两阶段排序架构。两条腿走路，总比单腿蹦好使。

目前来看，主流的排序模型架构无外乎那么两类，但它们的选型差异，直接决定了系统能在多大程度上挖掘出潜在的答案。

双编码器与交叉编码器：经典的两大阵营

第一类是双编码器。这个很容易理解，典型的代表就是 BERT。在双编码器架构下，查询和文档各自走一个独立的编码器，得到各自的向量表示，最后再经过一个 Pooling 层，统一压缩成一个向量。

你看，在排序阶段，只需要计算查询向量和文档向量的相似度就完事了。是不是够快？没错，向量搜索本质上就是这种排序模型的工程化应用。但有个问题：由于查询和文档是分别编码的，它们之间的 Token 不可能进行任何交互。换句话说，两个陌生人各自在房间里背诵自己的台词，没有眼神交流——最终难免会丢失大量语义细节。不过好在效率超高，一个向量计算就能出结果。

第二类是交叉编码器（Cross Encoder）。它的思路反过来了：把查询和文档拼在一起，让它们进入同一个编码器。这相当于让查询和文档海量的字符，直接进入同一个 Transformer，没有中间环节的编码损耗。结果就是，它能够捕捉查询和文档之间最复杂的交互关系。

不过代价也是巨大的：它对每一个需要排序的文档，都得跟查询拼在一起重新编码一次。这意味着，每对查询-文档都要走一遍完整的 Transformer 前向传播，导致推理速度极慢——即便是对初筛的 Top 10 文档进行重排序，也得慢到秒级。所以，它只能用于最后的精排。

两类模型一直就这样博弈着，既追求精度，又在乎速度，很难两全。

ColBERT 的登场：延迟交互模型的突破口

直到 ColBERT 这个特殊的存在，开始被社区反复提及。它的一些特点，让它与以上两类模型拉开了明显的距离。

先说跟 Cross Encoder 的对比。ColBERT 依然是个双编码器结构，它的查询 Token 和文档 Token 在编码时是完全隔离的，互不影响。但这个隔离，反而让文档端的编码能够完全离线完成，等查询过来时只需要实时编码一遍查询，效率远高于 Cross Encoder。

再说跟传统双编码器的对比。大多数双编码器最后会通过 Pooling 层，把一堆向量压缩成一个向量。但 ColBERT 不走这条路，它从 Transformer 的最终输出层直接获取多向量输出——每个 Token 对应一个向量。这样一来，就没有 Pooling 层导致的语义损失。

到这里有人会问：多向量有了，但怎么计算相似度呢？ColBERT 给出的方案叫“延迟交互”，它定义了一个叫 MaxSim 的计算方法。大致思路是：对查询的每个 Token 向量，跟所有文档 Token 向量做相似度运算，然后记下每个查询 Token 与文档的最大得分。最终的文档得分，就是这些最大得分的加和。举个例子，一个 32 Token 的查询，和一个 128 Token 的文档，就得执行 32 × 128 次相似性操作。这显然比传统向量搜索要重，但从架构上，它保全了语义的丰富性。

对比之下，Cross Encoder 可以被称为

，而 ColBERT 这类模型，则被称为。这里的“延迟”，指的是把交互计算推迟到了 Token 向量生成之后，而不是在编码阶段就合在一起。

从性能和排序质量的横对比来看，延迟交互模型做到了一个很难得的平衡：既捕获了查询和文档之间的复杂交互，又避免了对每个文档编码的开销。在同样数据规模下，ColBERT 的效率可以做到 Cross Encoder 的百倍以上。一个很自然的想法就冒出来了：既然 ColBERT 这么强，能不能直接在 RAG 中用一套 ColBERT，替代掉“向量搜索 + 精排”的两阶段架构？

理想落地，还得跨过工程化这道坎

想法很直接，但工程化的道路上，至少面对两个现实的麻烦。

因为采用多向量计算，MaxSim 的计算开销是普通向量相似度的 M × N 倍（M 是查询 Token 数，N 是文档 Token 数）。为此，ColBERT 的作者在 2021 年推出 ColBERT v2，通过 Cross Encoder 蒸馏来提高 Embedding 质量，并对文档向量做量化压缩来降低 MaxSim 计算量。后来社区围绕它包装出了 RAGatouille，成为 RAG 排序的标杆工具。但说到底，ColBERT v2 依然只是个算法库，要把它塞进企业级的 RAG 系统里端到端跑通，依然是件让人头疼的事。

训练数据来自搜索引擎的查询和结果，这些文本数据本身不长，所以模型通常把查询限制在 32 Token、文档限制在 128 Token。当真实数据中遇到长文档时，超出的部分直接就被截断了——这对长文档检索相当不友好。

针对这些问题，开源的 AI 原生数据库 Infinity 给出了另一种思路：在最新版本中提供 Tensor 数据类型，并原生地提供端到端的 ColBERT 方案。

简单来说，ColBERT 编码输出的多个向量，直接用 Tensor 存放。Tensor 间的相似度计算，直接就能得到 MaxSim 打分。

为了提升 MaxSim 的运算效率，Infinity 做了两件事：

• 二进制量化。
  原始 Tensor 的空间被压缩到只有 1/32，但 MaxSim 计算的相对排序结果几乎不受影响。这个方案主要用于 Reranker，因为它只对前一阶段粗筛出来的结果做重排。

• Tensor Index。
  这与 ColBERT v2 类似，但 Infinity 采用了更进一步的 EMVB 方案，通过量化加上预过滤技术，再辅以 SIMD 指令来加速。Tensor Index 只能用来做 Ranker，不能用于 Reranker。

对于长文本裁断的问题，Infinity 引入了 Tensor Array 类型。一篇超过 ColBERT 长度限制的文档，会被切成多个段落，分别编码成 Tensor 后，跟原始文档存在同一行。到计算相似度时，查询会跟这些段落分别算，取最大值作为整个文档的打分。

这样一来，采用 Infinity，就可以端到端地引入延迟交互模型，为 RAG 提供更强大的排序能力了。但一个核心问题还没解决：在构建系统时，到底该把 ColBERT 当作 Ranker 用，还是当作 Reranker 用？

两场关键评测：数据不会说谎

为了回答这个问题，用 Infinity 在 MLDR 数据集上跑了两组评测。MLDR 是 MTEB 里专门用来评测 Embedding 模型质量的 benchmark，全称 Multi Long Document Retrieval，包含 20 万条长文本数据。评测中用 BGE-M3 作为 Embedding 模型，用 Jina-ColBERT 生成 Tensor。所有评测脚本也都放在了 Infinity 的仓库里，随时可以复现。

评测一：ColBERT 作为 Reranker 是否有效？

将 20 万 MLDR 数据用 BGE-M3 生成稠密向量和稀疏向量，存到 Infinity 数据库中。数据库一共四列：原始文本、向量、稀疏向量、Tensor，并分别建好对应的索引。评测覆盖了单路召回、双路召回，甚至三路召回。

评测指标采用 nDCG@10。查询共 800 条，平均长度约 10 个 Token。

结论非常清晰：所有召回方案，在用 ColBERT Reranker 后都有明显提升。最值得关注的是性能——ColBERT 的重排序质量完全可以媲美 MTEB 排行榜上顶尖的 Cross Encoder，但速度却是它们的上百倍。这次评测中，用 ColBERT 对 Top 100 做重排序，效果非常好；但把范围扩大到 Top 1000 时，数值变化不大，性能反而降下来了——所以不推荐对更大规模做重排。

反观传统的 Cross Encoder Reranker，连 Top 10 都要慢到秒级，而 Infinity 内部实现的高性能 ColBERT Reranker，针对 Top 100 甚至 Top 1000 做重排，都不会影响用户体验。关键是，整个 ColBERT Reranker 的计算可以完全跑在 CPU 上，部署成本大幅降低。

评测二：ColBERT 作为 Ranker 的效果又怎样？

这次需要对 Tensor 列构建 Tensor Index，并同时进行暴力搜索来对比精度损耗。

结果多少有点意外：即便是没有精度损失的暴力搜索，也没表现出什么提升。甚至基于 Tensor Index 的排序质量，还不如用 ColBERT 做 Reranker。更关键的问题是查询速度：20 万条数据，用 Jina-ColBERT 转成 Tensor 后，数据量膨胀到了 320G（因为每个 Token 的 128 维向量都要存下来），构建了 Tensor Index 后，每个查询也要等 7 秒，结果却没有更好。

一个明确的结论清晰了：

综合来看，目前 RAG 检索效果最好的方案，是“3 路混合搜索（全文搜索 + 密集向量 + 稀疏向量）+ ColBERT Reranker”。有人会提出疑问：为了这个 Reranker 得额外加一列 Tensor 数据，而且数据量一下子就膨胀了两个数量级，值得吗？这里可以算两笔账：第一，Infinity 对 Tensor 提供二进制量化，作为 Reranker 时对效果影响很小，但数据空间直接降到 1/32；第二，即便认为这个开销太高，但站在使用者的角度，用存储换排序质量、用 CPU 换 GPU 成本，整体上非常划算。况且，接下来很快就会有存储开销更低的延迟交互模型推出，而 Infinity 作为数据基础设施，对这些变化保持透明，最终把取舍权交给用户——这才是合理的做法。

基于 Infinity 在 MLDR 数据集上的全面评测，虽然换到别的数据集上具体的数值可能会有差异，但整体结论是不会变的。

未来已来：多模态场景中的延迟交互

由此可见，ColBERT 及其背后的延迟交互模型，在 RAG 场景中已经体现出巨大的应用价值。但事情还没完——最近，延迟交互模型又成功跨界到了多模态场景，这就是 ColPali。

它直接改变了 RAG 面对复杂格式文档时的工作流程。过去，文档里的图表、图片要逐块识别、转文字，再按格式入库，链条很长。而 ColPali 直接用一个多模态模型生成 Embedding，连这些中间步骤都省了。提问的时候，可以直接针对文档中的图表回答问题。

ColPali 的训练思路跟 ColBERT 很相似，都是用查询-文档页面对的形式来训练。不同的是它用 PaliGemma 来生成多模态 Embedding。一个很直观的对比：同样都用 PaliGemma 生成 Embedding，但没有应用延迟交互机制的方案 BiPali，在 nDCG@5 上只拿到 58.8；而加上了 ColPali 的延迟交互后，这个数字跳到了 81.3。这种差距，已经不是一个量级了——是“极好用”与“基本没法用”的区别。

所以，尽管 ColBERT 已经提出四年了，但延迟交互模型在 RAG 中的应用可以说才刚刚拉开序幕。它会大大扩展 RAG 的使用场景，特别是在包含多模态数据的复杂场景中提供高质量的语义召回。而 Infinity 已经为这个走向，做好了端到端的底层准备。