AIxiv 是机器之心旗下一个发布学术和技术内容的专栏。过去几年，机器之心的 AIxiv 专栏共收到超过 2000 篇文章，涵盖全球各大高校和企业的顶尖实验室，有效促进了学术交流和传播。如果你有优秀的作品可以分享，欢迎投稿或联系我们进行报道。投稿邮箱：
张英锋：联合创始人，拥有多年搜索、AI、Infra基础设施开发经验，目前致力于下一代RAG核心产品的建设。
在RAG系统的开发中，好的模型是必不可少的，在各种评测中都会用到，这是因为用向量搜索表示的查询会面临命中率不高的问题，所以需要用先进的模型来弥补，从而形成了以向量搜索为粗筛选，模型为精排序的两阶段排序架构。
排名模型架构主要有两种类型：
1. 双编码器。以 BERT 模型为例，它对 query 和 分别进行编码，最后经过一层，使得输出只包含一个向量。在 query 阶段，只需要计算两个向量的相似度即可。如下图所示。双编码器可以用于 query 和 阶段。向量搜索其实就是这种排序模型。由于双编码器对 query 和 分别进行编码，因此无法捕捉 query 和 token 之间的关系。复杂的交互关系会造成大量语义损失，但由于只需要向量搜索就可以完成排序和打分计算，因此执行效率非常高。
2. Cross 。Cross- 使用单一编码器模型对 query 和 同时进行编码，能够捕捉 query 和 之间复杂的交互，从而提供更精准的搜索排序结果。Cross- 并不输出 query 和 的 token 对应的向量，而是加了一个分类器，直接输出 query 和 之间的相似度得分。它的缺点是在搜索时需要将每篇 和 query 一起编码，这让排序速度非常慢，所以 Cross- 只能用来对最终结果进行重新排序，比如对初始筛选结果的前 10 名进行重新排序依然需要数秒的时间才能完成。
今年，以[参考文献1]为代表的另一类工作引起了RAG开发社区的广泛关注，如下图所示，它具有一些与上述两类排序模型明显不同的特点：
首先，相比于 Cross，它依然采用了双编码器的策略，查询和文档分别用独立的编码器进行编码，因此查询 token 和文档 token 在编码过程中互不影响。这种分离使得文档编码可以离线完成。处理时，查询时只用到查询编码，因此处理速度比 Cross 快很多；
第二是相比于对偶编码器，输出的是多个向量而不是单个向量，直接从的最后一个输出层得到，而对偶编码器是将多个向量经过一层转换成一个向量输出，因此丢失了一些语义。
在计算排序时，引入一个延迟交互相似度计算函数，并命名为最大相似度（）。计算方法如下：对于每个查询 token 向量，与所有文档 token 对应的向量进行相似度计算。并跟踪每个查询 token 的最大得分。查询和文档的总得分是这些最大余弦得分之和。例如，对于具有 32 个 token 向量的查询（最大查询长度为 32）和具有 128 个 token 的文档，需要执行 32*128 次相似度运算，如下图所示。
因此，相比较而言，Cross可以称为早期互动模型（Early Model），而其代表的作品可以称为延迟互动模型（Late Model）。
下图从性能和排序质量两个方面对比了上述几种排序模型，由于延迟交互模型在排序过程中捕获了查询与文档之间复杂的交互，避免了文档token编码的开销，因此既能保证良好的排序效果，又能获得更快的排序性能。在同样的数据规模下，Cross的效率可以是Cross的100倍以上。因此，延迟交互模型是一种非常有前途的排序模型。对：我们能否直接在RAG中使用延迟交互模型来取代向量搜索+细排序这样的两阶段排序架构呢？
为此，我们需要考虑一些工程问题：
1. 的延迟交互相似度函数比Cross高效很多，但计算开销相比普通向量检索依然较高：因为查询与文档的相似度是多向量计算，开销是普通向量相似度计算的M*N倍（M为查询token个数，N为文档token个数）。针对此，作者在2021年推出了v2[参考2]，通过利用压缩技术对生成的文档向量进行量化，提升生成文档的质量，从而提高计算性能。基于v2包的项目[参考3]成为高质量RAG排序的解决方案。不过v2仅仅是一个算法库，端到端的实现，在企业级RAG系统中使用还有一定的难度。
2. 由于是预训练模型，训练数据来源于搜索引擎的查询和返回结果，这些文本数据并不大，例如查询 token 数为 32，文档 token 数为 128，是典型的长度限制，因此对于真实数据会使用，当长度超过限制时就会被截断，对于长文档检索并不友好。
基于以上问题，开源AI原生数据库在最新版本中提供了数据类型，原生提供了端到端的解决方案，作为数据类型使用时，可以将编码输出的多个向量直接存入一个，计算两者的相似度，直接得到评分。为了解决计算量大的问题，给出了两种方案对其进行优化：一种是量化，可以使空间只需要原来的1/32大小，但是却不改变计算的相对排序结果，主要因为需要根据前一阶段粗筛选的结果提取对应的结果，所以采用这种方案。另一种是Index，其实是作者推出的Index实现，采用的是EMVB[参考4]，可以看作是v2的改进，主要通过量化和预过滤技术，在关键操作上引入SIMD指令来加速实现。Index只能用于服务而不是。另外，对于超出token限制的长文本，引入了Array类型：
超出限制的文档会被拆分成多个段落，这些段落会与原文档一起编码保存在一行中。计算时，查询和这些段落分别计算，取最大值作为整篇文档的得分。如图所示：
因此通过采用，我们可以端到端的引入延迟交互模型，从而高质量地服务于RAG。那么，我们是应该采用as，还是采用or？接下来我们采用在真实数据集上进行评估。全混合搜索解决方案，召回手段包括向量搜索，全文搜索，稀疏向量搜索，以上，以及这些手段的任意组合，并且提供了多种手段，比如RRF，等等，所以我们在评估中包含了各种混合搜索和组合。
我们使用MLDR数据集进行评估。MLDR是MTEB[参考文献5]用来评估模型质量的数据集，其中MLDR是数据集之一。它的全名是Multi Long，总共包含20万条长文本数据。评估使用了BGE-M3[参考文献6]作为模型，使用Jina-[参考文献7]生成，评估脚本也放在仓库中[参考文献8]。
评估一：是否有效？20万MLDR数据使用BGE-M3生成稠密向量和稀疏向量，插入到数据库中，数据库包含4列，分别存储原文、向量、稀疏向量，并分别构建对应的全文索引、向量索引、稀疏向量索引。评估包括所有召回组合，包括单向召回、双向召回、三向召回，如下图：
评估指标采用nDCG@10。其他参数：使用RRF时，粗筛选返回的top N为1000，总查询数为800，平均每个查询的长度约为10个token。
从图中可以看出，所有召回方案被采用后效果都有明显提升，作为延迟交互模型，在MTEB排名上可以提供媲美top排名的排名质量，但是性能上，图中给出的结果都是针对top 100的，而top 1000的重新排序并没有明显的数值变化，性能明显下降，因此并不推荐使用。传统上外部top 10基于Cross会有秒级的延迟，而内部却能达到高性能，即使top 100甚至top 1000重新排序也不会影响用户体验，召回范围大大增加，因此最终的排名效果可以得到明显提升。另外这个计算可以在纯CPU架构上运行，大大降低了部署成本。
评估二：比较是基于行为而非结果，因此需要对这一列数据建立Index，同时为了评估Index引入的精度损失，还进行了暴力搜索。
可以看到，即便是不损失精度的暴力搜索，性能提升并不明显，基于索引排序后的质量甚至还不如MLDR数据集。包含20万篇文档数据，约2GB。使用Jina转换成数据后，高达320G。这是因为数据类型是保存一篇文档每个token对应的向量，模型的维度是128维。因此，默认数据量会扩大2个数量级。即使建了Index，查询这么多数据，平均也要7秒才能返回一条查询，但效果并不算好。
因此，显而易见的是，采用 的好处远高于 。目前最好的 RAG 检索方案是基于 3 路混合检索（全文检索 + 向量 + 稀疏向量）的。有小伙伴可能会问，为了采用它，需要增加一个单独的列，而且该列会比原始数据集扩大 2 个数量级，这值得吗？首先：它为它提供了一种量化的方法，结果对排序结果影响不大，但可以使最终数据只有原始大小的 1/32。其次，即便如此，也有人认为这样的开销过高。但是从用户的角度来看，使用更多的存储来换取更高的排序质量和更低的成本（排序过程中不需要 GPU），这非常值得。最后，我相信 Late 型号很快就会面世，性能略低，但存储开销要低得多。作为 Data Infra 基础设施，将这些变化透明化，将这些权衡利弊交给用户是明智的。
以上是基于MLDR数据集上的多路召回率评估，在其他数据集上的评估结果可能会有所不同，但整体的结论不会改变——3路混合搜索+重排序的依据是当前搜索中质量最高的召回率手段。
由此可见及其延迟交互模型在RAG场景下有着很大的应用价值。上面是文本对话内容生成的相关工作，最近延迟交互模型在多模态场景下也取得了SOTA的效果，这是[参考文献9]，它改变了RAG的工作流程如下图所示：
当面对复杂格式的文档时，目前的 SOTA 是先用文档识别模型识别文档的版式，然后针对识别出来的部分结构，比如图表、图片等，调用相应的模型转换成相应的文本，再以各种格式保存到 RAG 数据库中。但它省去了这些步骤，直接用多模态模型来生成内容，在提问的时候，直接看文档中的图表就可以回答：
模型训练与[10]类似，也是使用查询-文档页面对来捕捉查询和文档多模态数据之间的语义关联，但使用[10]来生成多模态数据。这两种方法具有相同的机制，但也使用生成的解决方案。nDCG@5中的评估指标对比为81.3 vs 58.8。这个差距就是“优秀”和“完全不起作用”之间的区别。
因此，虽然出现已经 4 年，但 Late 模型在 RAG 中的应用才刚刚开始，必将拓展 RAG 的使用场景，在包括多模态在内的复杂 RAG 场景中提供高质量的语义召回，为其端到端应用做好了准备，欢迎关注和 Star，我们致力于成为最好的 AI 原生数据库！
参考
1.：并通过 bert，SIGIR 2020。
2. ：并通过后期，arXiv：2112.01488，2021年。
3.
4. 带位的多密度，ECIR 2024。
5.
6.
7.
8.
9. ：与，arXiv：2407.01449，2024年。
10.
