LightRetriever: A LLM-based Text Retrieval Architecture with Extremely Faster Query Inference¶

会议: ICLR 2026
arXiv: 2505.12260
代码: GitHub
领域: 信息检索
关键词: LLM检索, 不对称编码器, 极速查询推理, 混合检索, 嵌入缓存

一句话总结¶

提出 LightRetriever，一种极端不对称的LLM检索架构：文档端保留完整LLM编码器，查询端完全去除深度建模——稠密检索仅需嵌入查表+平均，稀疏检索仅需token计数——实现查询编码1000倍加速、端到端10倍吞吐提升，同时保持95%的检索性能。

LLM-based检索器（如E5-Mistral、LLM2Vec）使用对称双编码器架构，文档和查询共享同一LLM编码器。文档可离线预计算，但查询必须在线编码，部署深度LLM作为查询编码器面临：

吞吐瓶颈: 全尺寸LLM编码65K查询需要100+秒

资源消耗: 需要GPU加速器在线服务

延迟敏感: 实时搜索对延迟有严格要求

关键洞察是：文档受益于LLM的完整建模能力（捕获丰富上下文语义），但查询是否真的需要同等深度的建模？BM25基于词法匹配几乎零推理成本但仍有竞争力。这说明查询理解的计算可以大幅简化。

核心idea：打破查询-文档编码器的对称性——查询端完全移除深度模型，训练时让各token独立通过LLM，然后缓存每个token的嵌入，推理时用查表+平均替代整个前向传播。

LightRetriever = 稠密检索（缓存token嵌入 + 平均池化）+ 稀疏检索（无编码器的词频向量），两者分数线性插值得到最终混合检索分数。

稠密检索：可缓存的token嵌入:
- 训练阶段：任务指令 + 单个查询token 独立输入LLM编码器，通过last token pooling获得token向量 \(v_{t_i}^{\text{den}} = Enc_q(Inst; t_i)\)，查询向量为所有token向量的平均 \(v_q^{\text{den}} = \frac{1}{n}\sum v_{t_i}^{\text{den}}\)
- 缓存阶段：预计算整个词表所有token的嵌入，存入查找表 \(E \in \mathbb{R}^{V \times H}\)。用Llama-8b在8×H800上缓存不到20秒
- 在线服务：\(v_q^{\text{den}} = \frac{1}{n}\sum E[t_i]\)，仅需嵌入查找+平均，无需GPU
- 设计动机：token独立编码时嵌入可缓存，去除token间交互是关键取舍
稀疏检索：无编码器的查询:
- 查询向量：直接用token计数 \(v_q^{\text{spr}}[t] = \text{count}(t)\)，完全不需编码器
- 文档向量：LLM最后一层隐状态通过语言模型头投影到词表空间，经ReLU + log饱和函数 + max pooling得到稀疏向量 \(v_d^{\text{spr}} = \max(\ln(\max(h_{\text{last}} \cdot P, 0) + 1))\)
- 用 FLOPs regulator 控制文档向量稀疏度
- 设计动机：稀疏检索天然不依赖深度查询理解，直接用词频即可
对比学习训练:
- 标准listwise对比损失 \(\ell^{CL} = -\log \frac{e^{v_q \cdot v_{d^+}/\tau}}{\sum e^{v_q \cdot v_d/\tau}}\)
- 稠密和稀疏分别训练，推理时线性插值得分

模型	BeIR(nDCG@10)	CMTEB-R	编码时间(s)	总时间(s)	QPS
Full-Llama8b	56.8	67.6	109.49	119.37	549
Full-Llama3b	55.6	66.1	52.59	62.42	1050
Llama8b首层	52.5	59.0	2.34	-	-
LightRetriever-Llama8b	54.0	63.8	0.04	10.08	6500
Static Embedding	44.9	49.1	0.04	-	-
BM25	42.0	53.4	0	-	-

配置	BeIR	CMTEB-R	说明
仅稠密	~50	~60	无稀疏补充
仅稀疏	~42	~53	类似BM25水平
混合（默认）	54.0	63.8	最佳性价比
全LLM编码器	56.8	67.6	性能上限
维度截断	~53	~62	可进一步压缩嵌入大小