LightRetriever：颠覆传统！千倍提速的LLM检索架构，将计算负担从查询侧彻底移除

传统的LLM Embedding模型通常采用对称式双塔结构，查询（Query）端和文档（Doc）端共享同一个完整的大语言模型。然而，一个长期被忽视的问题是：在线上推理场景中，查询端真的需要与文档端同等“重量级”的大模型吗？我们最新的研究论文LightRetriever给出了一个明确且激进的答案：不需要。大量实验证实了这一观点的可行性。

LightRetriever设计了一种极致的非对称结构LLM Embedding模型——文档侧使用完整的LLM进行建模，而查询侧最多仅使用一层Embedding查找表。这种极致的设计极大地降低了查询侧的推理负担，同时依然能保证高质量的大模型文本搜索效果。与查询端和文档端均使用完整LLM的标准设计相比，LightRetriever使查询侧的推理速度提升了千倍以上，端到端QPS提升了10倍，并且在BeIR、CMTEB-Retrieval等中英文检索测试集上，性能仍能维持在基准模型的95%左右。

该研究由中科院信工所与澜舟科技共同完成，已被国际顶级机器学习会议ICLR 2026接收。ICLR（International Conference on Learning Representations）是机器学习与表示学习领域的顶级会议之一，与NeurIPS、ICML并列为人工智能领域最具影响力的学术会议。本届ICLR 2026共收到近19000篇有效投稿，接收率约为28%。

• 论文标题：LightRetriever: A LLM-based Text Retrieval Architecture with Extremely Faster Query Inference
• 论文链接：https://arxiv.org/abs/2505.12260

LightRetriever：极致非对称的LLM Embedding模型

LightRetriever的核心思想非常明确：将深度建模的主要计算负担彻底转移到文档侧，查询侧仅保留必要且可缓存的表征能力。针对稠密检索和稀疏检索两大主流范式，LightRetriever分别设计了极致的非对称建模方法。

图：在稠密/稀疏检索中，对称式LLM Embedding模型（左）在查询侧使用标准的完整模型推理，负担沉重；LightRetriever（右）则大幅降低了查询推理成本，查询侧负载降至不超过一层Embedding查找表。

稠密检索（Dense Retrieval）
在训练阶段，文档侧保持原有的完整LLM建模方式不变。LightRetriever对查询侧进行了“词袋化”建模：完整的LLM接收“指令 + 单个查询词元（Token）”作为输入，首先建模词元嵌入（Token Embedding），然后通过求平均得到查询句向量，并借助对比学习获得优化的词元嵌入。

关键之处在于，这些训练完成的词元嵌入可以被整体缓存为一个词表级别的嵌入矩阵。在线推理时，查询句向量的生成仅需一次简单的词元嵌入查表与求均值操作，不再涉及任何LLM前向推理。由于查询侧在训练阶段仍需完整LLM参与建模，稠密检索遵循“训练全量，推理轻量”的设计思想。后续的消融实验证明，“训练全量”这一配置不可或缺。

图：LightRetriever的稠密检索设计遵循“训练全量+推理轻量”思想，通过词袋化查询侧建模，打破上下文依赖，使查询侧向量推理具备可缓存特性。仅需一次缓存，即可实现无需LLM的查询推理服务部署。

稀疏检索（Sparse Retrieval）
在稀疏检索中，LightRetriever的设计更为极致：查询侧被简化为词表空间上的“词元ID -> 词频”映射，完全移除了可学习的模型参数。

同样通过端到端对比学习，利用文档侧的完整LLM，学习类似SPLADE方法的基于词频（TF-based）的稀疏向量。

图：LightRetriever的稀疏检索设计更加极致，查询侧仅依靠词袋化的统计方法建模词频特征，以实现无需LLM的高效线上推理。

极端轻量化的查询，并未带来灾难性的性能损失

直觉上，移除查询侧的深度上下文建模会显著损害检索效果。然而，大规模实验结果给出了一个出乎意料的结论：

在BeIR（英文）与CMTEB-Retrieval（中文）等多任务文本检索基准上，相较于完整的对称式LLM Embedding模型，LightRetriever的nDCG@10排序指标仅下降1–5个百分点，平均性能保持率约为95%。更重要的是，该方法的性能水平大幅超越了传统稀疏方法（如BM25、SPLADE）以及多种轻量化或蒸馏检索模型，并逼近了在类似开源训练语料配置下，LLM2Vec、E5-Mistral等经典LLM Embedding方法的性能。

这表明：在绝大多数以相关性为导向的检索任务中，查询侧并不需要完整的深度词元交互，也能够匹配文档侧所学习到的语义结构。

表：BeIR / CMTEB-Retrieval主实验结果，包含经典Embedding模型基线、对称式完整LLM检索器与LightRetriever的检索效果对比。

文章进一步对比了LightRetriever在不同任务中的细粒度性能表现。以BeIR为例，LightRetriever在大多数常规相关性检索任务中表现优异，性能达到全对称式结构的93%以上；在领域特定问答、实体检索、引文预测等更具挑战性的分布外（OOD）任务中，性能维持在87%～89%。虽然相对性能略有下降，但这些任务的绝对性能数值仍然具备较强的竞争力。

表：在BeIR的不同任务中，LightRetriever的性能表现及相对基准模型的性能保持率（Retention）。

查询服务速度大幅提升

LightRetriever的查询轻量化设计，为推理效率带来了数量级的提升。

在MSMARCO检索场景下对64k条查询进行编码，完整的Llama-8B模型需要超过100秒；而LightRetriever的查询编码时间仅为0.04秒，实现了超过1000倍的编码加速。即使考虑Faiss（稠密检索）与Lucene（稀疏检索）的索引检索时间，端到端吞吐量（QPS）仍然获得了10倍以上的提升。文章还尝试了一个经典的Transformer层裁剪基线：在查询侧仅使用Llama-8B的第一层Transformer进行训练和推理。然而，该设置的检索性能和QPS均不及LightRetriever，因为训练时查询侧缺乏完整的LLM建模。这证明了“训练全量+推理轻量”设计思路的合理性。

表：查询编码时间与端到端QPS对比。

为什么“训练全量 + 推理轻量”的设计是必要的，而非偶然有效？

在 LightRetriever 的稠密检索架构中，查询（Query）侧在训练时采用全量建模，而在推理时则转化为高效的嵌入层（Embedding Layer）。为了验证这种设计的合理性，研究进行了以下两组消融实验：

A1) 文档（Doc）侧在推理时也使用嵌入层。
A2) 查询（Query）侧在训练时直接使用嵌入层。

两项实验均导致了检索性能的大幅下降。这表明，在大模型文本检索中，简单地移除深度建模并非可行方案。

消融实验一（A1）证明：文档侧始终需要完整的建模过程，而查询侧则可以通过词袋化方法实现近似建模。

消融实验二（A2）证明：LightRetriever 的关键创新不在于“减少建模”，而在于将建模负载重新分配至不同阶段——在训练阶段与文档侧共同进行充分建模，在推理阶段则最大化复用可缓存的查询词向量，从而实现“训练全量，推理轻量”。

从这个角度看，LightRetriever 并非仅仅是对模型结构的微调，而是对大型语言模型双塔检索计算范式的一次根本性重新审视。

表：对称性消融实验结果。A1) 文档侧推理时进行词袋轻量化；A2) 查询侧训练时直接使用嵌入词袋。两者均导致效果显著下降。

结语：当查询侧部署不再是负担，LLM检索才真正具备可扩展性

LightRetriever 表明，高质量的 LLM 嵌入模型并不必然伴随高昂的在线推理成本。通过明确区分查询与文档在检索流程中的角色，并有意识地打破“对称建模”这一长期默认的设计假设，检索系统可以在维持效果的前提下，实现数量级的效率提升。

对于面向真实应用场景的检索系统、RAG 框架与在线搜索服务而言，这种查询轻量化的建模思路，或许比单纯追求更大的模型规模更具实际应用价值。

关注“鲸栖”小程序，掌握最新AI资讯