微信扫一扫,关注公众号

  • 科技行者

  • 算力行者

见证连接与计算的「力量」

首页 哈工大深圳分校造出"既快又准"的AI搜索排序器,效率最高提升200倍!

哈工大深圳分校造出"既快又准"的AI搜索排序器,效率最高提升200倍!

2026-06-25 10:38
分享至:
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-
2026-06-25 10:38 科技行者

这项由哈尔滨工业大学(深圳)与深圳湾区研究院联合开展的研究,以预印本形式于2026年6月22日公开发布,论文编号为arXiv:2606.22807,感兴趣的读者可通过该编号查询完整原文。

每当你在网上搜索问题,背后其实有两个"工人"在悄悄合作:第一个工人叫"检索器",它负责从海量网页中飞速捞出一百个可能相关的结果;第二个工人叫"重排序器",它接过这一百个结果,仔细审读每一篇,重新排列顺序,把真正有用的推到最前面。这篇文章的主角,就是第二个工人——重排序器。

问题在于,现有的重排序器有一个根深蒂固的毛病:每次来了一个新问题,它就必须把问题和每一篇候选文章重新配对,从头读一遍,才能判断相关性。以一百篇候选文章为例,这意味着重排序器要做一百次完整的"阅读理解"。这就好比图书馆的管理员每次接到一个读者的问题,都要把仓库里预选的一百本书全部重新翻阅一遍,哪怕这些书昨天已经整理过了。效率之低,在大规模系统里会造成相当可观的计算开销。

哈工大深圳分校的研究团队针对这个痛点,提出了一种他们称之为"快速但非后期交互"(Fast but Not Late-Interaction,简称FBNL)的全新重排序器,取名为KaLM-Reranker-V1。这个名字听起来很学术,但核心思路其实非常直觉化:既然文章内容是固定的,为什么不提前把每篇文章"读完"并记录下来,等问题来了,只需要把问题和已经记录好的文章内容比对就好?这样一来,大量的"阅读"工作可以提前在服务器闲置时完成,真正到了用户发问的时刻,系统需要做的计算量就大幅缩小了。

研究团队将KaLM-Reranker-V1设计成了三个不同体量的版本,分别命名为Nano、Small和Large,对应的激活参数量分别约为2.7亿、10亿和40亿。这三个版本可以满足不同场景下的性能与成本需求,就像同一款发动机有入门版、标准版和旗舰版之分。

一、为什么现有的重排序器会"浪费力气"

要理解KaLM-Reranker-V1的突破,先得搞清楚现有重排序器的工作模式到底"浪费"在哪里。

主流的重排序器可以大致分成两类。一类是"编码器型",以BERT这类模型为代表,它把用户问题和候选文章拼接在一起,让模型从头到尾读一遍,输出一个相关性分数。另一类是"解码器型",以目前流行的大语言模型(LLM)为基础,同样需要把问题和文章合并输入,一起处理。这两类模型的共同点是:每当问题变化,所有候选文章都必须被重新计算,因为文章的"理解"是和问题绑定在一起的,无法单独储存复用。

还有第三种思路,叫做"后期交互"(Late Interaction),以ColBERT模型为代表。这种方法把问题和文章分开编码,各自生成一组向量,最后用相似度计算来打分,相当于先把书的每一页都拍成照片存起来,问题来了再拿着问题的照片去逐页比对。这种方式确实可以提前存储文章的表示,但问题是,比对的方式过于简单——仅仅是计算向量相似度——无法捕捉问题和文章之间更复杂、更深层的语义关联。

KaLM-Reranker-V1的目标,正是在这两种方案之间找到一条新路:既能提前存储文章表示(获得效率),又能在打分时进行深入的语义交互(保留准确性)。

二、编码器负责"读书",解码器负责"答题"

KaLM-Reranker-V1采用了一种被称为"编码器-解码器"的架构。这种架构可以理解为两个专业分工明确的员工在流水线上配合工作。

编码器这位员工专门负责阅读文章。给它一篇文档,它就把这篇文档"消化"成一组紧凑的数字向量,代表着文章的语义信息。关键在于,这个"消化"过程只需要做一次,结果可以保存起来,供之后的任何问题反复使用。就像一个速记员把一本书整理成详尽的读书笔记,之后读者直接看笔记就够了,不用再把原书翻一遍。

解码器这位员工则专门负责"答题"。它接收的是用户的问题(以及系统给出的指令说明),然后通过一种叫做"交叉注意力"(cross-attention)的机制,把自己对问题的理解和编码器之前存好的文章表示做深度对照,最终判断这篇文章和问题的相关程度。

这里有个技术细节值得展开说说。解码器在做这种"对照"时,不只是简单地算一个相似度分数,而是让问题的每一个词、每一个语义片段都和文章的内容做充分的交互。最终,模型会在两个特定的词——"yes"(相关)和"no"(不相关)——上给出概率预测,用这两个概率的比值来计算最终的相关性得分。这种打分方式既直接又有效,能够灵活适应不同任务的需求。

这个架构还有一个有趣的设计:模型支持"任务指令"输入。也就是说,你可以告诉系统"现在的任务是找反驳某个论点的文章"或者"现在要找回答金融问题的段落",解码器会根据这个指令调整自己的判断标准。这让模型在不同检索场景下都能发挥出较好的性能。

整个模型基于谷歌提出的T5Gemma2基础模型搭建而成,三个版本的编码器和解码器参数量相当,大约各占一半。在实际服务时,解码器在线运行,编码器则只负责离线预处理文章,不参与实时计算。

三、文章表示的"压缩黑科技":用更少的存储,保住大部分性能

提前存储文章的表示虽然省了计算时间,却带来了另一个问题:存储空间的压力。

一篇文章经过编码器处理后,会生成一个由很多向量组成的矩阵,向量数量等于文章的词元(token)数量。如果一篇文章有512个词元,对应的向量矩阵就有512行。当语料库规模达到数百万甚至数十亿篇文章时,存储这些向量需要极其庞大的内存,成本非常可观。

为了解决这个问题,研究团队引入了一种他们称之为"Matryoshka嵌入池化"(Matryoshka Embedding Pooling,简称MEP)的压缩技术。这个名字来源于俄罗斯套娃(Matryoshka),暗示着不同层次的压缩都能嵌套在同一个模型中支持。

MEP的工作原理其实相当直观。以压缩比为4为例,模型会把文章向量矩阵中每连续4行(即4个词元的表示)合并成1行,做法是取这4行向量的平均值。这样一来,原本需要512行存储的文章,只需要128行就够了,存储空间节省了75%。压缩比可以从2倍一直设到32倍,灵活程度很高。

当然,压缩越多,信息损失也越大,重排序的性能会有所下滑。研究团队在训练时同时针对多个压缩比进行优化,让模型学会在被"压缩"的表示下依然尽可能准确地打分。训练时使用的压缩比集合为2倍、4倍、8倍和16倍(32倍在训练时因为内存限制没有包含进去,但测试时可以用)。

实验结果显示,在压缩比为2倍到8倍的范围内,性能下降非常有限,几乎可以忽略不计。压缩比达到16倍时,性能开始有较明显的滑落;到32倍时,由于该设置未在训练中出现,性能下降幅度进一步加大。研究团队建议在实际部署时优先选择4倍或8倍压缩,这是在性能和存储成本之间取得平衡的甜蜜点。

四、三阶段训练:从泛化基础到精细调优

KaLM-Reranker-V1的训练过程被设计成三个递进的阶段,就像一个学生从打基础、学专业课、到精研难题的成长历程。

第一阶段是"通用重排序能力学习"。在这个阶段,模型不接收任何任务指令,只根据问题和文章本身的内容来学习判断相关性。这个阶段的目标是让模型建立起对"相关"和"不相关"的基本感知,不受特定任务偏见的干扰,就像先学会阅读理解的通用能力,再去做各科的专项练习。

第二阶段是"任务专项适配"。这时候,训练数据引入了针对不同检索任务的专属指令,比如"给定一个观点,找反驳它的文章",或者"给定一个医学问题,找最相关的研究论文"。模型学会根据不同的任务描述调整自己的评判标准,变得更加灵活实用。这个阶段使用的数据质量也更高,经过了更严格的筛选和处理。

第三阶段是"细粒度相关性蒸馏"。这是最精妙的一步。研究团队用KaLM-Reranker-V1-Large这个最强版本作为"老师",让它对每个训练样本打出一个介于0到1之间的连续分数(而不是简单的"是"或"否")。Nano和Small版本作为"学生",学习模仿老师打出的分数分布。

这种"知识蒸馏"训练方式的好处在于,连续分数比"是/否"的硬标签保留了更丰富的相关性细节。比如两篇文章可能都被标记为"相关",但一篇和问题的关联非常紧密,另一篇只是间接相关,老师打出的分数就能体现这种差异,帮助学生模型学到更细腻的判断能力。Large版本只经历前两个阶段,因为它本身就是蒸馏过程中的老师。

训练数据方面,整体数据量约为370万条训练样本,来源于KaLM嵌入模型的检索数据集和BGE-M3的训练数据。针对只有正样本(相关文章)的数据集,研究团队还专门做了"难负样本挖掘":用KaLM-Embedding-V2.5检索器从语料库中捞出前100名候选文章,然后从排名第10到第50之间随机选取16篇作为负样本。这个策略的考量是:排名前10的文章可能包含真正相关但未被标注的文章(假阴性风险高),排名50之后的文章太容易区分(学习价值低),10到50之间是最具挑战性、最有训练价值的"困难区域"。

五、效率究竟提升了多少?一组让人印象深刻的数字

研究团队对KaLM-Reranker-V1的计算效率进行了严格的理论分析,并与传统重排序器做了对比。

传统的编码器型或解码器型重排序器,对K篇候选文章进行重排序时,计算量与K乘以"问题长度加文章长度的平方"大体成正比。也就是说,文章越长,每篇文章的计算代价增长是平方级别的,成本极高。

KaLM-Reranker-V1的在线计算量则主要由解码器承担,而且由于编码器部分已经离线完成,在线部分相当于只用了一半参数量的模型来处理问题侧。加上MEP压缩了文章表示的长度(假设压缩比为r,文章有效长度从n缩减到n/r),整体计算量大幅降低。

具体数字方面,当文章长度为256词元、压缩比为16时,KaLM-Reranker-V1相比同等规模的传统重排序器有约16.6倍的效率提升。当文章长度增加到4096词元时,这个倍数急剧攀升到203.4倍。这种巨大的差异来源于平方关系的放大效应——文章越长,传统方法的代价越高,而KaLM-Reranker-V1的优势越明显。

即便在较低的压缩比(比如仅压缩2倍)下,效率也能提升近10倍。将压缩比提高到4倍和8倍时,效率提升分别达到18.5倍和33.3倍。

在实验评估时,研究团队统一用KaLM-Reranker-V1-Nano的在线计算成本作为基准(1倍),然后换算出其他所有模型的相对成本。举几个具体的例子:KaLM-Reranker-V1-Small的相对成本约为6.9倍,而同样大约0.6B参数的Qwen3-Reranker-0.6B的相对成本高达42.4倍;KaLM-Reranker-V1-Large的相对成本约为43.7倍,而2.5B参数的bge-reranker-v2-gemma高达81.3倍,8B参数的Qwen3-Reranker-8B更是高达539.7倍。

存储空间方面,MEP的引入也实现了近线性比例的压缩。以压缩比r处理N篇文章为例,存储总量从原始的"N乘以文章长度乘以向量维度",降低为"N乘以文章长度除以r乘以向量维度",直接按压缩比等比例减少。

六、在三个评测基准上的表现:与业界最强对手同台竞技

研究团队在三个代表性评测基准上测试了KaLM-Reranker-V1:专注英文多领域检索的BEIR、覆盖18种语言的多语言基准MIRACL,以及面向长对话记忆检索的LMEB。所有测试都采用相同的两阶段流程:先用KaLM-Embedding-V2.5检索器捞出前100名候选文章,再由各重排序器重新排序,评价指标为nDCG@10(越高越好)。

在BEIR基准上,BEIR包含13个不同领域的英文检索任务,从问答到事实核查到学术论文检索,覆盖面很广。KaLM-Reranker-V1-Nano(0.27B参数)在13个任务中有9个取得了本参数组的最佳或次佳成绩,平均分为57.41;KaLM-Reranker-V1-Small(1B参数)在8个任务中居前两位,平均分60.01,且计算成本仅为6.9倍,而同类参数规模的Qwen3-Reranker-0.6B(0.6B参数)计算成本高达42.4倍但平均分只有59.36;KaLM-Reranker-V1-Large(4B参数)在11个任务中居前两位,平均分62.87,而使用近2倍计算成本的Qwen3-Reranker-4B(4B参数)平均分为63.50,差距非常小。值得一提的是,KaLM-Reranker-V1系列总共只用了370万条训练样本,而Qwen3-Reranker系列使用了1900万条高质量数据,数据量相差超过5倍,但性能已基本持平,这说明FBNL架构本身的效率相当高。

在MIRACL基准上,由于KaLM-Reranker-V1主要用中文和英文数据训练,多语言能力并非其专项优势,研究团队为公平起见,排除了那些专门用大量多语言数据训练的模型再做对比。即便如此,KaLM-Reranker-V1-Large仍以70.07的平均分超越了2.5B参数的bge-reranker-v2-gemma(平均分69.82),同时计算效率提升近2倍。KaLM-Reranker-V1-Nano以仅1倍的计算成本获得62.08的平均分,而计算成本高达36.3倍的bge-reranker-large只得到52.52分,差距显著。不过,在中文语言子集上,KaLM-Reranker-V1表现相对较弱,研究团队坦承这可能是基础模型在中文处理能力上的瓶颈,并计划在后续版本中改进。

在LMEB基准上,LMEB专注于长对话记忆检索,模拟的是AI助手需要从大量历史对话记录中准确找回特定信息的场景。结果显示,重排序模型在这个任务上的提升幅度远超BEIR:KaLM-Reranker-V1-Small相比第一阶段检索器的nDCG@10提升高达12.35分,而在BEIR上的提升只有6.23分。这说明记忆检索任务对重排序的依赖程度更高,需要更深层的语义理解。

一个特别引人注目的发现是,0.5B参数的KaLM-Embedding-V2.5检索器加上0.27B参数的KaLM-Reranker-V1-Nano重排序器,总参数不过0.77B,却以61.39分的平均分超越了9B参数的bge-multilingual-gemma纯嵌入模型(59.60分)。这个对比有力地说明了"检索+重排序"的两阶段流水线比单纯堆大嵌入模型更有性价比。

七、压缩比与性能之间的"权衡曲线":量化你的牺牲

研究团队专门做了详细的消融实验,量化了不同压缩比下性能的变化情况。

在BEIR基准上,以KaLM-Reranker-V1-Nano为例:压缩比从2倍到4倍,平均分从57.69小幅下降到57.41,跌幅几乎可以忽略;从4倍到8倍,降到56.46;从8倍到16倍,降到55.19;从16倍到32倍,出现较明显的跌落,降到52.88。这种"先平稳后急落"的模式在三个模型版本中都能观察到。

更大的模型在高压缩比下展现出更强的韧性。以压缩比为32倍时KaLM-Reranker-V1-Large的平均分60.33为例,它仍然高于KaLM-Reranker-V1-Nano在压缩比为2倍时的57.69。这说明更大的模型具备更强的"从不完整信息中恢复语义"的能力,就像一个经验丰富的读者,即便读书笔记写得简略,也能通过上下文推断出原书的意思。

为了更深入地理解压缩对性能的影响机制,研究团队还绘制了ROC曲线(接收者操作特征曲线),并计算了AUC值(曲线下面积)。AUC衡量的是重排序器将相关文章与不相关文章区分开来的能力,与具体的排名截止位置无关,是一个更本质的能力指标。

实验结果显示,在FiQA、Natural Questions和MIRACL英文子集这三个任务上,当压缩比从2倍升至8倍时,AUC值保持相对稳定;但从16倍开始,AUC值出现较明显的下降,且小模型下降幅度更大。以FiQA任务为例,KaLM-Reranker-V1-Nano的AUC从压缩比2倍时的0.871降到32倍时的0.832,而KaLM-Reranker-V1-Large同期仅从0.952降到0.948,差距悬殊。这再次印证了大模型对压缩更具鲁棒性的结论,也说明中等程度的压缩并不显著损害模型区分相关和不相关内容的本质能力。

说到底,KaLM-Reranker-V1解决的是一个非常实在的工程问题:如何在不牺牲太多检索质量的前提下,让重排序器跑得更快、占的资源更少。它的答案是把"读文章"和"答题"两件事拆开来做,文章可以提前读完存好,题目来了只需要拿着"读书笔记"比对就行。配合上弹性压缩笔记长度的MEP技术,整套系统在不同规模的应用场景下都能找到合适的性价比定点。

这项研究对普通用户的实际意义在于:搜索引擎、智能客服、AI助手、法律/医疗文档检索等需要"从大量文本中找最相关答案"的应用,在采用类似架构之后,响应速度可以大幅提升,或者在相同计算预算下部署更大、更准确的模型。当AI助手开始需要记住你数月乃至数年的对话历史(就像LMEB测试的场景),高效的重排序能力将变得更加关键。

一个值得继续思考的问题是:随着文章越来越长(比如整本书、整份合同),压缩表示的信息损失问题会不会成为新的瓶颈?研究团队也坦承,开发在高压缩比下依然能保留关键信息的更聪明压缩方法,是未来工作的重要方向。有兴趣深入了解技术细节的读者,可以通过arXiv编号2606.22807查阅完整论文。

Q&A

Q1:KaLM-Reranker-V1和普通重排序器的核心区别是什么?

A:普通重排序器每来一个问题,都要把问题和每篇候选文章重新配对计算,文章被反复处理。KaLM-Reranker-V1则提前把所有文章"读完"存好,问题来了只需要用轻量的解码器把问题和存好的文章表示做对比,大幅减少了实时计算量,在长文章场景下效率提升可超过200倍。

Q2:Matryoshka嵌入池化(MEP)压缩文章表示会损失多少性能?

A:实验显示压缩比在2到8倍范围内,BEIR基准上性能下降非常有限,几乎可以忽略。压缩到16倍时开始有较明显的性能滑落,32倍时跌幅更大,尤其对小模型影响更显著。研究团队建议实际部署优先选择4到8倍压缩,这是存储效率与检索质量之间最划算的平衡点。

Q3:KaLM-Reranker-V1-Nano那么小,真的比大型嵌入模型还好用吗?

A:在LMEB长对话记忆检索任务上,0.5B检索器加0.27B的KaLM-Reranker-V1-Nano组合,总参数仅0.77B,却超越了9B参数的bge-multilingual-gemma纯嵌入模型。这说明"小检索器+小重排序器"的两阶段流水线,性价比往往高于单纯堆大嵌入模型。

分享至
1赞

好文章,需要你的鼓励

推荐文章
----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.- ----..---.-...-/--...-.-......./-...-....-..--../-............-.-