Jina AI将LLM Reranker延迟打下来了：21秒变3秒！

继

之后，Jina AI又开源了。这是一个基于大语言模型的新颖重排序器，专门用来做高效的列表式段落重排。简单说，它把文本编码成特殊标记再塞给LLM，而不是一股脑把原始文本丢进上下文窗口。

为什么PE-Rank值得关注

说到用大语言模型来做重排序，到底看中了它哪几点？很明显：灵活指令适配新任务、强悍的零样本能力，还有上下文推理带来的信息整合。这些优势让LLM重排序一度看起来是检索增强的不二之选。

那为什么在实际应用中，大家又迟迟不敢这么干呢？问题出在几个硬伤上。

• 上下文长度
  ：比如要重排100个文档，每个文档1000个token，LLM的上下文窗口立刻就被撑到10万token以上。不是所有模型都扛得住。

• 大海捞针效应
  ：信息在超长上下文中被稀释，排在中间的关键内容很容易被模型忽略，性能跟着大幅波动。

• 提示注入风险
  ：查询和指令被候选文档覆盖、干扰，输出的可靠性打折扣。

• 输出格式不稳定
  ：想让LLM老老实实输出“d1 > d3 > d2 > d7”这种排序结果，并不容易。语法错误、信息冗余、格式混乱，样样都可能出现。

这些问题凑在一起，LLM重排序在高延迟、低稳定性的场景里，始终难以落地。

PE-Rank的核心思路

PE-Rank的解决方案很直接：用嵌入模型把每个段落编码成一个特殊标记，代替原始文本输入给LLM。这样一来，LLM的输入变成了“指令 + 查询 + 一串段落嵌入标记”，上下文窗口的压力瞬间释放。

这种思路和软提示（soft prompt）有点像，但有一个关键差异：外部嵌入模型（比如Jina或BGE）生成的向量，和LLM自己的标记嵌入不在同一个空间里。为了弥合这个差距，PE-Rank冻结了嵌入模型和LLM，只训练了一个双层的多层感知器（MLP）来做空间映射。这层映射的代价极低，却能让两个世界顺畅沟通。

：(a) 检索阶段，获取 n 个段落的嵌入；(b) LLM 的前向传递过程；(c) 列表式解码。

到这里就有一个自然的问题：怎么微调LLM？标准的有监督微调（SFT）能行吗？实际上不太行——因为LLM的输出空间被限制在特殊的段落嵌入标记上，传统的SFT无法直接应用。PE-Rank的解决方案是组合两种损失函数：

，用来最大化生成下一个最相关段落标记的概率；以及，进一步基于原始内容进行条件化。这套组合拳，让模型学会了在嵌入空间中完成元素之间真正的排序推理。

效果评测：三个关键结论

用Mistral-7B-Instruct-v0.2作为骨干LLM，搭配Jina-embeddings-v2或BGE-v1.5做外部嵌入，PE-Rank得到了一个非常有意思的结果：性能与直接将原始文档喂给GPT-4（即RankGPT4）相当，但延迟只有后者的六分之一——

。如果只重排前20个候选项，单个查询的延迟还能进一步压到，这对线上场景来说已是相当实用的水平。

另一个值得注意的点是：无论底层的检索器是BM25、Jina还是BGE，PE-Rank都能稳定地提升它们的性能。有趣的是，尽管BGE在MTEB上的表现比Jina更亮眼，但当用它来重排BM25的检索结果时，三个不同数据集上的表现却始终低于Jina嵌入。这个现象说明了一个容易被忽视的道理：

。至少从目前的结果看，Jina嵌入在这个特定的任务上表现出更好的扩展性。

参考链接：  
https://github.com/liuqi6777/pe_rank  
https://arxiv.org/pdf/2406.14848  
Leveraging Passage Embeddings for Efficient Listwise Reranking with Large Language Models